Einführung in das Testen von Software (Ammann & Offutt) erwähnt auf S.32 ein 5-stufiges Testreife-Modell:

Level 0 Es gibt keinen Unterschied zwischen Testen und Debuggen.

Stufe 1 Der Zweck des Testens besteht darin, zu zeigen, dass die Software funktioniert.

Stufe 2 Der Zweck des Testens besteht darin, zu zeigen, dass die Software nicht funktioniert.

Stufe 3 Der Zweck des Testens besteht nicht darin, etwas Spezifisches zu beweisen, sondern das Risiko der Verwendung der Software zu verringern.

Level 4 Testing ist eine mentale Disziplin, die allen IT-Fachleuten hilft, qualitativ hochwertigere Software zu entwickeln.

Obwohl sie nicht viel weiter ins Detail gehen. Was sind die Unterschiede zwischen Debuggen und Testen?

Das Testen soll Fehler im Code oder aus einem anderen Blickwinkel finden, um auf einem geeigneten Niveau (es kann niemals 100% sein) zu beweisen, dass das Programm das tut, was es tun soll. Es kann manuell oder automatisiert sein und es gibt viele verschiedene Arten, wie Einheits-, Integrations-, System- / Akzeptanz-, Belastungs-, Last-, Einweich- usw. Tests.

Beim Debuggen wird ein bestimmter Fehler gefunden und aus dem Programm entfernt. Es ist immer ein manueller, einmaliger Vorgang, da alle Fehler unterschiedlich sind.

Ich vermute, dass der Autor bedeutet, dass auf Stufe 0 nur manuelle Tests ad hoc ohne Testplan oder irgendetwas durchgeführt werden, um sicherzustellen, dass der Tester die zu testende Funktion tatsächlich gründlich getestet hat und dass die Tests durchgeführt werden können zuverlässig wiederholt.

Das Debuggen ist ein manueller Schritt-für-Schritt-Prozess, der unstrukturiert und unzuverlässig ist. Durch Testen durch Debuggen erstellen Sie Szenarien, die nicht wiederholbar sind und daher für Regressionstests unbrauchbar sind. Alle Ebenen außer 0 (in Ihrem Beispiel) schließen aus meiner Sicht das Debuggen aus genau diesem Grund aus.

Das Debuggen ist ein Versuch, bekannte und unbekannte Probleme durch methodisches Durchgehen des Codes zu beheben. Beim Debuggen konzentrieren Sie sich normalerweise nicht auf den Code als Ganzes und arbeiten fast immer im Backend, im eigentlichen Code.

Das Testen ist ein Versuch, ein Problem durch verschiedene Verwendungsmöglichkeiten des Codes zu erstellen, der dann debuggt werden kann. Dies geschieht fast immer im Benutzerbereich, in dem Sie den Code so ausführen, wie ein Endbenutzer ihn ausführen würde, und versuchen, ihn zum Brechen zu bringen.

In einfachen Worten, ein "Fehler" soll aufgetreten sein, wenn sich Ihr Programm bei der Ausführung nicht so verhält, wie es sollte. Das heißt, es werden nicht die erwarteten Ergebnisse oder Ergebnisse erzielt. Jeder Versuch, die Ursache dieses Fehlers zu finden, Möglichkeiten zur Korrektur des Verhaltens zu finden und Änderungen am Code oder an der Konfiguration vorzunehmen, um das Problem zu beheben, kann als Debugging bezeichnet werden.

Beim Testen stellen Sie sicher, dass das Programm oder der Code unter verschiedenen Bedingungen korrekt und robust funktioniert: Sie "testen" Ihren Code, indem Sie Eingaben, standardmäßige korrekte Eingaben, absichtlich falsche Eingaben, Grenzwerte und sich ändernde Umgebungen (Betriebssystem, Konfigurationsdatei) bereitstellen. . Im Wesentlichen können wir sagen, dass Sie versuchen, Fehler zu entdecken und sie schließlich im Testprozess zu "debuggen". Hoffentlich hilft das.

Da sind keine. Wenn Sie es richtig machen:

Hit 'em High, Hit' em Low :

Regressionstests und der Saff Squeeze

