Kassettenrekorder - ein Tool zum Aufzeichnen von Autotests

Guten Tag, liebe Leser. Ich heiße Victor Burov. Ich arbeite als Entwickler bei ISPsystem und möchte meine Erfahrungen in der Testautomatisierung teilen.

So kam es, dass in unserem Land manuelle Tests vorherrschten und die Tester viel Zeit damit verbrachten, dieselben Aktionen durchzuführen. Einmal dachten wir: Warum nicht dem Panel beibringen, die Aktionen des Testers zu wiederholen, denn tatsächlich werden alle zu spezifischen API-Aufrufen. Dies würde es den Leuten ermöglichen, Tests auch ohne Programmierkenntnisse zu schreiben.

Wir haben beschlossen, ein Modul zum Erstellen automatischer Tests zu schreiben. Damit der Tester einfach die Taste drücken kann, um einen Test zu erstellen, die Bedingungen des Testfalls zu erfüllen, klicken Sie am Ende auf "Fertig stellen" - und fertig, der Test war fertig! Eine einfache Idee, aber zu realisieren war nicht einfach. Weil wir wollten, dass dieses Modul maximal an unsere Produkte angepasst wird und eine einheitliche Oberfläche nutzt, damit das aufgenommene Video wie ein vorgefertigter Testfall aussieht. Dies würde die manuelle Arbeit beim Schreiben von Tests vollständig eliminieren. Das resultierende System wurde als "Tonbandgerät" bezeichnet.


Schnittstelle zum Anzeigen von Testfallbedingungen

Arbeitsprinzip

Alle Anforderungsparameter (HTTP-Header, Umgebungsvariablen, POST-Daten, falls vorhanden) und die gesamte Antwort werden in die XML-Datei geschrieben. Jedem Datensatz ist eine Seriennummer zugeordnet. Alle Anforderungen sind in modifizierende und nicht modifizierende unterteilt. Nach dem Aufzeichnen des Tests werden viele der nicht modifizierenden Anforderungen herausgeschnitten, da sie die Ausführung der Tests nicht beeinflussen und nur den Ausführungsprozess verzögern und verwirren (daher die fehlenden Sequenznummern im Screenshot).

Während der Aufnahme können Sie mit dem Kassettenrekorder die Werteprüfung in den Feldern der Formulare und in den Listenspalten mit einem Klick festlegen. Außerdem können Sie negative Tests aufzeichnen und sich daran erinnern, welchen Fehler das Bedienfeld während der Aufzeichnung eines Tests zurückgegeben hat.

Während der Wiedergabe werden Anforderungen ohne Verwendung eines Browsers direkt an die Anwendungs-API gesendet.

Tatsächlich ist ein Kassettenrekorder ein Modul, das in alle unsere Produkte integriert ist und es Ihnen ermöglicht, ereignisreaktive Prozessoren zu installieren. Geschrieben mit COREmanager.

Ein Beispiel für die Aufzeichnung eines Anrufs mit einem Kassettenrekorder:

Verbesserungen (über die wir nicht im Voraus nachgedacht haben)

Warten

Eine Person kann "nur warten", ein Computer - nein. Eines der ersten Probleme, die der Kassettenrekorder lösen sollte, war das Schreiben von Vaters. Was die Leute nicht erfunden haben, um auf den Abschluss der Operation zu warten. Die Erwartung von Hintergrundaufgaben und die Möglichkeit, für eine bestimmte Anzahl von Sekunden einen Stopp am angegebenen Schritt hinzuzufügen, wurden implementiert.

Testschritte aufzeichnen und bearbeiten

Wahrscheinlich erinnert sich jeder an die Zeiten der Schreibmaschinen: ein Fehler - und Sie müssen die gesamte Seite neu drucken.



Damit der Tester nicht den gesamten Test mit einer fehlerhaften Aktion neu schreiben musste, wurde ein Mechanismus hinzugefügt, um den Test von jedem Schritt nach dem Speichern neu aufzuzeichnen. Die Möglichkeit zum Bearbeiten ist praktisch, wenn Sie den Test an Änderungen im Verhalten der getesteten Funktionen anpassen müssen.

Makros für Variablen

Während der Tests änderten sich die Werte in den übertragenen und überprüften Parametern je nach Server, auf dem sie ausgeführt wurden. Ein Beispiel für solche Daten sind IP-Adressen. Es ist unmöglich, sie in der Testaufzeichnungsphase zu erkennen, daher habe ich ein Makrosystem hinzugefügt. Auf diese Weise konnten wir Tests erstellen, die nicht so stark an die Umgebung gebunden sind. Der Nachteil der Lösung besteht darin, dass Makros nach der Aufzeichnung manuell angegeben werden müssen.

