Zum ersten Mal probieren wir App Center aus und berichten über unsere Erfahrungen

Wenn heute jeder Einwohner einer Großstadt einen Computer in der Tasche hat, der viel mehr kann als nur zum Mond zu fliegen , verwenden wir jeden Tag mobile Anwendungen. Nachrichten, Wetter, Werbeaktionen, Shopping - all diese Funktionen sind in Hunderttausenden von Anwendungen implementiert. Wenn eine Lieblingsanwendung jedoch einfriert oder abstürzt, ist sie schnell kein Favorit mehr.

Dieser Artikel wurde von den Jungs von WaveAccess geschrieben.

Wir entwickeln seit mehr als 10 Jahren mobile Anwendungen und können es uns nicht leisten, ein Produkt herauszubringen, das in den Händen der Benutzer liegt. Deshalb ist es für uns nicht weniger wichtig, das Testteam und die Infrastruktur zu „pumpen“ als in anderen Bereichen.

Hunderte von Android-Geräten, iPhones mit unterschiedlichen Betriebssystemversionen und eine unterschiedliche Diagonale von Geräten stellen QS-Ingenieure vor die Aufgabe, Fehler auf realen Mobilgeräten und auf verschiedenen Versionen von Betriebssystemen zu „erkennen“. Nur wenige können dasselbe manuelle Skript auf 10, 20, 50 Geräten verarbeiten. Dank dieser Aufgaben haben wir unsere Fähigkeit zum automatischen Testen, insbesondere auf Mobilgeräten, verbessert. Aber seien wir ehrlich: Das Erstellen und Verwalten der Infrastruktur selbst mit 20 realen Geräten zum Ausführen von Autotests bereitet Kopfschmerzen.

In diesem Artikel möchten wir Ihnen zeigen, wie wir den neuen Microsoft App Center-Dienst ausprobiert haben, um die Qualität der Anwendung zu überprüfen, die wir im Zoo realer Geräte entwickeln.

Warum stellte sich die Frage nach der Nutzung des Dienstes?

Jetzt entwickeln wir eine Anwendung zur Unterstützung des Einkaufs. Das Projekt läuft schon lange: Der Kunde bietet ständig neue Funktionen an, die er nur für uns entwickeln wird. Es gibt bereits Dutzende von Bildschirmen in der Anwendung, von "Kaufen" bis zu verschiedenen Nachrichtenoptionen, Drücken, "Sammeln Sie Ihren Bogen" -Funktionen. Und während dieser ganzen Zeit finden Präsentationen des Projekts für Investoren und Starts in neuen Einkaufszentren statt. Je höher die Veröffentlichungsgeschwindigkeit (ohne Abnahme der Produktqualität), desto besser.

Bisher haben wir Autotests auf einer begrenzten Anzahl von Geräten durchgeführt, die uns zur Verfügung standen (für dieses Projekt - etwa 30 Android-Geräte und „Äpfel“). Jetzt erreicht die Anwendung ein neues Niveau, das Publikum ist gewachsen und die Qualität ist noch kritischer geworden. Es stellte sich die Frage, ob ein Cloud-Dienst zum Ausführen von Autotests auf verschiedenen Geräten verwendet werden soll.

Bei der Veröffentlichung wollte ich alle modernen und bewährten Softwareentwicklungsmethoden anwenden: Cross-Review, kontinuierliche Integration, automatisierte Funktions- und Komponententests auf einer großen Liste von Geräten unter iOS + Android, Sammlung von Analysen und Crashlytics.

Wir haben jede dieser Praktiken früher angewendet, sowohl einzeln als auch in Kombination. Angesichts des Umfangs des Projekts und der Größe des Teams wollte ich jedoch eine universelle Lösung. Lassen Sie das Tool in der Lage sein, all das zu tun, und bieten Sie an einem Ort die Möglichkeit, den Entwicklungs- und Bereitstellungsstatus mobiler Anwendungen für verschiedene Plattformen zu verwalten und zu überwachen.

