Können wir beim Testen von Software davon ausgehen, dass ein Benutzer keine so dummen Aktionen mit Software ausführt?

Beispiel: Während der Funktionsprüfung eines Formulars in einer Webanwendung werden die Felder getestet, indem verschiedene Arten von Zufallseingabewerten eingegeben werden.

Im Allgemeinen geben wir als Benutzer der Webanwendung keine zufälligen Werte in Felder ein.

Was nützt es also, all diese Testfälle einzubeziehen, die zu Fehlern führen können oder nicht, wenn die Wahrscheinlichkeit, dass solche Probleme in der Produktion auftreten, viel geringer ist?

Hinweis: Das obige Beispiel ist nur ein Beispielfall. Solche Probleme können bei jeder Art von Funktion / Modul auftreten.

Ich stelle diese Frage nur, um zu wissen, ob es Standardpraktiken gibt, die befolgt werden müssen, oder ob sie vollständig vom Produkt, der Domäne und allen anderen Faktoren abhängen.

Möglicherweise geben Sie keine Zufallswerte in Felder einer Webanwendung ein, aber es gibt sicherlich Leute, die genau das tun.

Einige Personen werden zufällig eingegeben, andere versuchen absichtlich, die Anwendung zu unterbrechen. In beiden Fällen soll die Anwendung nicht abstürzen oder ein anderes unerwünschtes Verhalten aufweisen.
Für den ersten Benutzertyp möchten Sie das nicht, weil es ihnen eine schlechte Erfahrung macht und sie möglicherweise abweisen kann.
Für den zweiten Benutzertyp haben sie normalerweise keine ehrbaren Absichten und Sie möchten ihnen keinen Zugriff auf Informationen gewähren, auf die sie keinen Zugriff haben sollten, oder ihnen erlauben, echten Benutzern den Zugriff auf Ihre Dienste zu verweigern.

Die übliche Testpraxis besteht darin, nicht nur zu überprüfen, ob der Fall bei gutem Wetter funktioniert, sondern auch, ob ungewöhnliche Randfälle untersucht werden, um potenzielle Probleme zu finden und die Gewissheit zu haben, dass Angreifer nicht einfach auf Ihr System zugreifen können. Wenn Ihre Anwendung bereits mit zufälligen Eingaben abstürzt, möchten Sie nicht wissen, was ein Angreifer mit speziell gestalteten Eingaben tun kann.

Nimm niemals etwas an

Sie können nicht davon ausgehen, dass ein Benutzer versehentlich oder absichtlich etwas "Dummes" mit Ihrer Software anstellen wird. Benutzer können versehentlich die falsche Taste drücken, die Katze kann über die Tastatur laufen, das System kann fehlerhaft funktionieren, ihr Computer kann von bösartiger Software überfallen werden usw.

Darüber hinaus kann der Benutzer selbst böswillig sein und absichtlich nach Wegen suchen, Ihre Software zu beschädigen, in der Hoffnung, dass er einen Weg findet, sie zu seinem Vorteil auszunutzen. Selbst wenn sie einen Fehler finden, den sie nicht ausnutzen können, kann alles, was sie finden, sie dazu anspornen, Ihr System nach etwas zu durchsuchen, das sie angreifen können, da sie wissen, dass Ihre QA-Verfahren fehlen.

Was das Testen betrifft, ist es nützlich, sich vor zufälligen Eingaben zu schützen. Die Auswahl von Testeingaben vollständig zufällig (dh ohne besondere Berücksichtigung von Anwendungsfällen oder Randfällen) ist jedoch nahezu unbrauchbar. Der Zweck des Tests besteht darin, Ihre Lösung anhand der Anforderungen und Erwartungen Ihres Arbeitgebers / Kunden / Anwenders zu validieren. Das bedeutet, dass Sie sich darauf konzentrieren müssen, alle Rand- und Randbedingungen sowie alle "entarteten" Fälle zu erfassen, die nicht in den vom Benutzer erwarteten Workflow passen.

Natürlich können Sie Tests durchführen, die Fehler aufdecken, von denen Sie später feststellen, dass sie nicht behoben werden sollten. Dies kann verschiedene Gründe haben - der Fehler kann zu teuer sein, um ihn im Verhältnis zu seiner Auswirkung auf den Benutzer zu beheben, oder Sie können Fehler in Funktionen entdecken, die von niemandem verwendet werden, oder der Fehler ist möglicherweise bereits so gut im System verankert, dass einige Fehler auftreten Benutzer behandeln es als eine Funktion.

