Rigueur dans la capture des cas de tests pour les tests unitaires

Question

Disons que nous avons une fonction simple définie dans un pseudo langage.

List<Numbers> SortNumbers(List<Numbers> unsorted, bool ascending);

Nous transmettons une liste de nombres non triés et un booléen spécifiant l'ordre de tri croissant ou décroissant.En retour, nous obtenons une liste triée de nombres.

D’après mon expérience, certaines personnes parviennent mieux que d’autres à capturer les conditions aux limites.La question est : « Comment savoir si vous avez « terminé » de capturer les cas de test » ?

Nous pouvons commencer à énumérer les cas dès maintenant et une personne intelligente pensera sans aucun doute à « un cas de plus » qui n’est couvert par aucun des précédents.

Answer 1

Ne perds pas trop de temps à essayer de penser à chaque condition limite.Vos tests ne pourront pas détecter chaque bug la première fois.L'idée est d'avoir des tests qui sont très bon, et puis à chaque fois un bug fait surface, écrivez un nouveau test spécifiquement pour ce bug afin que vous n'en entendiez plus jamais parler.

Une autre remarque que je souhaite faire sur les outils de couverture de code.Dans un langage comme C# ou Java où vous disposez de nombreuses méthodes get/set et similaires, vous devriez pas filmez pour une couverture à 100 %.Cela signifie que vous perdez trop de temps à écrire des tests pour du code trivial.Toi seulement souhaitez une couverture à 100 % de votre logique métier complexe.Si votre base de code complète est plus proche d’une couverture de 70 à 80 %, vous faites du bon travail.Si votre outil de couverture de code permet plusieurs métriques de couverture, la meilleure est la « couverture de blocs » qui mesure la couverture des « blocs de base ».D'autres types sont la couverture de classe et de méthode (qui ne vous donne pas autant d'informations) et la couverture de ligne (qui est à grain trop fin).

Answer 2

Comment savoir quand vous avez « terminé » la capture des cas de test ?

Ce n'est pas le cas. Vous ne pouvez pas atteindre 100 %, sauf dans les cas les plus triviaux.De plus, une couverture à 100 % (des lignes, des chemins, des conditions...) ne vous indique pas que vous avez atteint toutes les conditions aux limites.

Plus important encore, les cas de test ne sont pas écrits et oubliés. Chaque fois que vous trouvez un bug, écrivez un test supplémentaire. Vérifiez qu'il échoue avec le programme d'origine, vérifiez qu'il réussit avec le programme corrigé et ajoutez-le à votre ensemble de tests.

Un extrait de L'art du test de logiciels par Glenford J.Myers :

1. Si une condition d'entrée spécifie une plage de valeurs, écrivez des scénarios de test pour les extrémités de la plage et des scénarios de test d'entrée non valide pour les situations juste au-delà des extrémités.
2. Si une condition d'entrée spécifie un certain nombre de valeurs, écrivez des cas de test pour le nombre minimum et maximum de valeurs et un en dessous et au-delà de ces valeurs.
3. Utilisez la ligne directrice 1 pour chaque condition de sortie.
4. Utilisez la ligne directrice 2 pour chaque condition de sortie.
5. Si l’entrée ou la sortie d’un programme est un ensemble ordonné, concentrez votre attention sur le premier et le dernier élément de l’ensemble.
6. De plus, utilisez votre ingéniosité pour rechercher d’autres conditions aux limites

(Je n'ai collé que le strict minimum pour des raisons de droits d'auteur.)

Points 3.et 4.ci-dessus sont très importants.Les gens ont tendance à oublier les conditions aux limites pour les résultats.5.c'est OK.6.ça n'aide vraiment pas :-)

Examen court

C’est plus difficile qu’il n’y paraît.Myers propose ce test :

Le programme lit trois valeurs entières à partir d'une boîte de dialogue de saisie.Les trois valeurs représentent les longueurs des côtés d'un triangle.Le programme affiche un message indiquant si le triangle est scalène, isocèle ou équilatéral.

N'oubliez pas qu'un triangle scalène est un triangle dans lequel il n'y a pas deux côtés égaux, alors qu'un triangle isocèle a deux côtés égaux et qu'un triangle équilatéral a trois côtés de même longueur.De plus, les angles opposés aux côtés égaux d’un triangle isocèle sont également égaux (il s’ensuit également que les côtés opposés aux angles égaux d’un triangle sont égaux), et tous les angles d’un triangle équilatéral sont égaux.

Écrivez vos cas de test.Combien en avez-vous?Myers pose 14 questions sur votre ensemble de tests et rapporte que les programmes professionnels hautement qualifiés obtiennent en moyenne une note de 7,8 sur 14 possibles.

Answer 3

D'un point de vue pratique, je crée une liste de tests qui, selon moi, doivent réussir avant d'être acceptés.Je les teste et les automatise si possible.En fonction du temps que j'ai estimé pour la tâche ou du temps qui m'a été imparti, j'étends la couverture de mes tests pour inclure les éléments qui doivent réussir avant l'acceptation.Bien entendu, la frontière entre devoir et devoir est subjective.Après cela, je mets à jour les tests automatisés au fur et à mesure que des bugs sont découverts.

Answer 4

@Keith

Je pense que vous avez réussi, la couverture du code est importante à examiner si vous voulez voir à quel point vous en avez terminé, mais je pense que 100 % est un objectif un peu irréaliste.Viser 75 à 90 % vous donnera une assez bonne couverture sans aller trop loin...ne testez pas dans le seul but d'atteindre 100 %, car à ce stade, vous perdez simplement votre temps.

Answer 5

Un bon outil de couverture de code aide vraiment.

Une couverture à 100 % ne signifie pas qu'elle est définitivement testée de manière adéquate, mais c'est un bon indicateur.

Pour .Net, NCover est plutôt bon, mais n'est plus open source.

---

@Mike Stone - Oui, cela aurait peut-être dû être "couverture élevée" - nous visons à 80% minimum, passant à 95%, il est généralement des rendements diminueurs, surtout si vous avez du code de ceinture de ceinture.