Jede der Rollen im Team hatte ihre eigenen Bedingungen: Die Entwickler wollten den bereits eingerichteten Entwicklungsprozess (Repository, Build-Tool usw.) nicht ändern und zu zu neuen, nicht verifizierten Tools im Produkt wechseln. Testingenieure träumten davon, die Belastung der Kontrollgeräte im Zoo zu verringern. Manager und Kunden wollten eine bequeme Schnittstelle zur Überwachung des gesamten Zustands mit transparentem Fluss.

Das Studium von Analoga ist eine ziemlich wichtige Phase bei der Auswahl eines Werkzeugs. Wir haben uns verschiedene Dienste angesehen, die solche Funktionen bereitstellen (für Appium-Tests, z. B. BrowserStack). Im Fall des Microsoft App Centers erhielten wir eine Testphase, sodass wir versuchen konnten, zu verstehen, was mit dem Projekt passieren würde, wenn wir etwas mehr Ressourcen für die Qualität verwenden und den gesamten Freigabeprozess der mobilen Anwendung für jede Plattform mit einem Dienst automatisieren. Wir erzählen, wie es war.

So richten Sie die iOS-App ein

Unter Verwendung des Testzeitraums, der die Funktionalität nicht einschränkt, erstellen wir unsere iOS-Anwendung im Microsoft App Center:

Wählen Sie eine Plattform:

Fügen Sie dem Projekt das App Center SDK hinzu:

pod 'AppCenter' 

Öffnen Sie nach der Installation der Herde die Datei AppDelegate.swift und fügen Sie die folgenden Zeilen unter Ihrem eigenen Importbefehl hinzu:

 import AppCenter import AppCenterAnalytics import AppCenterCrashes 

Fügen Sie der didFinishLaunchingWithOptions-Methode in derselben Datei die folgenden Zeilen hinzu:

 MSAppCenter.start("{Your App Secret}", withServices:[ MSAnalytics.self, MSCrashes.self ]) 

Ein ähnlicher Prozess ist für Ziel C, die Vollversion der Anweisung ist hier .

Buildim!

Gehen Sie zur Registerkarte Erstellen und wählen Sie unseren SVC-Dienst aus.

Konfigurieren Sie den Build. Vergessen Sie nicht zu unterschreiben, da dies eine Anwendungsdatei im App-Format generiert, die auf realen Geräten ausgeführt werden kann:

Fertig! Klicken Sie auf die Schaltfläche Jetzt erstellen und warten Sie auf den Build.

Eine ähnliche Geschichte für Android-Anwendungen finden Sie hier .

Wir starten die ersten Tests für iOS

Unit- und native Tests für jede Plattform können in die Assembly aufgenommen werden (es gibt ein Häkchen). Im Folgenden wird die Funktionalität von AT auf verschiedenen Geräten beschrieben.

Richten Sie eine Reihe von iOS- und Android-Geräten ein und senden Sie Tests an eine Reihe

Wechseln Sie zur Registerkarte Test, Gerätesätze. Wir erstellen eine Reihe von Geräten, auf denen wir unsere Tests durchführen werden. Es stehen mehr als 250 Android-Geräte zur Auswahl und mehr als 200 verschiedene iOS-Geräte (Generationsversion + iOS-Version). Eine detaillierte Liste der Geräte finden Sie hier .

Hier war es ein wenig enttäuschend, dass die offizielle Antwort auf die Frage, wie bald nach der Veröffentlichung die neuen Apple-Geräte erscheinen, wie „1-2 Monate nach dem Verkauf“ klingt.

Wir bereiten die Tests für den Start im App Center vor (ein Beispiel für XCUITest) und senden sie zum Start. Das App Center kann nur Anwendungen erstellen, sodass Sie das Testprojekt weiterhin lokal auf Ihrem Computer oder in Ihrem CI erstellen müssen.

 Shell: # Generate an XCUITest bundle and your iOS application as described above. $ rm -rf DerivedData $ xcrun xcodebuild build-for-testing -derivedDataPath DerivedData -scheme YOUR_APP_SCHEME # Upload your test to App Center $ appcenter test run xcuitest \ --app "<app center username/<app name>" \ --devices DEVICE_SET \ --test-series "master" \ --locale "en_US" \ --build-dir DerivedData/Build/Products/Debug-iphoneos 

