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

71

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.

Nagarani Dubbaka
quelle
4
Vielleicht relevant: Affentests mit Vor- und Nachteilen
Christophe

Antworten:

190

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.

Bart van Ingen Schenau
quelle
16
Und dann gibt es Dinge, die keine Menschen sind, die das tun. 👽
Kojiro
110
Oder sie versuchen, ihren tatsächlichen legalen Namen einzugeben, z. B. "O'Malley", "姓名" oder "Robert". DROP TABLE Students; - ” .
l0b0
90
Oder vielleicht echte Firmennamen ; TROPFENTABELLE "FIRMEN" - LTD .
Ben
25
Ich denke, der letzte Absatz kann gestärkt werden, indem betont wird, dass ein Programm, das mit zufälligen Eingaben einer Katze auf der Tastatur abstürzt, mit ziemlicher Sicherheit mit böswilligen Eingaben abstürzt (und schlimmer noch) .
Phihag
11
Außerdem geben viele Leute Zufallseingaben ein, weil sie nicht die tatsächlichen Daten (wie Name, Geburtstag usw.) angeben möchten. Einige gehen auch davon aus, dass der Computer so intelligent ist wie ein Angestellter, und geben möglicherweise "letztes Jahr" anstelle von "2016" ein und erwarten, dass Ihre Anwendung damit zurechtkommt, so wie es ein Mensch tun würde.
Luaan
102

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.

Ben Cottrell
quelle
12
Obwohl es nicht sinnvoll ist, nur zufällig zu testen, und Sie sollten auf jeden Fall explizit so viele Randfälle testen, wie Sie sich vorstellen können, kann eine gewisse Anzahl zufälliger Fuzzing-Vorgänge manchmal auch nützlich sein, um nach Problemen zu suchen, die Sie möglicherweise nicht vorhergesehen haben.
Sean Burton
10
Wir haben ein Sprichwort: "Es ist so schwierig, idiotensichere Software zu schreiben, weil Idioten so kluge Leute sind." Testen Sie also auf "Unsinn" -Eingaben!
Ralf Kleberhoff
For example, a user may enter a malicious input which wipes the entire database - if you haven't explicitly protected against and tested for this scenario, then there's no way you can be sure whether or not this can happen.Wie kleine Bobby Tables aus diesem XKCD-Comic? ;)
nick012000
12
"Nimm niemals etwas an." Ich nehme an, das ist ein guter Rat.
candied_orange
Vielen Dank für den Hinweis, dass nicht alle "Bugs" "Fixes" sind. Es ist ein großer Unterschied, sich eines Edge-Falls bewusst zu sein und Zeit und Geld für die Behebung eines Edge-Falls aufzuwenden. Es wäre sicher großartig, mögliche Eingaben in ein Webformular zuzulassen und eine festgelegte Antwort für alle Fälle zu erhalten, aber möglicherweise ist dies für Ihre spezifische Software nicht relevant. Möglicherweise erlaubt Ihre Eingabe nur Nummern am vorderen Ende, sodass es unmöglich ist, Nicht-Nummern am hinteren Ende zu empfangen. Das potenzielle Problem zu beheben, dass Nicht-Zahlen nur in Ihrer Zahlenform vorkommen, ist eine Verschwendung von Zeit und Geld.
EvSunWoodard
60

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 .

Arseni Mourzenko
quelle
9
Ah, U + 1D7E8: MATHEMATICAL SANS-SERIF DIGIT SIX.
Andreas Rejbrand
23
Zu dem anderen Unicode-Zeichen: Auf japanischen Tastaturen wird häufig von normalen Ziffern zu Ziffern voller Breite gewechselt, bei denen eine Ziffer so breit ist wie ein Kanji. Ein japanischer Benutzer hat also möglicherweise die japanische Eingabe aktiviert (und nicht die englische) und versehentlich Ziffern in voller Breite eingegeben.
Jan
3
Bevor ich Ihren 5𝟨-Abschnitt zum gleichen Homoglyphenproblem gesehen habe, habe ich tatsächlich eine 1 234,56Zeichenfolge erwartet (unter Verwendung von U + 00A0 NO-BREAK SPACE anstelle von U + 0020 SPACE), mit der diese Zahlenmarkierungen (oder mit U + 202F) ordnungsgemäß codiert werden können (ENGE BRECHSICHERUNG, Peroahps). Das Kopieren des Werts aus jeder Anwendung, die die Zahlen gemäß dem Gebietsschema formatiert, bevor sie dem Benutzer präsentiert werden, würde dies sehr leicht erzeugen.
Ángel
4
Das Einfügen von Kopien ist ein viel größeres Problem. Üblich ist es, Leerzeichen, Zeilenumbrüche, unsichtbare Zeichen
einzufügen
7
@ Arseni Mourzenko Sie müssen Glück haben. Das Kopieren von zB einem PDF und Einfügen kann dazu führen, dass alle Arten von Zeichen eingefügt werden, die in Abhängigkeit von Zirkulationen unerwünscht sind, zB Ligaturen (für fi usw.), intelligente Anführungszeichen, en oder em Bindestrich, bei denen ASCII minus gewünscht wurde usw.
Rosie F
12

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.

