Zusammenfassung der Senior-Tests, 7 Regeln für automatisierte Testfälle, alles in einem Artikel ...

Inhaltsverzeichnis: Einleitung

Vorwort

1. Alles ist ein Objekt

Studenten, die Java oder Python studiert haben, sollten diesen Satz alle kennen. Ja, wir brauchen dieses Konzept auch, wenn wir automatisierte Testfälle entwerfen.

Denn im Gegensatz zu Black-Box-Testfällen sind automatisierte Testfälle nicht für die Ausführung durch Menschen bestimmt. Wir müssen die entsprechende Entwicklungssprache verwenden, um die Anwendungsfälle zu schreiben.

Beim Schreiben von Testfallskripten muss dieses Konzept jederzeit umgesetzt werden.

Natürlich unterscheidet sich der Prozess des Schreibens von Anwendungsfällen nicht grundlegend von der Codierungsarbeit anderer Entwickler. Erwarten Sie nicht, dass die Anwendungsfallskripte in einem Rutsch geschrieben werden können. Die meisten Skripte müssen immer wieder optimiert werden.

Es spielt keine Rolle, ob die Schreibeffizienz zunächst etwas gering ist. Wir müssen zunächst sicherstellen, dass sie ausgeführt werden kann, und die Wiederverwendbarkeit und Robustheit können etwas geringer sein.

Nach dem Durchlaufen sollten wir uns jedoch auf die Leistung konzentrieren. Wenn Sie Python verwenden, ist es kein Problem, einige Anwendungsfälle auszuführen, da Python eine dynamische Sprache ist und der Compiler keine Vorhersagen treffen kann, wenn Variablen auf Objekte verweisen.

Darüber hinaus wird es interpretiert und ausgeführt, sodass bei der Ausführung einer großen Anzahl von Testfällen zwangsläufig lange Laufzeiten und unerwartete Fehler auftreten. Zu diesem Zeitpunkt hat die Verbesserung der Leistung des Codes oberste Priorität.

Die Optimierung der zeitlichen Komplexität des Algorithmus, die rationelle Verwendung integrierter Methoden, die Vermeidung globaler Variablen, die Reduzierung von Schleifen usw. können zu entsprechenden Leistungsverbesserungen für unseren Code führen.

2. Starke Geschäftsbeziehung

Im Gegensatz zu Black-Box-Testfällen ist die Geschäftsrelevanz innerhalb automatisierter Testfälle hoch.

Tatsächlich können wir es untersuchen, wenn wir seine wesentliche Form betrachten. Was es lösen muss, sind einige Vorwärtstestszenarien mit stabilen Funktionen und klaren Geschäftspfaden. Das Testfallskript kann nicht nur eine der Geschäftsschnittstellen bedienen. Funktion ist das zu verschwenderisch.

Im Allgemeinen müssen Testskripte den gesamten Prozess eines normalen Unternehmens abdecken, damit wir die verschiedenen Behauptungen hinzufügen können, die wir während des Betriebs benötigen, um die erwarteten Testergebnisse in mehreren Anwendungsfällen zu überprüfen.

Aufgrund der unterschiedlichen Natur von Black-Box-Testfällen ist außerdem ein besserer Beweis dafür, dass automatisierte Testfälle schnell Geschäftsüberprüfungen, Rückgaben und Smoke durchführen können.

3. Positives Szenario

Bei automatisierten Tests besteht die schrecklichste Situation darin, alle Vorwärts- und Rückwärts-Testszenarien in das automatisierte Test-Framework zu stopfen.

Einige Leute werden instinktiv denken, dass umgekehrte Testfälle nicht ausgeführt werden können, da es sich um eine automatisierte Ausführung handelt. Ist es wirklich narrensicher, solange die entsprechenden Parameter entworfen und Testfälle geschrieben werden?

Der Grund, warum umgekehrte Testszenarien und Testfälle für automatisierte Tests geeignet sind, liegt in ihrer eigenen Unsicherheit, die sich auf die endgültigen laufenden Ergebnisse automatisierter Tests auswirkt.