Appium- Tests

Es lohnt sich sicherzustellen, dass die verwendeten Test-Frameworks mit den unterstützten übereinstimmen. Darüber hinaus müssen Sie den vom App Center bereitgestellten Treiber verwenden. Dies schränkt die Verwendung von Frameworks ein (z. B. kann Google Giuce nicht verwendet werden).

Projekterstellung für Maven-Benutzer

Schritt 1. Fügen Sie ein Repository und Abhängigkeiten hinzu

Sie müssen das JCenter-Repository zur Datei pom.xml hinzufügen.

 XML <repositories> <repository> <id>jcenter</id> <url>https://jcenter.bintray.com/</url> </repository> </repositories> 

Fügen Sie dann eine Abhängigkeit für Erweiterungen von Appium-Tests hinzu

 XML <dependency> <groupId>com.microsoft.appcenter</groupId> <artifactId>appium-test-extension</artifactId> <version>1.3</version> </dependency> 

Während der Kompilierung stehen daher die erweiterten Android- und iOS-Treiber zur Verfügung (die zunächst zur Implementierung der Label-Funktion benötigt werden; mehr dazu in Schritt 4).

Schritt 2. Fügen Sie ein Startprofil hinzu

Kopieren Sie das Snippet in Ihre pom.xml in <Profile>. Wenn der Abschnitt <Profile> in der POM-Datei fehlt, müssen Sie ihn erstellen. Nach der Aktivierung packt das Profil unsere Testklassen und alle Abhängigkeiten in den Ziel- / Upload-Ordner, der zum Hochladen in TestCloud bereit ist.

Build für Gradle-Benutzer

Schritt 1. Repository und Abhängigkeiten

Wir stellen sicher, dass in der Datei build.gradle im Projektstammordner das JCenter-Repository aktiviert ist:

 gradle allprojects { repositories { jcenter() } } 

Fügen Sie build.gradle im Anwendungsordner das folgende Snippet hinzu:

 gradle androidTestCompile('com.microsoft.appcenter:appium-test-extension:1.0') 

Ab Gradle 3.0 ist androidTestCompile veraltet . Stattdessen benötigen Sie androidTestImplementation.

Schritt 2. Automatisieren Sie die Generierung der POM- Datei

