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.
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.
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.
|
|