Assurance qualité logicielle : résoudre les problèmes liés à la conception de tests combinatoires

Dans les tests logiciels , la conception des cas de test est fondamentale pour garantir la fiabilité et la robustesse des applications. Les techniques de conception de tests combinatoires, telles que les tests k-way et les tests par paires, visent à tester les interactions entre différentes variables d'entrée. Cependant, il devient évident que les défis et les pièges peuvent entraver leur efficacité à découvrir les erreurs critiques.

Ce court article se concentre sur les problèmes spécifiques qui pourraient être rencontrés lors de la conception de tests combinatoires, explorant les nuances qui nécessitent un examen attentif. Examinons les cas de valeurs d'entrée incorrectes, l'importance d'oracles robustes, l'importance des combinaisons de variables souvent négligées et la compréhension cruciale de la façon dont les variables interagissent.

Identification incorrecte des valeurs d'entrée

Un ensemble de tests k-way comprend toutes les combinaisons possibles de valeurs pour k variables. Par exemple, l’application de l’algorithme Allpairs aboutit à un ensemble de tests bidirectionnels, englobant toutes les combinaisons possibles de paires de valeurs variables. Par conséquent, une erreur k-way fait référence à une erreur résultant de l’interaction des valeurs de k variables. L'examen de deux systèmes, SYS1 et SYS2, a révélé des erreurs après leurs versions de production. Les deux systèmes ont subi des tests k-way avec des valeurs k de 2, 3, 4 et 5+.

Le tableau affiche les résultats des tests k-way pour les deux systèmes.

Des contrôles séquentiels ont été effectués pour chaque ensemble k-way. La figure 2.1 indique que les erreurs résultant de l'interaction de deux variables d'entrée ou moins étaient 29 in SYS1 et 30 in SYS2 . Les erreurs dues à l'interaction de trois variables étaient 4*(30+4) in SYS2 et 12*(29+12) in SYS1 . Pour les interactions impliquant quatre variables, les erreurs étaient 7*(30+4+7) in SYS2 et 1*(29+12+1) in SYS1 . Les erreurs dues aux interactions avec plus de quatre variables étaient 3*(29+12+1+3) in SYS1 et 7*(30+4+7+7) in SYS2 . Notamment, 43 erreurs n’ont pas été trouvées dans SYS1 et 34 erreurs n’ont pas été trouvées dans SYS2.

Dans cet exemple, les erreurs les plus significatives appartenaient à la catégorie Not Found . Des investigations plus approfondies ont révélé que la plupart des erreurs non détectées étaient des défauts unidirectionnels, ce qui signifie qu'une valeur spécifique d'une variable conduisait à l'erreur indépendamment des valeurs des autres variables. Les tests par paires auraient dû détecter ces erreurs, mais pour une raison quelconque, elles sont restées inconnues. Ces erreurs Not Found sont principalement des défauts unidirectionnels qui sont passés inaperçus car certaines valeurs d'entrée n'ont pas été sélectionnées ou ont été mal choisies.

L'essence du problème réside dans le fait que toutes les erreurs commises avant l'application de l'algorithme Allpairs persisteront. Cela implique que si les techniques de conception de tests précédentes ont été mal appliquées ou si les valeurs d'entrée étaient incorrectes, les erreurs dans l'application persisteront indépendamment de l'utilisation de l'algorithme Allpairs ou du test de réseau orthogonal.

Faiblesse dans la définition des résultats attendus : incertitude quant aux premiers résultats

A titre d'exemple, considérons un module d'application avec de nombreuses options (quelque chose qui ressemble à ce formulaire) et, par conséquent, un grand nombre de combinaisons de données d'entrée.

Dans le module, disons qu'il y a 2^12 * 3 combinaisons possibles. Ici, le défi n'est pas de choisir des valeurs d'entrée incorrectes, car toutes les valeurs de variables possibles peuvent être testées de manière exhaustive à l'aide de l'algorithme Allpairs. Cependant, cela permettra-t-il de découvrir toutes les erreurs critiques ? Probablement pas, en raison de problèmes liés aux résultats attendus. Après avoir manipulé chaque combinaison d'options dans ce type de module logiciel, il faudrait utiliser le système pendant un certain temps pour vérifier que les options fonctionnaient correctement et que rien d'autre ne se cassait après l'application des options choisies. Dans ce cas, rien ne garantit qu’il n’y aura pas de problème subtil et non évident pouvant facilement être ignoré.

Après chaque test, il faudra peut-être évaluer minutieusement les fonctions essentielles du système. Le fait est que les défauts graves ne sont souvent pas aussi apparents qu’on le souhaiterait et qu’il devient pratiquement impossible de tout prendre en compte dans les résultats attendus.

Inattention aux combinaisons les plus probables

Parmi les combinaisons 2^12 * 3 (comme nous l'avons suggéré dans l'exemple ci-dessus), il existe probablement une combinaison d'options de module qui se produira beaucoup plus fréquemment que toutes les autres : le paramètre par défaut . Si 95 % des personnes ne modifieront jamais les options par rapport aux paramètres par défaut de ce module, il devrait y avoir une bonne couverture des options presque/presque par défaut . Tester toutes les variantes présentant un écart par rapport à la configuration par défaut dans une option entraînerait un nombre de tests à 2 chiffres. Si l’on testait toutes les combinaisons d’options avec un écart possible de deux paramètres par rapport à la valeur par défaut, cela représenterait une centaine de cas de test. Les tests avec ces cas de test et les cas de test toutes paires peuvent donner de meilleurs résultats que d'ignorer l'existence de l'option par défaut. Cependant, l'algorithme Allpairs oblige le testeur à négliger les combinaisons de variables les plus probables et les plus couramment utilisées.

Interactions de variables inconnues

Le facteur clé du succès ou de l’échec des tests par paires réside dans la compréhension de la manière dont la combinaison des variables d’entrée affecte les données de sortie. L'application de tests par paires à deux applications testées différentes peut donner des résultats très différents. Certaines applications utilisent moins de données d’entrée pour produire des données de sortie, tandis que d’autres en utilisent davantage.

À titre d'exemple, considérons le programme, qui a trois variables d'entrée (X, Y, Z) et trois données de sortie possibles (1, 2, 3). Les flèches indiquent quelles variables doivent interagir pour produire un résultat spécifique. Pour obtenir un résultat de 1, les variables Y et X doivent interagir ; pour obtenir un résultat de 2, les variables Z et X doivent interagir. Pour cette application, l’application de tests par paires serait un choix approprié, et des résultats positifs sont probables. Cependant, dans les cas où les données de sortie résultent de l'interaction de plus de deux variables d'entrée, il est fort probable que les tests par paires ne parviennent pas à identifier les erreurs. La simple application de tests par paires augmente le risque de négliger des erreurs critiques dans l'application testée.