🥜 🀄️ ⛏️ Anstelle von 100 Anwendungsstarts - ein Autotest oder wie man einem QS-Ingenieur 20 Jahre Leben rettet 🧔 🤘🏽 💪

Hallo allerseits, mein Name ist Evgeny Demidenko. In den letzten Jahren habe ich bei Pixonic ein automatisiertes Spieletestsystem entwickelt. Heute wollte ich unsere Erfahrungen bei der Entwicklung, Unterstützung und Verwendung eines solchen Systems im Rahmen des War Robots-Projekts teilen.

Zunächst werden wir herausfinden, was wir mit diesem System automatisieren.

Zuallererst sind dies Regression-UI-Tests, Tests des Core-Gameplays und Automatisierung von Benchmarks. Alle drei Systeme als Ganzes ermöglichen es, die QS-Abteilung vor der Veröffentlichung zu entlasten, mehr Vertrauen in umfangreiches und tiefgreifendes Refactoring zu haben und ständig eine Gesamtbewertung der Leistung der Anwendung sowie ihrer einzelnen Teile aufrechtzuerhalten. Ein weiterer Punkt, den ich erwähnen möchte, ist die Automatisierung der Routine, zum Beispiel das Testen von Hypothesen.

Bild

Ich werde ein paar Zahlen geben. Mittlerweile wurden mehr als 600 UI-Tests und etwa 100 Kerntests für War Robots geschrieben. Allein bei diesem Projekt haben wir ungefähr eine Million Starts unserer Testskripte durchgeführt, von denen jedes ungefähr 80 Sekunden dauerte. Wenn wir diese Szenarien manuell überprüft hätten, hätten wir jeweils mindestens fünf Minuten verbracht. Darüber hinaus haben wir mehr als 700.000 Benchmarks eingeführt.

Von den Plattformen verwenden wir Android und iOS - nur 12 Geräte im Park. Zwei Programmierer sind an der Systementwicklung und -unterstützung beteiligt, und ein QS-Ingenieur schreibt und analysiert Tests.

Für den Software-Stack verwenden wir NUnit in unserer Datenbank, jedoch nicht für Komponententests, sondern für Integrations- und Systemtests. Für das grundlegende Gameplay und Build-Verifikationstests verwenden wir die integrierte Lösung von Unity - Unity Test Tools. Zum Schreiben und Analysieren von Berichten nach diesen Tests wird der Allure-Testbericht von Yandex sowie TeamCity verwendet - als kontinuierliches Integrationssystem für die Anwendungserstellung, Serverbereitstellung und Ausführung von Tests. Wir verwenden das Nexus Repository und die PostgreSQL-Datenbank, um unsere Artefakte zu speichern.

Wie erstellen, analysieren und führen Sie Tests durch?

Angenommen, wir möchten einen einfachen Test schreiben, bei dem im Fenster mit den Spieleinstellungen das Symbol zum Ein- und Ausschalten des Sounds überprüft wird.

Also haben wir einen Test geschrieben und ihn einem bestimmten Zweig in unserem Test-Repository zugewiesen. Wir haben die Tests ausgewählt, die wir ausführen möchten, einen Build zum Ausführen oder möglicherweise ein bestimmtes Commit, auf dem der Build zusammengestellt wird. Führen Sie nun den Test aus, warten Sie eine Weile und erhalten Sie das Ergebnis.

In diesem Fall wurden 575 Tests gestartet, von denen 97% erfolgreich waren. Wir haben ungefähr drei Stunden gebraucht, um alle Tests abzuschließen. Zum Vergleich würden dieselben Tests, wenn sie manuell durchgeführt würden, mindestens 50 Stunden Dauerbetrieb dauern.

Was ist mit diesen 3% der fehlgeschlagenen Tests passiert?

Wir öffnen einen bestimmten Test und sehen eine Meldung, dass beim Abgleichen von Screenshots ein Fehler aufgetreten ist.

Dann öffnen wir den Screenshot, der sich zu diesem Zeitpunkt auf dem Gerät befand, und sehen, dass Zonen, die nicht dem Original entsprechen, mit roten Pixeln markiert sind. Zum Vergleich geben wir ihm.

