Syllabus CFTL

4. Techniques de conception des tests (K3)

4.1 Le processus de développement de test (K3)

Termes
Spécification de cas de test, conception de tests, ordonnancement de l‟exécution de tests, spécification des procédures de test, script de test, traçabilité.
Contexte
Le processus de développement de test décrit dans cette section peut être effectué de diverses manières, de « très informelles » avec peu ou pas de documentation, à « très formelles » (comme décrit dans cette section). Le niveau de formalisme dépend du contexte des tests incluant la maturité des tests et des processus de développement, des contraintes de temps, des exigences de sureté de fonctionnement ou réglementaires et des personnes impliquées.
Pendant l‟analyse de conception des tests, la documentation de la base des tests est analysée de façon à déterminer ce qui est à tester, c‟est à dire à identifier les conditions de test. Une condition de test est définie comme un article ou événement qui peut être vérifié par un ou plusieurs cas de test (p.ex. une fonction, transaction, caractéristique qualité ou élément structurel).
Etablir la traçabilité des conditions de tests vers les spécifications et exigences permet à la fois l‟analyse d‟impact, quand les exigences changent, et une couverture des exigences à définir pour un ensemble de tests. Pendant l‟analyse de conception des tests, les approches détaillées de tests sont implémentées pour sélectionner des techniques de tests basées sur, entre autres considérations, les risques identifiés (voir Chapitre 5 pour plus d‟informations sur les analyses de risques).
Pendant la conception des tests, les cas de test et données de test sont créés et spécifiés. Un cas de test se compose d‟ un ensemble de valeurs d‟entrée, de pré-conditions d‟exécution, de résultats attendus et de post-conditions d‟exécution, conçu pour couvrir certains objectifs de tests et conditions de tests. Le Standard pour la Documentation de Tests Logiciel („Standard for Software Test Documentation‟ IEEE 829-1998) décrit le contenu des spécifications de conception de tests (contenant les conditions de test) et des spécifications des cas de test.
Les résultats attendus devraient être produits comme faisant partie des spécifications de cas de test et inclure les sorties, modifications de données et d‟états, et toute autre conséquence du test. Si des résultats attendus n‟ont pas été définis alors un résultat plausible mais erroné peut être interprété comme un résultat correct. Les résultats attendus devraient idéalement être définis avant l‟exécution des tests.
Pendant l‟implémentation des tests, les cas de test sont développés, implémentés, priorisés et organisés dans la spécification de procédure de test (IEEE STD 829-1998). La procédure de tests spécifie la séquence des actions pour l‟exécution d‟un test. Si les tests sont exécutés avec un outil d‟exécution des tests, la séquence d‟actions est spécifiée dans un script de tests (qui est une procédure de test automatisée).
Les diverses procédures de tests et scripts de tests automatisés sont ensuite consolidées en un planning d‟exécution de tests qui définit l‟ordre dans lequel les diverses procédures de test, et potentiellement les scripts de tests automatisés, sont exécutés. Les plannings d‟exécution des tests prendront en compte les facteurs tels que les tests de régression, de priorisation, et de dépendances technique et logique.

4.2 Catégories de techniques de conception de tests (K2)

Termes
Technique de conception boîte noire, technique de conception basée sur l‟expérience, technique de conception de test, technique boîte blanche.
Contexte
L‟objectif de la technique de conception des tests est d‟identifier les conditions de tests, les cas de test et les données de tests.
Il est fréquent de faire la distinction entre les techniques de tests boîte blanche et les techniques de test boîte noire. Les techniques de conception boîte noire (aussi appelées techniques basées sur les spécifications) sont une façon de dériver et de sélectionner les conditions de tests, les cas de test ou les données de test en se basant sur une analyse de la documentation de la base des tests. Ceci inclut les tests fonctionnels et non fonctionnels. Le test boîte noire, par définition, n‟utilise aucune information concernant la structure interne d‟un composant ou système à tester. Les techniques de conception boîte blanche (aussi dites techniques structurelles ou basées sur les structures) sont basées sur une analyse de la structure du composant ou du système. Les tests boîte noire et boîte blanche peuvent aussi être combinés avec des techniques s‟inspirant de l‟expérience des développeurs, des testeurs et des utilisateurs pour déterminer ce qui doit être testé.
Quelques techniques se retrouvent dans une seule catégorie, d‟autres comprennent des éléments de plus d‟une catégorie.
Ce syllabus référence comme techniques boîte noire les approches basées sur les spécifications, et référence comme techniques boîte blanche les approches basées sur les structures. De plus, les techniques de conception basées sur l‟expérience sont couvertes.
Caractéristiques habituelles des techniques de conception basées sur les spécifications:
 Les modèles, soit formels soit informels, sont utilisés pour la spécification des problèmes à résoudre, des logiciels ou des composants.
 Depuis ces modèles les cas de test sont dérivés de façon systématique.
