Introduction To Software Testing (Ammann & Offutt) mentionne à la p.32 un modèle de maturité de test à 5 niveaux:

Niveau 0 Il n'y a pas de différence entre tester et déboguer.

Niveau 1 Le but du test est de montrer que le logiciel fonctionne.

Niveau 2 Le but du test est de montrer que le logiciel ne fonctionne pas.

Niveau 3 Le but du test n'est pas de prouver quelque chose de spécifique, mais de réduire le risque d'utilisation du logiciel.

Les tests de niveau 4 sont une discipline mentale qui aide tous les professionnels de l'informatique à développer des logiciels de meilleure qualité.

Bien qu'ils n'entrent pas dans beaucoup plus de détails. Quelles sont les différences entre le débogage et les tests?

Les tests visent à trouver des défauts dans le code, ou sous un angle différent, pour prouver à un niveau approprié (il ne peut jamais être à 100%) que le programme fait ce qu'il est censé faire. Il peut être manuel ou automatisé, et il existe de nombreux types différents, comme les tests unitaires, d'intégration, de système / d'acceptation, de stress, de charge, de trempage, etc.

Le débogage est le processus de recherche et de suppression d'un bogue spécifique du programme. Il s'agit toujours d'un processus manuel unique, car tous les bogues sont différents.

Je suppose que l'auteur veut dire qu'au niveau 0, seuls des tests manuels sont effectués, de manière ad hoc, sans plan de test ou quoi que ce soit pour s'assurer que le testeur a réellement testé la fonctionnalité en cours de test et que les tests peuvent être répété de manière fiable.

Le débogage est un processus manuel étape par étape qui est impliqué, non structuré et peu fiable. En testant par le débogage, vous créez des scénarios qui ne sont pas reproductibles donc inutiles pour les tests de régression. Tous les niveaux autres que 0 (dans votre exemple) excluent le débogage à mon avis pour cette raison exacte.

Le débogage est une tentative de résolution des problèmes connus et inconnus en parcourant méthodiquement le code. Lorsque vous déboguez, vous n'êtes généralement pas concentré sur le code dans son ensemble, et vous travaillez presque toujours dans le backend, dans le code réel.

Le test est une tentative de création d'un problème par le biais de différentes manières d'utiliser le code qui peut ensuite être débogué. Cela se fait presque toujours dans l'espace utilisateur, où vous exécutez le code comme un utilisateur final l'exécuterait et essayez de le faire casser.

En termes simples, un "bug" se serait produit lorsque votre programme, lors de son exécution, ne se comporte pas comme il le devrait. Autrement dit, il ne produit pas la sortie ou les résultats attendus. Toute tentative pour trouver la source de ce bogue, trouver des moyens de corriger le comportement et apporter des modifications au code ou à la configuration pour corriger le problème peut être qualifiée de débogage.

Le test est l'endroit où vous vous assurez que le programme ou le code fonctionne correctement et de manière robuste dans différentes conditions: vous "testez" votre code en fournissant des entrées, des entrées correctes standard, des entrées intentionnellement erronées, des valeurs limites, un environnement changeant (OS, fichier de configuration) . Essentiellement, nous pouvons dire que vous essayez de découvrir des bogues et éventuellement de les «déboguer» dans le processus de test. J'espère que cela pourra aider.

Il n'y en a pas. Si vous le faites correctement:

Hit 'em High, Hit' em Low :

Test de régression et compression Saff

Kent Beck, Three Rivers Institute

Résumé: Pour isoler efficacement un défaut, commencez par un test au niveau du système et progressivement en ligne et élaguez jusqu'à ce que vous ayez le plus petit test possible qui démontre le défaut.

Le test est un privilège dont vous bénéficiez avant de le transmettre au client.

Les bugs sont un cauchemar que vous endurez après avoir été remis au client.

D'autres ont mentionné les différences entre les tests et le débogage.

Je voudrais souligner une partie commune . Lorsqu'un testeur trouve un défaut, il doit être isolé. Le débogage est l'une des techniques permettant d'isoler le problème et de trouver une cause première en analysant l'état de l'application et son code lors de l'exécution. En fait, le débogage est défini par Oxford Dictionaries comme «le processus d' identification et de suppression des erreurs du matériel informatique ou des logiciels».

Qui isolera (ou déboguera en particulier) un défaut, qu'il s'agisse d'un testeur ou d'un développeur, est une question secondaire.

Le modèle de maturité de test que vous avez répertorié est une description de la mentalité de l'équipe de développement.

Ce que la liste implique, sans le dire explicitement, c'est comment le changement de mentalité affecte la façon dont le test est effectué.