Alternativ können Sie auch eine maßgeschneiderte Software schreiben, die eine eng begrenzte Zielgruppe von "erfahrenen" Benutzern hat, bei denen die Behebung von Fehlern keinen kommerziellen Nutzen bringt, da diese Benutzer in der Lage sind, ihre Arbeit mit fehlerhafter Software (z. B. einem Diagnosetool) zu erledigen Das interne IT-Team erzielt keine Einnahmen. Wenn es also gelegentlich zum Absturz kommt, möchte wahrscheinlich niemand für die zur Behebung erforderliche Zeit bezahlen. Stattdessen wird das IT-Team lediglich angewiesen, mit den Fehlern umzugehen. .

Sie können diese Entscheidungen jedoch nur treffen, wenn Sie über diese Fehler informiert sind. Beispielsweise kann ein Benutzer eine böswillige Eingabe eingeben, die die gesamte Datenbank löscht. Wenn Sie für dieses Szenario nicht explizit geschützt und getestet haben, können Sie nicht sicher sein, ob dies möglich ist oder nicht. Das Risiko, unentdeckte Fehler im System zu hinterlassen, bedeutet, dass Sie sich potenziell echten Problemen stellen müssen, wenn einer dieser Fehler in der realen Welt auftritt und erhebliche Auswirkungen auf Ihre Benutzer hat.

Während die Entscheidung, ob Fehler behoben werden sollen, möglicherweise vom Eigentümer der Software Eingaben erfordert (in der Regel von demjenigen, der Ihr Gehalt bezahlt), ist die Entscheidung, ob auf Fehler geprüft werden soll und auf welche Fälle geprüft werden soll, ein Engineering-Problem, das gelöst werden muss Berücksichtigt in den Kostenvoranschlägen und der Projektplanung, bei denen das Ziel sein sollte, so nahe wie möglich an der vollständigen Abdeckung zu sein, da Zeit, Geld und Ressourcen knapp sind.

Es sind mehrere Faktoren zu berücksichtigen. Um diese Punkte zu veranschaulichen, werde ich ein Beispiel für ein Feld verwenden, in dem ein Benutzer einen Prozentsatz in einem Kontext eines Kontingents eingeben sollte, das für eine bestimmte Aufgabe in Bezug auf den für die Aufgabe verfügbaren Speicherplatz definiert wurde. 0% bedeutet, dass der Task nichts auf die Festplatte schreiben kann. 100% bedeutet, dass der Task den gesamten Speicherplatz ausfüllen kann. Werte dazwischen bedeuten, was sie bedeuten.

Als Entwickler denken Sie wahrscheinlich, dass die akzeptablen Werte [0, 1, 2, 3, ⋯ 99, 100] sind, und alles andere ist albern. Mal sehen, warum Benutzer immer noch diese "albernen" Werte eingeben.

Tippfehler

%^

Der Benutzer hat den Wert 56 Shifteingegeben, bei der Eingabe jedoch versehentlich gedrückt (z. B. weil Sie auf der französischen Tastatur drücken müssen Shift, um Ziffern einzugeben, und der Benutzer ständig zwischen einer französischen Tastatur und einer QWERTZ umgeschaltet hat).

Auf die gleiche Weise können Sie eine Zahl mit etwas danach oder davor oder dazwischen erhalten:

56q

Hier hat der Benutzer wahrscheinlich die Ziffern eingegeben, gefolgt von einem Tab, um zum nächsten Feld zu gelangen. Anstatt zu drücken   ⇆  , drückte der Benutzer die Nachbartaste.

Missverständnisse und Fehlinterpretationen

Eine leere Eingabe ist wahrscheinlich die üblichste. Der Benutzer stellte sich vor, dass das Feld optional ist, oder wusste nicht, was in dieses Feld eingefügt werden soll.

56.5

Der Benutzer hielt Gleitkommawerte für akzeptabel. Entweder ist der Benutzer falsch, und die Anwendung sollte höflich erklären, warum nur ganzzahlige Werte akzeptiert werden, oder die ursprünglichen Anforderungen waren falsch, und es ist sinnvoll, den Benutzern die Eingabe von Gleitkommawerten zu ermöglichen.

none