Kent Beck, Drei-Flüsse-Institut

Zusammenfassung: Um einen Fehler effektiv zu isolieren, beginnen Sie mit einem Test auf Systemebene und inline und beschneiden Sie ihn schrittweise, bis Sie den kleinstmöglichen Test haben, der den Fehler nachweist.

Das Testen ist ein Privileg, das Sie genießen, bevor Sie es an den Client weitergeben.

Bugs sind ein Albtraum, den Sie nach der Freigabe an den Client ertragen.

Andere haben erwähnt, was Unterschiede zwischen Testen und Debuggen sind.

Ich möchte einen gemeinsamen Teil hervorheben . Wenn ein Tester einen Defekt feststellt, muss dieser isoliert werden. Das Debuggen ist eine der Techniken, um das Problem zu isolieren und eine Grundursache zu finden, indem der Anwendungsstatus und sein Code zur Laufzeit analysiert werden. Tatsächlich wird das Debuggen von Oxford Dictionaries als "der Prozess des Identifizierens und Entfernens von Fehlern von Computerhardware oder -software" definiert.

Wer einen Fehler isoliert (oder insbesondere debuggt), sei es ein Tester oder ein Entwickler, ist eine sekundäre Frage.

Das von Ihnen aufgeführte Testreife-Modell beschreibt die Mentalität des Entwicklungsteams.

Die Liste impliziert, ohne explizit zu sagen, wie sich die Änderung der Mentalität auf die Art und Weise auswirkt, wie Tests durchgeführt werden.

Wenn ein Entwicklungsteam die nächste Stufe erreicht, wird der Testumfang erweitert.

Auf Stufe 0 werden keine Tests durchgeführt, da das Team dies für nicht erforderlich hält.

Auf Stufe 1 werden Tests durchgeführt, um eine nominelle Abdeckung der grundlegenden Funktionen zu gewährleisten.

Auf Stufe 2 wird das Testen erweitert, um alles in Stufe 1 einzuschließen, und es werden destruktive Tests hinzugefügt (ein dediziertes Testteam, das Zugriff auf alle Informationen hat, auf die Entwickler Zugriff haben, einschließlich Quellcode und Binärdateien, und versucht, mögliche Fehler zu finden ausgelöst von einer Benutzerrolle)

Auf Stufe 3 werden zusätzlich zu allem in Stufe 1-2 nicht funktionsbasierte Tests / nicht auf Korrektheit basierende Tests (z. B. Leistungsmerkmale) hinzugefügt.

Auf Stufe 4 sind die Ziele des Softwaretests von jeder Person, einschließlich der kundenorientierten IT-Mitarbeiter, gut verstanden. Auf diese Weise können IT-Mitarbeiter Feedback zu den zu testenden Szenarien geben und so die Risikodeckung von Level 4 verbessern.

(Haftungsausschluss: Ich habe keinen Zugriff auf das Lehrbuch, daher ist meine Terminologie möglicherweise falsch.)

Fehler sind sichtbare Fehler. Das Debuggen ist der Prozess, der nach dem Design des Testfalls gestartet wird. Es ist eine schwierigere Aufgabe als das Testen, da wir beim Debuggen die Fehlerquelle herausfinden und beseitigen müssen, sodass das Debuggen manchmal den Benutzer frustriert.

Wenn ich alltäglich und praktisch spreche, denke ich, dass es völlig vom Kontext abhängt .

In einem mittelgroßen Team, das nach hohen / sehr hohen Standards arbeitet (denken Sie an Bank-, Militär-, Groß-, Hochbudget- oder geschäftskritische Systeme), sollte "Debuggen" eindeutig "ein Ergebnis von Tests" sein , und das sind sie eindeutig ganz andere Dinge . Im Idealfall führt das Testen zum Debuggen (in einer Staging-Umgebung), und in der Produktion benötigen wir nahezu Null von beiden.

Das Testen ist umfangreich, regelmäßig und sehr formalisiert - während das Debuggen ein besonderer Prozess ist, der gelegentlich auftritt, wenn ein bestimmter Fehler behoben werden muss -, was nicht offensichtlich ist und eine eingehendere Untersuchung der Funktionsweise und der daraus resultierenden Ergebnisse eines Systems erfordert.