Studenten, die automatisierte Tests durchgeführt haben, wissen alle, dass das wirklich Beängstigende an der Durchführung automatisierter Tests nicht der umgekehrte Testfall ist, sondern die Testszenarien und Anwendungsfälle, die einen Fehler melden, ohne zu wissen, wann, und das Szenario, in dem sich diese Art von Testfall befindet befindet sich absolut. Die meisten werden in Reverse-Testing-Szenarien angezeigt.

Wir müssen wissen, dass automatisierte Tests nicht alles für die Tester erledigen. Daher können wir für Vorwärtstestszenarien mit stabilen Funktionen und wenigen Änderungen der Anforderungen problemlos automatisierte Tests einbauen, für Rückwärtstestszenarien wird dies jedoch nicht empfohlen.

Wenn Sie es wirklich einfügen möchten, wird nur empfohlen, weniger wichtige Funktionsmodule einzufügen. Einige umgekehrte Szenarien komplexer Geschäfts- und wichtiger Funktionsmodule erfordern immer noch eine manuelle Bestätigung durch erfahrene Tester, was zuverlässiger ist.

Im Allgemeinen muss das automatisierte Testen nur den Hauptglückspfad des Produkts abdecken. Es besteht keine Notwendigkeit, zu viele umgekehrte Szenarien zu entwerfen, die die Stabilität automatisierter Testaktivitäten beeinträchtigen würden.

Vergessen Sie nicht, dass die Hauptaufgabe automatisierter Tests darin besteht, unsere Tester von komplizierter und sich wiederholender Testarbeit zu befreien und ihre Energie wichtigeren und komplexeren Modul- und Geschäftstests zu widmen.

4. Multi-Szenario-Konstruktion

Das Multi-Szenario-Konstruktionskonzept besteht hier darin, die Vorteile automatisierter Tests voll auszunutzen und so viele Testszenarien wie möglich mit weniger Durchläufen abzudecken.

Wenn beispielsweise ein automatisiertes Testskript mehrere Testfälle enthält, müssen wir beim Entwerfen der Anwendungsfälle die Geschäftsschnittstelle im Skript vollständig nutzen, um eine Kombination mehrerer Szenarien zu erstellen.

In CRM überprüfen wir beispielsweise verschiedene Kundeninformationen, fügen Vorgänge hinzu, löschen, ändern und überprüfen sie in der Kundeninformationsschnittstelle. Wenn möglich, sollten diese Vorgänge in einmaligen Vorgängen auf der Seite platziert werden, es sei denn, sie stehen in engem Zusammenhang mit Folgegeschäft (notwendig für Folgebetrieb). Daten), ansonsten wird grundsätzlich diesem Grundsatz gefolgt.

Dies ist, was oben gesagt wurde: Versuchen Sie, überprüfbare Geschäftsszenarien in einem Durchgang zu kombinieren, anstatt mehrere Runden desselben Geschäftsbereichs, jedoch mit unterschiedlichen Verifizierungstestpunkten, durchzuführen.

5. Starke Relevanz

Im Allgemeinen entwerfen wir automatisierte Testfälle basierend auf den Black-Box-Testfällen, die wir zuvor entworfen haben. Ein gängiger Ansatz besteht darin, automatisierte Testfälle mit Vorwärtstestfällen der Ebenen P0 und P1 zu ergänzen.

Dies stellt absolut kein Problem dar, wir müssen jedoch auch beachten, dass unsere automatisierten Testfälle für verschiedene Testtypen nicht statisch sind.

Rauch- und Regressionstests werden beispielsweise am häufigsten bei automatisierten Tests verwendet. Die automatisierten Testfälle dieser beiden Typen sollten nicht identisch sein.

Die Testfälle des Rauchtests sollten eher dazu neigen, den Hauptprozess schnell zu überprüfen, um sicherzustellen, dass die Qualität der aktuellen Version für die Durchführung nachfolgender Testaktivitäten geeignet ist, und sich auch stärker auf die Anwendung alter Anwendungsfälle konzentrieren.

Regressionstests zielen darauf ab, ob die Reparatur einiger Funktionen den normalen Betrieb der Gesamtfunktionen und erweiterten Module beeinträchtigt. Dies erfordert automatisierte Tests zwischen den reparierten Funktionsmodulen und verwandten Modulen, die der Test für notwendig erachtet.