Der Benutzer hat falsch verstanden, dass die App eine Zahl erwartete, als er nach dem Platz gefragt wurde, den die Aufgabe einnehmen könnte. Dies könnte auf eine schlechte Benutzeroberfläche hindeuten. Wenn Sie beispielsweise den Benutzer fragen, wie viel Speicherplatz die Aufgabe belegen soll, werden Sie zu dieser Art von Eingaben aufgefordert, während ein Feld mit einem nachfolgenden Prozentzeichen weniger Eingaben erhält, da „none%“ keine Eingaben macht viel Sinn.

150

Der Benutzer hat falsch verstanden, was der Prozentsatz in diesem Fall bedeutet. Möglicherweise wollte der Benutzer mitteilen, dass die Aufgabe 150% des aktuell verwendeten Speicherplatzes beanspruchen kann. Wenn also auf einer Festplatte mit 2 TB 100 GB verwendet werden, kann die Aufgabe 150 GB beanspruchen. Auch hier könnte eine bessere Benutzeroberfläche helfen. Anstatt ein leeres Eingabefeld mit einem angehängten Prozentzeichen zu haben, könnte man zum Beispiel Folgendes haben:

[____] % of disk space (2 TB)

Wenn der Benutzer mit der Eingabe beginnt, ändert sich der Text im Handumdrehen wie folgt:

[5___] % of disk space (102.4 GB of 2 TB)

Vertretungen

Große Zahlen oder Zahlen mit Fließkomma können unterschiedlich dargestellt werden. Zum Beispiel kann eine Zahl 1234.56 könnte so geschrieben werden: 1,234.56. Je nach Kultur würde sich die Textdarstellung der gleichen Nummer unterscheiden. In Französisch, wird die gleiche Zahl wie folgt geschrieben werden: 1 234,56. Sehen Sie, ein Komma, wo Sie kein erwarten würden, und ein Leerzeichen.

Wenn Sie immer ein bestimmtes Format für ein bestimmtes Gebietsschema erwarten, bekommen Sie früher oder später Probleme, da Benutzer aus verschiedenen Ländern unterschiedliche Angewohnheiten haben, Zahlen, Datum und Uhrzeit usw. zu schreiben.

Menschen gegen Computer

Twenty-four

Gewöhnliche Menschen denken anders als Computer. "Vierundzwanzig" ist eine tatsächliche Zahl, unabhängig davon, was ein PC Ihnen sagen würde.

Obwohl (1) die meisten Systeme diese Art von Eingabe nicht verarbeiten und (2) sich fast jeder Benutzer nicht vorstellen würde, eine Zahl in Vollbuchstaben einzugeben, bedeutet dies nicht, dass eine solche Eingabe albern ist. In About Face 3 weist Alan Cooper darauf hin, dass das Nichtbearbeiten solcher Eingaben auf die Unfähigkeit von Computern hinweist, sich an Menschen anzupassen. Idealerweise sollte die Benutzeroberfläche in der Lage sein, diese Eingaben korrekt zu verarbeiten.

Das einzige, was ich zu Alan Coopers Buch hinzufügen muss, ist, dass in vielen Fällen Zahlen versehentlich in Ziffern geschrieben werden . Die Tatsache, dass Computer von ihren Benutzern erwarten, dass sie Fehler machen (und einen Benutzer, der richtig schreibt, nicht tolerieren), ist ärgerlich.

Unicode

5𝟨

Unicode behält sich seine eigenen Überraschungen vor: Charaktere, die gleich aussehen könnten, sind nicht gleich. Nicht überzeugt? Kopieren Sie sie "5𝟨" === "56"in die Entwicklertools Ihres Browsers und drücken Sie Enter.

Der Grund dafür, dass diese Zeichenfolgen nicht gleich sind, ist, dass das Unicode-Zeichen 𝟨nicht mit dem Zeichen übereinstimmt 6. Dies würde eine Situation schaffen, in der ein verärgerter Kunde anruft und mitteilt, dass Ihre App nicht funktioniert, einen Screenshot einer Eingabe liefert, die legitim aussieht, und Ihre App behauptet, dass die Eingabe ungültig ist.

Warum sollte jemand ein Unicode-Zeichen eingeben, das wie eine Ziffer aussieht? Während ich nicht erwarten würde, dass ein Benutzer ungewollt eins eingibt, könnte dies durch Kopieren und Einfügen aus einer anderen Quelle verursacht werden, und ich hatte einen Fall, in dem der Benutzer tatsächlich ein solches Kopieren und Einfügen einer Zeichenfolge ausführte, die ein Unicode-Zeichen enthielt, das nicht der Fall war erscheint auf dem Bildschirm.