In meinen Augen ist das Testen etwas Wesentliches, während das Debuggen ein spezielles Werkzeug ist, das nur benötigt wird, wenn die Lösung eines Fehlers undurchsichtig ist.

Ich verstehe den offensichtlichen Nutzen von TDD für große Teams und / oder Systeme, die es sich einfach nicht leisten können, "fehlerhaft" zu sein. Dies ist auch für komplexe (häufig "Back-End") Systeme sehr sinnvoll oder wenn der Code im Vergleich zur Ausgabe einen hohen Anteil an Komplexität aufweist. Dann hat "Testen" eine realistische Chance zu informieren, wann und warum Fehler auftreten. Systeme, die viel komplexe Arbeit leisten und / oder zu klar messbaren Ergebnissen führen, sind im Allgemeinen leicht testbar. Daher unterscheidet sich das Testen vom Debuggen. In diesen Fällen impliziert das Testen nachdrücklich eine verfahrensbasierte, formalisierte Methode zur Bestätigung oder Nichtbestätigung der Übereinstimmung von Erwartungen und tatsächlichem Output. Das Testen findet ständig statt und informiert uns gelegentlich über die Notwendigkeit des Debuggens.

Es wäre schön, wenn dies eine allgegenwärtige Wahrheit wäre. Ich würde es lieben, wenn meine Entwicklungszyklen durch klar definierte Binärausgaben (rot, grün) begrenzt wären, aber ...

In meinem Fall (der zugegebenermaßen besonders ist - ich arbeite zu 98% allein an kleinen, mittelgroßen, unterfinanzierten, webbasierten, datenorientierten Unternehmensadministrationssystemen) kann ich einfach nicht wirklich sehen, wie TDD mir möglicherweise helfen könnte. Oder besser gesagt, "Debuggen" und "Testen" sind praktisch gleich.

Hauptsächlich, obwohl die Verwendung des Begriffs "Testen" die Methodik von TDD impliziert / eng damit zusammenhängt.

Ich weiß, dass dies eine völlig unzeitgeistige "meide den Ungläubigen, meide, meide" ist, eine verabscheuungswürdige, nicht coole Sache zu sagen. Aber wenn ich an meinen Kontext denke, mit einem praktischen Hut auf, sehe ich in meiner wildesten Fantasie nicht einmal vage, wie TDD mir möglicherweise helfen könnte, meinen Kunden ein besseres Preis-Leistungs-Verhältnis zu bieten.

Oder besser gesagt, ich stimme der allgemeinen Annahme, dass "Testen" ein formaler Code-basierter Prozess ist, überhaupt nicht zu.

Mein grundlegender Einwand (anwendbar in meinem speziellen * Kontext *) ist, dass ...

Wenn ich keinen Code schreiben kann, der zuverlässig funktioniert - wie zum Teufel soll ich dann Code schreiben, der zuverlässig funktioniert, um den vermutlich unterdurchschnittlichen Code zu testen ?

Für mich habe ich noch nie ein Beispiel oder Argument gesehen, das mich (in meinem speziellen Kontext) so begeistert hat , dass ich überhaupt über das Schreiben eines einzelnen Tests nachdenken konnte. Ich könnte gerade einen lächerlich unwesentlichen Testcode schreiben, vielleicht "gibt mein Repository einen Benutzer zurück Entität mit Name == X, wenn ich genau - und nur - danach frage? ", aber es ist wahrscheinlich nützlicher, wenn ich dieses Streaming schreibe, vielleicht ist das Internet wirklich nur ein bloßes, dummes Ausspritzen. Selbstbefriedigend-wild-unter-informiert-Blut-kochend-bedeutend-verschwenderisch-alberner Müll, aber ich habe nur das Bedürfnis, hier den Anwalt des Teufels zu spielen. (Ich hoffe, jemand zeigt mir das Licht und bekehrt mich. Vielleicht bietet dies meinen Kunden ein besseres Preis-Leistungs-Verhältnis?)

