Quelle est la différence entre le débogage et les tests?
Introduction To Software Testing (Ammann & Offutt) mentionne à la p.32 un modèle de maturité de test à 5 niveaux:
Niveau Il n'y a aucune différence entre le test et le débogage.
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 Le but du test n'est pas de prouver quelque chose de spécifique, mais de réduire le risque d'utilisation du logiciel.
Niveau 4 Les tests 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 signifie que, 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é sous 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é quelles sont différences entre le test 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 pour isoler le problème et trouver une cause première en analysant l'état de l'application et son code au moment 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.
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.
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 est élargie.
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 ainsi la couverture des risques du niveau 4.
(Avertissement: je n'ai pas accès au manuel, donc ma terminologie peut être incorrecte.)
Parlant en termes quotidiens et pratiques, je pense que c'est totalement dépend 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 critiques), alors je pense clairement le "débogage" devrait être "le résultat de tests", et ils sont clairement 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 le tilité évidente dans 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 "back-end") 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 (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 et sous-financés) Je ne vois vraiment pas comment TDD pourrait peut-être m'aider. Ou plutôt "débogage" et "tests" sont pratiquement les mêmes.
Principalement, si l'utilisation du terme "test" implique/est étroitement liée à la méthodologie du TDD.
Je sais que c'est une 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 de base (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 déranger la réflexion sur en écrivant un seul test , je pourrais écrire du code de test ridiculement insignifiant en ce moment, peut-être "mon référentiel renvoie-t-il une entité utilisateur avec Nom == X, quand je lui demande exactement - et seulement - ça? ", mais il y a probablement plus d'utilité en moi à écrire ce streaming, peut-être-Internet-vraiment-est-juste-pur-idiot-jaillissant-auto-gratifiant-sauvagement-sous-informé-sang-bouillant-ignorant- des ordures inutiles, mais je ressens juste le besoin de jouer l'avocat du diable ici. (En quelque sorte, j'espère que quelqu'un me montrera la lumière et me convertira, 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 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 dans un budget à faible budget, dev solo RIA land), j'aimerais vraiment que quelqu'un me montre comment je pourrais éventuellement , logiquement et vitalement réaliste obtenez une valeur supplémentaire en écrivant plus ( tout comme potentiellement défectueux code de test) que je n'interagis réellement avec la sortie complète (et essentiellement uniquement) de mes efforts qui sont essentiellement liés à une véritable interaction humaine.
Pour moi, lorsque les développeurs parlent de "test", 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 d'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 ils réagissent à l'entrée humaine - donc " testing "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 bogues 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?
Est-ce que trop de développeurs pensent 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 le IDE parce qu'une icône devient rouge et vous ne pouvez pas comprendre pourquoi? Je pense que ces mots des jugements de valeur malheureux 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.