Fazit

Das sind die Fälle, die Sie für ein elementares Zahleneingabefeld erhalten. Ich würde Sie sich vorstellen lassen, was Sie für komplexere Formulare wie ein Datum oder eine Adresse tun müssen.

Meine Antwort konzentriert sich auf das, was Sie als "dumme" Eingabe bezeichnet haben. Beim Testen geht es nicht darum, die glücklichen Pfade zu überprüfen. Es geht auch darum zu überprüfen, ob Ihre App nicht kaputt geht, wenn ein böswilliger Benutzer absichtlich komische Dinge eingibt und versucht, sie zu kaputt zu machen. Wenn Sie also nach einem Prozentsatz fragen, müssen Sie auch testen, was passiert, wenn der Benutzer mit einer Zeichenfolge mit 1.000.000 Zeichen oder einer negativen Zahl oder einer Bobby-Tabelle antwortet .

Es gibt viele gute Antworten, die beschreiben, warum dies wichtig ist, aber nicht viele Ratschläge, wie Sie Ihre Anwendung sinnvoll schützen können. Die "Standardpraxis" besteht darin , sowohl auf dem Client als auch auf dem Server eine zuverlässige Eingabevalidierung zu verwenden . Gegen unsinnige Eingaben kann man sich leicht verteidigen. Sie lehnen einfach alles ab, was in diesem speziellen Kontext keinen Sinn ergibt. Eine Sozialversicherungsnummer besteht beispielsweise nur aus Bindestrichen und Ziffern. Sie können alles andere, was der Benutzer in ein Feld für die Sozialversicherungsnummer eingibt, sicher ablehnen.

Es gibt zwei Arten von Tests, die für jede von Ihnen geschriebene Anwendung durchgeführt werden sollten und die jeweils unterschiedliche Zwecke haben. Die Tests, die Sie in Ihrer eigenen Anwendung durchführen, sind positive Tests. Sie soll beweisen, dass das Programm funktioniert. Die Tests, die Tester zusätzlich für Ihre Anwendung durchführen, sind negative Tests. Sie soll beweisen, dass Ihr Programm nicht funktioniert. Warum brauchst du das? Weil Sie nicht die beste Person sind, um Ihre eigene Software zu testen. Immerhin hast du das Ding geschrieben, also funktioniert es offensichtlich schon, oder?

Wenn Sie eine Eingabevalidierung schreiben, verwenden Sie positive Tests, um zu beweisen, dass Ihre Validierung funktioniert. Tester versuchen anhand von Zufallseingaben zu beweisen, dass dies nicht funktioniert. Beachten Sie, dass der Problembereich für zufällige Eingaben im Wesentlichen unbegrenzt ist. Ihr Ziel ist es nicht, jede mögliche Permutation zu testen, sondern den Problembereich zu begrenzen, indem ungültige Eingaben zurückgewiesen werden.

Beachten Sie auch, dass der Endbenutzer nicht der einzige ist, der Eingaben für Ihr Programm bereitstellt. Jede Klasse, die Sie schreiben, hat ihre eigene API und ihre eigenen Einschränkungen für die als gültig geltenden Eingaben. Daher ist eine zuverlässige Validierung (dh "Codeverträge") auch für Ihre Klassen wichtig. Die Idee ist, Ihre Software so zu härten, dass unerwartetes Verhalten selten ist oder nicht im größtmöglichen Umfang vorhanden ist.

Schließlich ist der Workflow wichtig. Ich habe gesehen, wie Anwendungen umkippten, nicht weil der Benutzer etwas Unsinniges eingegeben hatte, sondern weil sie Dinge in der Anwendung in einer unerwarteten Reihenfolge ausführten. Ihre Anwendung sollte diese Möglichkeit kennen und unerwartete Workflows ordnungsgemäß verarbeiten oder den Benutzer dazu auffordern, Vorgänge in der angegebenen Reihenfolge auszuführen.

Normalerweise sind die Zufallswerte nicht zufällig. Sie versuchen, Randfälle zu erfassen, die "unbekannt unbekannt" sind.

Angenommen, das Zeichen # stürzt in Ihrer App ab. Sie wissen dies nicht im Voraus und es ist unmöglich, Testfälle für jede mögliche Eingabe zu schreiben. Aber wir können einen Test schreiben "¬!"£$%^&*()_+-=[]{};'#:@~,./<>?|\"und sehen, ob er kaputt geht

