Von der Eiszeit zu Rächern mit Appium

Lehren aus dem Kite-Robot-Ansatz

Lassen Sie mich hier mit einem langweiligen Haken beginnen: Meine persönlichen Erfahrungen beim manuellen Testen einer App. Da die Produktentwicklung die Lieferung in Einzelteilen umfasst, wird es für ein QA-Teammitglied eintönig, immer wieder dieselben Aktionen auszuführen. Jedes Mal, wenn ich etwas testen musste, brauchte ich einen neuen Benutzer und musste daher manuell einen neuen Benutzer anmelden. Es ist langweiliger als es klingt.

Hier kommt die Automatisierung ins Spiel. Was wäre, wenn wir Zeit damit verbringen würden, einen Code zu schreiben, der all diese langweilige Arbeit für uns erledigen würde? Was ist, wenn es auch genau funktioniert?

Das QA-Team von Kite führte eine ganze Reihe von Forschungs- und Entwicklungsarbeiten durch, um die richtigen Werkzeuge zu finden. Wir haben uns für Appium entschieden, da es:

  1. Ist Open Source
  2. Benötigt keinen Quellcode
  3. Benötigt keine Instrumentierung
  4. Hat Tonnen von Trägermaterial leicht verfügbar

Appium könnte sich für die meisten von uns wie eine Raketenwissenschaft anfühlen. Wenn Sie jedoch einen angemessenen Ansatz verfolgen, können Sie die Funktionen voll ausschöpfen.

In diesem Beitrag werde ich die Nachteile einer klassischen Herangehensweise an Appium hervorheben und wie unsere Robot-Herangehensweise an Kite Appium zu einer relativ stressfreien Erfahrung macht. Bei Kites erster App, Kite Cash, haben wir den Robot-Ansatz verwendet. Es wurde zu Versuchszwecken gestartet und hat sich zu einem Netzwerk von über 100.000 Nutzern in mehr als 1.100 Städten zusammengeschlossen.

Klassischer Denkansatz

Im Allgemeinen führt ein klassischer Ansatz dazu, dass eng gekoppelter Code, der nicht wartbar ist, Redundanzen erhöht, Refactoring erschwert und nicht skalierbar ist.

Angesichts dieser Einschränkungen betrachten wir Appium als eine Geschichte.

Klassisches Szenario

Betrachten Sie einen Anmeldebildschirm mit einem Benutzernamen, einem Kennwortbildschirm und einer Anmeldeschaltfläche. Wenn ich die richtigen Anmeldeinformationen eingebe und auf "Anmelden" klicke, kann ich mich möglicherweise anmelden und den nächsten Bildschirm anzeigen.

Während wir über einen Test nachdenken, stellen wir folgende Fragen: Was wollen wir erreichen? und wie werden wir es erreichen? Unser früherer Ansatz hat dieses Was- und Wie-Paar eng miteinander verbunden. Wenn dieses Paar jedoch zusammengehalten wird, ist es für eine Qualitätssicherung schwierig, Skripts zu verwalten und zu skalieren. Das Problem besteht zwangsläufig darin, dass sich die Geschäftsanforderungen ändern und wir aufgrund dieser Kopplung unseren Test ändern müssen. Hier ist ein Beispiel:

Was soll erreicht werden: Die Übergabe des richtigen Benutzernamens / Passworts sollte den Benutzer zum Dashboard-Bildschirm führen.

  • Geben Sie den Benutzernamen "hulk@spiderman.com" ein
  • Passwort eingeben “HS @ 1235”
  • Klicken Sie auf die Schaltfläche "Anmelden"
  • Überprüfen Sie, ob der Dashboard-Bildschirm angezeigt wird

Betrachten Sie den Code:

Sehen wir uns an, welche Probleme bei diesem Ansatz auftreten:

  1. Es gibt ein hohes Maß an Code-Duplizierung, was die Automatisierungsleistung weiter beeinträchtigt.
  2. Der obige Code ist nicht lesbar. In schnell wachsenden Unternehmen wie Kite (und vielen anderen) treten immer neue Mitglieder einzelnen Teams bei. Ein neues Mitglied kann diesen Code und seinen Zweck nicht verstehen, wenn es nach dem Schreiben des Codes beitritt.
  3. Wir werden in naher Zukunft mit der Verwaltung dieser Art von Code nicht zufrieden sein, wenn die Anwendungsworkflows zunehmen.
  4. Alle neuen Änderungen an der Benutzeroberfläche lassen sich nur schwer in diese Art von Code integrieren, da an mehreren Stellen viele Umgestaltungen erforderlich sind, damit der Code wieder funktioniert.

Natürlich mag der klassische Ansatz einfach aussehen, aber sobald die Funktionen in einer Anwendung erweitert werden, bereitet die Verwaltung dieses Codes Kopfzerbrechen.

Robot Ansatz

Was wäre, wenn wir einen Ansatz verfolgen würden, bei dem wir uns nur auf das konzentrieren, was wir erreichen wollen? und nicht Wie wollen wir es erreichen? Wir würden dann verschiedene Klassen für Wie und Was erstellen. Auf diese Weise sind die Kategorien Wie und Was unabhängig voneinander.