Wahrscheinlich ist "Debuggen" manchmal dasselbe wie "Testen". Damit meine ich wirklich, dass ich in meinem täglichen Arbeitsleben mindestens ein Drittel meiner Zeit damit verbringe, mit der lokalen Version meines Systems in verschiedenen Browsern herumzuspielen, verzweifelt verschiedene verrückte Dinge auszuprobieren, um meine Arbeit zu brechen und dann Nachforschungen anzustellen die Gründe, warum es fehlgeschlagen ist und sie zu korrigieren.

Ich stimme zu 100% dem offensichtlichen Nutzen des TDD-Mantras "Rot / Grün / Refaktor" zu, aber für mich (Arbeiten in Low-Med-Budget, Solo-Entwickler-RIA-Land) würde ich es wirklich lieben, wenn jemand mir bitte zeigt, wie ich könnte möglicherweise , logisch und äußerst realistisch keine zusätzlichen Wert erhalten von mehr schreiben ( nur als potentiell fehlerhaft testen Code) als ich von tatsächlich mit der vollen (und im wesentlichen nur) Ausgabe meiner Bemühungen in Wechselwirkung, die Wechselwirkung echten menschlichen wesentlichen gebunden sind.

Wenn Entwickler über "Testen" sprechen, bedeutet dies für mich im Allgemeinen TDD.

Ich versuche zu codieren, als ob es Tests gäbe. Ich denke, alle Muster / Praktiken und Trends, die all diese testorientierte Entwicklung gefördert hat, sind fantastisch und schön, aber für mich in meiner kleinen Welt bedeutet "Testen" nicht, mehr Code zu schreiben, sondern tatsächlich Das Testen der realen Welt gibt es auf eine nahezu realistische Weise aus, und das ist praktisch dasselbe wie das Debuggen, oder vielmehr ist die aktive Änderung hier das "Debuggen", das ein direktes Ergebnis menschlicher, ausgabezentrierter, nicht automatisierter "Tests" ist. Dies steht im Gegensatz zu der allgemein akzeptierten Ansicht, "Testen" als etwas Automatisiertes und Formales und "Debuggen" als etwas Menschliches und Ad-hoces oder Unstrukturiertes.

Wenn das Ziel wirklich ein gutes Preis-Leistungs-Verhältnis ist und Sie webbasierte interaktive Anwendungen erstellen, sind die Webseiten die Ausgabe der Bemühungen und im Wesentlichen die Art und Weise, wie sie auf menschliche Eingaben reagieren. Daher wird "Testen" am besten durch Testen erreicht diese Webseiten durch echte menschliche Interaktion. Wenn diese Interaktion zu unerwarteten oder unerwünschten Ausgaben führt, tritt "Debugging" auf. Das Debuggen ist auch eng mit der Idee der Echtzeitprüfung des Programmstatus verbunden. Testen ist im Allgemeinen mit Automatisierung verbunden, was meiner Meinung nach oft eine unglückliche Verbindung ist.

Wenn das Ziel wirklich ein Wert für den Aufwand ist und automatisierte Tests effizient und äußerst vorteilhaft sind, während das Debuggen entweder nur eine Ausgabe dieser Tests oder ein schlechter Ersatz für automatisierte Tests ist, warum ist dann die am zweithäufigsten besuchte Website der Welt (Facebook)? ) so oft mit verblüffend offensichtlichen (für Benutzer, aber eindeutig nicht für das Testteam und den Testcode) Fehlern durchsetzt?

Vielleicht liegt es daran, dass sie sich auf die beruhigenden grünen Lichter konzentrieren und vergessen, die Ergebnisse ihrer Arbeit tatsächlich zu nutzen?

Denken zu viele Entwickler, dass Sie mit Code testen und gelegentlich mit der IDE debuggen, weil ein Symbol rot wird und Sie nicht herausfinden können, warum? Ich denke, mit diesen Worten sind unglückliche Werturteile verbunden, die im Allgemeinen die praktische Realität dessen verschleiern, worauf wir uns konzentrieren sollten, um die Lücken zwischen Erwartungen und Ergebnissen zu schließen.

Einfach,

Testen bedeutet, dass das Finden der Eingaben, die dazu führen, dass eine Software beim Debuggen fehlschlägt, der Prozess ist, bei dem der Fehler eines bestimmten Fehlers gefunden wird.