Guten Tag, liebe Leser.
Ich möchte über die Erfahrung beim Aufbau eines Testautomatisierungssystems sprechen, wenn das Projekt überhaupt nicht getestet wird oder sein Abschluss minimal ist.
Ich hoffe, der Artikel ist nützlich für Autotests für Anfänger.
- Im ersten Teil bevorzugen wir den allgemeinen Ansatz.
- Im zweiten Teil ( Teil 1 ) mit Beispielen werden wir ein Projekt von Autotests auf JAVA + erstellen, in dem gezeigt wird, wie die API schnell getestet werden kann.
- Im dritten Teil werden wir das Projekt für UI-Tests ergänzen, wir werden parallele Tests durchführen.
Wann werden Autotests durchgeführt?
Die kurze Antwort ist so früh wie möglich.
Eine vollständige wird unten offenbart. In jedem Fall wird das Leben sehr eintönig, wenn das Projekt 3 Jahre lang funktioniert und alles manuell überprüft wurde. Eine Flotte von 5000 Szenarien, die in ein oder zwei Monaten automatisiert werden müssen, ist problematisch. In solchen Projekten müssen Sie in der Regel die Skripte erneut ausarbeiten. Weil es schneller geht. Und nicht die Tatsache, dass der Alte ohne wesentliche Änderungen automatisieren kann.
Warum?
Weil Autotets:
- Akkumulieren Sie Szenarien für die Regression
- Unvoreingenommen
- Schnell
Akkumulierte Szenarien
Je größer die Flotte automatisierter Szenarien ist, desto wahrscheinlicher ist es, dass eine Regression auftritt, insbesondere wenn sich die Daten bei jedem Lauf ändern.
Wenn der Autotest stabil bestanden wurde und auf einen Zweig fiel, haben sie entweder die Anforderungen oder einen Fehler geändert oder die Infrastruktur ist ausgefallen.
Unparteilichkeit
Wenn die Anforderungen geändert werden, sollte der Autotest zusammen mit der Änderung der Hauptfunktionalität zur Änderung gehen. Deshalb nehmen Tester an der Zulassung von TK teil.
Wenn ein Testlauf automatisch mit einer Aufgabe verknüpft wird, kann niemand sagen, dass sie nicht getestet wurde. Oder umgekehrt, er kann. Im Allgemeinen gibt es definitiv weniger Probleme.
Geschwindigkeit
Wenn jeder Test die langwierigen Bedingungen erfüllt:
Voraussetzung - Test - Nachbedingung
Solche Tests sind einfach zu automatisieren.
Und dann ist es einfach zu parallelisieren. Weil sie unabhängig sind.
Die Anzahl der Threads - wie viele Testserver können standhalten, um andere nicht zu stören.
Der zweite Punkt ist die Geschwindigkeit selbst. Klicken Sie im manuellen Modus auf die Erstellung des Produkts. Die Suche und der Kauf im Online-Shop dauern 5 Minuten. 4 Browser. Insgesamt 20 Minuten. In nur einem kleinen Szenario.
Der Autotest in diesem Szenario dauert 1,5 Minuten. Aber auf 8 Browsern. (Neueste und vorletzte Version jedes Browsers).
Wo soll ich anfangen?
Mit benutzerdefiniertem Scripting.
Der Wert von Atomtests sinkt ständig, insbesondere bei Mikrodiensten. In einer idealen Welt liegt dies im Allgemeinen im Verantwortungsbereich des Programmierers. Solche Fehler sollten in der Testphase des Geräts erkannt werden.
Die Qualitätssicherung sollte anhand der User Story funktionieren. Weil der Programmierer sie normalerweise nicht kennt und nicht wissen will.
Dementsprechend ist der logische 1 Test - 1 Benutzerfall (Geschäftsszenario) der Realität am nächsten.
Natürlich gibt es Schwierigkeiten bei der Aufbereitung von Daten, zum Beispiel im Fall eines Online-Shops erfordert der Kartenzahlungsprozess das Vorhandensein von Dingen im Warenkorb und entweder Daten für einen neuen Benutzer oder Autorisierungsdaten für einen vorhandenen.
Ja, manchmal dauern die Voraussetzungen länger als ein Test, aber es ist nicht schwierig, Skripte wiederzuverwenden.
Welche Skripte müssen automatisiert werden?
Am wenigsten kurzfristig anfällig für Veränderungen. Zur Automatisierung lebten zumindest einige.
Oder am häufigsten verwendet. Es ist sinnvoll, beim manuellen Testen beim Generieren von Testdaten zu helfen. Im Bulletin Board ist es beispielsweise sinnvoll, die Erstellung von Ankündigungen zu automatisieren, weil Darüber hinaus erfordert jedes Szenario eine erstellte Anzeige.
Was genau machen?
Normalerweise in Projekten dort
- Backend
- Frontend
- Mobile Apps
- Drüsen
Und die letzten beiden Punkte - leben normalerweise getrennt. Mobiltelefone werden anhand ihrer eigenen Skripte getestet, und nur wenige können sich laut JTAG ohne Vorbereitung dem Debuggen von Eisen nähern.
Daher schlage ich vor, mich mit dem Backend und der Front zu befassen.
Wählen Sie ein Szenario
Nehmen wir an, wir haben einen Online-Shop.
Es gibt ein Admin-Panel, eine Client- und eine Admin-Front.
Es gibt eine API, die all dies erfüllt.
Wo soll die Automatisierung beginnen?
Lass uns zuschauen.
Es gibt Kunden, es gibt Mitarbeiter.
Der Kunde hat den ersten Fall: Anzeigen und Suchen des Produkts, Hinzufügen zum Warenkorb und Entwerfen.
Der Mitarbeiter hat den häufigsten Fall - das Hinzufügen einer Produktkarte.
Welcher Fall wird zuerst automatisiert? Und wie?
Das Wichtigste für das Geschäft ist der Verkauf.
Daher ist die Kundenhistorie für das Geschäft am wichtigsten. Daher ist es das erste, was Sie tun müssen, um die Waren zu finden, sie in den Warenkorb zu legen und die Kaufabwicklung mit einer beliebigen Zahlungsmethode abzuschließen.
Nach API. Aber ohne Front. Hier kann man argumentieren, aber höchstwahrscheinlich wird sich das Design 2-3 mal mehr ändern, aber das Backend ist unwahrscheinlich. In Stufe 1 müssen Sie die Schnittstelle also manuell überprüfen.
Überprüfen Sie als Nächstes die API, die die Produktkarte und ihre Vorderseite bearbeitet.
Und kehre zum Kunden zurück. Zu diesem Zeitpunkt gibt es bereits Statistiken zu den häufigsten Benutzeraktionen und den häufigsten Clientpfaden. Ja, Yandex Metric und Webvisor helfen auch Testern.
In der ersten Phase ist es nicht sinnvoll zu prüfen, ob die Funktion der Zahlung auf das Konto des Unternehmens über das generierte Zahlungssystem funktioniert, wenn 0,5% der Besucher diese Funktion nutzen. Natürlich können Sie dem Manager eine Frage stellen, warum dies hier benötigt wird, aber darum geht es nicht.
Angenommen, 40% der Menschen zahlen auf der Website mit einer Karte, 30% in bar, 20% in bar und 10% in allen anderen Methoden.
Welche Zahlungsart prüfen wir zuerst? Natürlich die Karte.
Das heißt, wir müssen klar verstehen, welches Szenario im Moment für das Unternehmen am wichtigsten ist. Und seine Qualität ist in erster Linie.
Nachbedingungen
Wir haben alles geschaffen, alles in den Tests. Müll. Es wäre notwendig, nach sich selbst aufzuräumen. Es ist notwendig, im Voraus vorherzusagen, in welchen Tests wir nach uns selbst aufräumen werden und in welchen - nicht.
Wenn die Ware im Geschäft gelassen werden kann und nichts Schlimmes passiert, muss das Hinzufügen von Administratorrechten zum regulären Benutzer zurückgegeben werden. Und dann könnte der nächste Test in Bezug auf Rechte fallen. Oder schlimmer - gehen Sie positiv, obwohl es hätte fallen sollen.
Kuriositäten
Es gibt einen seltsamen Ansatz, wenn sie Skripte automatisieren, in denen Benutzer einen Fehler finden. Normalerweise sind dies sehr exotische Szenarien, und es macht keinen Sinn, eine Ressource dafür auszugeben. Es gab eine Situation, in der die Funktionalität zur Aktualisierung der Daten der Kontrahentenbank unterbrochen wurde. Die Synchronisierung mit dem BIC-Verzeichnis ist fehlgeschlagen.
Das heißt, der neue BIC wurde nicht aktualisiert. Aber die neue Bank startete normal.
Ist es sinnvoll, dieses Szenario zu automatisieren? Wenn sich die Auftragnehmer jeden Tag ändern - vielleicht. Und dann war es ein Planungsfehler.
Wenn dies 5-6 Mal im Jahr durchgeführt wird, kann es besser sein, eine Aufgabe mit höherer Priorität auszuführen?
Was wird als nächstes passieren?
Im nächsten Artikel werde ich Ihnen erklären, wie Sie schnell mit dem Testen der API beginnen, diese Tests in Releases einbetten, Tests parallelisieren, Daten für Tests auswählen und was sie uns geben.
Ich möchte Sie an die Wirkung eines Pestizids erinnern und daran, wie Sie es auf ein Minimum reduzieren können.
Technologien: Java + Maven + Testng + Allure + RestAssured + Pict.