Ich habe einmal ein Programm geschrieben, das ich in einem Labor mit 60 Studenten live getestet habe. Ich stand hinter den 60 Bildschirmen und sah, wie sie es benutzten. Die Menge der lächerlichen Dinge, die sie taten, war haarsträubend. Ich war schweißgebadet, als ich ihre "Kreativität" beobachtete. Sie haben viel mehr getan, als sich jeder Einzelne im Laufe seines Lebens vorstellen kann. Natürlich hat einer von ihnen es kaputt gemacht.

Danach verfolge ich einen Ansatz: if "a very specific use case" do, else show error

Wenn ich mehrere Anwendungsfälle habe, definiere ich sie genau und verkette sie.

Was Sie beschreiben, ist Fuzzing oder Fuzz Testing : werfen Sie zufällige und ungültige Eingaben auf ein System und sehen Sie, was passiert. Sie tun dies nicht, weil Sie erwarten, dass ein Benutzer dies tut. Sie tun dies, um Ihre eigenen Annahmen und Vorurteile zu offenbaren und die Ränder Ihres Systems zu belasten, um zu sehen, was passiert.

Normale Testeingaben, die von einem Menschen mit geschrieben wurden, gehen mit Annahmen und Vorurteilen einher. Diese Verzerrungen können bestimmte Klassen von Fehlern sein, die durch Tests nie gefunden werden.

Wenn sich der Großteil Ihrer Eingaben beispielsweise im ASCII-sicheren Unicode-Bereich befindet, werden keine Annahmen zur Zeichencodierung im Code getroffen. Oder es liegt immer unter einer bestimmten Größe, sodass ein Feld oder Puffer mit fester Größe nicht getroffen wird. Oder es gibt Sonderzeichen, die auf überraschende Weise interpretiert werden und aufzeigen, dass Benutzereingaben in eine Shell eingegeben oder zum Erstellen von Abfragen auf unsichere Weise verwendet werden. Oder es gibt einfach zu viele "Happy Path" -Tests und nicht genügend Versuche, die Fehlerbehandlung zu üben.

Fuzzing hat keine derartigen Vorurteile bezüglich der Eingabe. Es wird Ihr System brutal mit jeder möglichen Kombination von "gültigen" Eingaben belasten. Unicode, ASCII, groß, klein und viele, viele Fehler. Ihr System sollte auf alle ordnungsgemäß reagieren. Es sollte niemals abstürzen. Der Benutzer sollte immer eine vernünftige Nachricht darüber erhalten, was schief gelaufen ist und wie es behoben werden kann. Es ist nicht Garbage In / Garbage Out, es ist Garbage In / Error Out .

Während man die resultierenden Explosionen vielleicht verwerfen kann, weil "das kein wirklicher Benutzer tun wird", verfehlt dies den Punkt der Übung. Fuzzing ist ein billiger Weg, um Ihre Vorurteile über mögliche Eingaben zu beseitigen. Es ist ein billiger Weg, um all die seltsamen Dinge, die Benutzer versuchen werden, auf Ihr System zu werfen. Als Ingenieur müssen Sie sicherstellen, dass Ihr System ordnungsgemäß ausfällt.

Darüber hinaus geht es beim Fuzzing "Input" nicht nur um Benutzer. Dies könnte das Ergebnis einer API-Abfrage an einen Drittanbieter sein. Was passiert, wenn dadurch fehlerhafte Ergebnisse gesendet werden? Wie geht Ihr System damit um? Ein ordnungsgemäßes System sollte einen Administrator darüber informieren, dass eine Komponente fehlerhaft ist. Ein falsches System lehnt die fehlerhafte Abfrage stillschweigend ab oder akzeptiert sie als gute Daten.

Schließlich sind einige Benutzer böswillig. Wenn Sie Ihr System nicht auf Herz und Nieren testen, wird es jemand anderes tun. Sie werden die Ränder Ihres Systems auf häufige Fehler untersuchen und versuchen, diese als Sicherheitslücken zu nutzen. Fuzz-Tests können dies bis zu einem gewissen Grad simulieren, und Sie können mögliche Sicherheitslücken schließen, bevor sie zu einem Problem werden.