Danach muss der QS-Ingenieur natürlich entweder einen Fehler machen, dass das Verhalten des Builds nicht dem Spieldesign-Dokument entspricht, oder die ursprünglichen Screenshots aktualisieren, da sich das Spieldesign-Dokument geändert hat und diese Elemente nun nicht mehr im Spiel sind.

Es sieht cool aus. Warum ist das alles notwendig?

Vor einiger Zeit mussten wir beim War Robots-Projekt ein kleines Refactoring durchführen. Es bestand darin, einige Codeteile für das Abfeuern von Waffen - insbesondere Maschinengewehre - neu zu schreiben.

Während des Tests fanden wir eine interessante Nuance: Die Rate der Maschinengewehre hing direkt von der FPS ab. Ein solcher Fehler wäre beim manuellen Testen unrealistisch zu erkennen: Erstens aufgrund der Funktionen der Netzwerkberechnung des Schadens im Projekt und zweitens aufgrund der Tatsache, dass die War Robots-Anwendung recht gut optimiert ist und zu diesem Zeitpunkt auf allen ausgeführt wurde Geräte mit ungefähr den gleichen FPS - 30 Frames / s. Natürlich gab es kleine Abweichungen, aber sie reichten nicht aus, um einen Anstieg des Schadens durch Schusswaffen während manueller Tests zu bemerken. Dann haben wir uns gefragt: Wie viele solcher Fehler haben wir noch und wie viele können beim Refactoring auftreten?

Da wir die Anzahl der Tests nicht reduzieren, sondern erhöhen wollten, da wir größere Aktualisierungen und eine Erhöhung der Anzahl der Inhalte geplant hatten, wollten wir nicht horizontal wachsen und die Anzahl der Mitarbeiter der QS-Abteilung erhöhen. Stattdessen planten wir vertikales Wachstum mit einer Reduzierung der Routine der derzeitigen Mitarbeiter und einer Erleichterung ihres Lebens während der Integrationstests neuer Inhalte.

Welche Tools verwenden wir?

Als wir mit der Automatisierung von Tests begannen, machten wir zunächst auf die Unity Integration Test Tools aufmerksam, die zu diesem Zeitpunkt in Unity integriert waren. Wir haben mehrere Benutzeroberflächen und Kerntests darauf geschrieben, das zuvor begonnene Refactoring abgeschlossen und waren damit zufrieden, da die Lösung bereits funktioniert hat, was bedeutet, dass unsere Annahmen korrekt waren und wir weitermachen mussten. Das einzig Negative dieser Lösung, das für uns jedoch sehr wichtig war, war, dass Tests nicht auf Mobilgeräten ausgeführt werden konnten.

So kamen wir auf die Idee, das Appium-Framework zu verwenden. Dies ist eine Abzweigung eines anderen bekannten Testgerüsts - Selen. Es ist wiederum das vielleicht bekannteste Framework zum Testen von Webanwendungen, dessen Hauptkonzept darin besteht, mit UI-Elementen zu arbeiten, deren Koordinaten abzurufen und Eingaben in diese UI-Elemente zu organisieren. Appium übernahm dieses Konzept und fügte zusätzlich zu den vorhandenen Web-Treibern in Selenium auch iOS- und Android-Treiber hinzu: Sie verwenden native Test-Frameworks für jede dieser Plattformen.

Da es in Unity keine nativen UI-Elemente gibt und es nur ein UI-Element gibt, in dem das Bild gerendert wird, musste ich zusätzlich zum Appium UnityDriver hinzufügen, mit dem Sie mit der Szenenhierarchie arbeiten, Szenenobjekte abrufen und vieles mehr können.

Zu diesem Zeitpunkt war bereits ein QS-Ingenieur im Projekt erschienen, die Dinge begannen zu fließen, die Anzahl der Testszenarien begann erheblich zu wachsen, was wir schrittweise automatisierten. Wir haben begonnen, sie auf Geräten zu starten, und im Allgemeinen sah unsere Arbeit bereits so aus, wie wir es wollten.