À mesure qu'une équipe de développement passe au niveau supérieur, la portée des tests s'élargit.

Au niveau 0, aucun test n'est effectué, car l'équipe pense que ce n'est pas nécessaire.

Au niveau 1, des tests sont effectués pour fournir une couverture nominale des fonctionnalités de base.

Au niveau 2, les tests sont élargis pour inclure tout ce qui se trouve au niveau 1, et ajoute des tests destructifs (une équipe de test dédiée qui a accès à toutes les informations auxquelles les développeurs ont accès, y compris le code source et les binaires, et essaie de trouver des bogues qui peuvent être déclenchée à partir d'un rôle d'utilisateur)

Au niveau 3, en plus de tout ce qui se trouve aux niveaux 1-2, des tests non fonctionnels / non basés sur l'exactitude (tels que les caractéristiques de performance) sont ajoutés.

Au niveau 4, les objectifs des tests de logiciels sont bien compris par chaque personne, y compris le personnel informatique en contact avec le client. Ainsi, le personnel informatique sera en mesure de fournir des commentaires sur les scénarios à tester, améliorant la couverture des risques du niveau 4.

(Avertissement: je n'ai pas accès au manuel, donc ma terminologie peut être incorrecte.)

Les bogues sont des erreurs visibles. Le débogage est le processus démarré après la conception du scénario de test. C'est une tâche plus difficile que de tester, car dans le processus de débogage, nous devons trouver la source de l'erreur et la supprimer, donc le débogage frustre parfois l'utilisateur.

Parlant au quotidien, en termes pratiques, je pense que cela dépend totalement du contexte .

Dans une équipe de taille moyenne, travaillant selon des normes élevées / très élevées (pensez aux systèmes bancaires, militaires, à grande échelle, à budget élevé ou aux systèmes critiques), je pense clairement que le "débogage" devrait être "le résultat de tests" , et ils sont clairement des choses très différentes . Idéalement, les tests mènent au débogage (dans un environnement intermédiaire) et en production, nous avons besoin de près de zéro.

Les tests sont de grande envergure, réguliers et très formalisés - tandis que le débogage est un processus particulier qui se produit occasionnellement lorsqu'il est nécessaire de corriger une défaillance particulière - ce qui n'est pas évident et nécessite une enquête plus approfondie sur le fonctionnement d'un système et les sorties résultantes.

Ici, dans mon esprit, le test est quelque chose d'essentiel, tandis que le débogage est un outil spécifique nécessaire uniquement lorsque la résolution d'un échec est opaque.

Je comprends parfaitement l' utilité évidente de TDD pour les grandes équipes et / ou les systèmes qui ne peuvent tout simplement pas se permettre d'être "buggy". Il est également clair que cela a beaucoup de sens pour les systèmes complexes (souvent "dorsaux") ou s'il y a une proportion élevée de complexité dans le code par rapport à la sortie. Le «test» a alors une chance réaliste d'informer quand et pourquoi les échecs se produisent. Les systèmes qui effectuent beaucoup de travaux complexes et / ou produisent des résultats clairement mesurables sont généralement facilement testables, et les tests sont donc distincts du débogage. Dans ces cas, les tests impliquent fortement une méthode formalisée, basée sur la procédure, pour confirmer ou dé-confirmer la correspondance des attentes et des résultats réels. Les tests ont lieu tout le temps et nous informent parfois de la nécessité d'un débogage.

Ce serait bien si c'était une vérité omniprésente, j'adorerais que mes cycles de développement soient délimités par une sortie binaire clairement définie (rouge, verte) mais ...

Dans mon cas (ce qui est certes particulier - travailler à 98% en solo sur des systèmes d'administration d'entreprise basés sur le Web de petite à moyenne taille, sous-financés), je ne vois vraiment pas comment TDD pourrait m'aider. Ou plutôt «débogage» et «test» sont pratiquement les mêmes.

Principalement, si l'utilisation du terme "test" implique / est étroitement liée à la méthodologie de TDD.

Je sais que c'est une chose totalement, totalement anti -Zeitgeist "fuyez le non-croyant, fuyez, fuyez", chose horriblement moche à dire. Mais en pensant à mon contexte, avec un chapeau pratique, je ne le fais même pas vaguement, dans mon imagination la plus folle, je vois comment TDD pourrait m'aider à offrir un meilleur rapport qualité-prix à mes clients.

Ou plutôt, je suis fortement en désaccord avec l'hypothèse courante selon laquelle "tester" est un processus formel basé sur du code.

Mon objection fondamentale (applicable dans mon particulier contexte *) est que ...

Si je ne peux pas écrire du code qui fonctionne de manière fiable - alors comment diable suis-je censé écrire du code qui fonctionne de manière fiable pour tester ledit code vraisemblablement sous-standard.

Pour moi, je n'ai jamais vu d'exemple ni d'argument qui (dans mon contexte particulier) m'ait suffisamment enthousiasmé pour même prendre la peine de penser à écrire un seul test , je pourrais écrire un code de test ridiculement insignifiant en ce moment, peut-être "mon référentiel renvoie-t-il un utilisateur entité avec Nom == X, quand je lui demande exactement - et seulement - cela? ", mais il y a probablement plus d'utilité en moi à écrire ce streaming, peut-être-l'Internet-vraiment-est-juste-pur-idiot-jaillissant- auto-gratifiant-follement sous-informé-sang-bouillant-ignorant-gaspillage-idiot, mais je ressens juste le besoin de jouer l'avocat du diable ici. (J'espère que quelqu'un va me montrer la lumière et me convertir, peut-être que cela finira par donner à mes clients un meilleur rapport qualité-prix?).

On peut dire que le «débogage» est parfois le même que le «test». Par cela, je veux vraiment dire que dans ma vie professionnelle quotidienne, je passe au moins un tiers de mon temps à jouer avec la version locale de mon système dans différents navigateurs, essayant désespérément diverses choses loufoques différentes pour tenter de casser mon travail, puis enquêter sur les raisons pour lesquelles il a échoué et les corriger.

Je suis à 100% d'accord avec l'utilité évidente du mantra TDD "rouge / vert / refactor", mais pour moi (travaillant avec un petit budget med, solo dev RIA land), j'aimerais vraiment que quelqu'un me montre comment je pourrais peut - être , logiquement et de façon réaliste, obtenir une valeur supplémentaire en écrivant plus ( tout comme un code de test potentiellement défectueux ) que je ne le fais en interagissant avec la sortie complète (et essentiellement uniquement) de mes efforts qui sont essentiellement liés à une interaction humaine réelle.

Pour moi, lorsque les développeurs parlent de "tests", cela implique généralement TDD.

J'essaie de coder comme s'il y avait des tests, je pense que tous les modèles / pratiques et tendances que tout ce développement axé sur les tests a encouragés sont fantastiques et beaux, mais pour moi dans mon petit monde, "tester" n'écrit pas plus de code, c'est en fait tester le monde réel le produit de manière réaliste, et c'est pratiquement la même chose que le débogage, ou plutôt le changement actif ici est le "débogage" qui est le résultat direct de "tests" non automatisés centrés sur la sortie humaine. Cela contraste avec la conception généralement acceptée du «test» comme quelque chose d'automatisé et de formel, et du «débogage» comme quelque chose d'humain et ad hoc ou non structuré.

Si l'objectif est vraiment le rapport qualité / prix et l'effort, et que vous créez des applications interactives basées sur le Web, alors la sortie de l'effort est les pages Web et très essentiellement comment elles réagissent aux entrées humaines - donc "tester" est mieux réalisé en testant ces pages Web, grâce à une véritable interaction humaine. Lorsque cette interaction conduit à des sorties inattendues ou indésirables, le "débogage" se produit. Le débogage est également étroitement lié à l'idée d'une inspection en temps réel de l'état du programme. Les tests sont généralement associés à l'automatisation qui, je pense, est souvent une association malheureuse.

Si l'objectif est vraiment la valeur de l'effort et que les tests automatisés sont efficaces et très bénéfiques, alors que le débogage n'est qu'un résultat de ces tests ou un mauvais substitut aux tests automatisés, alors pourquoi est le deuxième site Web le plus visité au monde (Facebook ) si souvent criblé de bugs aveuglément évidents (pour les utilisateurs, mais clairement pas pour l'équipe de test et le code de test)?

Peut-être que c'est parce qu'ils se concentrent sur les feux verts rassurants et oublient d'utiliser réellement les sorties de leur travail?

Trop de développeurs pensent-ils que le test est quelque chose que vous faites avec du code, et que le débogage est quelque chose que vous faites occasionnellement avec l'IDE parce qu'une icône devient rouge et vous ne pouvez pas comprendre pourquoi? Je pense que ces mots ont des jugements de valeur malheureux qui leur sont associés, qui obscurcissent généralement la réalité pratique de ce sur quoi nous devrions nous concentrer pour combler les écarts entre les attentes et les résultats.

Simplement,

Test signifie, trouver les entrées qui provoquent la défaillance d'un logiciel pendant le débogage est le processus de recherche de la faute d'une défaillance donnée.