Ich wurde kürzlich beauftragt,
"Testen Sie jedes denkbare Szenario und versuchen Sie, die Komponente zu knacken"
Was könnte bei "Alles" sinnvoll sein, wenn die Anwendung eine Website ist?
HINWEIS: Diese spezielle Site ist ASP.NET mit MS-SQL, aber ich würde gerne wissen, was im Allgemeinen auch abgedeckt werden würde. Danke euch allen für die tollen Antworten!
Und natürlich die Grundlagen (kopiert von Bobby Jack und dr, Kredit, wo Kredite fällig sind):
Ich würde mit einem Rauch-Test beginnen - ein breiter Test, der die grundlegendsten Funktionen überprüft. Listen Sie anschließend die wichtigsten Funktionen in der Reihenfolge ihrer Wichtigkeit auf und erstellen Sie Tests für diese in dieser Reihenfolge. Wenn die Website überhaupt eine Größe hat und regelmäßig aktualisiert wird, sollten Sie diese Tests mit Selen automatisieren.
Einige davon hängen vom Kontext ab. Hier sind einige der weniger offensichtlichen:
Was ist der "Fluss" der Website? Gibt es eine Bestellung, auf die ein Benutzer zugreifen sollte?
Gibt es Formulare?
Sind Cookies beteiligt?
Vergessen Sie nicht die "bonehead" -Tests.
Öffnen Sie eine Seite und klicken Sie auf Senden. Hat das Formular korrekt gehandhabt?
Setzen Sie den Cursor in ein Textfeldfeld. Pfund auf die Tasten ein paar Mal (gestrahlt Katze auf meiner Tastatur, gesprenkelt Kaffee verschütten Dinge kurzschließen). Hat die Eingabevalidierung mit "nicht standardmäßigen" Daten funktioniert?
Senden Sie ein Formular / eine Anfrage. Drücken Sie die Zurück-Taste. Wird die Form erneut gesendet? Sollte es sein? Zeigt es die richtigen Daten bei der Rückkehr an?
Sie wären überrascht, wie oft ich mich in der Vergangenheit von den "bonehead" Situationen verbrannt habe.
Neben Bobby Jacks Liste und NomeN und so ziemlich allen anderen ... Ich sehe das nicht ausdrücklich erwähnt; Entschuldigung, wenn es ist. Sie haben nicht erwähnt, welche Art von Website das ist, aber abhängig von der Problemdomäne können speziell fehlerhafte Daten Kopfschmerzen verursachen. Zum Beispiel: Was passiert bei einer E-Commerce-Site, wenn jemand versucht, negative Mengen zu bestellen? Viele Dinge können durch "rückwärts" (aus Mangel an einem besseren Wort) Eingang gebrochen werden.
Vergessen Sie auch Validierungswerkzeuge nicht. Das World Wide Web Consortium, das Standardisierungsgremium für das Internet, bietet eine Fülle von Tools, wie auch andere feine Organisationen. Hier sind ein paar gute Online-Tools für:
Endlich, hier ist eine Person nimmt eine vernünftige Checkliste und hier ist ein Seite mit dem grandiosen Anspruch eines Online-Alles-Checkers .
Zusätzlich zu Bobby Jacks Liste würde ich empfehlen, Ihre Website vor den Szenarien für die meisten dummen Nutzer und Hacker-Nutzer zu schützen. Dies würde unter anderem bedeuten, dass Sie Ihre URLs und QueryString ordnungsgemäß schützen.
Es gibt so viele Testtypen, die mit einer Software ausgeführt werden können, dass die Liste endlos ist und von mehreren verschiedenen Typen abgedeckt wird. Es gibt keine einzige Antwort, die ausreicht.
Funktionstest, Integrationstests, Leistungstest, Penetrationstests, Regressionstests, Kompatibilitätstests für Browser, Stresstest - Liste geht weiter.
Und das ist, bevor Sie in jeden einzelnen bohren und anfangen, spezifische wie css / xss Angriffe, usw. zu sprechen
für Websites, die meisten gebräuchlichen Pausen, über die Sie während der Entwicklung nachdenken würden Einige der Großen sind: verhindert die mysql-injektion Vorbeugung gegen unbefugten Zugriff (Nichtmitglieder, die in einen Mitgliederbereich gelangen) Wenn Sie zu irgendeinem Zeitpunkt eine Formularübergabe haben, überlegen Sie, was passieren würde, wenn der Benutzer die get- oder sogar die Post-Daten ändern würde
Das sind alles, was ich mir im Moment vorstellen kann, all diese Dinge würden Sie nicht wirklich "versuchen", die Seite zu zerstören, Sie werfen nur ein paar Fänge in Ihren Code.
Eigentlich ist es besser, mit sehr häufigen Fällen zu beginnen. Erhalten Sie eine gute Auswahl an typischen Anwendungsfällen und stellen Sie sicher, dass diese alle gründlich getestet werden. Beginnen Sie dann mit der Verzweigung zu etwas weniger häufigen Fällen.
Testen ist immer eine kombinatorische Situation, daher können Sie nicht jedes Szenario testen. Betrachten Sie 10 Browser x 10 Arten von Benutzern x 10 Methoden x 10 OS x 10 Formen = 100.000 Testszenarien.
Es gibt wahrscheinlich Billiarden von Szenarios für jede vernünftige Anwendung.
Sie müssen also mit den häufigsten Szenarien beginnen und sich dann von dort aus arbeiten. Sie müssen auch über die Orthogonalität der Tests nachdenken. Brute Force "alle Szenarien testen" funktioniert einfach nicht.
Es wäre unpraktisch, "für jedes denkbare Szenario zu testen". Warum ist das so? Mit nur 14 der Vorschläge hier, hauptsächlich aus Bobby Jacks exzellenter Antwort, würden Sie mit 2.654.208 möglichen Tests enden. Realistischerweise würden oder würden Sie nicht für jeden von denen testen. Also, was sollten Sie tun?
Dies ist ein großartiges Beispiel dafür, wo paarweise (oder andere, komplexere Kombinationstestmethoden) äußerst nützlich sein könnten. Nur 38 Tests würden nicht nur jeden Parameterwert mindestens einmal abdecken, sondern würden mindestens einen Testfall umfassen, der jedes Paar der Parameterwerte abdeckte, die miteinander wechselwirken. (z. B. Browser="Opera" und CSS="on" wird getestet, und Drop-Konnektivität simulieren?="Y", und Cookies aktiviert="N" wird getestet, usw.) Ein paar Screenshots von Hexawise , ein neues (derzeit kostenloses) Test-Design-Tool, kann diesen Punkt besser als ich in Worten sagen:
Dieses erste Bild zeigt jeden der 14 Parameter mit bis zu 6 Werten pro Parameter
%Vor%Dieses zweite Bild zeigt: (A) die Eingaben erstellen 2.654.208 mögliche Testfälle / Szenarien und (B) nur 38 Testfälle werden für jedes einzelne mögliche Paar von Parameterwerten in mindestens einem Testfall getestet. (z. B. Browser="Opera" und CSS="on" wird getestet und Simulated Dropped Connectivity?="Y", und Cookies aktiviert="N" wird getestet, usw.)
%Vor%Weitere Informationen zu dieser Methode zur Maximierung der Abdeckung in möglichst wenigen Testfällen finden Sie unter www.combinatorialtesting.com, insbesondere unter Ссылка
Justin Hunter - Gründer und CEO von Hexawise - Mehr Abdeckung. Weniger Tests www.hexawise.com
Tags und Links unit-testing asp.net testing code-coverage