Google setzt sich dafür ein, die Rassengerechtigkeit für schwarze Gemeinschaften zu fördern. Siehe wie.
Diese Seite wurde von der Cloud Translation API übersetzt.
Switch to English

Komplexe Testkonfiguration

Einige Testmodule erfordern möglicherweise angepasste Auf- und Abbauschritte, die nicht im Testfall selbst ausgeführt werden können. Typische Beispiele können sein:

  • installiere andere apks (zusätzlich zum test apk)
  • Schieben Sie einige Dateien auf das Gerät
  • Befehle ausführen (zB adb shell pm ...)

In der Vergangenheit haben Komponententeams normalerweise einen Host-seitigen Test geschrieben, um solche Aufgaben auszuführen. Dies erfordert ein Verständnis des Trade Federation-Kabelbaums und erhöht in der Regel die Komplexität eines Testmoduls.

In Anlehnung an CTS haben wir das Konzept der Testmodulkonfiguration eingeführt, um solche Aufgaben zu unterstützen. Die oben aufgeführte Liste der allgemeinen Aufgaben kann mit nur wenigen Konfigurationszeilen erreicht werden. Für maximale Flexibilität können Sie sogar Ihren eigenen Zielvorbereiter implementieren, wie von ITargetPreparer oder ITargetCleaner definiert , und diese für die Verwendung in Ihrer eigenen Testmodulkonfiguration konfigurieren.

Eine Testmodulkonfiguration für ein Testmodul ist eine erforderliche XML-Datei, die dem Quellordner des Moduls der obersten Ebene mit dem Namen "AndroidTest.xml" hinzugefügt wird. Das XML folgt dem Format einer Konfigurationsdatei, die vom Testautomatisierungs-Harness der Trade Federation verwendet wird. Derzeit sind die Haupt-Tags, die über die Testmodul-Konfigurationen verarbeitet werden, die Tags "target_preparer" und "test".

Zielvorbereiter

Ein "target_preparer" -Tag definiert, wie der Name schon sagt, einen Zielvorbereiter (siehe ITargetPreparer ), der eine Setup-Methode bietet, die aufgerufen wird, bevor das Testmodul zum Testen ausgeführt wird. Wenn die Klasse, auf die im Tag "target_preparer" verwiesen wird , auch ITargetCleaner implementiert, wird die Teardown-Methode nach Abschluss des Testmoduls aufgerufen.

Um die integrierte Konfiguration des allgemeinen Moduls zu verwenden, fügen Sie eine neue Datei 'AndroidTest.xml' im Ordner der obersten Ebene für Ihr Testmodul hinzu und füllen Sie sie mit folgendem Inhalt:

 <?xml version="1.0" encoding="utf-8"?>
<!-- [insert standard AOSP copyright here] -->
<configuration description="Test module config for Foo">
<!-- insert options here -->
</configuration>
 

Als Beispiel können wir die folgenden Options-Tags hinzufügen (im obigen Kommentar "Einfügen"):

     <target_preparer class="com.android.tradefed.targetprep.RunCommandTargetPreparer">
        <option name="run-command" value="settings put secure accessibility_enabled 1" />
        <option name="teardown-command" value="settings put secure accessibility_enabled 0" />
    </target_preparer>
 

Mit den Optionen wird der Testkabelbaum wie folgt konfiguriert:

  1. Führen Sie vor dem Aufrufen des Testmoduls den Shell-Befehl "Einstellungen setzen sichere Barrierefreiheit_aktiviert 1" auf dem Gerät aus
  2. Führen Sie nach Abschluss des Testmoduls den Shell-Befehl "settings put safe accessibility_enabled 0" aus.

In diesem speziellen Beispiel wird die Barrierefreiheit vor / nach der Ausführung des Testmoduls aktiviert / deaktiviert. Anhand eines einfachen Beispiels müssen weitere Details zur Verwendung des Options-Tags erläutert werden. Wie oben gezeigt, kann das Tag zwei Attribute haben: Name, Wert. Das Namensattribut gibt den Namen der Option an und ist weiter in zwei Teile unterteilt, die durch einen Doppelpunkt getrennt sind: Kurzname für den Ersteller und den tatsächlichen Optionsnamen, der vom Ersteller angeboten wird.

