Qu'en est-il de confirmer la fonctionnalité dans des tests positifs, de prouver qu'elle fonctionne - dois-je dire que c'est une perte de temps? Quel genre de concept se cache derrière cette citation?
Les tests infructueux, c'est-à-dire les tests qui ne détectent pas d'erreurs, sont une perte de temps.
Web Engineering: The Discipline of Systematic Development of Web Applications citant Cem Kaner .
Réponses:
J'ai écrit la plupart des tests de logiciels informatiques il y a plus de 25 ans. J'ai depuis indiqué plusieurs parties du livre que je considère comme obsolètes ou tout simplement erronées. Voir http://www.kaner.com/pdfs/TheOngoingRevolution.pdf
Vous pouvez en voir plus (vues actuelles, mais sans pointeurs explicites vers TCS) sur mon site pour le cours de test de logiciel Black Box (vidéos et diapositives disponibles gratuitement), www.testingeducation.org/BBST
La culture de test à l'époque était largement confirmative.
Dans les tests modernes, l'approche des tests unitaires est largement confirmative - nous écrivons de grandes collections de tests automatisés qui vérifient simplement que le logiciel continue de fonctionner comme prévu. Les tests servent de détecteurs de changement - si quelque chose dans d'autres parties du code et cette partie a maintenant des problèmes, ou si des valeurs de données qui étaient auparavant impossibles dans le monde réel atteignent maintenant l'application, alors les détecteurs de changement se déclenchent, alertant le programmeur à un problème de maintenance.
Je pense que l'état d'esprit de confirmation est approprié pour les tests unitaires, mais imaginez un monde dans lequel tous les tests du système étaient confirmatifs (pour les personnes qui font une distinction, veuillez interpréter les "tests d'intégration du système" et les "tests d'acceptation" comme inclus dans mes commentaires sur le système test.) Le but du test était de confirmer que le programme répondait à ses spécifications et l'approche dominante était de créer un million (ou au moins quelques centaines) de tests de régression au niveau du système qui mappaient des parties de la spécification aux comportements du programme. (Je pense que la confirmation de la spécification au comportement est utile, mais je pense que c'est une petite partie d'un objectif plus large.)
Il existe encore des groupes de test qui fonctionnent de cette façon, mais ce n'est plus la vue dominante. À l'époque, ça l'était. J'ai écrit avec emphase et j'ai dessiné de forts contrastes pour souligner les gens qui étaient constamment formés dans cet état d'esprit. Aujourd'hui, certains des contrastes marqués (y compris celui cité ici) sont dépassés. Ils sont mal interprétés comme des attaques contre les mauvais points de vue.
À mon avis, les tests de logiciels sont un processus empirique d'apprentissage des informations liées à la qualité d'un produit ou service logiciel.
Un test doit être conçu pour révéler des informations utiles.
À l'époque, d'ailleurs, personne ne parlait du test comme méthode pour révéler des "informations". À l'époque, les tests visaient soit (une version de ...) à trouver des bogues, soit (une version de ...) à vérifier (vérifier) le programme par rapport aux spécifications. Je ne pense pas que l'affirmation selon laquelle les tests servent à révéler des informations utiles soit entrée dans le vocabulaire des tests jusqu'à ce siècle.
Imaginez les tests de notation en fonction de leur valeur d'information. Un test qui est très susceptible de nous apprendre quelque chose que nous ne savons pas sur le logiciel aurait une valeur d'information très élevée. Un test qui est très susceptible de confirmer quelque chose que nous attendons déjà et qui a déjà été démontré à plusieurs reprises auparavant, aurait une faible valeur d'information. Une façon de hiérarchiser les tests consiste à exécuter des tests de valeur d'informations plus élevés avant des tests de valeurs d'informations plus faibles.
Si je devais simplifier à l'excès cette hiérarchisation afin qu'elle attire l'attention d'un programmeur, d'un chef de projet ou d'un responsable de processus qui n'a aucune idée des tests de logiciels, je dirais "UN TEST QUI N'EST PAS CONÇU POUR RÉVÉLER UN BOGUE EST UNE PERTE DE TEMPS . " Ce n'est pas une traduction parfaite, mais pour les lecteurs qui ne peuvent ou ne comprendront aucune subtilité ou qualification, c'est aussi proche que possible.
À l'époque, et je le revois ici, certaines personnes qui ne comprennent pas les tests répondraient qu'un test conçu pour trouver des cas d'angle est une perte de temps par rapport à un test d'une utilisation majeure d'une fonction majeure. Ils ne comprennent pas deux choses. Premièrement, lorsque les testeurs trouvent le temps de vérifier les valeurs limites, les principales utilisations des principales fonctions ont déjà été exercées plusieurs fois. (Oui, il existe des exceptions, et la plupart des groupes de tests accorderont une attention particulière à ces exceptions.) Deuxièmement, la raison pour laquelle tester avec des valeurs extrêmes est que le programme est plus susceptible d'échouer avec des valeurs extrêmes. Si cela n'échoue pas à l'extrême, vous testez autre chose. C'est une règle efficace. D'un autre côté, s'il échoue à une valeur extrême, le testeur peut s'arrêter et signaler un bug ou le testeur peut dépanner davantage, pour voir si le programme échoue de la même manière à des valeurs plus normales. Qui fait ce dépannage (le testeur ou le programmeur) est une question de culture d'entreprise. Certaines entreprises budgétisent le temps du testeur pour cela, certaines budgétisent les programmeurs et certaines s'attendent à ce que les programmeurs corrigent les bugs de coin, qu'ils soient généralisables ou non, de sorte que le dépannage ne soit pas pertinent. Le malentendu courant - que les testeurs perdent du temps (plutôt que de maximiser l'efficacité) en testant des valeurs extrêmes est une autre raison pour laquelle "Un test qui n'est pas conçu pour révéler un bug est une perte de temps" est un message approprié pour les testeurs. C'est un contrepoint à l'encouragement de certains programmeurs à (en fait) ne jamais exécuter de tests qui pourraient contester le programme. Le message est trop simplifié, mais toute la discussion est trop simplifiée.
Soit dit en passant, la «valeur de l'information» ne peut pas être le seul système de priorisation. Ce n'est pas ma règle lorsque je conçois des suites de tests unitaires. Ce n'est pas ma règle lorsque je conçois des tests de vérification de build (aka sanity checks). Dans ces deux cas, je suis plus intéressé par les types de couverture que par la puissance des tests individuels. Il existe d'autres cas (par exemple, des tests automatisés à haut volume qui sont peu coûteux à configurer, à exécuter et à surveiller) où la puissance des tests individuels n'est tout simplement pas pertinente pour ma conception. Je suis sûr que vous pouvez penser à des exemples supplémentaires.
Mais en règle générale, si je pouvais énoncer une seule règle (par exemple, parler à un cadre dont la tête explose s'il essaie de traiter plus d'une phrase), ce serait qu'un test à faible valeur d'information est généralement une perte de temps.
la source
L'idée est, selon Kaner, "puisque vous manquerez de temps avant de manquer de cas de test, il est essentiel d'utiliser le temps disponible aussi efficacement que possible."
Le concept derrière la citation que vous demandez est présenté et expliqué en détail dans l'article Testing Computer Software par Cem Kaner , Jack Falk, Hung Quoc Nguyen, dans le chapitre "LES OBJECTIFS ET LIMITES DES TESTS":
Vous voyez, le point ci-dessus est que vous devez prioriser vos tests à bon escient. Le test devrait prendre un temps limité et il est impossible de tout tester dans le temps imparti.
Imaginez que vous ayez passé une journée (semaine, mois) à exécuter des tests, à ne trouver aucun bogue et à laisser passer un bogue parce que vous n'aviez pas le temps d'exécuter un test qui le révélerait. Si cela se produit, vous ne pouvez pas simplement dire "ce n'est pas de ma faute parce que j'étais occupé à effectuer d'autres tests" pour justifier cette erreur - si vous le dites, vous serez toujours tenu responsable.
Vous avez perdu du temps à exécuter des tests qui n'ont pas révélé de bogues et à cause de cela, vous avez raté un test qui trouverait un bogue.
(Au cas où vous vous poseriez la question, les échecs comme ci-dessus sont généralement inévitables, peu importe comment vous essayez, et il existe des moyens de les résoudre, mais ce serait plus un sujet pour une question distincte ... et probablement un meilleur choix pour SQA. SE.)
la source
Eh bien, je ne connais pas M. Caner, mais à mon humble avis
sont une perte de temps. Cela inclut la situation où vous avez déjà des tests (peu importe s'ils sont automatiques ou simplement sur une liste de contrôle), et vous ajoutez de nouveaux tests qui valident essentiellement les mêmes cas que vous avez déjà. Vos nouveaux tests ne trouveront donc pas plus d'erreurs que les existants.
Une telle situation peut se produire, par exemple, si vous parcourez simplement une liste de façon aléatoire - je pourrais aussi dire «sans cervelle» (pardonnez-moi ce mot) - choisissez des cas de test dans votre programme, sans penser s'ils vérifient un nouveau cas de pointe, une nouvelle équivalence classes de vos données d'entrée, ou si elles augmentent la couverture du code par rapport aux tests déjà écrits.
la source
À mon avis, cette citation fait référence à des tests trop généraux ou non fiables.
Si vous effectuez un test pour une fonction qui valide les e-mails et que vous ne fournissez que des e-mails valides, ce test est complètement inutile. Il faudrait tester cette fonction pour "n'importe quelle" chaîne possible, courriels invalides, courriels trop longs, caractères Unicode (áêñç ....)
Si vous codez un test qui vérifie uniquement que [email protected] renvoie vrai et que nom @ com renvoie faux, ce test est identique à aucun test du tout.
la source