Ein weiteres Problem, das die Arbeit mit dem Kassettenrekorder erheblich erschwert, ist die Verwendung nicht nativer Schlüssel. Wir haben es nicht sofort bemerkt, als wir den Kassettenrekorder auf ISPmanager getestet haben, der native Bezeichner verwendet. In einigen anderen Bereichen wird der Datensatz jedoch durch eine eindeutige ID identifiziert. Daher musste ich dem Kassettenrekorder beibringen, die Kennung nach dem Erstellen des Datensatzes oder Objekts nicht nur zu erhalten (da sich die ID von Anfang zu Start ändern kann), sondern sie auch bei allen nachfolgenden Anforderungen zu ersetzen.

Unterstützung des JUnit-Formats

Von Bändern generierte Tests werden automatisch in der Jenkins-Umgebung für die kontinuierliche Integration ausgeführt. Nach Abschluss der Tests wird eine XML-Datei erstellt, die die Daten im JUnit-Format enthält. Damit die Datei korrekt erstellt werden kann, wurde eine Einschränkung für die Benennung von Tests eingeführt. Beispielsweise fiel der Test User.Create.xml in die Testsuite mit dem Namen User und hatte daher einen Testfall namens Create. Im Fehlerfall wurde ein Fehlerknoten mit einer vollständigen Beschreibung des Fehlers hinzugefügt.

Metriken

Die Anzahl der eindeutigen aufgerufenen Funktionen wird während des Testdurchlaufs berechnet und das Verhältnis als Prozentsatz der Gesamtzahl der Funktionen bestimmt, ausgenommen diejenigen, die nur für den internen Gebrauch verfügbar sind. Somit wird die einfachste Testabdeckung gemessen. Darüber hinaus zeigen die Metriken die Gesamtzeit für den Abschluss des Tests und die Anzahl der erfolgreichen und fehlgeschlagenen Tests.

Repository testen

Das Test-Repository löst zunächst das Problem der Übertragung vorgefertigter Tests auf andere Server. Es ist auch praktisch, wenn mehrere Tester Tests schreiben. Auf Basis unseres CORE-Managers wurde ein kleines Panel zum Speichern von Speichertests entwickelt und bereitgestellt. Das Tonbandgerät verfügt über ein Modul zum Synchronisieren von Tests mit dem Speicher. Wenn Sie einen neuen Test schreiben oder Tests aus dem Repository entladen, sind sie automatisch nicht mehr zum Laden in das Repository verfügbar, sodass keine Verwirrung entsteht. Nach dem Ändern des Tests wird die Versionsnummer erhöht, sodass nur Tests nach dem Laden der Änderungen in das Repository geladen werden.

Schwierigkeiten (na ja, wo ohne sie)

Die Verwendung eines Tonbandgeräts zeigte, dass nicht alle API-Funktionen unseren internen Empfehlungen entsprachen. Insbesondere haben nicht alle Funktionen die Datensatzkennung nach ihrer Erstellung zurückgegeben. Ich musste zurückkehren, einschließlich eines Arbeitscodes, und ihn an die Anforderungen anpassen.

Deadlock ist ein weiteres Problem. Das Panel impliziert die Ausführung einiger kritischer Aktionen im exklusiven Modus. Und das Tonbandgerät, das Teil desselben Panels war und solche Funktionen verursachte, ließ das gesamte System einfrieren. Dies konnte nur mit Hilfe von GDB festgestellt werden (niemand erinnerte sich an diese Funktion). Leider gab es Krücken, da bei der Ausführung der Tests des Tonbandgeräts entschieden wurde, diese Funktionen im Multithread-Modus auszuführen. Theoretisch war es möglich, ein Tonbandgerät nicht mit einem Modul, sondern mit einem separaten Panel zu entwerfen. Aber wir haben es nicht versucht.

Leider ist auch das Schreiben und Vergessen gescheitert. Die Benutzeroberfläche unserer Produkte ändert sich und wird immer komplizierter. Darüber hinaus wächst die Anzahl der Schnittstellenkomponenten aktiv. Daher muss der Kassettenrekorder von Zeit zu Zeit geändert werden, damit er beim Erscheinen neuer Komponenten deren Struktur analysieren und die Ergebnisse von Abfragen verarbeiten kann.

Fazit

Die Erstellung eines Tonbandgeräts hat dazu beigetragen, die Qualität der getesteten Produkte zu verbessern. Zeit und Ressourcen für die Schulung von Testern gespart. Auf dem Weg dorthin konnten wir mit dem Kassettenrekorder unsere API auf Übereinstimmung mit internen Empfehlungen überprüfen und die API daher etwas „logischer“ gestalten.