Wenn Sie ein Qualitätsprodukt erstellen möchten, testen Sie jede mögliche Art von Eingabe, die ein Benutzer physisch einreichen kann. Andernfalls warten Sie nur auf den Tag, an dem jemand diese eine Art von Eingabe übermittelt, die Sie als nicht testbedürftig empfunden haben.

Während einer großen Demonstration neuer E-Auction-Software bei einer örtlichen Behörde, bei der ich tätig war, entschied mein Vorgesetzter (zugegebenermaßen mit einigem Unfug), dass er das Bedürfnis verspürte, zu sehen, was passierte, wenn er ein Auktionsgebot mit einem negativen Wert abgab. Zu meiner großen Überraschung hat die Auktionssoftware dieses unsinnige Gebot zugelassen und den gesamten Auktionsprozess zum Erliegen gebracht. Die Art der vorgeführten Auktion hätte niemals die Einreichung negativer Beträge gestatten dürfen.

Einige der großen Gruppe versammelter Einkaufs- und Finanzbeauftragter waren verärgert über meinen Manager, der einen unsinnigen Wert vorgelegt hatte. Aber andere, einschließlich mir, waren verärgert über die Softwareentwickler, die es versäumt hatten, solch eine offensichtliche Art ungültiger Eingaben zu testen und abzulehnen. Ich kann mir nur vorstellen, wie schwach die Software bei der Ablenkung anderer ungültiger Eingaben gewesen sein muss (Versuche zur Codeeingabe, exotische Zeichen, die in der Datenbanktabelle nicht darstellbar sind usw.).

Wenn es nach mir ginge, hätte ich die Software zurückgegeben und für nicht zweckmäßig befunden. Der Unterschied zwischen einem schwachen und einem starken Softwareprodukt besteht in der Teststufe.

Beispiel: Während der Funktionsprüfung eines Formulars in einer Webanwendung werden die Felder getestet, indem verschiedene Arten von Zufallseingabewerten eingegeben werden.

Ja. Dies ist eine Art Test, aber kein Funktionstest . Dies wird als Stresstest bezeichnet . Es ist die Handlung, Druck auf ein System auszuüben, um zu sehen, ob es damit umgehen kann.

Was nützt es also, all diese Testfälle einzubeziehen, die zu Fehlern führen können oder nicht, wenn die Wahrscheinlichkeit, dass solche Probleme in der Produktion auftreten, viel geringer ist?

Wenn Sie eine Stresstestsoftware sind, versuchen Sie, die Grenzen der Softwaregrenzen zu ermitteln.

Die Tests sind von Natur aus erschöpfend. Wo Sie Nutzungsgrenzen und Bruchstellen ermitteln, alle logischen Verzweigungen überprüfen oder feststellen müssen, wie sich Teilausfälle auf das gesamte System auswirken.

Sie können alle Ihre Funktionstests bestehen lassen, aber die Stresstests trotzdem nicht bestehen .

Ich stelle diese Frage nur, um zu wissen, ob es Standardpraktiken gibt, die befolgt werden müssen, oder ob sie vollständig vom Produkt, der Domäne und allen anderen Faktoren abhängen.

Ja, dies ist eine Standardpraxis.

Beim Testen von Software geht es darum, eine Frage zum erwarteten Verhalten zu stellen. Wenn alle Tests bestanden wurden, wird angezeigt, dass die Software wie beabsichtigt funktioniert. Aus diesem Grund bieten Tests gute Voraussetzungen für die Bereitstellung von Updates.

Stresstests liefern keine eindeutigen spezifischen Pass- oder Fail-Indikatoren. Die Ergebnisse sind informativer. Hier erfahren Sie, was Ihr System verarbeiten kann, und anhand dieser Informationen können Sie Entscheidungen treffen.

Sie können spezifische Ziele für Stresstests definieren, die bestanden werden müssen, um mit der nächsten Entwicklungsstufe fortzufahren. Diese können Teil Ihres Qualitätssicherungsprozesses sein, aber Änderungen in der Umgebung können die Ergebnisse eines Stresstests verändern. Aus diesem Grund werden Stresstests zu unterschiedlichen Zeiten durchgeführt, um festzustellen, wie das System mit sich ändernden Bedingungen umgeht.

Ich meine, Sie können nicht einfach jedes Mal Stresstests durchführen, wenn Sie eine neue Version Ihrer Software bereitstellen, und davon ausgehen, dass dies bedeutet, dass später alle Stresstests bestanden werden.