Concept: Stratégie de test
Ces instructions décrivent le développement d'une stratégie de test dont l'objectif est de décrire l'approche générale et les objectifs des tâches de test.
Relations
Description principale

Une stratégie pour la partie test d'un projet décrit l'approche générale et les objectifs des tâches de test. Elle comprend ces étapes de test (unité, intégration, et système) à aborder et les genres de tests (fonction, performance, charge, contrainte) à réaliser.

La stratégie définit :

  • Les techniques et outils de test à utiliser.
  • Quels seront les critères d'achèvement et de réussite du test utilisés. Par exemple, les critères peuvent permettre au logiciel de passer au test de réception si 95% des cas de test ont été réalisés avec succès. Un autre critère est la couverture du code. Ce critère peut, sans un système où la sécurité est critique, être une couverture à 100% du code par des tests.
  • Des considérations particulières affectent les exigences en matière de ressource ou ont des implications sur le calendrier comme :
  • test de toutes les interfaces sur des systèmes externes
  • simulation de dommages physiques ou de menace sécuritaire

Certaines organisations ont défini des stratégies de test d'entreprise. De ce cas, vous devez appliquer ces stratégies à votre projet spécifique.

Les dimensions les plus importantes autour desquelles vous devez planifier vos tâches de test sont :

  • Dans quelle itération êtes-vous et quels sont les objectifs de cette itération ?
  • Quelle étape du test (test d'unité, test d'intégration, test système) êtes-vous en train de réaliser? Vous pouvez travailler toutes les étapes du test dans une itération.

Examinez maintenant comment les caractéristiques de vos tâches de test peuvent changer en fonction de là où vous vous trouvez dans les dimensions de test précédemment citées. Il y a beaucoup de caractéristiques que vous pouvez examiner, comme les ressources nécessaires et le temps passé, mais, à ce point, concentrez-vous sur ce qui est important pour définir votre stratégie de test comme :

  • types de test (fonctionnels, contrainte, volume, performance, facilité d'utilisation, distribution, etc.)
  • critères d'évaluation utilisés (couverture de test basée sur le code, couverture de test basée sur les exigences, nombre d'anomalies, temps moyen entre les pannes, etc.)
  • techniques de test employées (manuel ou automatisé)

Il n'y a pas de modèle général sur comment les types de tests sont distribués sur les cycles de test. Vous vous concentrez sur différents types de tests en fonction du nombre d'itérations, de la taille de l'itération, et du type de projet que vous testez.

Vous trouverez que l'étape de test système est fortement axée sur la garantie que vous couvrez toutes les exigences testables exprimées en termes d'ensemble de cas de test. Cela signifie que vos critères d'achèvement seront axés sur une couverture de test basée sur les exigences. Dans les étapes de test d'intégration et unitaire, vous trouverez que la couverture de test basée sur le code est un critère d'achèvement plus approprié. La figure suivante montre comment l'utilisation de ces deux types de mesures de couverture de test peut changer au fur et à mesure que vous développez de nouvelles itérations de votre logiciel.

  • Le plan de test doit définir des ensembles de critères d'achèvement pour les tests d'unité, d'intégration et système.
  • Vous pouvez avoir différents ensembles de critères d'achèvement définis pour des itérations individuelles.

Image des exigences et des domaines basés sur le code d'un tableau de test

Dans votre projet, envisagez d'automatiser vos tests autant que possible, notamment le genre de tests que vous répétez plusieurs fois (tests de régression). Gardez à l'esprit que la création et la maintenance de tests automatisés nécessitent du temps et des ressources. Chaque projet comportera toujours un certain nombre de tests manuels. La figure suivante illustre quand et à quelles étapes du test vous réaliserez probablement des tests manuels.

Image d'un tableau de test avec domaines de test manuel entourés

Exemple

