Wir bei Alfastrakhovanie verwenden SAP ERP als Prozessverlust-Abwicklungssystem. Und es ist einfach so passiert, dass wir es ein wenig finalisieren, was unweigerlich zu Fehlern im Code führt. Wenn Fehler ein produktives System erreichen, ist dies schlecht. Dies sollte vermieden werden. Eine Möglichkeit sind Regressionstests. In diesem Artikel werde ich genau darüber sprechen, wie wir die "Regression" für SAP durchführen, weil wir dies tun (oh!) Nicht standardisiert.
Alles begann vor ein paar Jahren. In diesen Jahren haben wir bereits aktiv Regressionstests verwendet, dies war jedoch in SAP nicht möglich. Die verwendeten Tools funktionierten nicht mit SAP. Das Testteam wollte die für SAP „geschärften“ Tools nicht untersuchen. Ich erinnere mich nicht genau, warum, aber ich nahm es als Herausforderung (dies war, bevor ich zum Date Engineering wechselte) und beschloss, das Problem zu „studieren“.
Die Ergebnisse der Studie (sowie "Doing") - in diesem Artikel (unten) möchte ich kurz Folgendes sagen: Wir testen SAP (und seine unmittelbare Umgebung) automatisch, wir machen es ziemlich effektiv (in jeder Hinsicht), wir haben keinen einzigen Rubel für Lizenzen ausgegeben und Training ist unser Ansatz einfach und vollständig reproduzierbar. Und wir verwenden keine SAP-Tools zum automatischen Testen von SAP (außer an dem Ort, an dem wir das Transportsystem eingebaut haben).
Große Striche
Es besteht die Gefahr, auf Details einzugehen und Leser zu verlieren. Ich werde versuchen, dies nicht zu tun (als Autor kenne ich alle Details).
Alles begann mit dem Studium und der Kommunikation mit SAP, unseren Partnern und Herrn Google.
Das Ergebnis dieser Mitteilung war wie folgt:
- SAP verfügt über Tools zum Testen der Automatisierung (wir haben uns eCATT genau angesehen, SAP CBTA).
- Sie erfordern ein erhebliches Eintauchen (insbesondere SAP CBTA).
- Einschränkungen können erforderlich sein, falls erforderlich, gehen sie über die Grenzen von SAP hinaus (er befindet sich bei uns nicht in einem „Vakuum“).
- Es gibt Produkte von Drittanbietern (z. B. HP), für die wir jedoch keine Kompetenzen haben, genau wie wir Lizenzen gekauft haben
- Es gibt eine Möglichkeit, SAP von außen zu "verwalten" (die Firma Convista hat mir diese Idee mitgeteilt, vielen Dank dafür).
Da ich persönlich keine SAP-Kenntnisse hatte, habe ich mich entschlossen, in die letzte Richtung zu graben - die Verwaltung von SAP erfolgt nicht über SAP. Herr Google stellte schnell das Dokument "SAP GUI Scripting API für die Windows- und Java-Plattformen" zur Verfügung, das einen guten Start für diese Initiative darstellte. Ein kurzer Test mit meiner Lieblingspython zeigte, dass es funktioniert.
Als nächstes war es eine kleine Sache - ein geeignetes Framework für die Testautomatisierung zu finden. Da Python meine Lieblingssprache war, wurde das Robot Framework schnell in Betracht gezogen. Und tatsächlich, nachdem er auf die Liste gekommen war und vor Gericht gestellt wurde, blieb nur er auf der Liste. Bestochen durch die Tatsache, dass "es" sofort funktionierte (mit Blick auf die Zukunft - und immer noch funktioniert, bereue ich keine Minute über meine Wahl).
Ein kleiner Pilot zeigte, dass SAP von einem Roboter perfekt "gesteuert" wird (ich werde das Robot Framework als russisches Wort bezeichnen): schnell, synchron, vorhersehbar und zuverlässig. Gleichzeitig verwenden wir - ich betone - die von SAP dokumentierte Art der Interaktion mit der SAP-GUI (keine Art von „Krücken“).
Architektur
(Ja, lassen Sie mich dieses Wort hier verwenden)
Wie es funktioniert:
- Das Skript wird auf dem Server ausgeführt (das Wort "Server" wird hier in dem Sinne verwendet, dass dieser Computer unsere Testanforderungen erfüllt. In diesem speziellen Fall ist es korrekter, das Wort "Client" zu verwenden, da das Skript den Testprozess steuert.)
- Über den Standardmechanismus der Roboterfernbedienung interagiert das Skript mit der Serverkomponente des Roboters, der auf SUT (zu testendes System) ausgeführt wird.
- Diese Serverkomponente ruft die Methoden der SAP-Verwaltungsbibliothek auf
- SAP GUI verarbeitet diese Anforderungen (synchron, dies ist wichtig)
- Die Ergebnisse der Ausführung von Abfragen oder nur „Beats“ werden an das Skript auf dem „Server“ zurückgegeben, wo sie für die Tests verwendet werden
Technisch
- "Server" ist eine virtuelle Maschine unter Ubuntu
- SUT - die Workstation, auf der die SAP-Workstation installiert und konfiguriert ist (in unserem Fall ein Windows-Computer oder eine virtuelle Maschine)
- Die SAP-Verwaltungsbibliothek ist in Python geschrieben (es gibt einige - einige hundert Zeilen).
- "script" ist ein "Programm" in einer Sprache, die vom Robot Framework verstanden wird
- Der Roboter (als solcher) impliziert eine Befehlszeile, da ABAP-Entwickler nicht daran gewöhnt sind. Ich habe eine WEB-Schnittstelle erstellt, die insbesondere kollektive Arbeit bietet (etwas später).
Was ist wunderbar
Was haben wir eigentlich bekommen, abgesehen von der fehlenden Lizenzbelastung?
Viele Dinge, wenn auch kurz und über die Hauptsache:
Russisch
Das Skript sieht ungefähr so aus:
Ganz am Anfang der Reise (wahrscheinlich während des Piloten) dachte ich - und dass wir uns die Zunge brechen und uns ein paar unverständliche Worte einfallen lassen? Der Roboter impliziert die Erstellung eigener Schlüsselwörter (Entschuldigung für die Terminologie - so nennt er sie). Warum kommen wir nicht sofort auf Russisch auf sie? Er fragte in der Community der Tester (irgendwo im Internet) - sie "verpatzten" mich: Es ist gefährlich, warum, wer hat es gesagt usw. Ich bin meinen eigenen Weg gegangen - wir haben alles auf Russisch (Variablen, Wörter, nur die Kontrollstrukturen des Roboters bleiben übrig, aber sie müssen in den Schlüsselwörtern versteckt sein - wenn Sie Englisch sehen, ist es Zeit für eine Umgestaltung).
Was ist gut an der russischen Sprache (außer für die Verständlichkeit ohne Wörterbuch) - das Skript kann einem Nicht-IT-Spezialisten, einem Geschäftsmann, gezeigt werden. Sie können dieses Skript direkt mit ihm schreiben (ich werde hier nicht einmal versuchen, auf das ATDD-Thema einzugehen - dies ist ein separater und großer Beitrag, ich werde ihn eines Tages schreiben).
Totale und totale Kontrolle und Erweiterbarkeit
Ich weiß genau, was während des Testprozesses passiert. Es gibt überhaupt keine Magie - alles ist extrem klar. Ich weiß nicht wie jemand, das gefällt mir.
Über Erweiterbarkeit - Funktionalität kann in jede Richtung entwickelt werden, die wir aktiv genutzt haben:
- Ich habe es geschafft, meine eigene "Sprache" für Testskripte zu entwickeln, die für Unternehmen verständlich ist
- Es war möglich, automatisch zu überprüfen, ob die Felder in der Schnittstelle am Ende des Tests korrekt ausgefüllt waren (insbesondere haben wir die Robotervariablen in Startparameter und Schnittstellenparameter unterteilt, um zu bestimmen, welches Schnittstellenelement welchen Startparameter haben soll).
- Haltepunkte können zu Tests hinzugefügt werden. Überprüfen Sie während Haltepunkten die Werte von Variablen
- Wir haben einen Mechanismus zum Erstellen und Einfügen von Dateivorlagen in den Ausführungsprozess implementiert. Ohne diesen Mechanismus wäre es unmöglich, ein Tier wie ein VLP zu testen (und wir haben es in einem vollautomatischen Modus getestet - von der Generierung einer Anwendung bis zum Parsen eines Extrakts).
Das Vorhandensein unserer eigenen Weboberfläche fügte weitere Erweiterungsmöglichkeiten hinzu - zum Beispiel können wir es uns leisten, die Robotersprache zu ändern (wir haben uns zum Beispiel unseren bedingten Operator ausgedacht - wir und unsere Geschäftsbenutzer mochten das Standard-Schlüsselwort "Ausführen, wenn" nicht). Dies wurde möglich, weil Dateien mit Testquellcode von einer Webanwendung für den Roboter generiert werden.
Einfache Eingabe
Tester haben in der Regel keine Kenntnisse der SAP-Infrastruktur und insbesondere der SAP-Programmierung. Sie schaffen es, den Roboter und unsere Verbesserungen in ein paar Wochen zu beherrschen.
Benutzeranleitung
Wir wandten uns auch "Unser William ..." zu - der Dokumentation. Es ist für niemanden ein Geheimnis - in der Regel gibt es keine Dokumentation für das System, und selbst wenn dies der Fall ist, ist es sehr schnell veraltet. Benutzer übergeben die Regeln für die Arbeit mit dem System "Mundpropaganda". Wenn der automatische Testcode laut Autor eine Beschreibung der Verwendung des Systems enthält, warum nicht in eine Anweisung konvertieren?
Natürlich sind die Details auf diesem Fragment schwer zu erkennen. Es ist wichtig, dass die Anweisung in einem vollautomatischen Modus einschließlich Screenshots generiert und aktualisiert wird. Die Anweisung ist immer auf dem neuesten Stand (da Autotests immer funktionieren). Im Fall von SAP werden Screenshots im Allgemeinen gut aufgenommen - in SAP finden Sie immer ein Schnittstellenelement - ein Rechteck, dessen Koordinaten für die aktuelle Stelle im Testcode relevant sind. Dieses (für das Auge unsichtbare) Steuerelement wird als Parameter für das Schlüsselwort "Take a Screenshot" (dieses Wort) verwendet Natürlich funktioniert es nur mit dem entsprechenden Teststartmodus - warum einfach so Strom ausgeben).
Wir haben die Anleitung mit Sphinx formatiert (ich bin sicher, dass viele das Farbschema gelernt haben), daher sind sie sowohl im Online-Handbuch als auch in gedruckter Form verfügbar.
Ein bisschen über Robot Framework
Trotzdem kann nichts über den Roboter gesagt werden - er wird sich zu unverständlich und oberflächlich herausstellen. Ich werde es kurz versuchen.
Die Hauptidee dieses Frameworks ist die Möglichkeit, eine eigene Testsprache zu erstellen (in der Terminologie des Roboters ist die ausführbare Einheit das Schlüsselwort - das Schlüsselwort). Das Framework bietet
- Programmausführungsumgebung (Programmierer - seien Sie nicht beleidigt) in dieser Sprache
- funktionsreiche Bibliotheken (von der Arbeit mit Strings und Listen bis zu ssh und Selen)
- Berichterstattung (während des Nutzungsprozesses gab es nicht einmal den Gedanken, irgendeine Art von Bericht zu schreiben)
- Ein einfaches Paradigma für die Bildung eines Programms aus Schlüsselwörtern (etwas eigenartig, aber man kann sich daran gewöhnen). Es gibt beispielsweise Variablen, Parameter und die Ergebnisse von „Aufrufen“ (Schlüsselwörtern).
- Einfache und leistungsstarke Erweiterbarkeit - Es ist sehr einfach, eine eigene Bibliothek in Python zu erstellen (z. B. haben wir auf diese Weise mit Excel gearbeitet), sowohl lokal (d. h. am selben Ort wie der Testcode ausgeführt) als auch remote (z. B. z. welches die SAP GUI steuert)
Das Erstellen eines Tests ist ziemlich einfach
- Wir bilden eine Abfolge von Aktionen und übersetzen sie in einen Roboter (etwas niedriger sind die Einzelheiten zur Interaktion mit dem zu testenden System).
- Wiederholte Sequenzen werden in ihren (neuen) Schlüsselwörtern umgestaltet
- Führen Sie den Test aus, sehen Sie, wie er funktioniert, beheben Sie ihn, verbessern Sie ihn
- Das Debuggen erfolgt über Haltepunkte (mit der Möglichkeit, Variablen anzuzeigen - genauer gesagt durch die Architektur - die Verwendung der Remote-Bibliothek des Roboters).
Das Ergebnis ist nicht einmal ein Programm (siehe Beispiele oben), sondern eine formalisierte Abfolge von Aktionen, die im Übrigen die Verwendung des Programms in der vom Autor beabsichtigten Form beschreibt (siehe ATDD oben).
Interaktion mit dem zu testenden System
In unserem Fall testen wir auf der Ebene der Benutzeroberfläche (d. H. Unsere Tests interagieren mit dem SAP auf der GUI-Ebene - sie "klicken" auf Schaltflächen, füllen Textfelder aus usw.). Es ist allgemein anerkannt, dass diese Art, Tests zu schreiben, nicht die beste ist. Ich stimme dem teilweise zu, bin aber bereit zuzuhören und zu diskutieren, wie SAP-GUI-Anwendungen (wie unser SAP FS CM) getestet werden.
Es gibt so einen Guru - Robert Martin (alias "Onkel Bob" - der Autor von "Clean Coder", falls jemand liest), wir haben ein wenig darüber korrespondiert. Sie waren sich einig, dass wenn es nicht sehr schwierig ist, es sich nicht sehr oft ändert (Breaking-Tests), dann okay - Sie können auch über die Schnittstelle testen.
Ich für meinen Teil kann Folgendes sagen: Im Fall der SAP-GUI gibt es nicht viele Optionen für die Implementierung der Benutzeroberfläche. Wenn Sie beispielsweise die Möglichkeit hinzufügen müssen, den IMEI-Code zu verfolgen, können Sie dies auf fast eine Weise tun - indem Sie einem der Lesezeichen das entsprechende Feld hinzufügen. Daher denke ich, dass alle Nuancen dieser "Ergänzung" vom Kunden durchdacht werden können und sollten (wie dieses Feld in der Benutzeroberfläche, der Breite, der Verwendungsreihenfolge usw. aufgerufen wird). Und er kann es direkt in einem Skript tun, das es dann automatisch testet. Wenn Sie eine Revision nicht bis zum Ende durchdenken können (wie sie sagen - nun, Sie tun es und wir werden sehen), ist es besser, diese Revision nicht durchzuführen. Und zu tun, was Sie durchdenken können. Nun, ich bin wieder zu ATDD gekommen ...
Zurück zur Interaktion mit der SAP-GUI: Wir haben, wie ich bereits schrieb, ungefähr 200 Zeilen in Python und ungefähr 10 verschiedene Schnittstellenverwaltungsfunktionen (wie "Gehe zu Lesezeichen", "Füllen Sie das Feld aus", "Drücken Sie die Taste"). Dieses Set wurde fast in den frühen Tagen gebildet und dehnte sich anschließend nicht viel aus. Zur Ehre von SAP stelle ich fest, dass alles sehr schnell funktioniert - das Auge hat keine Zeit, um zu verfolgen, wie die Schnittstelle „blinkt“, Verzögerungen wurden in den Regelkreis eingefügt, um zu verlangsamen (falls erforderlich, visuelle Kontrolle). Ich stelle auch die Vorteile des Synchronbetriebs fest: Nirgendwo im Code müssen Sie auf etwas warten. Wenn beispielsweise die Taste gedrückt wird, ist die dem Klicken auf die Schaltfläche entsprechende Aktion abgeschlossen (z. B. wurde der Verlust gespeichert).
def get_ctrl_attr ( self, uid, attr ): """ ( ) ( ) exception = ( log) """ ctrl = self._get_ctrl(uid) try: retText = getattr( ctrl, attr ) except: raise AssertionError(" {1} {0}".decode("utf-8").format(attr,uid)) return retText
Ein paar Kommentare zum Code
- Fragment der SAP GUI Management Library
- Eine Bibliothek ist ein Objekt. Methoden sind direkt in Tests verfügbar (in Schlüsselwörtern). Die obige Methode kann beispielsweise folgendermaßen aufgerufen werden: "res = get ctrl attr $ {UID} text" (unter Verwendung der Roboternotation)
- Im Fehlerfall wird der Ausnahmetext im Protokoll des Roboters angezeigt (Sie müssen hierfür nichts tun - nur die Ausnahme "töten"
Der Code ist sehr einfach, es gefällt.
Ausführen von Tests
Nach der Logik des Roboters werden in unseren Projekten einzelne Tests kombiniert. Ein Test oder Projekt kann manuell über die Weboberfläche gestartet werden. Der Regressionstestprozess ist ebenfalls in das SAP-Transportsystem integriert:
- Der Eigentümer des Produkts genehmigt am Ende der Geschäftstestphase Transportaufträge zur Übertragung
- Genehmigte Anforderungen "verschieben" sich nacheinander in die Vorproduktionsumgebung, in der gemäß den Einstellungen der eine oder andere Testsatz gestartet wird (genauer gesagt Projekte).
- Wenn das Testergebnis positiv ist, wird die Anforderung freigegeben und geht an die Produktionsumgebung
- Wenn Fehler auftreten, wird dem Autor der Anfrage ein Brief mit einem Link zum Testbericht (vom Roboter generiert) gesendet. Die Anfrage geht nicht weiter
Wichtig - Die Weboberfläche reduziert den Schwellenwert für die Eingabe des Testprozesses erheblich: Um den Test zu starten, ist es einfach - klicken Sie auf die Schaltfläche "Start". Gleichzeitig bleiben (aufgrund der Verwendung des Robot Frameworks) alle Vorteile der Dateidarstellung der Tests (Versionskontrolle, Befehlszeile und zugehörige Automatisierung usw.) erhalten.
Nicht sap om
Wir haben unsere Entwicklung erfolgreich angewendet, um nicht nur die SAP-GUI zu testen. Ich hatte eine kleine Entwicklung (vereinfachte Schnittstelle zur Verlustregistrierung) in Python und Django. Da wir bereits alle grundlegenden Punkte implementiert hatten, musste lediglich eine Browser-Verwaltungsbibliothek geschrieben werden (genau wie ich die SAP-GUI nur über Selenium verwalten musste). Und es stellte sich als großartig heraus:
- Tests funktionieren immer noch auf einer virtuellen Linux-Maschine (auf derselben - SAP-Tests und nicht SAP-Tests befinden sich in derselben "Instanz")
- Der Browser "blinkt" am Arbeitsplatz des Testers (volle visuelle Kontrolle ohne Tricks)
- Standardberichte, vertraute Tools
Bei den Tests dieses Systems ging ich weiter (in Richtung ATDD) - visuell sichtbare Elemente (Beschriftungen und Platzhalter) wurden ursprünglich in den Tests gebildet, dort stimmten sie mit dem Unternehmen überein und "fielen" von dort in den Quellcode des Systems selbst (es stellte sich als etwas trocken heraus) - das können Sie nicht Schreiben Sie Code, ohne zuerst den Test zu schreiben. Cool
Natürlich wurden viele Tools für Webanwendungen entwickelt, aber ich kann nicht sagen, dass ich während der Arbeit Unannehmlichkeiten hatte. Hier ist es gut geworden ...
Zusammenfassend
Die Welt von SAP ist groß und enthält anscheinend alles, was für das vollständige Glück der Entwickler erforderlich ist. Dies bedeutet jedoch keineswegs, dass Sie nur die Wege gehen müssen, die SAP und sein Ökosystem "gegangen" sind. Am Anfang des Weges ist es nützlich, sich die Frage zu stellen: Möchte ich definitiv "wie alle anderen" tun? Wir bei Alfastrakhovanie fragen ihn selbst, nicht nur in der IT.
Und wieder ist beim Programmieren alles möglich, die Frage ist nur Zeit und Geld (Motivation).