Warum für das neue Projekt habe ich Robot Framework genommen

Kürzlich habe ich das Projekt geändert - ich bin zu einer neuen Entwicklung gekommen, bei der es vor mir keine manuellen oder automatischen Tests gab. Der Kunde hat dem Toolkit keine Bedingungen auferlegt (außer dass es Python war), also habe ich meine eigene Wahl getroffen. In diesem Artikel werde ich erklären, warum ich mich unter solchen Bedingungen für Robot Framework entschieden habe. Und am Ende wird es einige Beispiele geben, die speziell für den Artikel geschrieben wurden und veranschaulichen, wovon wir sprechen.

Bild

Ich mache seit über 10 Jahren Testautomatisierung und ungefähr drei von ihnen haben mit dem Robot Framework interagiert.

Wie ich oben erwähnt habe, bin ich vor nicht allzu langer Zeit zu einem neuen Projekt gekommen, bei dem ich angefangen habe, die Automatisierung von Grund auf neu zu testen. Ich kann Ihnen nichts über das Projekt erzählen - NDA. Ich stelle nur fest, dass dies ein cooles Automatisierungstool ist, das in Zukunft viel Personal einsparen sollte. Es besteht aus Microservices. Bisher betrifft meine Arbeit vier von ihnen, aber in Zukunft werde ich meine Aktivitäten auf andere ausweiten - alles hängt davon ab, dass ich nur 8 Arbeitsstunden pro Tag habe. Alles braucht Zeit.

Der Mangel an Tests bei diesem Projekt war identisch mit dem Mangel an empfohlenen Werkzeugen. Als Teil des Python-Stacks hatte ich freie Wahl. Und ich habe es ausgenutzt.

Warum Robot Framework?


Ich denke, ich kann Fans des Robot Framework zugeschrieben werden. Es scheint mir, dass fast alles daran getan werden kann.

Bei anderen Projekten verwendet das Unternehmen Pytest. Meiner Meinung nach verfügt es jedoch nicht über solche Funktionen, da es durch die Funktionen von Python eingeschränkt ist. Sie schreiben einfach Python-Code und stellen fest, dass Sie in einer solchen Variablen einen bestimmten Wert erwarten. Für meinen Geschmack ist es einfach, aber zu abstrakt. Viel wurde dem Entwickler überlassen, der alle nützlichen Funktionen von Hand hinzufügen muss. Robot Framework macht es selbst. Hier sind vier Punkte, die es wert sind, in Ihr Projekt aufgenommen zu werden.

Flexibilität


Das Robot Framework selbst ist in Python geschrieben (d. H. Alles, was Python kann), und dafür gibt es viele Bibliotheken, die von der Community erstellt wurden, was das Spektrum der zu lösenden Probleme erheblich erweitert.

Unter dem Robot Framework können Sie ganz einfach Ihre eigenen Bibliotheken schreiben und in fast alles integrieren, und alles wird sofort funktionieren. Es sind keine Krücken oder Fahrräder erforderlich.
Darüber hinaus können Sie mit dem Robot Framework parametrische Tests (Vorlagen) schreiben, was die Arbeit des Automatisierungstools erheblich beschleunigt.

Russische Sprache in Tests


Einer der grundlegenden Punkte ist, dass das Schlüsselwort (Analoga herkömmlicher Methoden im Robot Framework, die aus irgendeinem Grund historisch so genannt wurden) auf Russisch geschrieben werden kann. Dadurch sind die Testtexte natürlich weit von der literarischen Sprache entfernt, aber auf den ersten Blick wird klar, was dort passiert. Dies wird vor allem nicht von Endentwicklern benötigt, sondern beispielsweise von Stakeholdern. Sie können die Tests unabhängig voneinander öffnen und sehen, was genau dort passiert: "Wählen Sie ein zufälliges Element aus ..." usw.

Markieren