In Zukunft tauchten neben UI-Tests immer mehr Kerntests und andere Tools auf, die auf unserem System basierten. Infolgedessen stießen wir auf Leistung und Qualität der Arbeit auf verschiedenen Geräten, fügten Unterstützung für mehrere weitere Geräte hinzu, parallele Tests und gaben Appium in auf Nutzen Sie Ihren eigenen Rahmen.

Das einzige Problem, das bei uns blieb - und immer noch besteht - war die UI-Hierarchie. Denn wenn sich eine Hierarchie in einer Szene aufgrund von UI-Refactoring ändert oder an der Szene arbeitet, muss dies in Tests unterstützt werden.

Nach den nächsten Innovationen und Überarbeitungen sah die Architektur des gesamten Systems wie folgt aus.

Wir nehmen den War Robots-Build, führen unsere Tests durch, die sich in einem separaten Repository befinden, fügen dort einige Parameter hinzu, die es uns ermöglichen, den Start von Tests in jedem Fall zu konfigurieren, und senden alles an den TeamCity-Agenten auf einem Remote-PC. Der TeamCity-Agent startet unsere Tests, übergibt ihnen die Roboter-Build- und Startparameter. Danach beginnen die Tests zu arbeiten und „kommunizieren“ unabhängig mit den Geräten, die per Kabel mit dem TeamCity-Agenten verbunden sind: Erstellen Sie Builds auf ihnen, führen Sie sie aus, führen Sie bestimmte Skripte aus, löschen Sie sie erstellt, starten Sie die Anwendung neu und so weiter.

Da die Tests und die Anwendung selbst auf physisch unterschiedlichen Geräten ausgeführt werden - auf einem Mobiltelefon und einem Mac mini - mussten wir die Kommunikation zwischen unserem Framework, der War Robots API und der Unity API implementieren. Wir haben der Anwendung einen kleinen UDP-Server hinzugefügt, der Befehle vom Framework empfängt und über Handler mit der Anwendungs-API und Unity kommuniziert.

Die Hauptaufgabe unseres Frameworks besteht darin, die Arbeit der Tests zu organisieren: die korrekte Vorbereitung, Fertigstellung und Verwaltung der Geräte. Insbesondere Parallelisierung zur Beschleunigung der Arbeit, die richtige Auswahl von Geräten und Screenshots, Kommunikation mit dem Build. Nach Abschluss der Tests sollte unser Framework alle generierten Artefakte speichern und einen Bericht erstellen.

Tipps zur Auswahl von Geräten

Separat möchte ich auf die Auswahl der zu testenden Geräte achten.

Hubs sollten besondere Aufmerksamkeit geschenkt werden. Wenn Sie Benchmarks auf Ihren Geräten ausführen möchten - insbesondere wenn es sich um Android-Geräte handelt - geht ihnen der Strom aus. Hubs müssen die erforderliche Stromversorgung für die verwendeten Geräte bereitstellen. Es gibt noch eine weitere sehr subtile Funktion: Einige Hubs haben Wirkleistung, und diese Stromversorgung wird nach Spannungsspitzen ausgeschaltet. Danach wird sie nur durch physisches Drücken einer Taste eingeschaltet. Wir haben solche Hubs, und das ist sehr unpraktisch.

Wenn Sie Regression UI-Tests und Testlogik auf Geräten ausführen möchten, nehmen Sie keine anderen Geräte. Nehmen Sie die gleichen Geräte - besser die produktivsten, die Sie sich leisten können, denn auf diese Weise sparen Sie Zeit beim Bremsen der Geräte, die Bequemlichkeit der Arbeit mit ihnen und das Verhalten der Anwendung auf allen Geräten.

Ein separates Problem ist die Verwendung von Cloud-Farmen. Wir verwenden sie noch nicht, obwohl wir sie untersucht haben: Was sie sind, wie viel sie kosten und wie wir unsere Tests mit ihnen durchführen können - aber bisher haben wir genug von unserem internen Gerätepark, um unsere Anforderungen zu erfüllen.

Testberichterstattung

Nach Abschluss der Tests erstellen wir einen Allure-Bericht, der alle Artefakte enthält, die während unseres Tests erstellt wurden.

