+ bessere, aber weniger lustige Coverversion Früher oder später kommt jeder zu AT. Die Situation, wenn dies spät geschieht, ist verständlich, und wann ist es früh? Und wie kann man verstehen, was bereits möglich ist?Der Artikel basiert auf der Erfahrung eines Teams: Ich werde Ihnen unsere Voraussetzungen und Gründe für die Einführung des Autotests erläutern, welche Kriterien wir für die AT-Bereitschaft ausgewählt haben und welche Tools wir letztendlich verwenden. Spoiler: am Ende einige erfolgreiche und nicht sehr Fälle mit Xamarin.UITest.Einführung in das Produkt. , , , , , . offline.
-.
Was die Theorie sagt
Betrachten Sie den Automatisierungsansatz am Beispiel der Testpyramide. Als Ebenen der Pyramide werde ich die Arten von Tests verwenden, die wir verwenden. Unit-Tests, Integrationstests und End-to-End-Tests (E2E).
Unit-Tests (Unit-Tests) überprüfen den Betrieb einzelner kleiner Teile des Systems (Funktion, Methode). Sie sind klein, vergehen schnell und erfordern keine großen Entwicklungs- und Wartungskosten.Integrationstests testen den Betrieb der Anwendung mit externen Komponenten. Zum Beispiel mit einer Datenbank oder verschiedenen Diensten. Sie nehmen sich mehr Zeit, sowohl für das Schreiben und Unterstützen von Tests als auch für ihre Läufe. Für solche Tests müssen Sie meistens eine Umgebung konfigurieren und unterstützen. In diesem Fall werden sie oft zerbrechlicher, weil Umwelt neigen dazu zu brechen.End-to-End-Tests überprüfen den Betrieb des gesamten Systems und emulieren die Aktionen des Endbenutzers. Meistens greifen sie über die Benutzeroberfläche auf das System zu: Sie drücken als Benutzer die Tasten, füllen die Felder aus usw. Sie können aber auch in Systemen ohne Schnittstelle eingesetzt werden. Diese Tests sind viel teurer als die oben genannten, weil benötigen mehr Zeit, um sowohl die Tests selbst als auch die gesamte Umgebung zu entwickeln und zu unterstützen. Darüber hinaus sind sie sehr anfällig, da sie von Änderungen in einem beliebigen Teil des Systems betroffen sind und das unerwartete Verhalten eines Emulators oder Browsers das Ergebnis eines bestimmten Tests beeinflussen kann. Die Dauer der Ausführung solcher Tests ist ebenfalls erheblich länger als der Rest: Um eine einzelne Benutzeraktion auszuführen, müssen Sie viele zusätzliche Aktionen ausführen. Melden Sie sich beispielsweise an oder gehen Sie zum gewünschten Menüpunkt.Nach dem Prinzip der Pyramide sollten sie umso mehr in einem Prozentsatz der Gesamtzahl der Tests enthalten sein, je einfacher, schneller und billiger der Test ist. Jene. Ein Durchgangstest sollte nicht die Zuordnung verschiedener Werte zu einem Feld überprüfen (es sei denn, Sie müssen in diesen Fällen die Funktionsweise der Benutzeroberfläche überprüfen).Für alle diese Testarten wurde eine Rolle zugewiesen. Irgendwann im Lebenszyklus der Anwendung besteht Bedarf an der einen oder anderen Testautomatisierung. Ihr Produkt kann problemlos nur Unit-Tests durchführen und kann schnell zu End-to-End-Tests werden. Bei der Planung der Automatisierung ist es wichtig zu verstehen, wovon genau Ihr Produkt derzeit profitiert und wofür Sie wahrscheinlich Zeit verschwenden.Vergessen Sie bei der Implementierung der Automatisierung nicht das manuelle Testen, auch bei einem hohen Automatisierungsgrad gibt es immer Dinge, die manuell überprüft werden müssen. Zumindest neue Funktionen, für die es nicht sinnvoll ist, sofort Tests zu schreiben.Meiner Meinung nach sollte jede Automatisierung in erster Linie darauf abzielen, das Volumen manueller Tests zu reduzieren. Bei der Planung manueller Tests ist zu berücksichtigen, welche Fälle bereits automatisiert sind.Wie sind Autotests bei uns organisiert?
Jedes Produkt hat einzeln Unit-Tests, die auf jedem PR durchgeführt werden. Sie liegen in der Verantwortung der Entwickler.
Integrationstests überprüfen die Interaktion des Webdienstes mit dem EDMS.Sie simulieren den Betrieb einer Clientanwendung. Sie wenden sich Webdienstmethoden zum Abrufen und Ändern von EDS-Daten zu.Führen Sie nach jedem Build eine neue Version der Serverseite aus.
End-to-End-Tests simulieren die Leistung des Endbenutzers. Sie drücken die Tasten in der Benutzeroberfläche der mobilen Anwendung, und die Anwendung arbeitet mit dem EDMS über einen Webdienst.Integrations- und End-to-End-Tests werden jetzt von Testern durchgeführt.Warum brauchen wir End-to-End-AT-Mobilanwendungen?
Bevor Sie mit der Automatisierung beginnen, sollten Sie sich überlegen, welches Problem Sie durch Einführung lösen möchten. Wenn Sie keine bestimmten Ziele haben, können Sie dem Vorgesetzten oder Produktbesitzer nicht erklären, warum Sie Zeit mit Autotests verbringen sollten. Es wird schwierig sein, die Vorteile ihrer Umsetzung zu bewerten.Wir haben mobile Anwendungen lange Zeit manuell getestet. Obwohl dies eine Anwendung mit wenig Funktionalität war, haben wir sie erfolgreich bewältigt. Alles, was entwickelt wurde, befand sich in einem Bereich, und manuelle Tests konnten so organisiert werden, dass alle Funktionen der Anwendung schnell und einfach getestet werden konnten.Nach einiger Zeit begann die Anwendung jedoch mit neuen Funktionen zu wachsen, die ziemlich unabhängig waren und mehr Aufmerksamkeit erforderten. Es gab ein Problem mit Fehlern in der alten Funktionalität, die wir nur in den letzten Phasen des Projekts finden konnten.Daher waren die ersten Ziele der Einführung von UI-Tests für mobile Anwendungen für uns:- AT-Abdeckung der Hauptanwendungsfälle;
- Reduzierung der Anzahl der Fehler in der Regression vor der Veröffentlichung.
Das Erreichen des ersten Ziels sollte automatisch zum Erreichen des zweiten Ziels führen Regelmäßige Testläufe für grundlegende Funktionen während des gesamten Projekts sollten Fehler in früheren Phasen finden.Nach einiger Zeit wurde ein weiteres Ziel hinzugefügt - die Anzahl der manuellen Regressionstests zu reduzieren.Und wann ist es Zeit, die Automatisierung in das Testen einzuführen?
Bevor Sie mit der Testautomatisierung beginnen, sollten Sie die Bereitschaft Ihrer Anwendung zur Automatisierung bewerten. Und auch Ihre Bereitschaft für diesen Prozess.Stabile Funktionalität
Damit AT eine Chance hat, nützlich zu sein, muss die Anwendung über eine stabile Funktionalität verfügen. Und es lohnt sich, über Autotests zu berichten. Andernfalls werden Sie aufgrund von Anwendungsänderungen viel Zeit und Mühe in die Aktualisierung und Aktualisierung von Tests investieren.Entwicklungspläne
Die Automatisierung sollte nur implementiert werden, wenn Ihre Anwendung zukünftige Entwicklungspläne für die kommenden Jahre hat. Warum Autotests für eine Anwendung, die sich nicht ändert?Ressourcen
Sie müssen über Ressourcen für die Entwicklung von Tests und vor allem für deren weitere Unterstützung verfügen. Jene. Bei der Planung der Implementierung der Automatisierung ist es wichtig zu verstehen, dass nicht nur Ressourcen zum Schreiben von Tests benötigt werden. Tests werden sicherlich aus irgendeinem Grund fallen. Die Ergebnisse der Läufe müssen analysiert und Maßnahmen ergriffen werden. Einschließlich etwas in Tests ändern. Vergessen Sie nicht nur die Unterstützung, sondern auch die Notwendigkeit ihrer Entwicklung.Wie entscheide ich mich?
Als wir über die UI-Tests mobiler Anwendungen nachdachten, kamen wir sofort auf große Regale mit Geräten oder Farmen, auf denen Geräte gemietet werden. Bei den Tests gab es viele Probleme, da unterschiedliche Größen und Bildschirmauflösungen überprüft werden mussten. Ja, und es gab nicht viel Erfahrung in der Entwicklung. Es war alles beängstigend und gezwungen, Pläne wegzulegen.Die zuvor formulierten Ziele kamen zur Rettung, und das wichtigste war ein Funktionstest. Deshalb haben wir klein angefangen.Als Ergebnis unserer Tests:- einmal am Tag ausführen (dies reicht aus, um die Ursache des Problems zu finden, wenn etwas passiert);
- lokal auf unseren Servern ausführen;
- auf zwei Geräten (iOS und Android);
- Für Android gibt es jetzt ungefähr 50 Tests, der Lauf dauert ungefähr eine Stunde (zusammen mit der Montage);
- für iOS - ungefähr 40 Tests dauert der Lauf ungefähr 30 Minuten;
- Tests werden mit Xamarin.UITest geschrieben;
- Sie werden automatisch von Builds in TFS gestartet. An derselben Stelle in TFS überwachen wir die Ergebnisse von Läufen.
Ein bisschen über Xamarin.UITest
Dies ist ein Framework für automatische UI-Tests für Projekte unter Xamarin.iOS und Xamarin.Android (Unterstützung für Objective-C / Swift und Java wird ebenfalls angekündigt). Tests werden mit NUnit in C # geschrieben. Inhaltsprojekte können einfach integriert werden.Das Prinzip der Framework-Operation basiert auf zwei Komponenten: Suchen nach einem Element (Abfragen) und Ausführen von Aktionen damit (Aktionen), z. B. Drücken oder Ausführen eines Wischens.Hier ist zum Beispiel ein Test, der die Fehleranzeige bei der Eingabe eines ungültigen Logins überprüft:public void ShowErrIncorrectLoginOrPassword_IfLoginIsWrong()
{
var wrongLogin = TestsSettings.UserLogin + "1";
app.EnterLoginAndPassword(wrongLogin, TestsSettings.UserPassword);
app.WaitForElement(Resources.Identifiers.ErrorMessage, "Login is incorrect, alert message wasn't shown.", TestsSettings.Delay);
Assert.AreEqual(CoreResources.ErrIncorrectLoginOrPassword, ErrorMessage);
}
private string ErrorMessage =>
app.Query(x => x.Marked(Resources.Identifiers.ErrorMessage)).First().Text;
Die darin verwendete Eingabemethode für Anmeldeinformationen:public static void EnterLoginAndPassword(this AndroidApp app, string login, string password)
{
app.WaitForElement(Resources.Identifiers.LoginEdit, TestsSettings.Delay);
app.EnterText(Resources.Identifiers.LoginEdit, login);
app.EnterText(Resources.Identifiers.PasswordEdit, password);
app.Tap(Resources.Identifiers.LoginButton);
}
In diesem Beispiel werden die Standard-Framework-Methoden verwendet: Warten auf ein Element, Eingeben von Text und Klicken auf ein Element.Beim Entwickeln und Debuggen von Tests ist es bequem, das integrierte Konsolendienstprogramm REPL (read-eval-print-loop) zu verwenden, mit dem Sie den Baum der Elemente anzeigen können, die sich jetzt auf dem Bildschirm befinden, und Standard-Framework-Methoden ausführen können.Für uns unerwartet zu sein
Das Adressieren von Schnittstellenelementen führte manchmal nicht zu dem, was wir erwartet hatten.Wenn beispielsweise ein neues Fenster in einer Anwendung mit einem Fragment in derselben Aktivität geöffnet wird, sieht der Benutzer nur dieses neue Fenster auf dem Bildschirm. In diesem Fall befinden sich jedoch die Elemente im Baum der sichtbaren Elemente, die der Benutzer jetzt nicht mit den Augen sieht. Die Suche nach einem solchen "unsichtbaren" Element ist erfolgreich und Sie können damit eine Aktion ausführen. Das ist nur ein Klick wird in dem Fenster ausgeführt, das der Benutzer sieht. Jene. in der Tat wird es ein falsches positives sein.Der Baum kann mehrere identische Elemente enthalten. Standardmäßig wird die Aktion mit dem ersten geeigneten Element des Baums ausgeführt. Und wenn Sie in einem Test über eine Beschriftung auf ein Element zugegriffen haben und dann irgendwo ein Element mit derselben Beschriftung haben, beginnt der Test zu fallen (oder vielleicht auch nicht, wenn das benötigte Element das erste ist).Wir hatten einen Fall, in dem ein schriftlicher und debuggter Test beim ersten Kampfstart fiel. Weil die Tests auf einem Gerät mit einer anderen Bildschirmgröße ausgeführt wurden. Das Element, auf das auf diesem Gerät geklickt wurde, wurde unter einem anderen Schnittstellenelement angezeigt.
Der Postausgangsordner befand sich unter der Schaltfläche Aufgabe erstellen. Wenn Sie in diesem Fall auf den Ordner klicken, klicken Sie auf die Schaltfläche. Dies ist eine vertraute Situation für den Benutzer, er wird einfach den Bildschirm scrollen. Im Elementbaum ist diese Überlagerung jedoch nicht sichtbar.Solche Probleme verursachen geringfügige Unannehmlichkeiten und lassen Sie einige Tests genauer durchdenken. Und manchmal passen wir die Daten einfach in die Datenbank ein, damit nichts den Test stört. Schließlich besteht das Ziel in diesem Beispiel darin, einen Ordner zu öffnen und nicht zu überprüfen, ob nichts das Öffnen verhindert.Eine weitere Überraschung und Enttäuschung war die Unfähigkeit, iOS-Tests in Visual Studio für Windows auszuführen und zu debuggen. Diese Funktion wurde noch nicht implementiert. Ich muss für MacOS im Studio arbeiten.Einige Kapitänsergebnisse
Implementieren Sie die Automatisierung, wenn dies sinnvoll ist.Lassen Sie Ihre Tests mit einem Minimum an Konfigurationen sein, lassen Sie sie manuell und nur einmal im Monat ausführen, aber wenn sie Ihre Probleme lösen und Ihnen helfen - warum nicht?Vergessen Sie nicht das Prinzip der Pyramide.