Daher überschneiden sich die automatisierten Testfälle mit dem Rauchteil und es werden neue Anwendungsfälle hinzugefügt, um zu bestätigen, dass die Funktionen der relevanten erweiterten Teile normal funktionieren.

6. Funktionspunkte unabhängig testen

Dies ist ebenfalls leicht zu verstehen und unterscheidet sich nicht vom Black-Box-Testfall, obwohl das Skript den aktuellen gesamten linearen Geschäftsbetrieb einer bestimmten Seite entwirft.

Wir müssen jedoch weiterhin sicherstellen, dass in jedem automatisierten Testfall nur ein Funktionspunkt überprüft wird, und wir dürfen nicht bequem mehrere Funktionspunkte zur Bestätigung in einem Anwendungsfall zusammenfassen.

Zu diesem Zeitpunkt muss jemand fragen: Kann ich eine multifunktionale Bestätigung durchführen, wenn ich noch ein paar Behauptungen aufstelle? Tatsächlich widerspricht diese Ansicht der ursprünglichen Absicht des Testfallentwurfs: Mehrere Behauptungen können natürlich mehrere Funktionspunkte beurteilen.

Aber stellen Sie sich vor, dass mehrere Verifizierungspunkte in einem Testfall dazu führen, dass der Anwendungsfall selbst mehr Schritte erfordert und nicht mehr zerlegt werden kann. Der Unterschied zum Schreiben eines Black-Box-Testfalls besteht darin, dass Ihr Code nicht unabhängig voneinander zerlegt werden kann.

Die nächste Frage ist also, dass es sich auch um einen Testfall handelt. Ist eine Reihe kombinierter Testfälle hochgradig wiederverwendbar? Oder ist der Anwendungsfall für das unabhängige Testen von Funktionspunkten in hohem Maße wiederverwendbar?

Niemand muss sorgfältig nachdenken, die Antwort liegt bereits auf der Hand.

Es ist wie bei Legosteinen. Wenn Sie ein Schloss entwerfen müssen, wäre es dann besser, ein ganzes Stück großer, unregelmäßig geformter Bausteine oder ein kleines Stück normaler kleiner Bausteine zu haben?

7. Komplettes Design

Zusätzlich zum Entwurf grundlegender Testfälle können wir die Vorteile der Automatisierung auch nutzen, um einige zusätzliche Anwendungsfallerweiterungen zu entwerfen.

In der täglichen Arbeit geht es bei unseren automatisierten Tests nicht nur um die Gestaltung relevanter funktionaler Testpunkte, sondern auch um einige damit verbundene Testdatenoperationen.

Dann ist die Vor- und Nachbearbeitung von Testdaten natürlich zu einem der notwendigen Schritte beim Entwurf von Testfällen geworden.

Beim Black-Box-Test werden unsere Testdaten definiert oder erstellt, bevor wir sie ausführen, sodass der Ausführungsprozess reibungsloser verläuft.

Beim automatisierten Testen müssen wir diesen Vorgang nicht mehr manuell im Voraus ausführen. Im Allgemeinen werden wir die zu generierenden Testdaten im Voraus in einen unabhängigen Testfall einfügen und ihn im Voraus erstellen. Dies wird als Voroperation bezeichnet . Tatsächlich nennen wir das die Voraussetzung.

In ähnlicher Weise können wir die Testdaten auch recyceln und löschen, nachdem wir bestimmte Vorgänge oder Geschäftsabläufe ausgeführt haben. Dies wird als Nachoperation bezeichnet. Auf diese Weise können wir stets sicherstellen, dass unsere Testumgebung wiederholt dieselben Testfälle ausführen kann, ohne uns Gedanken über Änderungen bei Faktoren wie Umgebung oder Daten machen zu müssen.

Da unser Testprozess „keine Spuren hinterlässt“, können wir außerdem Screenshot-Funktionen, Druckprotokolle usw. verwenden, um Testnachweise bei wichtigen Anwendungsfällen und Behauptungen zu hinterlassen, um die Fehlerbehebung und die Lokalisierung von Fehlern zu erleichtern.

Das Folgende ist das umfassendste Systemdiagramm zum Lernen von Software-Testingenieuren und Wissensarchitektur im Jahr 2023, das ich zusammengestellt habe.