Damit der Uploader funktioniert, ist die Datei pom.xml erforderlich. Fügen Sie das folgende Snippet in build.gradle im Anwendungsordner hinzu, damit die POM-Datei automatisch erfasst wird:

 gradle apply plugin: 'maven' task createPom { pom { withXml { def dependenciesNode = asNode().appendNode('dependencies') //Iterate over the compile dependencies (we don't want the test ones), adding a <dependency> node for each configurations.testCompile.allDependencies.each { def dependencyNode = dependenciesNode.appendNode('dependency') dependencyNode.appendNode('groupId', it.group) dependencyNode.appendNode('artifactId', it.name) dependencyNode.appendNode('version', it.version) } def profilesNode = asNode().appendNode('profiles') profilesNode.append(new XmlParser().parse('https://raw.githubusercontent.com/Microsoft/AppCenter-Test-Appium-Java-Extensions/master/gradleuploadprofilesnippet.xml')) } }.writeTo("pom.xml") 

Teständerungen

Schritt 1. Importe hinzufügen

Importieren Sie Pakete in Ihre Testklassen:

 Java import com.microsoft.appcenter.appium.Factory; import com.microsoft.appcenter.appium.EnhancedAndroidDriver; import org.junit.rules.TestWatcher; import org.junit.Rule; 

Schritt 2. Erstellen Sie eine Instanz von TestWatcher

Zu jeder JUnit Rule-Testklasse (oder der Basistestklasse) hinzufügen:

 Java @Rule public TestWatcher watcher = Factory.createWatcher(); 

Schritt 3. Ändern Sie den Fahrertyp

Ändern Sie den Treibertyp, wenn er deklariert wird, entweder von AndroidDriver <MobileElement> in EnhancedAndroidDriver <MobileElement> oder von IOSDriver <MobileElement> in EnhancedIOSDriver <MobileElement>

 Java private static EnhancedAndroidDriver<MobileElement> driver; 

Schritt 4. Aktualisieren der Treiberinstanzen

Wir ändern die Treiberinstanzen so, dass die Zeilen des Formulars:

 Java driver = new AndroidDriver<MobileElement>(url, capabilities); 

... im Aussehen verändert:

 Java driver = Factory.createAndroidDriver(url, capabilities); 

Mit diesen Treibern können Sie weiterhin Tests ohne zusätzliche Änderungen lokal ausführen. Darüber hinaus können Sie den Schritten in einem ausführbaren Test mithilfe von driver.label ("Ihr Text") eine "Bezeichnung" hinzufügen. Der Text und der Screenshot vom Gerät sind im Testbericht in Test Cloud verfügbar. Es wird dringend empfohlen, dass Sie über die After- Methode auf das Etikett zugreifen, da dies dem Testbericht einen Screenshot des letzten Status der Anwendung hinzufügt.

Ein Screenshot wird auch dann erstellt, wenn der Test fehlschlägt. In der Regel sind genügend Informationen enthalten, um zu verstehen, warum dies passiert ist. Eine Beispielimplementierung in der After- Methode:

 Java: @After public void TearDown(){ driver.label("Stopping App"); driver.quit(); } 

In den App Center- Test herunterladen

Der Ladevorgang ist wie folgt:

1. Generieren Sie den App Center Test-Upload-Befehl. Dokumentation (DE) - Starten eines Testlaufs .
2. Wir packen Testklassen und alle Abhängigkeiten in den Ziel- / Upload-Ordner

Shell:

1. mvn -DskipTests -P Paket zum Vorbereiten des Uploads
2. Das Herunterladen und Ausführen von Tests wurde gestartet

Nach Abschluss können wir die Ergebnisse auf jedem Gerät aus der Liste anzeigen:

Bildschirme mit Ergebnissen, Protokollen, Bericht

Auf jedem iOS- oder Android-Gerät können Sie ein detailliertes Protokoll und einen Screenshot zur Diagnose eines Testabsturzes anzeigen:

Sowie Statistiken aller Starts über ein Zeitintervall:

Richtig, der Zugriff auf das "Gerät" zum Debuggen und Überprüfen wird nicht bereitgestellt. Wenn bei den Tests etwas schief geht und die Protokolle nicht ausreichen, wird alles nur durch Support entschieden. In einem der beliebten Dienste zum Starten von AT auf Geräten - BrowserStack - gibt es eine solche Möglichkeit, und sie ist in Appium integriert. Man könnte die URL und den Port angeben, um eine Verbindung zum Geräteserver herzustellen.

Schlussfolgerungen

Überraschenderweise wird der gesamte Release-Prozess von der kontinuierlichen Integration bis zur kontinuierlichen Bereitstellung der Anwendung an einem Ort bereitgestellt: Microsoft App Center bietet CI-Erstellung, Test, Bereitstellung zum Speichern, Analyse und Crashlytics.

Nachdem das Team weniger als die Hälfte der vorgeschlagenen Funktionalität ausprobiert hatte, machte es einen guten Eindruck. Aus den offensichtlichen Pluspunkten: Sie müssen nicht für jedes Gerät Unterstützung in Form von Code schreiben. Nun, andere Leckereien bitte:

• Sie müssen den Server nicht für eine Vielzahl von Geräten erhöhen.
• Es ist nicht erforderlich, 100500 Geräte an diesen Server anzuschließen.
• Keine Notwendigkeit, mit Android-Störungen zu leben, wenn es 24 \ 7 eingeschaltet ist.
• Sie müssen keinen Container für das Gerät zusammenstellen, diese Container müssen nicht verwaltet werden.
• Keine Notwendigkeit, begrenzte Emulatoren zu ertragen.

Das Microsoft App Center hat uns nach den anfänglichen Parametern geordnet: Es ist nicht sehr anspruchsvoll in Bezug auf die Integration, bietet jedoch alle erforderlichen Funktionen, wodurch die schwierige Unterstützung entfällt. Wir planen, den Service für das Projekt zu nutzen, da er die Aufgaben der Tools löst und gleichzeitig die Qualität sicherstellt.