Caractéristiques habituelles des techniques de conception basées sur la structure:
 L‟information sur la manière dont le logiciel est construit est utilisée pour dériver les cas de test (par exemple, le code et les informations de conception détaillée).
 Le niveau de couverture du logiciel peut être mesuré à partir de cas de test existants, et des cas de test complémentaires peuvent être dérivés de façon systématique pour augmenter la couverture.
Caractéristiques habituelles des techniques de conception basées sur l‟expérience:
 La connaissance et l‟expérience des personnes sont utilisées pour dériver les cas de test.
 La connaissance des testeurs, développeurs, utilisateurs et autres parties prenantes concernant le logiciel, son utilisation et son environnement sont autant de sources d‟information;
 La connaissance des défauts possibles et de leur distribution est une autre source d‟information.

4.3 Techniques basées sur les spécifications ou techniques boîte noire (K3)

Termes
Analyse des valeurs limites, tests par tables de décisions, partitions d‟équivalence, tests de transition d‟états, tests de cas d‟utilisation.

4.3.1 Partitions d‟équivalence (K3)
Pour les partitions d‟équivalence, les entrées d‟un logiciel ou système sont divisées en groupes qui doivent montrer un comportement similaire, de ce fait elles auront un traitement identique. Les partitions (ou classes) d‟équivalence peuvent être trouvées pour des données valides, c‟est-à-dire des données qui devraient être acceptées et des données invalides, c‟est-à-dire des valeurs qui devraient être rejetées. Les partitions peuvent aussi être identifiées pour les sorties, les valeurs internes, les valeurs liées au temps (p.ex. avant ou après un événement) et pour les paramètres d‟interface (p.ex. composants intégrés en cours de test pendant les tests d‟intégration). Des tests peuvent être conçus pour couvrir toutes les partitions valides et invalides. Les partitions d‟équivalence sont applicables à tous les niveaux de tests.
Les partitions d‟équivalence peuvent être utilisées pour atteindre des objectifs de couverture d‟entrées et de sorties. Elles peuvent être appliquées aux entrées humaines, aux entrées via l‟interface du système, ou aux paramètres d‟interface des tests d‟intégration.

4.3.2 Analyse des valeurs limites (K3)
Le comportement au bord de chaque partition d‟équivalence risque plus d‟être incorrect qu‟à l‟intérieur, donc les limites sont des zones plus propices pour découvrir des défauts. Les valeurs maximum et minimum d‟une partition sont ses valeurs limites. Une valeur limite pour une partition valide est une valeur limite valide; la limite d‟une partition invalide est une valeur limite invalide. Des tests peuvent être conçus pour couvrir les valeurs limites valides et invalides. Quand on conçoit des cas de test, une valeur de chaque limite est sélectionnée pour un test.
L‟analyse des valeurs limites peut être appliquée à tous les niveaux de tests. C‟est relativement aisé à appliquer et la capacité de détection de défauts est élevée. Des spécifications détaillées sont utiles pour déterminer les limites intéressantes.
Cette technique est souvent considérée comme une extension des partitions d‟équivalences ou autre technique de conception boîte noire. Elle peut être utilisée pour les classes d‟équivalence aussi bien sur les données d‟entrées humaines ou écran, par exemple, que sur des limites de temps (par exemple, le time out, les exigences de rapidité de transactions) ou sur des limites de tableaux (par exemple, une taille de tableau de 256*256).

4.3.3 Tests par tables de décisions (K3)
Les tables de décisions sont une bonne façon de capturer des exigences système contenant des conditions logiques, et pour documenter la conception système interne. Elles peuvent être utilisées pour enregistrer les règles de gestion complexes que doit implémenter un système. Lors de la création des tables de décisions, la spécification est analysée, et les actions et conditions du système sont identifiées. Les conditions d‟entrée et les actions sont souvent décrites de façon à ce qu‟elles peuvent être soit vraies soit fausses (Booléen). Les tables de décision contiennent les conditions de déclenchement, souvent des combinaisons de vrais et faux pour toutes les conditions d‟entrée, et sur les actions résultantes pour chaque combinaison de conditions. Chaque colonne de la table correspond à une règle de gestion qui définit une combinaison unique de conditions qui résultent en l‟exécution de l‟action associée à cette règle. La couverture standard généralement utilisée avec les tables de décisions est d‟avoir au moins un test par colonne, ce qui implique typiquement de couvrir toutes les combinaisons de conditions de déclenchement.