Das Robotertestmuster ähnelt dem weit verbreiteten Seitenobjektmodell, bei dem es sich um ein Entwurfsmuster handelt, mit dem ein Objektrepository für Benutzeroberflächenelemente für webbasierte Plattformen erstellt wird.

Gegenwärtig verlassen wir uns auf einen manuellen Benutzer, um Aktionen auszuführen. Was wäre, wenn Roboter das alles für uns tun würden? Beim Robot-Ansatz wissen wir, dass wir auf dem Bildschirm einen Benutzernamen / ein Passwort eingeben können, ohne uns darum zu kümmern, wohin diese Werte gehen.

Roboterszenario

Auf UsernamePasswordScreenBot ist ein Roboter vorhanden, der Werte in den Feldern für Benutzername und Kennwort übergibt und auf "Anmelden" klickt. Der Bildschirm ändert sich nun und dieser Roboter hat nur die Kontrolle über die UsernamePasswordScreenBot-Klasse. Von hier aus nimmt ein anderer Bot beispielsweise einen ResultScreenBot an, um auf dem nächsten Bildschirm weitere Aktionen auszuführen.

Mit anderen Worten, erstellen Sie einen Roboter pro Bildschirm, der die erforderlichen Aktionen ausführt.

Lehnen Sie sich zurück, entspannen Sie sich und lassen Sie die Roboter für Sie arbeiten.

In diesem Code wird erklärt, was wir möchten, dh, dass Sie einen Benutzernamen und ein Kennwort eingeben können, unter denen sich der Benutzer anmelden soll.

Vergleich

Vergleichen wir die Metriken und Leistungsänderungen im klassischen Ansatz und im Robot-Ansatz:

  1. Die Codeduplizierung wird minimiert, da wir Element-IDs in eine Klasse einfügen und jedes Mal dieselbe Klasse verwenden.
  2. Die Lesbarkeit des Codes wurde verbessert, da ein neues Mitglied, das dem Team beitritt, intuitiver verstehen kann, was dieser Code tut.
  3. Das Verwalten eines solchen Codes und das Anpassen an Änderungen an der Benutzeroberfläche ist jetzt einfacher. Code an einer Stelle ändern, und diese Änderung spiegelt sich überall wieder. Betrachten Sie ein Beispiel: Im Anmeldefluss wird die ID eines Elements geändert oder ein neues Feld hinzugefügt. Bei der klassischen Methode müssen wir an jedem Punkt, an dem wir einen Benutzer anmelden, Änderungen vornehmen. Bei der Robot-Methode fügen wir einfach die Elemente in der UsernamePasswordScreenBot-Klasse hinzu oder bearbeiten sie und rufen sie direkt von dort aus auf.

Umfang der Robotertests

Zuerst denken wir vielleicht, dass Bots nicht klug genug sind, um einen Sanity-Test durchzuführen oder negative Flows abzudecken. Ihre Bots führen jedoch Negativ-, Sanity- und Regressionstests durch, indem sie einen Code wie den folgenden verwenden. Dies gibt Ihnen ein paar zusätzliche wertvolle Minuten für Ihre Mittagspause. Dazu müssen wir verschiedene Methoden erstellen und Inhalte übergeben.

Der obige Code zeigt, wie Sie Methoden für alle Arten von Daten erstellen können, die Sie in einer einzelnen Klasse übergeben möchten. Die klassische Herangehensweise konzentrierte sich darauf, was zu erreichen ist und wie es insgesamt zu erreichen ist. Wir müssen diese "Wie" -Komponente loswerden, um die Dinge einfacher zu machen.

Zeitersparnis und Kapazitätsaufbau

Wir haben viel Zeit gespart und unsere Fähigkeiten erweitert, indem wir auf den Robot-Ansatz umgestiegen sind.

  1. Unsere Testabdeckung hat im Vergleich zu manuellen Tests zugenommen.
  2. Wir haben die Zeit, die benötigt wird, um eine geistige Gesundheit zu vollenden, von einem ganzen Tag auf 5 bis 10 Minuten verringert.
  3. Wir haben die Erstellungszeit von Skripten um 50% verkürzt und das Problem der Skalierbarkeit behoben.
  4. Mit dem Skriptansatz können wir eine Regressionssuite erstellen, die das Testen einfacher und genauer macht.

Fazit

In einem Startup wie Kite hatte ich die Flexibilität, neue Dinge auszuprobieren und Zeit in die Forschung zu investieren. Aus diesem Grund konnte ich einen neuen Ansatz für die Verwendung von Appium entwickeln. Jeden Tag stoße ich dank des äußerst unterstützenden Teams, mit dem ich bei Kite zusammenarbeite, auf bessere Methoden. Durch den offenen Austausch konnten wir Innovationen entwickeln, die unsere Arbeit effektiver, effizienter und unterhaltsamer machen. Wenn Ihr Arbeitsplatz dies unterstützt, empfehle ich Ihnen, Sitzungen zum Wissensaustausch zu organisieren und jede Woche eigene Stunden einzurichten, um mit neuen Techniken zu experimentieren. Dies ist der effektivste Weg, um langfristige Strategien zu entwickeln, mit denen Ihre Teams eng verbunden bleiben und sich ständig weiterentwickeln.