Was ist destruktives Testen in der Softwareentwicklung?

⚡ Intelligente Zusammenfassung

Destruktive Tests treiben eine Softwareanwendung gezielt bis zum Ausfall und decken so genau die Punkte auf, an denen die Robustheit bei unsachgemäßer Verwendung, ungültigen Eingaben und unvorhersehbarem Verhalten versagt, die bei gewöhnlichen Funktionsprüfungen nie erreicht werden.

  • 💥 Kernidee: Die Anwendung ist absichtlich so konzipiert, dass sie versagt, damit ihre Fehlerquellen sichtbar und messbar werden.
  • 🔎 Keine Voraussetzungen erforderlich: Vorkenntnisse der Spezifikation sind optional, verbessern aber die Teststrategie.
  • Gegensätzliches Paar: Die zerstörungsfreie Prüfung beschreitet den optimalen Weg; die zerstörende Prüfung greift ihn aus jedem falschen Blickwinkel an.
  • 🧰 Nähert sich: Fehleranalyse, Peer-Review der Tester, Business-Review und explorative Testläufe mit Testprotokollen.
  • 🧪 Wiederverwendete Methoden: Regressionstests, Schnittstellentests, Äquivalenzklassentests, Schleifentests und Akzeptanztests dienen allesamt destruktiven Zielen.
  • 📉 Ehrliche Grenzen: Eine umfassende Berichterstattung ist schwer zu gewährleisten, der Aufwand ist hoch und die Ergebnisse lassen sich unter Umständen nur schwer reproduzieren.

Was ist destruktives Testen in der Softwareentwicklung und welche Methoden und Techniken werden angewendet?

Was ist zerstörende Prüfung?

Destruktives Testen Destruktives Testen ist eine Softwaretestmethode, die dazu dient, Schwachstellen in einem Softwareprogramm aufzuspüren. Dabei wird eine Anwendung absichtlich zum Absturz gebracht, um ihre Robustheit zu überprüfen und ihre Schwachstellen zu identifizieren. Im Gegensatz zu Testmethoden, die das erwartete Verhalten der Anwendung überprüfen, untersucht destruktives Testen unvorhersehbares Benutzerverhalten innerhalb der Anwendung.

Kenntnisse der ursprünglichen Anforderungen sind für zerstörende Prüfungen nicht notwendig. Etwas Wissen ist jedoch bei der Entwicklung hilfreich.ping eine gute Teststrategie.

Die folgende Abbildung veranschaulicht die Idee – der Tester arbeitet gegen das Produkt, nicht mit ihm.

Konzept des zerstörenden Testens: Eine Anwendung wird absichtlich bis zum Ausfallpunkt belastet.

Warum werden zerstörende Prüfverfahren angewendet?

  • Es hilft dabei, das vorhersehbare Verhalten der Software zu verstehen, wenn die Software unsachgemäß verwendet wird.
  • Es hilft, die Robustheit eines Softwareprodukts zu überprüfen.
  • Es deckt seltene Fehler auf, die normale Benutzer nie auslösen, die aber später in der Produktion auftreten.

Zerstörende Prüfung vs. zerstörungsfreie Prüfung

Die beiden Ansätze ergänzen sich, sie stehen nicht in Konkurrenz zueinander. Zerstörungsfreie Analyse Beim sogenannten Positivtest oder Happy-Path-Test interagiert die Software korrekt mit ihr und der Build bleibt intakt. Der destruktive Test hingegen führt ungültige Daten und falsche Sequenzen ein, bis ein Fehler auftritt.

Aspekt Destruktives Testen Zerstörungsfreie Analyse
Absicht Die Anwendung zum Scheitern bringen Bestätigen Sie, dass die Anwendung wie angegeben funktioniert.
Eingabe verwendet Ungültig, fehlerhaft, außerhalb des zulässigen Bereichs, nicht in der richtigen Reihenfolge Gültige Daten innerhalb des erwarteten Bereichs
Frage beantwortet Wo und wie geht es kaputt? Erfüllt es seinen Zweck?
Kenntnisse der Anforderungen Optional Essential
Typische Kosten Höher – explorativ und ergebnisoffen. Niedriger – vorgegeben und wiederholbar
Ergebnis Fehlerpunkte, Bereichsgrenzen, Wiederherstellungsverhalten Bestanden oder nicht bestanden gemäß der Spezifikation