La force des tests par les tables de décisions est la création de combinaisons de conditions qui autrement n‟auraient pas été traitées pendant les tests. Cela peut être appliqué à toutes les situations quand l‟action du logiciel dépend de plusieurs décisions logiques.

4.3.4 Test de transition d‟états (K3)
Un système peut montrer plusieurs réponses différentes en fonction des conditions actuelles ou passées (son état). Dans ce cas, cet aspect du système peut être montré par un diagramme d‟états et de transitions. Cela permet au testeur de visualiser le logiciel en termes d‟états, de transitions entre les états, de données d‟entrées ou des événements qui déclenchent des changements d‟état (transitions) et des actions qui peuvent résulter de ces transitions. Les états du système ou de l‟objet sous test sont séparées, identifiables et en nombre fini.
Une table des états montre la relation entre les états et les entrées, et peut mettre en lumière des transitions possibles invalides.
Des tests peuvent être conçus pour couvrir une séquence typique d‟états, pour couvrir chaque état, pour exécuter toutes les transitions, pour exécuter une séquence spécifique de transitions ou tester des transitions invalides.
Les tests de transitions d‟états sont fréquemment utilisés dans l‟industrie du logiciel embarqué et généralement dans l‟automatisation technique. Cependant, la technique est aussi utilisable pour modéliser les objets métier possédant des états spécifiques ou pour tester les dialogues d‟interfaces écran (p.ex. pour les applications Internet ou les scénarios métier).

4.3.5 Tests de cas d‟utilisation (K2)
Les tests peuvent être spécifiés à partir de cas d‟utilisation. Un cas d‟utilisation décrit l‟interaction entre acteurs ( utilisateurs et système), qui produit un résultat ayant une valeur pour l‟utilisateur du système ou le client. Les cas d‟utilisation peuvent être décrits à un niveau abstrait (cas d‟utilisation métier, indépendant de la technologie, niveau processus métier). Chaque cas d‟utilisation a des pré-conditions, qui doivent être atteintes pour que ce cas d‟utilisation soit exécuté avec succès. Chaque cas d‟utilisation se termine par des post-conditions, qui sont les résultats observables et l‟état final du système après la fin de l‟exécution du cas d‟utilisation. Un cas d‟utilisation a généralement un scénario dominant (c‟est à dire le plus plausible), et parfois des scénarios alternatifs.
Les cas d‟utilisation décrivent les “flux du processus” dans un système, basé sur une utilisation probable, donc les cas de test dérivés des cas d‟utilisation sont extrêmement utiles pour découvrir les défauts dans le flux de traitement pendant l‟utilisation réelle du système. Les cas d‟utilisation, souvent appelés scénarios, sont très utiles pour concevoir des tests d‟acceptation avec la participation du client/utilisateur. Ils permettent aussi de découvrir des défauts d‟intégration causés par l‟interaction et les interférences entre divers composants, ce que ne découvrent pas les tests individuels de composants. La conception de cas de test à partir des cas d‟utilisation peut être combinée avec d‟autres techniques de tests basées sur les spécifications.

4.4 Technique de conception basée sur la structure ou technique de conception boîte blanche (K3)

Termes
Couverture de code, couverture des décisions, couverture des instructions, tests structurels.
Contexte
Les tests basés sur la structure ou tests boîte blanche suivent la structure identifiée du logiciel ou du système, comme décrit dans les exemples suivants:
 Niveau composant: la structure d‟un composant logiciel c‟est à dire instructions, décisions, branches ou même des chemins distincts
 Niveau intégration: la structure peut être un arbre (ou graphe) d‟appel (un diagramme où des modules appellent d‟autres modules).
 Niveau système: la structure peut être une structure de menus, des processus métier ou la structure d‟une page web.
Dans cette section, trois techniques structurelles liées à la couverture du code, portant sur les instructions et les décisions, sont discutées. Pour les tests des décisions, un diagramme de contrôle de flux peut être utilisé pour visualiser les alternatives de chaque décision.

4.4.1 Test des instructions et couverture (K3)
Dans les tests de composants, la couverture des instructions est l‟évaluation du pourcentage d‟instructions exécutables qui ont été exercées par une suite de cas de test. Le test des instructions dérive des cas de test pour exécuter des instructions spécifiques, généralement pour accroître la couverture des instructions.
La couverture des instructions est déterminée par le nombre d‟instructions exécutables couvertes par des cas de test (conçus ou exécutés) divisé par le nombre de toutes les instructions exécutables dans le code testé.

4.4.2 Test des décisions et couverture (K3)
La couverture des décisions, liées aux tests de branches, est l‟évaluation des pourcentages de résultats de décisions (p.ex. les options Vrai et Faux d‟une instruction IF) qui ont été traitées par une suite de cas de test. Les cas de test provenant des tests de décisions sont amenés à exécuter des résultats de décisions spécifiques. Les branches trouvent leur origine dans les points de décision du code et montrent le transfert du contrôle vers différents endroits du code.
La couverture des décisions est déterminée par le nombre de tous les résultats des décisions couvertes par des cas de test (conçus ou exécutés) divisé par le nombre de tous les résultats possibles des décisions dans le code sous test.
Les tests de décisions sont une forme de contrôle de flux car ils génèrent un flux spécifique de contrôle entre des points de décisions. La couverture des décisions est supérieure à la couverture des instructions: une couverture de 100% des décisions garantit une couverture à 100% des instructions, mais l‟inverse n‟est pas vrai.

4.4.3 Autres techniques basées sur les structures (K1)
Il existe des niveaux de couverture structurelle plus forts que les couvertures de décisions, par exemple les couvertures de conditions et les couvertures de conditions multiples.

Le concept de couverture peut aussi être appliqué aux autres niveaux de tests. Par exemple, au niveau intégration, le pourcentage des modules, composants ou classes qui ont été exercées par une suite de cas de test peut être exprimé comme une couverture de modules, composants ou classes.
L‟aide via des outils est utile pour le test structurel de code.

4.5 Techniques basées sur l’expérience (K2)

Termes
Tests exploratoires, (faute) attaque.
Contexte
Le test basé sur l‟expérience a lieu lorsque les tests sont conçus à partir des compétences des testeurs, de leur intuition et de leur expérience avec des applications et technologies similaires. Quand ils sont utilisés pour améliorer les techniques systématiques, les tests intuitifs peuvent être utiles pour identifier des tests spéciaux, difficilement atteints par des approches formelles. Cependant, cette technique peut donner des degrés d‟efficacité extrêmement différents, selon l‟expérience des testeurs.
Une technique basée sur l‟expérience communément utilisée est l‟estimation d‟erreur. Généralement, les testeurs anticipent les défauts basés sur l‟expérience. Une approche structurée pour la technique d‟estimation d‟erreurs est d‟énumérer une liste des défauts possibles et de concevoir des tests pour mettre en évidence ces défauts. Cette approche systématique est appelée « attaque par faute » . Ces listes de défauts et de défaillances peuvent être construites sur la base de l‟expérience, des données disponibles sur les défauts et anomalies, et de la connaissance commune sur les causes de défaillances.
Les tests exploratoires comprennent la conception et l‟exécution des tests, l‟écriture des résultats de tests et l‟apprentissage (de l‟application), basés sur une charte de tests contenant les objectifs de tests, et effectués dans des périodes de temps délimitées. C‟est l‟approche la plus utile pour augmenter ou compléter d‟autres méthodes de tests plus formelles lorsque les spécifications sont rares ou non adéquates, et que le test est soumis à de sévères contraintes de temps. Cela peut servir comme vérification de processus de tests, pour s‟assurer que les défauts les plus sérieux sont trouvés.

4.6 Sélectionner les techniques de tests (K2)

Termes
Pas de terme spécifique.
Contexte
Le choix des techniques de tests à utiliser dépend de différents facteurs incluant le type de système, les standards réglementaires, les exigences client ou contractuelles, le niveau de risque, le type de risque, les objectifs de test, la documentation disponible, la connaissance des testeurs, le temps disponible et le budget, le cycle de vie de développement utilisé, les modèles de cas d‟utilisation et l‟expérience sur les défauts découverts précédemment.
Quelques techniques sont plus applicables que d‟autres à certaines situations et niveaux de tests, d‟autres sont applicables à tous les niveaux de tests.
Lors de la création de cas de test, les testeurs utilisent généralement une combinaison de techniques de tests incluant les techniques orientées processus, règles et données pour assurer une couverture adéquate de l‟objet testé.