Robot Framework funktioniert gut mit Tags. Sie können nicht nur Tests mit einem bestimmten Tag ausführen, sondern auch Berichte mit deren Hilfe analysieren. Die Protokolldatei enthält Statistiken zu Tags, auf deren Grundlage Sie Maßnahmen ergreifen können, wenn Sie im Voraus über die Anordnung von Tags nachdenken.

Praktischerweise müssen Sie nicht in jedem Test alle Tags in ein langes Fußtuch schreiben, sondern Sie können Tests in eine Baumstruktur einbetten. In meinem Fall sieht es so aus: Die erste Ebene ist ein Microservice, die zweite ist die Art des Tests, die dritte ist der Test selbst (es ist praktisch, eine Init-Datei mit Tags für das, was darin eingebettet ist, zu platzieren).

Ich habe für jeden Microservice, jeden Testansatz (Rauchtests, CRUD-Tests, Integration usw.) ein Tag erstellt. Ich kann Tests eines bestimmten Typs oder nur für einen bestimmten Dienst ausführen. Ich markiere auch die Art der Funktionsliste oder detailliert. Und wenn das für die Liste verantwortliche Produkt im Produkt „bricht“, werden alle Tests mit diesem Tag rot, unabhängig davon, wo sie sich befinden und worauf sie sich beziehen.

Durch Tags binde ich Autotests an Jira. Wenn der Fehler vom Tracker geschlossen wird und der Test von Rot grün wird, haben wir immer noch eine Historie dessen, was sich genau geändert hat. Viele Monate später, wenn der Test wieder rot wird, können wir sehen, welche Schritte unternommen wurden, um das Problem beim letzten Mal zu beheben, und sogar davon ausgehen, dass dies zur Wiederholung des Fehlers geführt hat.

Ein weiteres spezielles Tag, das ich für unkritische Fehler hinzugefügt habe. Mit GitLab können wir nichts mit der Assembly tun, wenn mindestens ein Test abstürzt. Dies ist logisch - bis alle Fehler behoben sind, können wir weder ein Produkt noch einen wöchentlichen Sprint veröffentlichen. Aber wir haben niedrige Priorität und unbedeutende Fehler. Für sie habe ich ein Tag ausgewählt, mit dem das Robot Framework nicht die gesamte Baugruppe löschen kann, es sei denn, diese Tests (Tests mit diesem Tag) schlagen fehl.

Tolles Protokoll


Die Protokollanalyse ist ein wesentlicher Bestandteil des Testens. Was auch immer zum Zeitpunkt der Testdurchführung passiert, das Robot Framework schreibt absolut alles. Bis zu dem Punkt, dass ich einen speziellen Wrapper schreiben musste, der das Login und das Passwort aus dem Log verbirgt, um eine Verbindung zur Datenbank herzustellen.

Eine solche Detaillierung hilft, viel schneller zu verstehen, was der Grund für den Testabsturz ist - funktioniert das zu testende System nicht richtig oder wird etwas im Test nicht berücksichtigt und muss behoben werden? Die Antwort auf diese Frage ist nicht immer offensichtlich. Fehler von Entwicklern und Testern werden 50/50 verteilt.
In anderen Tools - im selben Test - können Sie dasselbe detaillierte Protokoll erstellen. Die Aufgabe, sie zu generieren, liegt jedoch beim Entwickler, der die Tests schreibt. Er muss darüber nachdenken, welche Art von Protokolleinträgen wirklich benötigt werden.

Was ist gerade auf dem Projekt?


Von dem Moment an, als ich anfing, das Robot Framework zu verwenden, sind mehrere Monate vergangen. Derzeit hat das Robot Framework mehr als 200 Tests implementiert. Wie oben erwähnt, gibt es eine Integration mit GitLab, mit deren Hilfe Änderungen am entwickelten Produkt überprüft werden können (Testfälle mit Kennungen, mit denen Sie Autotests an sie binden können, werden in testrail gespeichert).

