Erweiterung benutzerdefinierter Testumgebungen in Device Farm

Im benutzerdefinierten Modus von Device Farm können Sie mehr als nur Ihre Testsuite ausführen. In diesem Abschnitt erfahren Sie, wie Sie Ihre Testsuite erweitern und Ihre Tests optimieren können.

Eine PIN festlegen

Bei einigen Anwendungen müssen Sie eine PIN auf dem Gerät festlegen. Device Farm unterstützt das native Einstellen einer PIN auf Geräten nicht. Dies ist jedoch mit den folgenden Einschränkungen möglich:

• Auf dem Gerät muss Android 8 oder höher ausgeführt werden.

• Die PIN muss nach Abschluss des Tests entfernt werden.

Um die PIN in Ihren Tests festzulegen, verwenden Sie die post_test Phasen pre_test und, um die PIN festzulegen und zu entfernen, wie im Folgenden gezeigt:

phases:
    pre_test:
      - # ... among your pre_test commands
      - DEVICE_PIN_CODE="1234"
      - adb shell locksettings set-pin "$DEVICE_PIN_CODE"
    post_test:
      - # ... Among your post_test commands
      - adb shell locksettings clear --old "$DEVICE_PIN_CODE"
    

Wenn Ihre Testsuite beginnt, ist die PIN 1234 festgelegt. Nach dem Beenden Ihrer Testsuite wird die PIN entfernt.

Warnung

Wenn Sie die PIN nach Abschluss des Tests nicht vom Gerät entfernen, werden das Gerät und Ihr Konto unter Quarantäne gestellt.

Beschleunigung von APPIUM-basierten Tests durch die gewünschten Funktionen

Wenn Sie Appium verwenden, stellen Sie möglicherweise fest, dass die Testsuite im Standardmodus sehr langsam ist. Dies liegt daran, dass Device Farm die Standardeinstellungen anwendet und keine Annahmen darüber trifft, wie Sie die Appium-Umgebung verwenden möchten. Diese Standardeinstellungen basieren zwar auf den bewährten Methoden der Branche, gelten jedoch möglicherweise nicht für Ihre Situation. Um die Parameter des Appium-Servers zu optimieren, können Sie die Standardfunktionen von Appium in Ihrer Testspezifikation anpassen. Im Folgenden wird beispielsweise die usePrebuildWDA Fähigkeit true in einer iOS-Testsuite auf festgelegt, um die anfängliche Startzeit zu beschleunigen:

phases:
  pre_test:
    - # ... Start up Appium
    - >-
    appium --log-timestamp
    --default-capabilities "{\"usePrebuiltWDA\": true, \"derivedDataPath\":\"$DEVICEFARM_WDA_DERIVED_DATA_PATH\",
    \"deviceName\": \"$DEVICEFARM_DEVICE_NAME\", \"platformName\":\"$DEVICEFARM_DEVICE_PLATFORM_NAME\", \"app\":\"$DEVICEFARM_APP_PATH\",
    \"automationName\":\"XCUITest\", \"udid\":\"$DEVICEFARM_DEVICE_UDID_FOR_APPIUM\", \"platformVersion\":\"$DEVICEFARM_DEVICE_OS_VERSION\"}"
    >> $DEVICEFARM_LOG_DIR/appiumlog.txt 2>&1 &
      
    

Bei Appium-Fähigkeiten muss es sich um eine JSON-Struktur mit Shell-Escape-Code in Anführungszeichen handeln.

Die folgenden Appium-Funktionen sind häufig Quellen für Leistungsverbesserungen:

noReset und fullReset

Diese beiden Funktionen, die sich gegenseitig ausschließen, beschreiben das Verhalten von Appium nach Abschluss jeder Sitzung. Wenn auf gesetzt noReset isttrue, entfernt der Appium-Server keine Daten aus Ihrer Anwendung, wenn eine Appium-Sitzung endet, und führt praktisch keine Bereinigung durch. fullResetdeinstalliert und löscht alle Anwendungsdaten vom Gerät, nachdem die Sitzung geschlossen wurde. Weitere Informationen finden Sie unter Reset-Strategien in der Appium-Dokumentation.

ignoreUnimportantViews(Nur Android)

Weist Appium an, die Hierarchie der Android-Benutzeroberfläche nur auf die für den Test relevanten Ansichten zu komprimieren, wodurch die Suche nach bestimmten Elementen beschleunigt wird. Dies kann jedoch einige XPath-basierte Testsuiten beschädigen, da die Hierarchie des UI-Layouts geändert wurde.

skipUnlock(Nur Android)

Informiert Appium darüber, dass derzeit kein PIN-Code festgelegt ist, was Tests nach einem Ausschalten des Bildschirms oder einem anderen Sperrenereignis beschleunigt.

webDriverAgentUrl(nur iOS)

Weist Appium an, davon auszugehen, dass eine wichtige iOS-Abhängigkeit,webDriverAgent, bereits läuft und für die Annahme von HTTP-Anfragen an der angegebenen URL verfügbar ist. Wenn Appium noch webDriverAgent nicht aktiv ist, kann es zu Beginn einer Testsuite einige Zeit dauern, bis Appium gestartet ist. webDriverAgent Wenn Sie webDriverAgent selbst starten und http://localhost:8100 beim Start von Appium webDriverAgentUrl auf einstellen, können Sie Ihre Testsuite schneller starten. Beachten Sie, dass diese Funktion niemals zusammen mit der useNewWDA Funktion verwendet werden sollte.

Sie können den folgenden Code verwenden, um mit Ihrer Testspezifikationsdatei am lokalen Port 8100 des Geräts zu beginnen webDriverAgent und sie dann an den lokalen Port des Testhosts weiterzuleiten 8100 (auf diese Weise können Sie den Wert auf setzen webDriverAgentUrlhttp://localhost:8100). Dieser Code sollte während der Installationsphase ausgeführt werden, nachdem der Code für die Einrichtung des Appium und der webDriverAgent Umgebungsvariablen definiert wurde:

      # Start WebDriverAgent and iProxy
      - >-
        xcodebuild test-without-building -project /usr/local/avm/versions/$APPIUM_VERSION/node_modules/appium/node_modules/appium-webdriveragent/WebDriverAgent.xcodeproj
        -scheme WebDriverAgentRunner -derivedDataPath $DEVICEFARM_WDA_DERIVED_DATA_PATH
        -destination id=$DEVICEFARM_DEVICE_UDID_FOR_APPIUM IPHONEOS_DEPLOYMENT_TARGET=$DEVICEFARM_DEVICE_OS_VERSION
        GCC_TREAT_WARNINGS_AS_ERRORS=0 COMPILER_INDEX_STORE_ENABLE=NO >> $DEVICEFARM_LOG_DIR/webdriveragent_log.txt 2>&1 &
        
        iproxy 8100 8100 >> $DEVICEFARM_LOG_DIR/iproxy_log.txt 2>&1 &

Anschließend können Sie Ihrer Testspezifikationsdatei den folgenden Code hinzufügen, um sicherzustellen, dass sie erfolgreich webDriverAgent gestartet wurde. Dieser Code sollte am Ende der Vortestphase ausgeführt werden, nachdem sichergestellt wurde, dass Appium erfolgreich gestartet wurde:

      # Wait for WebDriverAgent to start
      - >-
        start_wda_timeout=0;
        while [ true ];
        do
          if [ $start_wda_timeout -gt 60 ];
          then
              echo "WebDriverAgent server never started in 60 seconds.";
              exit 1;
          fi;
          grep -i "ServerURLHere" $DEVICEFARM_LOG_DIR/webdriveragent_log.txt >> /dev/null 2>&1;
          if [ $? -eq 0 ];
          then
              echo "WebDriverAgent REST http interface listener started";
              break;
          else
              echo "Waiting for WebDriverAgent server to start. Sleeping for 1 seconds";
              sleep 1;
              start_wda_timeout=$((start_wda_timeout+1));
          fi;
        done;

Weitere Informationen zu den Funktionen, die Appium unterstützt, finden Sie unter Appium Desired Capabilities in der Appium-Dokumentation.

Verwenden Sie Webhooks und andere APIs nach der Ausführung Ihrer Tests

Sie können Device Farm einen Webhook aufrufen lassen, nachdem die Verwendung curl jeder Testsuite abgeschlossen ist. Der dazu erforderliche Vorgang hängt vom Ziel und der Formatierung ab. Informationen zu Ihrem spezifischen Webhook finden Sie in der Dokumentation zu diesem Webhook. Im folgenden Beispiel wird jedes Mal, wenn eine Testsuite fertig ist, eine Nachricht an einen Slack-Webhook gesendet:

phases:
  post_test:
    - curl -X POST -H 'Content-type: application/json' --data '{"text":"Tests on '$DEVICEFARM_DEVICE_NAME' have finished!"}' https://hooks.slack.com/services/T00000000/B00000000/XXXXXXXXXXXXXXXXXXXXXXXX

Weitere Informationen zur Verwendung von Webhooks mit Slack findest du unter Deine erste Slack-Nachricht mit Webhook versenden in der Slack-API-Referenz.

Du bist nicht darauf beschränkt, Webhooks aufzurufen. curl Testpakete können zusätzliche Skripts und Tools enthalten, sofern sie mit der Device Farm Farm-Ausführungsumgebung kompatibel sind. Ihr Testpaket kann beispielsweise Hilfsskripten enthalten, die Anfragen an andere APIs stellen. Stellen Sie sicher, dass alle erforderlichen Pakete zusammen mit den Anforderungen Ihrer Testsuite installiert sind. Um ein Skript hinzuzufügen, das ausgeführt wird, nachdem Ihre Testsuite fertiggestellt ist, nehmen Sie das Skript in Ihr Testpaket auf und fügen Sie Ihrer Testspezifikation Folgendes hinzu:

phases:
  post_test:
    - python post_test.py

Anmerkung

Die Verwaltung aller API-Schlüssel oder anderer Authentifizierungstoken, die in Ihrem Testpaket verwendet werden, liegt in Ihrer Verantwortung. Wir empfehlen Ihnen, jegliche Form von Sicherheitsanmeldedaten außerhalb der Quellcodeverwaltung aufzubewahren, Anmeldeinformationen mit möglichst wenigen Rechten zu verwenden und wann immer möglich widerrufbare, kurzlebige Token zu verwenden. Informationen zur Überprüfung der Sicherheitsanforderungen finden Sie in der Dokumentation der von Ihnen verwendeten Drittanbieter-APIs.

Wenn Sie planen, AWS Dienste als Teil Ihrer Testausführungssuite zu verwenden, sollten Sie temporäre IAM-Anmeldeinformationen verwenden, die außerhalb Ihrer Testsuite generiert und in Ihrem Testpaket enthalten sind. Für diese Anmeldeinformationen sollten die wenigsten erteilten Berechtigungen und die kürzestmögliche Lebensdauer gelten. Weitere Informationen zum Erstellen temporärer Anmeldeinformationen finden Sie unter Temporäre Sicherheitsanmeldeinformationen anfordern im IAM-Benutzerhandbuch.

Zusätzliche Dateien zu Ihrem Testpaket hinzufügen

Möglicherweise möchten Sie zusätzliche Dateien als Teil Ihrer Tests verwenden, entweder als zusätzliche Konfigurationsdateien oder als zusätzliche Testdaten. Sie können diese zusätzlichen Dateien Ihrem Testpaket hinzufügen, bevor Sie es hochladenAWS Device Farm, und dann im benutzerdefinierten Umgebungsmodus darauf zugreifen. Grundsätzlich handelt es sich bei allen Uploadformaten für Testpakete (ZIP, IPA, APK, JAR usw.) um Paketarchivformate, die standardmäßige ZIP-Operationen unterstützen.

Sie können Ihrem Testarchiv Dateien hinzufügen, bevor Sie es hochladen, AWS Device Farm indem Sie den folgenden Befehl verwenden:

$ zip zip-with-dependencies.zip extra_file

Für ein Verzeichnis mit zusätzlichen Dateien:

$ zip -r zip-with-dependencies.zip extra_files/

Diese Befehle funktionieren erwartungsgemäß für alle Upload-Formate von Testpaketen mit Ausnahme von IPA-Dateien. Für IPA-Dateien, insbesondere wenn sie mit XCUITests verwendet werden, empfehlen wir, dass Sie alle zusätzlichen Dateien aufgrund der Art und Weise, wie AWS Device Farm iOS-Testpakete entworfen werden, an einem etwas anderen Speicherort ablegen. Beim Erstellen Ihres iOS-Tests befindet sich das Testanwendungsverzeichnis in einem anderen Verzeichnis namens Payload.

So könnte beispielsweise ein solches iOS-Testverzeichnis aussehen:

$ tree
.
└── Payload
    └── ADFiOSReferenceAppUITests-Runner.app
        ├── ADFiOSReferenceAppUITests-Runner
        ├── Frameworks
        │   ├── XCTAutomationSupport.framework
        │   │   ├── Info.plist
        │   │   ├── XCTAutomationSupport
        │   │   ├── _CodeSignature
        │   │   │   └── CodeResources
        │   │   └── version.plist
        │   └── XCTest.framework
        │       ├── Info.plist
        │       ├── XCTest
        │       ├── _CodeSignature
        │       │   └── CodeResources
        │       ├── en.lproj
        │       │   └── InfoPlist.strings
        │       └── version.plist
        ├── Info.plist
        ├── PkgInfo
        ├── PlugIns
        │   ├── ADFiOSReferenceAppUITests.xctest
        │   │   ├── ADFiOSReferenceAppUITests
        │   │   ├── Info.plist
        │   │   └── _CodeSignature
        │   │       └── CodeResources
        │   └── ADFiOSReferenceAppUITests.xctest.dSYM
        │       └── Contents
        │           ├── Info.plist
        │           └── Resources
        │               └── DWARF
        │                   └── ADFiOSReferenceAppUITests
        ├── _CodeSignature
        │   └── CodeResources
        └── embedded.mobileprovision

Fügen Sie für diese XCUITest-Pakete dem Verzeichnis, das auf .app endet, alle zusätzlichen Dateien innerhalb des Payload-Verzeichnisses hinzu. Die folgenden Befehle zeigen beispielsweise, wie Sie diesem Testpaket eine Datei hinzufügen können:

$ mv extra_file Payload/*.app/
$ zip -r my_xcui_tests.ipa Payload/

Wenn Sie Ihrem Testpaket eine Datei hinzufügen, können Sie AWS Device Farm je nach Upload-Format ein leicht unterschiedliches Interaktionsverhalten erwarten. Wenn für den Upload die ZIP-Dateierweiterung verwendet wurde, AWS Device Farm wird der Upload vor dem Test automatisch entpackt und die entpackten Dateien werden an dem Speicherort mit der Umgebungsvariablen $DEVICEFARM_TEST_PACKAGE_PATH belassen. (Das heißt, wenn Sie wie im ersten Beispiel eine Datei namens extra_file zum Stammverzeichnis des Archivs hinzufügen würden, würde sie sich während des Tests unter $DEVICEFARM_Test_Package_Path/extra_file befinden).

Um ein praktischeres Beispiel zu verwenden: Wenn Sie ein Appium TestNG-Benutzer sind und Ihrem Test eine Datei testng.xml hinzufügen möchten, können Sie sie mit dem folgenden Befehl in Ihr Archiv aufnehmen:

$ zip zip-with-dependencies.zip testng.xml

Anschließend können Sie Ihren Testbefehl im benutzerdefinierten Umgebungsmodus wie folgt ändern:

java -D appium.screenshots.dir=$DEVICEFARM_SCREENSHOT_PATH org.testng.TestNG -testjar *-tests.jar -d $DEVICEFARM_LOG_DIR/test-output $DEVICEFARM_TEST_PACKAGE_PATH/testng.xml

Wenn Ihre Upload-Erweiterung für das Testpaket nicht ZIP ist (z. B. APK-, IPA- oder JAR-Datei), befindet sich die hochgeladene Paketdatei selbst unter $DEVICEFARM_TEST_PACKAGE_PATH. Da es sich immer noch um Dateien im Archivformat handelt, können Sie die Datei entpacken, um von dort aus auf die zusätzlichen Dateien zuzugreifen. Mit dem folgenden Befehl wird beispielsweise der Inhalt des Testpakets (für APK-, IPA- oder JAR-Dateien) in das Verzeichnis /tmp entpackt:

unzip $DEVICEFARM_TEST_PACKAGE_PATH -d /tmp

Im Fall einer APK- oder JAR-Datei würden Sie feststellen, dass Ihre zusätzlichen Dateien in das Verzeichnis /tmp entpackt wurden (z. B. /tmp/extra_file). Im Fall einer IPA-Datei würden sich zusätzliche Dateien, wie bereits erläutert, an einem etwas anderen Ort innerhalb des Ordners befinden, der auf .app endet und sich innerhalb des Payload-Verzeichnisses befindet. Basierend auf dem obigen IPA-Beispiel würde sich die Datei beispielsweise im Verzeichnis /tmp/payload/ADFIOS ReferenceApp UITests-Runner.app/extra_file befinden (referenzierbar als /tmp/Payload/ *.app/extra_file).