Les tableaux suivants montrent quand les différents types de tests sont identifiés et fournissent un exemple de critères d'achèvement à définir. Le premier tableau illustre un projet MIS "typique".

Test d'itération Test système Test d'intégration Test d'unité
Itération 1 Test de performance automatisé pour tous les cas d'utilisation.
· Tous les tests prévus ont été exécutés.
· Toutes les anomalies de gravité 1 ont été traitées.
· Tous les tests prévus ont été ré-exécutés et aucune nouvelle anomalie de gravité 1 n'a été identifiée.
Aucun Tests informels
Itération 2 Tests de performance et de fonctionnalité automatisés pour tous les nouveaux cas d'utilisation et les précédents en tant que test de régression.
· Tous les tests prévus ont été exécutés.
· Toutes les anomalies de gravité 1 et 2 ont été traitées.
· Tous les tests prévus ont été ré-exécutés et aucune nouvelle anomalie de gravité 1 ou 2 n'a été identifiée.
Aucun Tests informels
Itération 3 Tests de fonctionnalité et négatifs automatisés pour tous les nouveaux cas d'utilisation, et tous les précédents en tant que test de régression ; 95% des cas de test ont réussi.
· Tous les tests prévus ont été exécutés.
· Toutes les anomalies de gravité 1, 2 et 3 ont été identifiées.
Test automatisé, 70% du code couvert. Tests informels
Itération 4 Tests de fonctionnalité et négatifs automatisés pour tous les cas d'utilisation, tests manuels pour toutes les parties non automatisées, et tous les précédents en tant que test de régression. 100% des cas de test ont réussi.
· Tous les tests prévus ont été exécutés.
· Toutes les anomalies de gravité 1, 2, et 3 ont été traitées.
· Tous les tests prévus ont été ré-exécutés et aucune nouvelle anomalie de gravité 1 ou 2 n'a été identifiée.
Test automatisé, 80% du code couvert. Tests informels

Le deuxième tableau illustre les types de test et les critères d'achèvement appliqués pour un système typique dans lequel la sécurité est critique.

Test d'itération Test système Test d'intégration Test d'unité
Itération 1 Tests de performance automatisés pour tous les cas d'utilisation ; couverture de 100% des cas de test.
· Tous les tests prévus ont été exécutés.
· Toutes les anomalies de gravité 1 ont été traitées.
· Tous les tests prévus ont été ré-exécutés et aucune nouvelle anomalie n'a été identifiée.
Aucun Aucun
Itération 2 Tests de performance, de fonctionnalité et négatifs automatisés pour tous les cas d'utilisation ; couverture de 100% des cas de test.
· Tous les tests prévus ont été exécutés.
· Toutes les anomalies de gravité 1 ou 2 ont été traitées.
· Tous les tests prévus ont été ré-exécutés et aucune nouvelle anomalie n'a été identifiée.
Test de performance automatisé. Tests informels
Itération 3 Tests de performance, de fonctionnalité et de facilité d'utilisation négatifs, et de documentation automatisés pour tous les cas d'utilisation ; couverture de 100% des cas de test.
· Tous les tests prévus ont été exécutés.
· Toutes les anomalies de gravité 1, 2, et 3 ont été traitées.
· Tous les tests prévus ont été ré-exécutés et aucune nouvelle anomalie n'a été identifiée.
Tests de performance automatisés et les précédents sous forme de test de régression. Test automatisé, couverture de 70% du code.
Itération 4 Tests de performance, de fonctionnalité et de facilité d'utilisation négatifs, et de documentation automatisés pour tous les cas d'utilisation ; couverture de 100% des cas de test.
· Tous les tests prévus ont été exécutés.
· Toutes les anomalies de gravité 1, 2, et 3 ont été traitées.
· Tous les tests prévus ont été ré-exécutés et aucune anomalie n'a été identifiée.
Tests de performance automatisés et les précédents sous forme de tests de régression. Test automatisé, couverture de 80% du code.