Der genaue Zweck des Wertefelds hängt davon ab, wie der Ersteller die Option definiert hat: Es kann sich um eine Zeichenfolge, eine Zahl, einen Booleschen Wert oder sogar um einen Dateipfad usw. handeln. Im obigen Beispiel bedeutet der Name "run-command: run-command" dass wir einen Wert für die Option "run-command" festlegen, die von einem Zielvorbereiter mit dem Kurznamen "run-command" definiert wurde; und der Name "Run-Befehl: Teardown-Befehl" bedeutet, dass wir den Wert für die Option "Teardown-Befehl" festlegen, die auch von demselben Zielvorbereiter mit dem Kurznamen "Run-Befehl" definiert wurde. Hier ist eine Zusammenfassung der drei gängigen Zielvorbereiter:

  • Klassenname: PushFilePreparer

    • Kurzname : Push-Datei
    • Funktion : Verschiebt beliebige Dateien im Testfallordner in das Ziel auf dem Gerät
    • Anmerkungen :
      • Dieser Ersteller kann von Ordner zu Ordner oder von Datei zu Datei pushen. Das heißt, Sie können eine Datei nicht unter einen Ordner auf dem Gerät verschieben. Sie müssen auch den Zieldateinamen unter diesem Ordner angeben
    • Optionen :
      • push: Eine Push-Spezifikation, formatiert als ' /path/to/srcfile.txt->/path/to/destfile.txt ' oder ' /path/to/srcfile.txt->/path/to/destdir/ '. Kann wiederholt werden Dieser Pfad kann relativ zum Testmodulverzeichnis oder zum out-Verzeichnis selbst sein.
      • ** Post-Push: ** Ein Befehl, der auf dem Gerät ausgeführt werden soll (mit ` adb shell <your command> `), nachdem alle Pushs versucht wurden. Ein typischer Anwendungsfall wäre die Verwendung von chmod für Berechtigungen
  • Klassenname: InstallApkSetup

    • Kurzname: install-apk
    • Funktion: Schiebt beliebige APK-Dateien unter in das Ziel auf dem Gerät
    • Optionen:
      • test-file-name: der name der apk, die auf dem gerät installiert werden soll.
      • install-arg: Zusätzliche Argumente, die an den Befehl pm install übergeben werden sollen, einschließlich des führenden Bindestrichs, z. B. "-d". Kann wiederholt werden
  • Klassenname: RunCommandTargetPreparer

    • Kurzname: Run-Befehl
    • Funktion: Führt beliebige Shell-Befehle vor oder nach der Ausführung des Testmoduls aus
    • Optionen:
      • run-command: Ausführender adb-Shell-Befehl. Kann wiederholt werden
      • Teardown-Befehl: Befehl adb shell, der während der Teardown-Phase ausgeführt wird. Kann wiederholt werden

Testklasse

Eine Testklasse ist die Trade Federation-Klasse, mit der der Test ausgeführt wird.

 <test class="com.android.tradefed.testtype.AndroidJUnitTest">
  <option name="package" value="android.test.example.helloworld"/>
  <option name="runner" value="android.support.test.runner.AndroidJUnitRunner"/>
</test>
 

Hier sind drei gängige Testklassen:

  • Klassenname: GTest

    • Kurzname: gtest
    • Funktion: Ein Test, der ein natives Testpaket auf einem bestimmten Gerät ausführt.
    • Optionen:
      • native-test-device-path: Der Pfad auf dem Gerät, auf dem sich native Tests befinden.
  • Klassenname: InstrumentationTest

    • Kurzname: Instrumentierung
    • Funktion: Ein Test, der ein Instrumententestpaket auf einem bestimmten Gerät ausführt
    • Optionen:
      • package: Der Manifest-Paketname der auszuführenden Android-Testanwendung.
      • Klasse: Der Name der Testklasse, die ausgeführt werden soll.
      • Methode: Der Name der auszuführenden Testmethode.
  • Klassenname: AndroidJUnitTest

    • Funktion: Ein Test, der ein Instrumentationstestpaket auf einem bestimmten Gerät mit android.support.test.runner.AndroidJUnitRunner ausführt. Dies ist die Hauptmethode zum Ausführen eines Instrumentationstests.