Dans   , 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. les tests logiciels  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   des valeurs d'entrée incorrecte  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.  Type de défaut  SYS1  SYS2  2 voies  30  29  3 voies  4  12  4 voies  7  1  > 4 voies  7  3  Pas trouvé  34  43  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   et   . Les erreurs dues à l'interaction de trois variables étaient   et   . Pour les interactions impliquant quatre variables, les erreurs étaient   et   . Les erreurs dues aux interactions avec plus de quatre variables étaient   et   . Notamment,   erreurs n’ont pas été trouvées dans SYS1 et   erreurs n’ont pas été trouvées dans SYS2. 29 in SYS1 30 in SYS2 4*(30+4) in SYS2 12*(29+12) in SYS1 7*(30+4+7) in SYS2 1*(29+12+1) in SYS1 3*(29+12+1+3) in SYS1 7*(30+4+7+7) in SYS2 43 34  Dans cet exemple, les erreurs les plus significatives appartenaient à la catégorie   . 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   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. Not Found Not Found    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. L'essence du problème   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   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é. 2^12 * 3  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   (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   . 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   . 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. 2^12 * 3 par défaut presque/presque par défaut  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.  En tant que professionnel de l’assurance qualité, il est important de comprendre ces nuances. Bien que théoriques dans certains cas, ces informations soulignent la nécessité d’une approche de test holistique qui va au-delà de la surface, garantissant la fiabilité et la robustesse de vos applications. Comprendre la complexité de la conception des tests combinatoires permet aux professionnels de l'assurance qualité de tester efficacement la logique métier complexe des applications et de fournir des logiciels de haute qualité à leurs utilisateurs.

About Me

Read My Articles

Hire Me

Cet audio est produit dans la langue originale de l'histoire !

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

About Author

COMMENTAIRES

ÉTIQUETTES

CET ARTICLE A ÉTÉ PARU DANS

Related Stories

Libérer la puissance de l’IA. Une revue systématique des techniques de pointe : résumé et introduction

Créer des produits cryptographiques centrés sur l'utilisateur : l'importance des retours clients

La fuite de l'invite du système Claude Sonnet 3.5 : une analyse médico-légale

Croissance des crypto-monnaies : créer des profils d'utilisateurs efficaces

Libérer la puissance de l’IA. Une revue systématique des techniques de pointe : résumé et introduction

Créer des produits cryptographiques centrés sur l'utilisateur : l'importance des retours clients

La fuite de l'invite du système Claude Sonnet 3.5 : une analyse médico-légale

Croissance des crypto-monnaies : créer des profils d'utilisateurs efficaces

Light-Mode

Classic

Newspaper

Dark-Mode

Neon Noir

Minty

HN StartUps