In diesem Artikel werden die Testfunktionen von nativen und plattformübergreifenden Anwendungen verglichen. Ich werde meine Eindrücke von der Arbeit mit Flutter teilen und Ihnen sagen, welche Tools wir beim Testen in Surf verwenden, warum Flutter praktisch ist und auf welche Probleme wir gestoßen sind.
Die Testfunktionen in Flutter sind mit den nativen vergleichbar
Wenn ein Unternehmen seinen Entwicklungsansatz ändert oder eine neue Technologie entsteht, ist es wichtig, dass die Testfunktionen nicht stark beeinträchtigt werden. Im Idealfall verwenden QS-Spezialisten bei der Arbeit mit einer neuen Sprache oder einem neuen Framework weiterhin den bekannten Stapel von Tools und Technologien, die sich am besten bewährt haben.
Beim Testen nativer Apps verwenden wir bei Surf Autotest und lesen und ersetzen Pakete. Nirgendwo ohne Autotests, insbesondere mit Regression, und ohne die Hilfe eines Proxys, nehmen die Variabilität der Anwendung und die Abdeckung vieler Fälle ab.
Für uns war es wichtig, dass die bekannten Funktionen beim Testen von Flutter-Anwendungen erhalten bleiben.
Automatischer Test
Surf arbeitet mit den Calabash- und Ruby-Frameworks, um native Apps automatisch zu testen. Als Flutter auftauchte, fragten wir uns als erstes: Ist es möglich, Calabash nicht zu verwenden, aber gleichzeitig vollständig mit Autotests zu arbeiten, wie wir es gewohnt sind - oder sogar noch cooler.
Es stellte sich heraus, dass dies nicht nur möglich ist, sondern auch ohne Dienste von Drittanbietern: In Flutter sind Integrationstests und das Testen von Widgets in der Konsole sofort verfügbar. Unser Flutter-Entwickler hat dies im Artikel über Autotesting auf Flutter ausführlicher beschrieben .
Autotests auf Flutter sind gleichzeitig plattformübergreifend und nativ: Sie können Tests innerhalb des Anwendungsprojekts schreiben und sie funktionieren auf beiden Plattformen. Wenn das gesamte Projekt vor Ihren Augen liegt, können Sie fehlende ID-Schnicks hinzufügen oder sogar Fehler finden und beheben - dies ist eine weitere Möglichkeit, die Qualität der Anwendung zu verbessern.
Flutter unterstützt auch den BDD-Ansatz (Behavior Driven Development). Wir verwenden es für UI-Tests. Wir haben Gurke als Sprache gewählt: Sie können Feature-Dateien verwenden, Skripte in Englisch und Russisch schreiben. Es ist verständlich, es hat die Implementierung von Skriptschritten ohne zusätzliche Argumente in oder mit ihnen, die Möglichkeit, den Start von Autotests anzupassen: zum Beispiel das Ausführen einiger Skripte nach Tags und nicht alle schriftlichen Tests als Ganzes.
Um Gherkin beim Testen von Flutter-Anwendungen zu verwenden, haben wir das OpenSource-Framework flutter_gherkin verbunden .
Als wir feststellten, dass es bei Flutter Autotests gibt, fragten wir uns, was die Unterschiede zwischen den Technologien Calabash und Dart + Gherkin sind. Welcher Ansatz ist besser? Vergleichen wir sie miteinander.
1. Feature-Dateien sind für beide Ansätze absolut identisch.
Beispielsweise wird das Skript zur Autorisierung durch PIN-Code sowohl in Dart als auch in Ruby mit Calabash korrekt interpretiert:
: ( )
Beide Technologien unterstützen Russisch, Englisch und andere Sprachen.
2. Die Schritte unterscheiden sich in der Implementierung.
| Dart + flutter_gherkin
|
Kalebasse
|
|
|
3. Flutter verwendet eine zusätzliche Dart-Datei, um Tests zu konfigurieren und damit zu arbeiten. Mit Calabash existiert keine solche einzelne Datei.
Unserer Meinung nach ist es unmöglich zu sagen, dass dies ein Flattern in Flutter oder Calabash ist - dies sind nur die Besonderheiten der Arbeit mit bestimmten Werkzeugen und Technologien.
4.Für die Arbeit mit Elementen in der Anwendung ist es erforderlich, dass jedes Element eine eigene ID hat. Wenn Sie mit Autotests mit Calabash arbeiten, müssen Sie im Voraus darauf achten, dass beide Plattformen in den getesteten Anwendungen eine ID haben. Bei Dart können Sie beim Schreiben von Autotests eine ID hinzufügen, ohne die Dateien von iOS- und Android-Anwendungen separat neu laden zu müssen. Dies ist praktisch und spart Zeit.
Unser Fazit: Autotests auf Dart sind Autotests mit dem Calabash-Framework nicht unterlegen.
Proxies
Um die Anwendungsabdeckung nach Fällen zu erhöhen, verwendet Surf Programme zum Lesen und Fälschen von Datenverkehr, z. B. Charles. Die Analyse der Client-Server-Interaktion ermöglicht:
- Stellen Sie fest, ob eine echte Interaktion mit dem Backend besteht.
- Finden Sie heraus, auf welcher Seite das Problem liegt: auf dem Client oder auf dem Server.
- , .
- : , , . Charles , , , .
Dart hat einen eigenen Client für die Arbeit mit dem Netzwerk. Da alle Anforderungen durchlaufen werden, müssen die erforderlichen Einstellungen für die Arbeit mit einem Proxy in der Anwendung eingegeben werden. Zur Erleichterung der Tester werden alle erforderlichen Einstellungen auf einem separaten Bildschirm platziert: In Surf verwenden wir den Debug-Bildschirm, den wir selbst entwickelt haben.
Der Debug-Bildschirm ist ein zusätzlicher Einstellungsbildschirm, der nur im Debug-Build verfügbar ist und beim Testen hilft. Darin können Sie den erforderlichen Server auswählen, das Lesen und Speichern von http-Anforderungen in der Anwendung aktivieren, das fcm-Token des Geräts anzeigen und vieles mehr - es gibt viele Möglichkeiten zum Testen.
Der Debug-Bildschirm ist benutzerdefiniert: Entwickler fügen ihm auf Anforderung von Testern zusätzliche Elemente hinzu, z. B. Felder zum Konfigurieren von Proxys aus der Anwendung. Daher haben wir alle Möglichkeiten, mit Charles zusammenzuarbeiten: Sie können einen Proxyserver mit dem Debug-Bildschirm verbinden, ohne die Anwendung neu zu starten.
Wie Sie sehen, sind die Möglichkeiten zum Testen von Flutter-Anwendungen nicht begrenzt. Alles, mit dem wir gewohnt sind, wenn es nativ ist, ist bequem und einfach zu bedienen. Das sind gute Neuigkeiten.
Probleme: Framework-Fehler, Fehler in Bibliotheken von Drittanbietern, erwartetes natives Verhalten
Die Probleme, mit denen wir beim Testen von Flutter-Anwendungen konfrontiert sind, sind ebenfalls nativ. Es kann nicht gesagt werden, dass dies die spezifischen Mängel von Flutter sind: In jeder Technologie ist die Problemlösung nicht immer offensichtlich und einfach.
Lassen Sie uns Ihnen sagen, worauf Sie beim Testen von Flutter-Anwendungen achten müssen. Vorgewarnt ist gewappnet.
Flutter-Framework-Fehler
Beim Testen sind beim Anzeigen und Formatieren von Schriftarten unter iOS ein Problem aufgetreten: Der Buchstabenabstand auf der iOS-Plattform war deutlich größer als unter Android. Dies verursachte viele visuelle Fehler.
Es stellte sich heraus, dass das Problem im Framework selbst lag. Als sich unsere Entwickler mobiler Apps mit der Bitte an die Entwickler der Flutter Framework-Entwickler-Community wandten, einen solchen unangenehmen Fehler zu beheben, wurde das Framework bald aktualisiert und die Textanzeige unter iOS wurde behoben.
Sicherlich werden sich solche Situationen wiederholen. Dies kann jedoch nicht als großes Problem bezeichnet werden: Die Mitarbeiter der Flutter-Community reagieren schnell auf Probleme, unterstützen und entwickeln das Framework.
Mängel in Bibliotheken von Drittanbietern
In iOS-Versionen 10 und 11 wurden Implementierungsfehler in Bibliotheken von Drittanbietern festgestellt. Wir haben beispielsweise einen Fehler behoben, bei dem die Berechtigung zum Zugriff auf Benachrichtigungen sofort beim Start der Anwendung angezeigt wird und nicht auf der Schaltfläche, wie in der technischen Spezifikation und im Design geplant.
Solche Probleme können sowohl plattformübergreifend als auch nativ auftreten. Sie werden durch Korrekturen innerhalb des Projekts oder zusammen mit den Bibliotheksentwicklern gelöst.
Umgang mit dem erwarteten
nativen Verhalten Durch die langfristige Verwendung und das Testen nativer Anwendungen unter iOS und Android ist es einfach, die Benutzererwartungen aufgrund des unterschiedlichen Anwendungsverhaltens vorherzusagen. So ist es beispielsweise eine Standardgeste, mit einem Backwipe unter iOS zurückzukehren. Und unter Android brauchen Sie es nicht.
Systemdialoge auf beiden Plattformen sind unterschiedlich: Unter iOS müssen Sie die Berechtigung zum Zugriff auf Benachrichtigungen anfordern, und unter Android ist dieser Zugriff standardmäßig gewährt.
Es sind diese Teile der Betriebssystemspezifikationen, die häufig manuell abgeschlossen werden müssen. Und manchmal - um zu schneiden, wenn plötzlich das erwartete Verhalten für die iOS-Plattform auf Android migriert wurde, wie es beim Backwipe der Fall war.
In nativen Anwendungen sind Probleme wie Bildschirmaktualisierung, falsche Anwendungsminimierung und Anwendungsbetrieb, die für das aktuelle Betriebssystem ungewöhnlich sind, selten: Tools und Technologien zum Entwickeln einer Anwendung für eine bestimmte Plattform zielen bewusst darauf ab, alle Versionen und Funktionen eines bestimmten Systems abzudecken.
Beim Testen einer der Flutter-Anwendungen hatten wir eine interessante Situation: Die Möglichkeit, den Bildschirm zu aktualisieren, war auf iOS-Geräten mit Pony nicht verfügbar - beginnend mit dem iPhoneX und höher. Gleichzeitig funktionierten iOS-Geräte ohne Pony und Android ordnungsgemäß.
Bei Android Version 6 ist ein weiterer Fehler aufgetreten: Bei Minimierung wurde die Anwendung vollständig aus dem Speicher entladen.
Solche Fehler wurden von unseren Entwicklern innerhalb des Projekts behoben.
iOS ist sich seiner Geräte und Systeme bewusst, welche Chips sie mit der neuen Betriebssystemversion veröffentlichen und welche in früheren Versionen nicht mehr funktionieren, worauf sie sich bei der Aktualisierung desselben Swift konzentrieren sollten. Android versteht, dass sie auf eine große Anzahl von Geräten und völlig unterschiedliche Bildschirmgrößen abzielen müssen, und sie kennen auch ihre Besonderheiten.
Ich möchte, dass die plattformübergreifende Version alle Feinheiten der Implementierung aus der nativen Entwicklung enthält. Natürlich gibt es einige Mängel bei der Arbeit mit Flutter, aber dies ist kein Problem: Sie benötigen lediglich Ihren eigenen Ansatz für die plattformübergreifende Arbeit.
Vorteile: eine Codebasis, ein Entwicklungsteam
Eine einzige Codebasis verkürzt die Testzeit.
Der Grund für Fehler können unscharfe technische Spezifikationen, fehlende gerenderte Zustände im Design und Abwärtskompatibilität beim Aktualisieren des Backends sein. Es ist einfacher, solche Fehler zu erstellen, da Sie halb so viele Aufgaben erstellen müssen, was bereits Zeit spart.
Sie können auf einer Plattform nach Fehlern suchen und Funktionen überprüfen: Mit hoher Wahrscheinlichkeit werden sie auf beiden Plattformen wiederholt - schließlich gibt es eine Implementierung.
Die Logik neuer Funktionen auf beiden Plattformen ist ebenfalls dieselbe, da derselbe Code geschrieben wird: Beim Testen komplexer Prozesse in einer Anwendung müssen sie auf einer Plattform getestet und auf einer anderen bestätigt werden. Wir führen einen vollständigen Zyklus von Aktivitäten auf einer Plattform durch: Wir führen Erkundungstests durch, Feature-Läufe, Rauch / Vernunft / Voll, analysieren Feedback. Danach muss die Qualität nur noch durch Erkundungstests auf einer anderen Plattform bestätigt werden. Dieser Ansatz spart etwa 1,3-mal Zeit beim Testen der Logik.
, , , : , . , .
, (, iOS), , (Android), event .
Wenn Baugruppen für beide Plattformen am selben Tag an den Kunden geliefert werden müssen, werden sie zur selben Zeit herausgebracht und es gibt nur einen QS-Techniker im Projekt. Möglicherweise bleibt nicht genügend Zeit für die Überprüfung in der nativen Entwicklung: Der Testzyklus muss auf beiden Plattformen separat durchgeführt werden. Wir sparen Zeit, indem wir plattformübergreifende Anwendungen testen: Regressionstests beider Plattformen finden in einem einzigen Zyklus statt.
Wir haben versucht, die Tests von zwei ähnlichen Projekten grob zu bewerten - eines auf nativem Android und iOS, das zweite auf Flutter - und sie apikal verglichen.
Analyse und Test wurden auf einem iOS-Gerät und einem Android-Plattformgerät durchgeführt. Wie Sie in der Praxis sehen können, gibt Flutter wirklich einen Zeitgewinn, wenn auch nicht zweimal. Dies ist verständlich: Sie können Tests auf einer der beiden Plattformen nicht vollständig entfernen. Was auch immer man sagen mag, sie haben unterschiedliche Spezifitäten und konzentrieren sich auf den Benutzer.
|
|
Natives iOS
|
Native Android
|
Flattern Android + iOS
|
| Passwort Wiederherstellung
|
2h
|
2h
|
3h 20m
|
| Genehmigung
|
1h 30m
|
1h 30m
|
2h 20m
|
| Mitteilungen
|
2h
|
2h
|
4h
|
Wenn Sie eine vorgefertigte Funktion testen, die die Besonderheiten des Betriebssystems nicht vollständig beeinflusst und nicht für jede Plattform separat geschrieben wurde, wird die Zeit zum Überprüfen einer Flutter-Anwendung auf beiden Plattformen um das 1,3-1,5-fache reduziert. Beispielsweise reduzieren Autorisierungs- und Kennwortwiederherstellungsfunktionen, die auf verschiedenen Plattformen kein spezifisches Verhalten aufweisen, die Testzeit der Flutter-Version um das 1,3-fache.
Bei Funktionen, die von jeder Plattform ein benutzerdefiniertes Verhalten erfordern, sollten Sie keine Zeitverkürzung erwarten. Das Verhalten für iOS und Android wird voraussichtlich unterschiedlich sein, was bedeutet, dass beide Plattformen vollständig und getrennt voneinander getestet werden müssen. Beispielsweise ist es häufig erforderlich, Push-Benachrichtigungen auf beiden Plattformen aufgrund unterschiedlicher Berechtigungen im gesamten Zyklus zu testen, mit Benachrichtigungsverbindungen zu arbeiten, Pusher-Einstellungen für das Senden von Benachrichtigungen unter iOS und Android sowie andere Feinheiten bei der Implementierung zu verwenden, damit die übliche Arbeit des Benutzers mit Benachrichtigungen unterstützt wird. TK und Design wurden respektiert.
Es ist einfacher, die Kommunikation innerhalb des Teams zu organisieren
Wenn viele Leute im Projekt sind, ist es schwierig, den Prozess so zu organisieren, dass selbst die kleinsten Feinheiten nicht vorbeiziehen. Insbesondere wenn noch viele Verbesserungen bevorstehen, Implementierungen neuer Funktionen und Änderungen im Allgemeinen. Die meisten Probleme werden gelöst, wenn das Entwicklungsteam eines ist.
Erstens ist es einfacher, eine Anwendung durch Implementieren eines einzelnen Befehls zu testen, als mit zwei verschiedenen Implementierungen auf zwei Plattformen zu arbeiten. Der Qualitätssicherungsprofi ist natürlich daran interessiert, vollständige Informationen über den Status der Anwendung sowohl auf der iOS-Plattform als auch auf der Android-Plattform zu erhalten. Es ist einfacher, mit Flutter zu arbeiten.
Zweitens gibt es einen wichtigen Punkt in der nativen Entwicklung: Über die Änderungen, die eine Plattform gelernt und akzeptiert hat, muss die andere Plattform benachrichtigt werden, die manchmal bei großen und intensiven Änderungen vergessen wird oder verloren geht. Bei der Entwicklung von Flutter-Anwendungen gibt es kein solches Problem: Es gibt nur ein Team - das heißt, eine Aufgabe für die Überarbeitung gilt für beide Plattformen.
Wir lieben es, Flutter-Anwendungen zu testen
Teil einer coolen Community sein
Für uns ist ein neues Framework ein Plus: Wenn wir nicht standardisierte Probleme lösen, erweitern wir unseren Horizont. Wir finden viele interessante und einzigartige Fehler, die unsere Fähigkeiten und Fertigkeiten beim Testen von Anwendungen entwickeln.
Gleichzeitig geben Entwickler aus der Flutter-Framework-Community schnell Feedback zu erkannten Problemen, verbessern die Bibliothek und ermöglichen uns, einen Beitrag zum Projekt zu leisten: Wir kommen gemeinsam voran, und es ist schön.
Seien Sie ein Spezialist
Bei der Arbeit mit plattformübergreifenden Anwendungen ist es wichtig, die Unterschiede in den Betriebssystemen zu berücksichtigen und nicht den Fokus auf die Spezifität der Plattform zu verlieren. Suchen und sehen Sie Unterschiede, wo sie theoretisch minimal sein sollten, und lernen Sie etwas, das Sie noch nie zuvor erlebt haben - solche Arbeiten erhöhen die Professionalität.
Beim Entwickeln und Testen nativer Apps ist es unmöglich, eine iOS-App beispielsweise aus Android Studio oder Visual Studio Code zu erstellen. Bei der Arbeit mit Flutter ist die IDE für Android und iOS gleich. Das ist cool.
Seien Sie unabhängig
Bei der Arbeit mit Flutter stehen wir bei Surf vor sehr unterschiedlichen Projekten: vom E-Commerce bis zum Bankgeschäft. Die Praxis hat gezeigt, dass ein QS-Ingenieur beide Plattformen im Alleingang testen kann. Es ist notwendig, einen anderen Spezialisten nur näher an das Release anzuschließen, wenn das Arbeitstempo zunimmt und die Zeit für die Erledigung von Aufgaben knapp wird.
Flattern - ein Schritt nach vorne
Das Testen plattformübergreifender Apps ist nicht schwierig. Manchmal ist es sogar schneller und bequemer als mit einheimischen zu arbeiten. Alle Schwierigkeiten, auf die man stoßen kann, überschneiden sich nicht mit der Bequemlichkeit und den Vorteilen.
Die Erfahrung beim Entwickeln und Testen von Flutter-Anwendungen hat Surf gezeigt, dass dieses Framework ein großer Schritt nach vorne ist.