Dans des articles de blog précédents, nous avons évoqué la décomposition d'un aspect du défi des tests, à savoir la gestion de plusieurs entrées dans le cadre d'une expérience planifiée, où nous pouvons commencer par nous concentrer sur une entrée à la fois. Un article de blog ultérieur a revisité les principes fondamentaux des effets factoriels dans les expériences planifiées. Nous allons maintenant combiner ces idées et discuter de ce que nous pourrions vouloir dans la conception d'une expérience à utiliser pour les tests.
Revenons à la distribution bêta et considérons maintenant si nous voulons tester la variation des entrées de la distribution bêta, en nous concentrant sur q, alpha et bêta.
Supposons que nous choisissons trois valeurs pour chacune de ces entrées (une valeur faible/moyenne/élevée). On pourrait imaginer essayer les 27 combinaisons possibles (3x3x3). Mais cela fonctionnerait-il si nous avions 10 entrées ? 20 ? 100 ? À un moment donné, il devient évident que nous avons besoin d'une stratégie différente. Bien que nous ayons un moyen de gérer cela dans les problèmes de conception d'expériences typiques, cette même approche fonctionne-t-elle pour les tests de logiciels ? En nous rappelant que nous voulons trouver des bugs et qu'ils se cachent dans les coins et les limites , reformulons cela pour dire que notre objectif est de trouver des combinaisons d'entrées qui induiront un échec (c'est-à-dire que nous n'observons pas le résultat attendu).
Qu'en est-il des limites ?
Vous avez peut-être remarqué que je semble ignorer les limites. C'est là que l'approche OFAT peut avoir de la valeur. Idéalement, nous avons déjà vérifié nos limites pour chacune de nos entrées (et avons corrigé tous les problèmes) avant d'arriver à ce point des tests. Néanmoins, comme nous le découvrirons plus tard, nous pouvons prendre en compte les limites lorsque nous faisons varier nos entrées.
Au-delà de l'OFAT
Dans un modèle factoriel, les principes fondamentaux des effets factoriels concernent les effets importants/significatifs. Cependant, pour les tests logiciels, nous reformulons les principes fondamentaux en termes de « combinaisons génératrices d’échecs » :
Hiérarchie des combinaisons : i) Les combinaisons impliquant moins d’entrées sont plus susceptibles d’entraîner un échec que celles impliquant plus d’entrées. ii) Les combinaisons du même ordre sont tout aussi susceptibles d’être importantes.
Rareté des combinaisons : Le nombre de combinaisons entraînant des échecs sera faible.
Hérédité combinée : une combinaison est plus susceptible d’entraîner des échecs si au moins l’un des facteurs parents impliquant l’interaction est connu pour être plus susceptible d’être impliqué dans l’induction des échecs.
Pourquoi avons-nous besoin de faire une distinction ?
L'une des différences clés dans les tests est que notre réponse est simplement une réussite/échec : est-ce que nous nous écartons ou non du résultat attendu ? De plus, nous supposons généralement un résultat déterministe. Autrement dit, si nous utilisons les mêmes entrées, nous obtenons les mêmes résultats (aucune erreur). Bien qu'un testeur souhaite trouver des bugs, nous espérons qu'ils seront éventuellement corrigés. Nous ne cherchons pas à adapter un modèle, à trouver des effets ou à optimiser une réponse. En fait, l'analogie la plus proche de l'idée de modélisation est la tâche consistant à rechercher une combinaison qui a provoqué une défaillance. C'est ce qu'on appelle le problème de localisation des pannes, et il comporte son propre ensemble de défis uniques.
Alors, ces principes ont-ils un sens pour les tests ?
Il s’avère que des preuves empiriques démontrent que la hiérarchie des combinaisons est valable (voir Kuhn et al., 2004). D’un autre côté, la rareté des combinaisons n’est pas toujours une hypothèse raisonnable. Si un système n’a subi aucun type de test d’interactions, ou même de test d’entrées individuelles, il peut y avoir de nombreux échecs dans une suite de tests (en particulier avant que les bugs ne commencent à être corrigés). Cela est également lié au principe d’hérédité des combinaisons : si une entrée individuelle induit un échec, alors toute combinaison impliquant cette entrée induira un échec.
Alors, si ces hypothèses sont raisonnables, qu'est-ce qui constitue une bonne série de tests ? Restez à l'écoute de nos prochains articles de blog.
Kuhn, DR, Wallace, DR et Gallo, AM, 2004. Interactions entre les pannes logicielles et implications pour les tests logiciels.Transactions IEEE sur l'ingénierie logicielle, 30(6), pp.418-421.