Was prüft man bei zerstörenden Prüfverfahren?

Destruktive Tests betrachten beide Seiten der Verhaltensgrenze:

  • Korrektes Softwareverhalten
  • Unsachgemäßes Softwareverhalten
  • Missbrauch
  • Falsche Eingabedaten
  • Richtige Ausgabedaten

Zwei Bedingungen müssen während der gesamten Übung erfüllt sein:

  • Die Software darf niemals ungültige Eingabedaten verarbeiten oder akzeptieren.
  • Ungeachtet der Gültigkeit oder Korrektheit der Eingabedaten sollte die Software stets korrekte Ausgabedaten erzeugen.

Wie führt man zerstörende Tests durch?

Destruktives Testen umfasst viele Aktivitäten, wie zum Beispiel das Entwerfen eines Satzes von Testskripten, das Ausführen dieser Skripte, das Melden von Fehlern, das Schließen von Fehlern und das Bereitstellen von Erfolgs- oder Misserfolgsmetriken für die Stakeholder am Ende der Iteration.

Es gibt zahlreiche Möglichkeiten, es auszuführen. Einige Beispiele folgen.

  • Methode der Fehlerpunktanalyse: Ein Überblick über das System, der bewertet, was an verschiedenen Stellen schiefgehen könnte. Hilfe von einem Business Analyst kann für diese Strategie in Betracht gezogen werden.
  • Peer-Review der Tester: bekomm dein Testfälle analysiert oder überprüft von einem anderen Tester, der mit dem System oder der Funktion weniger vertraut ist.
  • Geschäftliche Überprüfung der Testfälle: Endnutzer oder Experten denken oft an plausible Szenarien, die Tester übersehen, weil sich der Fokus des Testers auf die vorgegebenen Anforderungen richtet.
  • Führen Sie explorative Tests mithilfe von Testprotokollen durch: exploratives Testen Mithilfe von Testprotokollen wird festgehalten, was getestet wurde, die Wiederholung der Tests ermöglicht und die Testabdeckung unter Kontrolle gehalten.
  • Verwenden Sie eine andere Quelle: Bitten Sie eine andere Person, das Softwareprodukt zum Absturz zu bringen und die dabei auftretenden Szenarien zu analysieren.

Beispiel für eine zerstörende Prüfung

Betrachten wir die Anmelde- und Profilseiten einer Banking-Anwendung. Ein destruktiver Pass würde in Fällen wie diesen ablaufen:

  • Fügen Sie eine 5,000 Zeichen lange Zeichenkette in ein Feld ein, das auf 50 Zeichen begrenzt ist, und überprüfen Sie, ob das Feld die Zeichenkette ablehnt, anstatt sie stillschweigend abzuschneiden.
  • Geben Sie Buchstaben, Symbole und negative Werte in ein numerisches Betragsfeld ein.
  • Durchbrechen Sie die erwartete Abfolge – öffnen Sie die Zahlungsbestätigungsseite direkt, ohne den vorhergehenden Schritt abzuschließen.
  • Drücken Sie wiederholt und schnell hintereinander auf „Absenden“, um zu sehen, ob doppelte Datensätze erstellt werden.
  • Trennen Sie die Netzwerkverbindung während der Transaktion und prüfen Sie, ob die Anwendung sich fehlerfrei erholt oder einen unvollständigen Datensatz hinterlässt.

Jeder Fall hat eine definierte Erwartung: eine eindeutige Validierungsmeldung, keine Datenbeschädigung und keine unbehandelte Ausnahme. Alles andere stellt einen Fehler dar, der als Defekt gemeldet werden muss.

Zerstörende Prüfmethoden

Folgende Methoden werden in der Softwareentwicklung eingesetzt, um die Ziele destruktiver Tests zu erreichen:

Zerstörende Prüftechniken

Die folgenden Techniken können mit Anpassungen angewendet werden:

