Au sens strict, il n'est pas juste de faire des réclamations tant que la qualité de la suite de tests n'est pas établie. Réussir 100% des tests n'est pas significatif si la plupart des tests sont triviaux ou répétitifs les uns avec les autres.
La question est: dans l'histoire du projet, l'un de ces tests a-t-il révélé des bogues? Le but d'un test est de trouver des bugs. Et s'ils ne l'ont pas fait, ils ont échoué en tant que tests. Au lieu d'améliorer la qualité du code, ils pourraient seulement vous donner un faux sentiment de sécurité.
Pour améliorer vos conceptions de test, vous pouvez utiliser (1) des techniques de boîte blanche, (2) des techniques de boîte noire et (3) des tests de mutation.
(1) Voici quelques bonnes techniques de boîte blanche à appliquer à vos conceptions de test. Un test de boîte blanche est construit avec un code source spécifique à l'esprit. Un aspect important du test de la boîte blanche est la couverture du code:
- Est-ce que chaque fonction est appelée? [Couverture fonctionnelle]
- Chaque instruction est-elle exécutée? [Couverture des relevés - La couverture fonctionnelle et la couverture des relevés sont très basiques, mais mieux que rien]
- Pour chaque décision (comme
ifou while), avez-vous un test qui le force à être vrai et un autre qui le force à être faux? [Couverture de la décision]
- Pour chaque condition qui est une conjonction (utilisations
&&) ou une disjonction (utilisations ||), chaque sous-expression a-t-elle un test où elle est vraie / fausse? [Couverture de condition]
- Couverture de boucle: avez-vous un test qui force 0 itérations, 1 itération, 2 itérations?
- Chacun
breakd'une boucle est-il couvert?
(2) Les techniques Blackbox sont utilisées lorsque les exigences sont disponibles, mais le code lui-même ne l'est pas. Ceux-ci peuvent conduire à des tests de haute qualité:
- Vos tests Blackbox couvrent-ils plusieurs objectifs de test? Vous voudrez que vos tests soient "lourds": non seulement ils testent la fonctionnalité X, mais ils testent également Y et Z. L'interaction de différentes fonctionnalités est un excellent moyen de trouver des bogues.
- Le seul cas où vous ne voulez pas de tests "gras" est lorsque vous testez une condition d'erreur. Par exemple, tester une entrée utilisateur non valide. Si vous avez essayé d'atteindre plusieurs objectifs de test d'entrée non valides (par exemple, un code postal non valide et une adresse municipale non valide), il est probable qu'un cas masque l'autre.
- Considérez les types d'entrées et formez une "classe d'équivalence" pour les types d'entrées. Par exemple, si votre code teste pour voir si un triangle est équilatéral, le test qui utilise un triangle avec des côtés (1, 1, 1) trouvera probablement les mêmes types d'erreurs que les données de test (2, 2, 2) et (3, 3, 3) trouvera. Il vaut mieux passer votre temps à penser à d'autres classes de contribution. Par exemple, si votre programme gère les taxes, vous voudrez un test pour chaque tranche de taxe. [Cela s'appelle le partitionnement d'équivalence.]
- Des cas particuliers sont souvent associés à des défauts. Vos données de test doivent également avoir des valeurs limites, telles que celles sur, au-dessus ou au-dessous des bords d'une tâche d'équivalence. Par exemple, lors du test d'un algorithme de tri, vous voudrez tester avec un tableau vide, un tableau à un seul élément, un tableau à deux éléments, puis un très grand tableau. Vous devez considérer les cas limites non seulement pour l'entrée, mais également pour la sortie. [Il s'agit de l'analyse des valeurs limites d'appel.]
- Une autre technique consiste à «deviner les erreurs». Avez-vous le sentiment, si vous essayez une combinaison spéciale, que vous pouvez interrompre votre programme? Alors essayez-le! Rappelez-vous: votre objectif est de trouver des bogues, pas de confirmer que le programme est valide . Certaines personnes ont le don de deviner les erreurs.
(3) Enfin, supposons que vous ayez déjà beaucoup de bons tests pour la couverture de la boîte blanche et des techniques de boîte noire appliquées. Que pouvez vous faire d'autre? Il est temps de tester vos tests . Une technique que vous pouvez utiliser est le test de mutation.
Sous test de mutation, vous apportez une modification à (une copie de) votre programme, dans l'espoir de créer un bug. Une mutation peut être:
Changer une référence d'une variable à une autre variable; Insérez la fonction abs (); Remplacez moins que par supérieur à; Supprimer une déclaration; Remplacez une variable par une constante; Supprimer une méthode prioritaire; Supprimer une référence à une super méthode; Modifier l'ordre des arguments
Créez plusieurs dizaines de mutants, à différents endroits de votre programme [le programme devra encore être compilé pour pouvoir tester]. Si vos tests ne trouvent pas ces bogues, vous devez maintenant écrire un test qui peut trouver le bogue dans la version mutée de votre programme. Une fois qu'un test a détecté le bogue, vous avez tué le mutant et vous pouvez en essayer un autre.
Addendum : j'ai oublié de mentionner cet effet: les bugs ont tendance à se regrouper . Cela signifie que plus vous trouvez de bogues dans un module, plus vous avez de chances de trouver plus de bogues. Donc, si vous avez un test qui échoue (c'est-à-dire que le test est réussi, car le but est de trouver des bogues), non seulement vous devez corriger le bogue, mais vous devez également écrire plus de tests pour le module, en utilisant le techniques ci-dessus.
Tant que vous trouvez des bogues à un rythme constant, les efforts de test doivent se poursuivre. Ce n'est que lorsqu'il y a une baisse du taux de nouveaux bogues trouvés que vous pouvez avoir confiance que vous avez fait de bons efforts de test pour cette phase de développement.