Robert Harvey
quelle
Ein häufiges Beispiel für eine Anwendung, die eine bestimmte Reihenfolge erwartet, ist eine "Teardown" -Funktion, die Handles freigibt, die nie reserviert wurden.
wizzwizz4
2
Leider besteht die übliche Praxis darin, alles abzulehnen, was keinen Sinn ergibt, und den Benutzer verwirrt und frustriert zu lassen. Richtig ist, genau zu erklären (z. B. durch Fehlermeldungen / Rückmeldungen), warum die Eingabe abgelehnt wurde, damit der Benutzer weiß, wie er seine Eingabe korrigiert und akzeptiert. Eine einfache "Ganzzahl von 1 bis 100 erhalten" erfordert mindestens 4 verschiedene Fehlermeldungen (leere Zeichenfolge, nicht unterstütztes Zeichen, zu groß, zu klein); plus Tests, um sicherzustellen, dass in jedem Fall das richtige Feedback gegeben wird.
Brendan
2
@Brendan: Es ist nur eine Nachricht erforderlich: "Dies muss eine Zahl zwischen 1 und 100 sein." Der Benutzer weiß nicht (und muss auch nicht wissen), was eine Zeichenfolge ist oder was "nicht unterstützte Zeichen" bedeuten. Dies sind Programmiererprobleme, keine Benutzerhilfe.
Robert Harvey
@RobertHarvey Ich würde dieser Aussage wahrscheinlich etwas hinzufügen, das "aus Ziffern zusammengesetzt" ist. Da die Eingabe "Neunundsiebzig" eine Zahl zwischen 1 und 100 ist, aber keine Eingabe, mit der die meisten Programme arbeiten können.
Delioth
1
@Delioth: Du kannst das nicht dumm beheben.
Robert Harvey
11

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

Ewan
quelle
2
+1 Es ist auf den ersten Blick überraschend, wie oft diese zufälligen Zeichen einen Fehler finden. Daten aus Benutzereingaben können viele Komponenten / Dienste durchlaufen. Es wird nur eine Komponente in der Kette benötigt, die nicht verarbeitet wird, damit das System einen Fehler aufweist.
Lan
4
esp. jetzt, da alle mobilen Tastaturen Emoticons haben
Ewan
Für .NET-Entwickler ist das IntelliTest-Tool (früher Pex genannt) eine sehr gute Möglichkeit, Codepfade auszuüben, um Randfälle zu finden. Es ist besonders nützlich bei der Eingabevalidierung und für eine gute Codeabdeckung.
James Snell
7

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.

Arthur Tarasov
quelle
1
Diese spezifischen Anwendungsfälle könnten jedoch zu spezifisch sein. Wir unterschätzen immer den Raum gültiger Eingaben. (O'Hara, lokal formatierte Dezimalstellen usw.). Wie viele Finanzroutinen waren auf negative Zinssätze vorbereitet?
Guran
6

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.

Schwern
quelle
Und es gibt die Quick Check- Test-Tools, die ähnliche Dinge tun
icc97
4

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.

Arkanon
quelle
2
test every possible type of input that a user will be physically able to submit.- Dieser Problemraum ist im Wesentlichen unendlich, und Sie verschwenden Ihre Zeit, indem Sie versuchen, alles zu testen. Die Überprüfung auf negative Eingaben erfolgt durch eine einzige Verzweigung. Das ist nicht nur sinnvoll, sondern wird auch von kompetenten Entwicklern erwartet. Sie müssen nicht jede negative Zahl überprüfen, um zu beweisen, dass eine solche Validierung funktioniert.
Robert Harvey
13
Deshalb habe ich jede Art von Eingabe gesagt und nicht jede mögliche Eingabe. Und ich wiederhole meinen Punkt: Wenn Sie nicht jede Art von Eingabe testen, werden die Benutzer dies letztendlich tun.
Arkanon
1

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.

Reactgular
quelle