Das wichtigste „Arbeitstier“ für die Analyse des Geschehens und die Ermittlung der Absturzursachen während des Tests sind die Protokolle. Zunächst sammeln wir sie aus unserem Framework, das uns über den Status des Skripts und die Ereignisse in diesem Skript informiert. Wir unterteilen die Protokolle in das System (detaillierter) und das Protokoll für die Qualitätssicherung (kompakter und bequemer für die Analyse). Wir erfassen auch Systemprotokolle von Geräten (z. B. logcat) und Protokolle von einer Unity-Anwendung.

Während des Sturzes der Tests machen wir auch einen Screenshot, um zu verstehen, was zum Zeitpunkt des Sturzes auf den Geräten passiert ist, zeichnen ein Video auf, um zu verstehen, was vor dem Absturz passiert ist, und versuchen, Informationen über den Status des Geräts, wie z. B. unsere Server-Pings und ifconfig-Informationen, maximal zu sammeln um zu verstehen, ob das Gerät eine IP hat. Sie werden überrascht sein, wenn Sie die Anwendung 50 Mal manuell starten, ist alles in Ordnung. Wenn Sie sie jedoch 50.000 Mal im Automatikmodus ausführen, werden Sie feststellen, dass das Internet auf dem Gerät möglicherweise verloren geht und während des Tests nicht klar ist. ob es vor und nach dem Sturz eine Verbindung gab.

Wir sammeln auch eine Liste von Prozessen, Batterieleistung, Temperatur und allgemein alles, was wir erreichen können.

Was sind gute Screenshots und Videos?

Vor einiger Zeit schlug unser QS-Ingenieur vor, im Herbst an bestimmten Stellen in den Tests zusätzlich zu den Screenshots Screenshots zu machen, um diese Screenshots mit den Vorlagen in unserem Repository zu vergleichen. Daher schlug er vor, Zeit bei der Anzahl der Testläufe zu sparen und die Größe der Codebasis zu reduzieren. Das heißt, mit einem Test könnten wir die Logik und den visuellen Teil überprüfen. Aus Sicht des Konzepts des Unit-Tests ist dies nicht sehr richtig, da wir in einem Test nicht mehrere Hypothesen testen sollten. Dies ist jedoch ein bewusster Schritt: Wir wissen, wie man all dies richtig analysiert, und haben es daher gewagt, ähnliche Funktionen hinzuzufügen.

Zunächst haben wir darüber nachgedacht, Bibliotheken hinzuzufügen, um Screenshots abzugleichen. Wir haben jedoch festgestellt, dass die Verwendung von Bildern mit unterschiedlichen Auflösungen nicht sehr zuverlässig ist. Daher haben wir auf Geräten mit derselben Auflösung aufgehört und die Bilder nur Pixel für Pixel mit einem bestimmten Schwellenwert verglichen.

Ein sehr interessanter Effekt der Verwendung des Screenshot-Abgleichs besteht darin, dass wir einen Prozess, der schwer zu automatisieren ist, so weit wie möglich automatisieren und ihn dann einfach manuell betrachten. Genau das haben wir mit der Testlokalisierung gemacht. Wir haben die Anfrage erhalten, die Lokalisierung unserer Anwendungen zu testen, und haben uns daher mit Bibliotheken befasst, die die Texterkennung ermöglichen. Wir haben jedoch festgestellt, dass dies ziemlich unzuverlässig ist. Daher haben wir mehrere Skripte geschrieben, die über verschiedene Bildschirme laufen und unterschiedliche Popups verursachen. ups, und in diesem Moment werden Screenshots erstellt. Bevor wir ein solches Skript starten, ändern wir das Gebietsschema auf dem Gerät, führen das Skript aus, machen Screenshots, ändern das Gebietsschema erneut und führen das Skript erneut aus. Somit werden alle Tests nachts durchgeführt,Damit der QS-Techniker am Morgen 500 Screenshots ansehen und sofort analysieren kann, ob irgendwo Probleme mit der Lokalisierung auftreten. Ja, Screenshots müssen noch angesehen werden, aber dies ist viel schneller als das manuelle Durchlaufen aller Bildschirme auf dem Gerät.

