Vor etwas mehr als einem Jahr habe ich das Robot Framework zum ersten Mal ausprobiert. Während meiner Teilnahme an einem ziemlich großen Projekt habe ich zwei verschiedene Ansätze zum Testen der Automatisierung mit diesem Tool erlebt: Schreiben von Tests auf einem reinen DSL Robot Framework und Arbeiten in Zusammenarbeit mit Python. Wenn der erste Pfad eine niedrige Einstiegsschwelle hat, ist der zweite meiner Meinung nach im Hinblick auf die Unterstützung großer Projekte bequemer. Obwohl es keinen grundsätzlichen Unterschied zwischen den Ansätzen gibt. Auf die eine oder andere Weise kommt es darauf an, Bibliotheken zu finden.
Es lohnt sich jedoch, über die Merkmale der Ansätze zu sprechen.
Wer ist Roboter und womit isst er?
Es lohnt sich wahrscheinlich, mit der Einführung dieses leistungsstarken Tools zu beginnen.
Das Robot Framework ist ein Framework für schlüsselwortgesteuerte Tests. Es wird verwendet, um Abnahmetests und ATDD (Entwicklungsansatz durch Abnahmetests) zu automatisieren. Dieses System verfügt über eine benutzerfreundliche Testdatensyntax und ermöglicht die Automatisierung von Tests mithilfe von Schlüsselwörtern. Darüber hinaus verfügt das Robot Framework über hervorragende integrierte Bibliotheken und Bibliotheken von Drittanbietern, mit denen Sie die Automatisierung schnell starten und in Arbeitsprozesse integrieren können, ohne Ihre eigenen Fahrräder zu erfinden - dieselbe niedrige Einstiegsschwelle, die ich oben erwähnt habe.
Die Grundstruktur des Robot Frameworks wird mit Python implementiert und funktioniert auch mit Jython (JVM) und IronPython (.NET).
Anwendungsbeispiele sowie eine vollständige Dokumentation des Frameworks und der internen Bibliotheken finden Sie auf der offiziellen Website des Projekts:
http://robotframework.org/ .
Meine ersten Schritte. Erster Ansatz
Zum ersten Mal bin ich vor einem Jahr auf das Robot Framework gestoßen, nachdem ich meinen Job gewechselt hatte. Vorher hatte ich nur in Java und C # automatisiert.
Ich wählte für mich die Werkzeuge aus, mit denen ich mich mit vorhandenen Tests befassen muss, und interviewte neue Kollegen zu ihren Vorlieben. Sie waren sich nicht einig über die beste IDE für die Arbeit mit dem Robot Framework. Plugins für verschiedene Texteditoren und IDEs wie PyCharm ermöglichen hauptsächlich die Arbeit mit dem Robot Framework. Und die Empfehlungen, die ich gesammelt habe, wurden 50/50 zwischen Atom und PyCharm aufgeteilt. Natürlich gibt es RIDE, aber das ist kein Allheilmittel. Zu dieser Zeit (vor einem Jahr) fand ich keine normale Dokumentation darüber, und in der, die ich fand, sah ich keine großen Vorteile für meine Aufgabe. Daher habe ich mich für den Anfang entschieden, Atom mit Plugins auszuprobieren. Nachdem ich das Repository geklont hatte, begann ich langsam zu untersuchen, was in unseren Tests und im Robot Framework selbst geschah.
Ich bin für praktisch alles mit dem Projekt verbunden. Eine Reihe von Jython + Robot Framework funktionierte bereits dort, eine riesige Codebasis (geschrieben auf dem DSL Robot Framework selbst) wurde aus mehr als 1000 Tests und mehreren tausend Codezeilen von Hilfsbibliotheken in Java zusammengestellt.
So wie ich es verstehe, als das Projekt begann, d.h. Noch bevor ich in die Abteilung kam, arbeiteten hauptsächlich Java-Spezialisten daran, und das zu testende Produkt selbst befand sich in Java. Bei der Auswahl eines Ansatzes konzentrierten wir uns daher auf die verfügbaren Ressourcen. Im Allgemeinen war die Berechnung ungefähr so: Nach der Lösung einiger Probleme im Zusammenhang mit der Integration von Robot Framework und Java (hauptsächlich aufgrund der Tatsache, dass Java eine kompilierte Sprache ist, aber dasselbe Python und dieselben Tests im Python + RF-Bundle interpretiert werden) Es ist einfach, Experten von Drittanbietern zu gewinnen, die nur das DSL Robot Framework kennen, und leise Tests zu Schlüsselwörtern zu schreiben. Zwar mussten Kollegen viel Aufwand in die Erstellung von Bibliotheken in Java investieren, daher würden sie ohne die Bedingungen des Kunden einen solchen Pfad nicht empfehlen.
Nachdem ich im Rahmen meiner ersten Aufgabe ein wenig umgestaltet hatte, führte ich zuerst die Tests durch. Da das Jython + RF-Bundle verwendet wurde, wurde alles von maven gesammelt und die Roboterdateien wurden zur späteren Ausführung einfach in das Zielverzeichnis kopiert.
Die Tests wurden von Skripten (.bat- oder .sh-Dateien) ausgeführt, die entweder zu einem separaten Testfall (einer separaten .robot-Datei) oder zu einem Testplan (einer Datei mit einer Liste relativer Pfade zu Testfällen) führten.
Das Refactoring wirkte sich auf eine große Anzahl von Tests aus, sodass der erste Durchlauf etwa 15 Minuten dauerte. Nach Abschluss ist es Zeit, sich die vom Robot Framework bereitgestellten Berichte anzusehen.
Der Standardbericht (im obigen Screenshot) besteht aus den Dateien report.html und log.html:
- Der Bericht enthält eine allgemeine Zusammenfassung des letzten Laufs, in der Sie die Oberflächenergebnisse aller Tests (bestanden oder nicht bestanden) sehen können.
- In der Protokolldatei sehen Sie detailliertere Informationen - die schrittweise Ausführung jedes Tests. Dort können Sie alles anzeigen, was Sie zum Debuggen von Tests benötigen.
Ehrlich gesagt, beim ersten Blick auf den Robot Framework-Bericht beginnt das Auge ein wenig zu zucken: Es wird eine große Menge an Informationen angezeigt, und es dauert einige Zeit, um die End-to-End-Struktur der Tests zu verstehen und die Fähigkeit zu entwickeln, ein solches Protokoll zu lesen. Aber dieses Geschäft ist nicht so schwierig. Innerhalb weniger Monate könnte ich The Matrix zitieren: „Ihr Gehirn macht die Übersetzung selbst. Ich sehe nicht einmal den Code. Ich sehe eine Blondine, eine Brünette und eine Rothaarige. “ Also habe ich alle notwendigen Informationen in einer Datei ohne zusätzliche Werkzeuge gesehen.
Das Plus ist, dass die Ausgabe gesteuert werden kann: Es gibt verschiedene Protokollierungsstufen, die bestimmen, welche Informationen angezeigt werden und welche nicht. Der Pegel kann sogar für jede Zeile einzeln über die integrierte Bibliotheksmethode angepasst werden. Gleichzeitig ist es nicht überflüssig, die Reihenfolge der Anrufe innerhalb der Test- und Hilfsbibliotheken zu kennen - es ist einfacher, den Moment des Fehlers zu erfassen.
Mit dem DSL Robot Framework als Hauptwerkzeug haben wir ungefähr sechs Monate gearbeitet. Während dieser Zeit wechselte ich von persönlichen Einstellungen von Atom zu VSCode, aber dies änderte nichts an der Essenz des Ansatzes.
Das Projekt entwickelte sich jedoch. In der letzten Iteration umfasste die Hilfsbibliothek für die Arbeit mit der Datenbank insgesamt 6.700 Codezeilen auf einem reinen Robot Framework. Mit einer solchen Skalierung der Codebasis ist es schwierig geworden, die erforderlichen Ressourcen, die nicht zugewiesen wurden, zu warten und umzugestalten.
Das letzte Wort bei der Anwendung des ersten Ansatzes gehörte der Wirtschaft. Der Kunde unseres Projekts arbeitete auch mit anderen Teams an verwandten Aufgaben. In einer der parallelen Spuren sah er aus seiner Sicht eine effektivere und anschaulichere Option für die Verwendung des Robot Frameworks, das für die Implementierung speziell für das Management gestartet wurde.
Zweiter Ansatz
Der zweite Ansatz war die Entwicklung von Tests in Python in Verbindung mit dem Robot Framework. Anstatt alles mit der DSL Robot Framework-Syntax zu erstellen, haben wir begonnen, Hilfsbibliotheken und andere Interaktionen auf niedriger Ebene mit dem Testprodukt in Python zu schreiben. Und das Robot Framework wurde tatsächlich nur ein Läufer.
Da Python eine reine Hochsprache und kein DSL ist, gibt es mehr Strukturierungsoptionen. Es ist einfacher, alles herauszufinden. Zumindest können Sie die Python-IDE verwenden, um dieselben Methoden zu finden (sie tun dasselbe, werden aber unterschiedlich aufgerufen) oder sogar einen Code für Sie schreiben. Einige Daten können in Generatoren verpackt werden, Dekoratoren an Funktionen hängen usw. Vor diesem Hintergrund sehen die Werkzeuge des ersten Ansatzes (Pure Robot Framework) ziemlich hart aus - tatsächlich war es Notepad mit Syntaxhervorhebung. Keine Setter oder Getter, die IntelliJ für Sie schreibt. Ich war froh, zu einer höheren Sprache zurückzukehren. Die Arbeit mit diesem Ansatz ist eher eine normale Entwicklung. Es stimmt, es gibt eine Fliege in der Salbe. Ohne zusätzliches Tanzen ist es unmöglich zu verstehen, was in Python fiel, genannt von RF.
Langsam begannen die ersten Tests und Hilfsbibliotheken für unser Subsystem zu schreiben. Während der Zeit, in der ich mit einem neuen Ansatz arbeiten konnte, hatte ich das Gefühl, dass es mit einem anderen Tool wirklich mehr Möglichkeiten gibt. Tatsächlich hat sich am Schreiben der Tests nicht viel geändert. In diesem speziellen Projekt wurden innerhalb des Python-Codes die in Robot Framework integrierten Bibliotheksmethoden weiterhin aufgerufen. Dies war auf die besonderen Anforderungen des Kunden an die Entwicklung von Tests zurückzuführen. Wir haben einfach den ausführbaren Teil vom Testfallalgorithmus getrennt.
Welches ist besser?
Ich persönlich mag den zweiten Ansatz. Wenn Sie jedoch den Pfad Ihres Projekts auswählen, sollten Sie von der Aufgabe ausgehen - wer schreibt Tests und wie.
Wie oben erwähnt, bietet Python (der zweite Ansatz) mehr Möglichkeiten. In diesem Fall werden jedoch Personen benötigt, die mit dieser Sprache vertraut sind. Das Robot Framework selbst (und der erste Ansatz) ist weniger anspruchsvoll - Sie können sich ihm nähern, indem Sie die offizielle Dokumentation zu DSL lesen. Nach dem Studium der Bedienungsanleitung können Sie beliebige Tests erstellen - diese sehen ziemlich sauber aus.
Infolgedessen sind das Robot Framework und seine anfängliche Verwendung besser für die gestrigen manuellen Tester geeignet, ohne explizite Programmiererfahrung in Hochsprachen. Selbst eine Person, die nicht sehr an der Programmierung beteiligt ist, kann einen Test schreiben, indem sie einfach die erforderlichen Schlüsselwörter aufruft.
Wenn Sie jedoch den ausführbaren Teil nach dem Beispiel unseres Projekts getrennt halten und gleichzeitig den Code in benutzerfreundlichen IDEs umgestalten möchten, ist der zweite Ansatz für Sie.
Artikelautor: Dmitry Masters
PS: Wir veröffentlichen unsere Artikel auf mehreren Runet-Sites. Abonnieren Sie unsere Seiten auf
VK ,
FB oder
Telegramm-Kanal , um mehr über unsere Veröffentlichungen und andere Maxilect-Nachrichten zu erfahren.