Um die Abdeckung zu berechnen, habe ich ein Dienstprogramm geschrieben, das eine Liste von Backend-APIs von Swagger übernimmt und diese mit den getesteten vergleicht. Somit haben wir ein klares Verständnis der aktuellen Abdeckung. Zum Beispiel wissen wir, dass dieser Mikroservice heute vollständig abgedeckt ist, während der andere zu 98% abgedeckt ist. Und nachdem neue Funktionen hinzugefügt wurden, die sich noch nicht in Tests widerspiegeln, sinkt die Abdeckung. Dementsprechend können Sie planen, dass der nächste Sprint von mir durchgeführt wird.

Natürlich entwickelt sich das Projekt weiter. Zum Beispiel stellen wir jetzt einen Mock-Server bereit ( mein Kollege hat bereits über Habré geschrieben, was es ist und warum es benötigt wird).

Nun zum Üben


Die obigen Beispiele wurden speziell für den Artikel entwickelt, um die obigen Ideen zu veranschaulichen. Wenn Sie selbst mit diesen Beispielen experimentieren möchten, werden sie alle in unserem Repository veröffentlicht .

Das einfachste Testbeispiel


Beginnen wir mit dem einfachsten Test des Robot Frameworks.

Im folgenden Beispiel wird zunächst eine Sitzung für eine bestimmte offensichtlich zugängliche Ressource erstellt (in unserem Fall en.wikipedia.org/wiki ). Durch Aufrufen von Get root (/) überprüfen wir den Statuscode 200.

*** Settings *** Documentation  smoke-. Library RequestsLibrary *** Variables *** ${base_url} https://en.wikipedia.org/wiki ${url} / *** Test Cases ***   Wiki Create session conn ${base_url} disable_warnings=1 ${response} Get request conn ${url} Delete all sessions Should be equal ${response.status_code} ${200} 

Vorlagentests (parametrisch)


Mit Robot Framework können Sie Testmuster erstellen. Wenn wir den Test aus dem vorherigen Beispiel in die Vorlagenansicht übertragen, können wir ihn einfach skalieren, indem wir Aufrufe mit den erforderlichen Argumenten hinzufügen. Lassen Sie uns zum Beispiel die Antwort 200 auf Seiten mit Biografien von Wissenschaftlern überprüfen.

 *** Settings *** Documentation  smoke-.    . ...    . Library RequestsLibrary Test Setup   Test Teardown    Test Template Smoke- *** Variables *** ${base_url} https://en.wikipedia.org/wiki *** Test Cases ***      /Isaac_Newton      /Albert_Einstein      /Stephen_Hawking *** Keywords ***   Create session conn ${base_url} disable_warnings=1    Delete all sessions Smoke- [Arguments] ${url} ${response} Get request conn ${url} Should be equal ${response.status_code} ${200} 

Protokolle markieren und lesen


Wir verbessern den einfachsten Test weiter.

Mit einer Vorlage als einzigem Einstiegspunkt können wir problemlos die Überprüfung des Geburtsjahres des Wissenschaftlers hinzufügen. Auf diese Weise bestätigen wir, dass auf der geladenen Seite die richtigen Daten angezeigt werden.

Darüber hinaus habe ich im folgenden Beispiel das vorhandene Schlüsselwort in russische Namen eingeschlossen - für meinen Geschmack, sodass der Test organischer lautet. Als Tester habe ich mich immer über Methoden geärgert, die als "wie auf Englisch" bezeichnet wurden, aber völlig Analphabeten waren. Es ist immer besser, in der Sprache zu schreiben, die Sie kennen.

 *** Settings *** Documentation  smoke-.    . ...    . ...      . ...  . Library RequestsLibrary Test Setup   Test Teardown    Test Template Smoke- *** Variables *** ${base_url} https://en.wikipedia.org/wiki *** Test Cases ***      [Tags] Newton /Isaac_Newton 1642      [Tags] Einstein /Albert_Einstein 1879      [Tags] Hawking /Stephen_Hawking 1942     (  ) [Tags] Numbers /123456789 1899 *** Keywords ***   Create session conn ${base_url} disable_warnings=1    Delete all sessions Smoke- [Arguments] ${url} ${expected_word} ${response} Get request conn ${url} Should be equal ${response.status_code} ${200} ... msg=  GET ${url}    ,   200 .      ${response.text} ${expected_word}      [Arguments] ${text} ${expected_word} Should contain ${text} ${expected_word} msg=    ${expected_word}! 

Achten Sie auf [Tags] . Sie können hier Tags hinzufügen, die, wie oben geschrieben, dazu beitragen, Probleme auf Berichtsebene zu bewerten. In ähnlicher Weise können Sie mit Force Tags in der __init __. Robot-Datei (siehe Beispiel in unserem Repository ) Tags für alle Tests im Verzeichnis festlegen, einschließlich verschachtelter. Wenn das Tagging korrekt durchgeführt wird, ohne die Namen der Tests selbst zu lesen und ohne in ihre Logik zu kriechen, können wir ziemlich genau davon ausgehen, dass es im Testprojekt nicht funktioniert.

Schauen Sie sich den Bericht über den Start dieser Tests an. Aus Gründen der Übersichtlichkeit habe ich einen Test hinzugefügt, bei dem ein Fehler festgestellt wird.

Berichtsstatistiken sind der wichtigste Teil.

Bild

In unserem Beispiel haben Tests mit dem numbers Tag nicht vollständig bestanden (wir haben 1 von 1, aber im wirklichen Leben gibt es zum Beispiel 17 von 20). Es kann davon ausgegangen werden, dass das Problem auf dieser Seite liegt.

Mithilfe von Tags können Tests selektiv ausgeführt werden. Um alle Tests mit einem bestimmten Tag in der Startzeile auszuführen, müssen Sie Folgendes angeben:

 --include <tag> 

Auch logische Operationen mit Tags werden unterstützt:

 -- include <tag>AND<tag> 

Wenn Sie beispielsweise nur den Rauchtest für Tests mit dem Nummern-Tag ausführen möchten, sollten Sie Folgendes hinzufügen:

 --include smokeANDnumbers 

Unkritische Tests


Kommen wir zu Tricks, die die Arbeit erheblich vereinfachen.

Nachdem Sie den Test mit Tags versehen haben, können Sie eines oder mehrere davon als "unkritisch" definieren. Ein Test mit einem solchen Tag zeigt weiterhin Fehler (falls vorhanden) an, aber am Ende werden diese Fehler nicht als "ungültig" interpretiert. Ich verwende diese Option, wenn einige kleinere Fehler berücksichtigt, in den Bug-Tracker eingegeben, aber noch nicht behoben wurden. Ohne diese Funktion können die in CI enthaltenen Autotests nach Feststellung solcher bekannter Probleme das Projekt nicht zusammenstellen, was nicht immer praktisch ist.

Neuen Test hinzufügen:

     (   ) [Tags] Letters Known /abcdefghi 1799 

Beim Start wird das hinzugefügte Tag mithilfe des Schlüssels als "unkritisch" definiert:

 --noncritical Known 

Schlüsselwort in Python


Im folgenden Beispiel werde ich veranschaulichen, wie meine Bibliothek hinzugefügt wird.

Erstellen Sie ein neues Schlüsselwort "Generieren Sie ein Array von Zahlen". Sein Zweck ist offensichtlich (dafür liebe ich russische Namen).

 from random import randint from typing import List from robot.api.deco import keyword class ArrayGeneratorLibrary: ROBOT_LIBRARY_SCOPE = 'GLOBAL' @keyword("  ") def generate_array(self, length: int, minimal: int, maximal: int) -> List[int]: result = [] for i in range(int(length)): result.append(randint(int(minimal), int(maximal))) return result 

Wir verbinden die Bibliothek im Test:

 Library libraries.ArrayGeneratorLibrary 

und benutze es:

   ,   python. ${array}    ${5} ${2} ${8} Log to console ${array} 

Vergessen Sie nicht, dass Sie eine verschachtelte Struktur wie im Beispiel durch Punkte trennen sollten.
Ein weiterer Trick: Die in ${} Zahlen werden als int und nicht als Zeichenfolgen behandelt!

Inline-Argumente


Eine weitere schöne Sache sind die eingebauten Argumente, die nicht wie üblich am Ende des Anrufs, sondern direkt in seinem Körper übergeben werden.

Zur Veranschaulichung schreiben wir einen Wrapper für den oben erstellten Array-Generator, der die Verwendung der integrierten Argumente ermöglicht:

  ${n} ,  ${from}  ${to} ${result}    ${n} ${from} ${to} [Return] ${result} 

Jetzt können Sie so schreiben:

       . ${array}  5 ,  2  8 Log to console ${array} 

Ersetzen eines Teils des Methodennamens, der Python-Einfügung und der Schleifen


Der nächste Trick, den ich am Robot Framework wirklich mag, ist das Ersetzen eines Teils des Namens. Angenommen, wir haben zwei Methoden: eine wählt gerade Zahlen aus, die andere ungerade.

      [Arguments] ${list} ${evens} Evaluate [i for i in $list if i % 2 == 0] [Return] ${evens}      [Arguments] ${list} ${odds} Evaluate [i for i in $list if i % 2 != 0] [Return] ${odds} 

Mit dem oben verwendeten Schlüsselwort Evaluate können Sie eine Zeile Python-Code "genau hier" ausführen. Bitte beachten Sie, dass Sie den Variablennamen unmittelbar nach dem $ -Zeichen ohne geschweifte Klammern angeben sollten, wenn Sie ein Stück der Zeichenfolge nicht durch den Inhalt der Variablen ersetzen möchten, dh einen Link dazu übergeben möchten!

Sie können also beide Methoden aufrufen und den unterschiedlichen Teil ihres Namens ersetzen:

     ,   . . ${types} Create list   ${array}  5 ,  12  28 FOR ${type} IN @{types} ${numbers} Run keyword  ${type}    ${array} log to console ${numbers} END 

Method Decorators


Ja, mit Robot Framework können Sie einen Dekorateur für andere Schlüsselwörter schreiben!

Um diese Funktion zu veranschaulichen, schreiben wir einen Dekorateur, der in der Antwort einer Methode, die eine Liste zurückgibt, negative Zahlen auswählt.

     ,  [Arguments] ${keyword} @{args} &{kwargs} ${list} Run keyword ${keyword} @{args} &{kwargs} ${negs} Evaluate [i for i in $list if i < 0] [Return] ${negs} 

Beachten Sie:
@{args} sind alle unbenannten Argumente;
&{kwargs} sind alle benannten Argumente.
Mit diesem Bündel können Sie sie umleiten und so einen Dekorateur erstellen.
Die Arbeit mit dem Dekorateur sieht folgendermaßen aus:

    ${negs}     ,     10 -5 5 log to console ${negs} 

Anstelle einer Schlussfolgerung


In den obigen Beispielen habe ich die Hauptfunktionen des Robot Framework gezeigt, die das Leben erheblich erleichtern. Aber seine Chips sind nicht auf diese Liste beschränkt.

Wenn Sie Fragen haben, schreiben Sie in die Kommentare. Wir werden die Hauptrichtung des Leseinteresses herausgreifen und die Fragen mit einer Fortsetzung des Textes beantworten.

Der Autor des Artikels: Vladimir Vasyaev.

PS Wir veröffentlichen unsere Artikel auf mehreren Websites der Runet. Abonnieren Sie unsere Seiten auf VK , FB oder Telegramm-Kanal , um mehr über unsere Veröffentlichungen und andere Maxilect-Nachrichten zu erfahren.

Source: https://habr.com/ru/post/de470924/


All Articles