Manchmal reichen Screenshots und Protokolle nicht aus: Auf den Geräten passiert etwas Seltsames, aber da sie sich remote befinden, können Sie nicht bewerten, was dort passiert ist. Darüber hinaus ist manchmal unklar, was wenige Momente vor dem Test buchstäblich passiert ist. Aus diesem Grund haben wir eine Videoaufnahme vom Gerät hinzugefügt, die mit dem Start des Tests beginnt und nur im Falle eines Sturzes gespeichert wird. Mit Hilfe solcher Videos ist es sehr bequem, Anwendungsabstürze zu verfolgen und einzufrieren.

Was kann unser System noch tun?

Vor einiger Zeit erhielten wir von der QS-Testabteilung die Anfrage, ein Tool zum Sammeln von Metriken während manueller Spieletests zu entwickeln.

Wofür ist das?

Dies ist erforderlich, damit QS-Ingenieure nach einem manuellen Test zusätzlich das Verhalten von FPS und den Speicherverbrauch in der Anwendung analysieren und gleichzeitig Screenshots und Videos anzeigen können, die die Vorgänge auf diesem Gerät widerspiegeln.

Das von uns entwickelte System funktionierte wie folgt. Der QS-Ingenieur startete War Robots auf dem Gerät, schaltete die Aufzeichnung der Playbench-Sitzung ein - unser Analogon zur Gamebench - spielte den Playtest ab und klickte dann auf „Playbench-Sitzung beenden“. Der generierte Bericht wurde im Repository gespeichert, wonach der Ingenieur mit den Daten für diesen Playtest seine Arbeit erreichen konnte Maschinen und sehen Sie sich den Bericht an: Was waren die Nachteile von FPS, welcher Speicherverbrauch, was geschah auf dem Gerät.

Wir haben auch den Start von Benchmarks für das War Robots-Projekt automatisiert und im Wesentlichen nur die vorhandenen Benchmarks in einen automatischen Start eingebunden. Das Ergebnis von Benchmarks ist normalerweise eine Ziffer. In unserem Fall ist dies normalerweise der durchschnittliche FPS pro Benchmark. Zusätzlich zum automatischen Start haben wir beschlossen, eine weitere Playbench-Sitzung hinzuzufügen, und erhielten daher nicht nur eine bestimmte Zahl, wie der Benchmark funktioniert, sondern auch Informationen, anhand derer wir analysieren können, was zu diesem Zeitpunkt mit dem Benchmark passiert ist.

Wir sollten auch den Pull-Request-Test erwähnen. Diesmal ging es eher darum, dem Kundenentwicklungsteam zu helfen, als um QS-Ingenieure. Wir führen für jede Pull-Anfrage den sogenannten Build-Verifikationstest durch. Sie können sie sowohl auf Geräten als auch im Unity-Editor ausführen, um die Überprüfung der Logik zu beschleunigen. Wir führen auch eine Reihe von Kerntests in separaten Zweigen durch, in denen eine Art Neugestaltung einiger Elemente oder Code-Refactoring stattfindet.

Und andere nützliche Funktionen

Am Ende möchte ich auf einige interessante Fälle eingehen, die wir in den letzten Jahren kennengelernt haben.

Einer der interessantesten Fälle, die kürzlich bei uns aufgetreten sind, sind Benchmarks bei Kämpfen mit Bots.

Für das neue Projekt entwickelte Pixonic Dino Squad ein System, in dem der QS-Ingenieur einen Spieltest mit Bots durchführen konnte, um nicht auf seine Kollegen zu warten, sondern einige Hypothesen zu testen. Unser QS-Ingenieur wiederum bat darum, die Möglichkeit hinzuzufügen, nicht nur mit Bots zu spielen, sondern auch, damit Bots miteinander spielen können. Daher starten wir einfach die Anwendung und in diesem Moment beginnt der Bot mit anderen Bots zu spielen. Gleichzeitig ist die gesamte Interaktion ein Netzwerk mit echten Servern, anstatt dass Spieler einen Computer spielen. All dies ist in Benchmarks verpackt und eine Playbench-Sitzung mit Triggern für Nachtstarts. So starten wir nachts mehrere Kämpfe zwischen Bots und Bots. Zu diesem Zeitpunkt werden FPS und Speicherverbrauch geschrieben, Screenshots gemacht und Videos aufgezeichnet. Am Morgen kommt der QS-Ingenieur und kann sehen,Welche Spieletests wurden abgehalten und was ist mit ihnen passiert?

Ebenfalls einen Blick wert ist die Texturleckage. Dies ist eine Art Unteranalyse der Speichernutzung - aber hier überprüfen wir hauptsächlich die Verwendung von beispielsweise Garagentexturen im Kampf. Dementsprechend sollte es im Kampf keine Atlanten geben, die in der Garage verwendet werden, und wenn wir den Kampf verlassen, sollten die im Kampf verwendeten Texturen nicht im Gedächtnis bleiben.

Ein interessanter Nebeneffekt unseres Systems ist, dass wir fast von Beginn seiner Verwendung an die Ladezeit der Anwendung verfolgt haben. Im Fall von Kriegsrobotern ist diese Zeit nicht stark, aber sie wächst ständig, da neue Inhalte hinzugefügt werden und sich die Qualität dieser Inhalte verbessert - aber wir können diesen Parameter unter Kontrolle halten und uns immer seiner Größe bewusst sein.

Anstelle einer Schlussfolgerung

Am Ende möchte ich auf die Probleme aufmerksam machen, die wir kennen und die wir in erster Linie lösen möchten.

Das erste und schmerzhafteste sind Änderungen an der Benutzeroberfläche. Da wir mit einer Black Box arbeiten, binden wir nichts in die War Robots-Anwendung ein, außer unseren Server. Das heißt, wir testen alles auf die gleiche Weise, wie es ein QS-Ingenieur testen würde. Aber irgendwie müssen wir auf die Elemente in der Szene zugreifen. Und wir finden sie auf dem absoluten Weg. Wenn sich also auf der Bühne etwas ändert, insbesondere auf einer hohen Hierarchieebene, müssen wir diese Änderungen in einer großen Anzahl von Tests unterstützen. Leider können wir damit momentan nichts anfangen. Natürlich gibt es einige Lösungen, aber sie bringen ihre zusätzlichen Probleme mit sich.

Das zweite große Problem ist die Infrastruktur. Wie gesagt, wenn Sie Ihre Anwendung 50 Mal mit Ihren Händen ausführen, werden Sie die meisten Probleme nicht bemerken, die auftreten, wenn Sie Ihre Anwendung 50.000 Mal ausführen. Diese Probleme, die im manuellen Modus leicht gelöst werden können - zum Beispiel das Neuinstallieren von Builds oder das Neustarten des Internets -, stellen sich als echtes Problem bei der Automatisierung heraus, da all diese Probleme korrekt behandelt, eine Fehlermeldung angezeigt und vorausgesetzt werden müssen, dass sie überhaupt auftreten können. Insbesondere müssen wir feststellen, warum die Tests fehlgeschlagen sind: aufgrund einer fehlerhaften Logik oder eines Infrastrukturproblems oder aus einem anderen Grund. Es gibt viele Probleme mit Low-End-Geräten: Sie haben keine Builds, das Internet fällt aus, Geräte frieren ein, stürzen ab, lassen sich nicht einschalten, werden schnell entladen und so weiter.

Ich würde auch gerne mit nativen Benutzeroberflächen interagieren, aber bisher haben wir keine solche Gelegenheit. Wir wissen, wie das geht, aber das Vorhandensein anderer Anforderungen an die Funktionalität ermöglicht es uns nicht, dies zu erreichen.

Mein persönlicher Wunsch ist es, die in der Branche geltenden Standards einzuhalten, aber dies steht auch in den Plänen für die Zukunft, vielleicht sogar in diesem Jahr.

Anstelle von 100 Anwendungsstarts - ein Autotest oder wie man einem QS-Ingenieur 20 Jahre Leben rettet