Folgende angrenzende Techniken sind sinnvoll, wenn Robustheit das Ziel ist: negative Prüfung, Stress-Tests, Wiederherstellungstests und Fuzz-Tests.

Vorteile und Nachteile zerstörender Prüfverfahren

Der damit verbundene Kompromiss sollte klar benannt werden, bevor die Technik in eine Veröffentlichung eingeplant wird.

Vorteile

  • RevErkennt Schwachstellen, die bei spezifikationsbasierten Tests nie auftreten.
  • Legt realistische Reichweitengrenzen fest, sodass das Produkt innerhalb dieser Grenzen bedenkenlos eingesetzt werden kann.
  • Deckt seltene Mängel auf, die erst lange nach der Markteinführung in der Produktion auftreten.
  • Prüft Haltbarkeit, Wiederherstellbarkeit und Fehlerbehandlung unter Missbrauchsbedingungen.

Nachteile

  • Da es sich naturgemäß um ein offenes System handelt, kann der Umfang weder garantiert noch einfach gemessen werden.
  • Zeitaufwändig und abhängig von der Erfahrung und Kreativität der Tester.
  • Die Ergebnisse lassen sich ohne sorgfältige Protokollierung der durchgeführten Schritte nur schwer reproduzieren.
  • Schlecht kontrollierte Testläufe können gemeinsam genutzte Testdaten beschädigen, daher ist eine isolierte Umgebung erforderlich.

Häufig gestellte Fragen

Sie überschneiden sich, unterscheiden sich aber im Umfang. Negativtest Es werden definierte ungültige Eingaben mit der erwarteten Fehlerbehandlung abgeglichen. Destruktive Tests sind umfassender und ergebnisoffen und suchen nach jeder Bedingung, die zum Absturz der Anwendung führt.

In der Regel sind dies erfahrene QA-Ingenieure, unterstützt von Kollegen, die mit dem Modul nicht vertraut sind, und von Anwendern aus dem Fachbereich. Die Perspektive von außen ist wichtig, da die Entwickler der Funktion diese tendenziell so testen, wie sie konzipiert wurde.

Sobald die Funktionssuite stabil ist, deuten Fehler eher auf mangelnde Robustheit als auf unfertige Funktionen hin. Viele Teams planen dies während der Systemtests ein und wiederholen es vor größeren Releases. Testlebenszyklus.

Die Modelle erzeugen fehlerhafte Nutzdaten, Grenzwerte und ungewöhnliche Aktionssequenzen in einem Umfang, den kein Tester erreichen kann, und ordnen diese anschließend nach ihrer Anomalie. Maschinelles Lernen anhand vergangener Fehlerdaten sagt zudem voraus, welche Module die strengste Behandlung erfordern.

GitHub-Copilot Er erstellt schnell Eingabegeneratoren, Grenzwerttests und Deaktivierungsroutinen. Der Tester entscheidet weiterhin, welche Fehlermodi relevant sind und ob das beobachtete Verhalten als akzeptables Ergebnis gilt.

Die genauen Eingaben bzw. die verwendete Sequenz, der beobachtete Fehler, Protokolle und Screenshots, die Umgebung und die Schwere der Auswirkungen. Die Kennzahlen für Erfolg oder Misserfolg der Iteration werden zusammen mit den anderen Beteiligten an die Stakeholder übermittelt. Fehlerprotokolle.

Es sollte niemals mit der Produktionsumgebung in Berührung kommen. Führen Sie es in einer isolierten Umgebung mit wiederherstellbaren Daten aus, da absichtlich ungültige Eingaben und erzwungene Abstürze unvollständige Datensätze hinterlassen können, deren Bereinigung aufwändig ist.

Führen Sie während der Sitzung ein Ablaufprotokoll, in dem jede Aktion und Eingabe in der richtigen Reihenfolge aufgezeichnet wird. Spielen Sie das Protokoll aus einem fehlerfreien Zustand ab und reduzieren Sie es dann auf die kürzeste Sequenz, die den Fehler noch auslöst.

Fassen Sie diesen Beitrag mit folgenden Worten zusammen: