Automatisierungstestsoftware QIWI-Terminals

Hallo Habr!

Heute sprechen wir über ein bestimmtes Thema: Automatisierung von Softwaretests für QIWI-Self-Service-Terminals.

Es gibt Bereiche im Bereich der Testautomatisierung, die mehrmals nach oben und unten gescannt werden, z. B. das Testen von Webdiensten. Für solche Bereiche gibt es separate Tools, Muster und Best Practices. Sie müssen nichts erfinden, die Risiken sind minimal, Sie gehen und tun.

Es gibt umgekehrte Situationen. Der Themenbereich ist spezifisch, niemand hat einen Blick auf die vorgefertigten Lösungen, es gibt keine Werkzeuge, der technologische Stapel des Produkts ist eigenartig. Sie müssen tief in den Themenbereich eintauchen, von Stöcken und anderen improvisierten Materialien, um Werkzeuge für sich selbst herzustellen und gleichzeitig viele, viele Rechen unterschiedlicher Größe und tödlicher Kraft zu sammeln.

Ich wollte heute über so etwas sprechen. Der Artikel eignet sich für diejenigen, die an der Entwicklung und dem Testen von Software für Bankterminals oder Selbstbedienungsautomaten beteiligt sind. Und auch für diejenigen, die ihren technischen Horizont mit Beispielen von "aber es passiert auch so" erweitern wollen. QIWI-Terminal im Jahr 2020. Im Hintergrund sehen Sie seine Füllung.




Problem


Das erste QIWI-Terminal erschien im Jahr 2004 und konnte dann das Konto eines Mobiltelefons auffüllen. Seitdem ist viel Wasser geflossen, und ASO (Selbstbedienungsmaschinen) haben sich stark verändert. Mit ihrer Hilfe können Sie jetzt Bankkarten auffüllen, Überweisungen vornehmen, Dienstleistungen verschiedener Anbieter (Anbieter) bezahlen - Wohnungs- und kommunale Dienstleistungen, Geldstrafen der Verkehrspolizei, Kreditinstitute, unsere eigenen QIWI-Produkte (QIWI-Geldbörse, zinslose Ratenkarte für Gewissen). QIWI-Terminals können auch im Postamata-Modus (automatisierte Zustellpunkte für Online-Shops) betrieben werden.

Wie ist ein Terminal?


Das ASO-Terminal ist aus Sicht von Eisen ein gewöhnlicher Desktop mit bestimmten Peripheriegeräten wie Geldschein- und Münzprüfern, Quittungsdruckern, Spendern, POS-Terminals (Empfang von Plastikkarten) usw.

Und hier ist das erste Problem.


Dieses berühmte Foto wurde in Sonoma County, Kalifornien aufgenommen. Sie sagen, dass dies natürliche Farben sind, ohne jegliche Verarbeitung. Übrigens befand sich auf dem Territorium des Sonoma County die südlichste russische Kolonie in Amerika.

Ja, das ist sie. Das Betriebssystem, das 2014 eingestellt wurde, ist Windows XP. Die POSReady-Version wurde bis 2019 gezogen, aber ... es ist nicht so einfach.

Tatsache ist, dass die Terminals nicht Eigentum von QIWI sind. Sie gehören Partnern, den sogenannten Agenten, Einzelunternehmer und juristische Personen, die eine Vereinbarung mit QIWI-Kaufterminals abschließen, Flächen in Einkaufszentren mieten und nahezu passives Einkommen erhalten.

Dementsprechend verwenden 90% der Flotte von QIWI-Terminals (und es gibt mehr als 100.000 in Russland und im Ausland) Windows XP auf einer Vielzahl von Hardware - von 512 MB bis 4 GB RAM, einer Vielzahl von CPUs (von Pentium 4 bis zu null Jahren). weniger moderner Core i5) und unterschiedliche Qualität und Geschwindigkeit des Internets. Terminals unterschiedlichen Alters, von denen einige regelmäßig aktualisiert werden und einige schon lange nicht mehr aktualisiert wurden (es funktioniert - berühren Sie es nicht!). Unsere Aufgabe ist es, regelmäßig die neuesten Terminalsoftware-Updates (MarATL) bereitzustellen und die Kompatibilität mit all diesen verschiedenen Belägen und Peripheriegeräten aufrechtzuerhalten.

Abgelaufenes Support-Betriebssystem


Stellen Sie sich eine einfache Testautomatisierungsschaltung vor. Wir haben einen CI-Server, zum Beispiel TeamCity oder Jenkins. Unsere Terminalsoftware wird nach Ereignis (Commit oder Heap) aus Raws gesammelt, die gesammelte Binärdatei wird irgendwo angelegt. Die Software wird automatisch installiert, die nächtlichen Autotests werden gestartet ... Äh, hör auf! Wohin geht die Softwareinstallation? Und wie?

Wie oben erwähnt, verwenden 90 Prozent der Terminals Windows XP, das 2014 endete. Dies bedeutet, dass dieses Betriebssystem lange Zeit nicht mehr den Sicherheitsrichtlinien entspricht, keine Updates dafür veröffentlicht werden, keine neue funktionierende Software dafür vorhanden ist und sogar das native Microsoft Visual Studio C ++ erst nach dem Tanzen mit einem Tamburin oder vielmehr mit der Version der Toolchain für den MSBuild-Kollektor kompiliert.

Im Allgemeinen ist es eine sehr schlechte Idee, Tests und irgendeine Art von Software auf einem Terminal oder einer virtuellen Maschine mit Windows XP auszuführen. Sie können Buildagent TeamCity unter XP nicht erhöhen. Sie können einen solchen Computer nicht in Ansible Playbook konfigurieren. Dort sind auch keine Container vorhanden. Virtualisierungsvorlagen für Windows XP sind auch nicht so viel. In jedem großen Unternehmen, das an Informationssicherheit denkt, wird ein Windows XP-Computer vom Unternehmensnetzwerk oder sogar von der Domäne ferngehalten. Das heißt, jede Interaktion mit dem Terminal (oder der virtuellen Maschine, die vorgibt, es zu sein) muss remote erfolgen. Das Terminal selbst muss über ein Minimum an Software von Drittanbietern verfügen.

Entscheidung


Einige Leute sind überrascht, wenn sie von einer Reihe von OpenSSH und Windows XP hören. In einer modernen Version von Microsoft ist die Arbeitsschutzunterstützung direkt im System enthalten. In der nicht so modernen Version (Windows 7) gibt es SSH-Installationsprogramme, die PowerShell verwenden. C Windows XP ist die Situation etwas schlimmer, aber nur wenig. Es gibt eine alte Version des Installationsprogramms , die ohne zusätzliche Software ausgeführt wird.

SSH ist eine alte, gute und zuverlässige Methode zur Fernsteuerung eines Hosts, eine bekannte Technologie. Sie müssen Klassen von SSH-Konnektoren implementieren, die mehrere Dinge parallel ausführen können. Laden Sie beispielsweise im Online-Modus neue Protokolle vom Terminal, führen Sie einige Befehle aus (Kopieren von Dateien, Ausführen von Skripten, Ausstellen von Rechten, Abrufen einer Liste von Prozessen, Überwachen der Systemzeit des Terminals usw.).

Besonders interessant ist die Überwachung der Systemzeit. Mit den Standard-Befehlszeilentools zeigt Windows XP die Zeit nur in formatierter Form Stunden-Minuten-Sekunden usw. an, keine UNIX-Zeit für Sie. Der Hinterhalt ist zum Beispiel, dass XP seit langer Zeit keine Zeitzonen-Updates mehr erhalten hat und unsere russische Regierung für ständige Spiele mit der Absage der Sommer- oder Winterzeit bekannt ist.

Beispielsweise zeigt das Standard-Windows XP SP3 in der Moskauer Zeitzone die Zeit eine Stunde früher als die tatsächliche Moskauer Zeit an. Dementsprechend stimmen die Zeitstempel der Terminalprotokolle in jedem Fall nicht mit der Zeit auf der Testschaltung überein.

Zahlungen-Zahlungen-Zahlungen ...


Die QIWI-Terminalschnittstelle ist im Wesentlichen ein Web, das auf einer Browser-Engine ausgeführt wird, die normalerweise ziemlich alt ist. Gemäß dem Websocket- Protokoll interagiert es mit MarATL, einer Terminalsoftware. Bei der Auswahl einer Zahlung auf dem Terminal (z. B. Bezahlen für die Mobilfunkkommunikation) mithilfe einer Reihe von Befehlen wird ein Zahlungsanbieter ausgewählt, die Höhe der Provisionen und Einschränkungen für die Annahme von Banknoten festgelegt. Für einen bestimmten Anbieter wird eine Zahlung erstellt, die dann über die Verarbeitung des Zahlungsterminals an Zahlungen gesendet wird.

Die Remote-Interaktion mit der Weboberfläche ist eine mittelmäßige Idee, insbesondere Schnittstellentests - eine weitere Aufgabe. Sie können eine Testwebseite erstellen, die auf der Testzeit anstelle der Standard-index.html basiert. Auf der Seite wird ein JS-Skript ausgeführt, das mit Terminalsoftware funktioniert, und andererseits wird ein Web-Socket-Client erstellt, der nach außen auf den Host blickt, auf dem die Tests ausgeführt werden.

Neben Autotests müssen Sie einen Web-Socket-Server implementieren, der zu Beginn der Client-Verbindung vom Terminal wartet und Befehle, die über die Testseite unverändert bleiben, an die Terminalsoftware sendet. Softwareantworten werden auch an den Test-Web-Socket-Server gesendet.

Das heißt, Sie können den Befehlssatz für den Zahlungstest in Form von JSON beschreiben, in dem nacheinander beschrieben wird, welche Befehle Sie senden müssen und welche Art von Antwort Sie darauf warten müssen.


Schnittstellentestseite. Zeigt die durchlaufenden Befehle an.

Und wo ist das Geld?


Die heimtückischste technische Aufgabe besteht darin, die Peripheriegeräte des Terminals zu simulieren. Der Belegdrucker wird trivial simuliert, im Betriebssystem wird ein virtueller Drucker erstellt, der die Daten in eine Datei druckt. Sie können diese Prüfung vom Terminal (oder der von der Terminalsoftware selbst erstellten Kopie) abrufen und dekodieren, indem Sie beispielsweise gleichzeitig prüfen, ob alle erforderlichen Felder in dieser Prüfung vorhanden sind.

Komplizierter bei Geräten, die Geld akzeptieren - Geldschein- und Münzprüfer. Es ist klar, dass wir, wenn wir das Zahlungsszenario testen möchten, die Anwesenheit des Rechnungsakzeptors auf dem Terminal irgendwie emulieren, die Funktionalität des Akzeptierens von Rechnungen, der Rücksendung und der Simulation verschiedener Probleme (z. B. der Rückgabe einer zerknitterten Rechnung) unterstützen müssen.

Die meisten Geldempfangsgeräte arbeiten mit dem CashCode NET-Protokoll. Dieses Protokoll definiert die Interaktionsszenarien zwischen dem Rechnungsprüfer und dem Controller (in unserem Fall ist der Controller unsere Terminalsoftware).


Ein Beispiel für die Interaktion des Controllers und des Validators von Banknoten mit dem CashCode-Protokoll. Ab einer bestimmten Frequenz fordert der Controller den Status des Geräts an.


Die Mindestgröße des CashCode-Befehls beträgt 6 Byte. Eine Beschreibung der Befehle finden Sie in der CashCode NET-Protokollspezifikation.

Der Standard-Rechnungsprüfer ist über den COM-Anschluss mit dem Terminal verbunden. Es gibt Dienstprogramme von Drittanbietern, mit denen Sie eine virtuelle serielle Schnittstelle auf dem Computer erstellen können, z. B. VSPE . Sogar Skripte zum Weiterleiten dieses Ports über eine TCP-Verbindung werden unterstützt.

Unser Fall ist einfacher, wir benötigen ein Tool, das mit WinAPI am Port haften kann und über eine beliebige praktische Schnittstelle verfügt, z. B. das einfachste stdin / stdout, das über SSH angeschlossen werden kann.

Tula in einem separaten Stream kommuniziert mit dem Controller über eine serielle Schnittstelle und ahmt bei Bedarf Situationen nach, in denen angeblich „Geld“ empfangen wird. Es ist auch notwendig, eine Art Pool von Testkonten oder Anbietern zu haben, deren Zahlungen nicht real verarbeitet werden, sondern irgendwann zurückgewiesen werden. In komplexeren Fällen wird das Geld zwar tatsächlich verarbeitet, jedoch auf Sonderkonten überwiesen, von denen sie dann erneut für Zahlungstests belastet werden.

Dies ist der Geldkreislauf in der Natur.


Belegdrucker (oben) und Rechnungsprüfer (unten).

24/7


Software für Terminals und Geldautomaten sollte äußerst widerstandsfähig gegen verschiedene Notfallsituationen sein - mangelndes Internet, Probleme mit einem Rechnungsprüfer usw. Da solche Software auf einem Terminal mit einer sehr hohen Priorität und Rechten ausgeführt wird, fängt sie im Wesentlichen die gesamte Betriebssystemsteuerung ab. Sie können es nicht einfach reduzieren oder mit Alt-F4 schließen. Die Software kann sich selbst neu starten und das Terminal, inkl. In einer Schleife. Es ist auch notwendig, solche stressigen Szenarien zu überprüfen, beispielsweise die mangelnde Kommunikation mit der Zahlungsabwicklung. Das Terminal reagiert darauf mit regelmäßigen Neustarts. Sie müssen bei jedem Laden der Terminalsoftware überprüfen, ob es ordnungsgemäß und korrekt ausgeführt wird.

Installation von Grund auf neu und Update


Die installierte Terminalsoftware wird mithilfe der Zahlungsabwicklung zentral aktualisiert. Die Verarbeitung plant, ein bestimmtes Terminal zu aktualisieren, und bestimmt das Aktualisierungsprofil dafür, dh welche Dateien und wo sie geladen werden sollen. Zum Aktualisieren müssen eine Reihe von Prozeduren in der Verarbeitungsdatenbank ausgeführt und anschließend das Terminal überwacht werden. Überprüfen Sie anhand von Protokollen, ob der Download der erforderlichen Dateien begonnen hat und ob das Update erfolgreich abgeschlossen wurde und die Terminalsoftware gestiegen ist.

Eine saubere Installation von Grund auf ist schwieriger. Normalerweise führt eine Person dies „vor Ort“ durch, indem sie einfach die Installationsdatei auf das Terminal kopiert und die Einstellungen und Autorisierungsdaten in die Installationsformulare eingibt. Dies ist normalerweise eine WinAPI-Anwendung mit Standard-Windows-Controllern (TextBox, CheckBox usw.).

Bei unseren automatischen Tests für ein sauberes Installationsskript wird ein Python-Skript an das Terminal angehängt, das das Installationsprogramm startet, mit den Controllern über die pywinauto-Bibliothek interagiert und ein eigenes Installationsprotokoll schreibt. Nachdem die erste Phase der Installation abgeschlossen ist, wird das Skript beendet und die Terminalsoftware übergibt die Autorisierung bei der Verarbeitung, empfängt Pfade zum Installationsprofil und lädt alle erforderlichen Dateien herunter. Hier müssen Sie in Echtzeit die Protokolle auf dem Terminal über SSH überwachen. Alle anormalen Situationen während der Installation (z. B. falsche Autorisierungsdaten) werden darauf geschrieben. Sie müssen diese Protokolle online lesen und gegebenenfalls den Test für die Neuinstallation als fehlgeschlagen betrachten.


Saubere Installation von Grund auf MarATL

Fazit


Wir haben uns die Übersichten zu den wichtigsten technischen Aspekten der Erstellung von Autotests für Terminalsoftware angesehen. Ohne tief in die Technologie einzutauchen, haben wir eine große Aufgabe in verschiedene Aspekte unterteilt. Stellen Sie Fragen in den Kommentaren. Wenn das Thema interessant ist, können Sie einige Punkte in einem separaten Artikel genauer hervorheben. Vielen Dank für Ihre Aufmerksamkeit!

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


All Articles