Komplexe Testkonfiguration

Einige Testmodule erfordern möglicherweise eine benutzerdefinierte Einrichtung und Bereinigungsschritte, die nicht im Testlauf selbst durchgeführt werden. Typische Beispiele:

  • andere APK-Dateien installieren (zusätzlich zum Test-APK)
  • einige Dateien auf das Gerät übertragen
  • Befehle ausführen (z.B. adb shell pm ...)

In der Vergangenheit schreiben Komponententeams normalerweise einen Host-Side-Test, diese Aufgaben auszuführen, wofür ein Verständnis der Handelsföderation und erhöht in der Regel die Komplexität eines Testmoduls .

In Anlehnung an CTS haben wir das Konzept der Konfiguration von Testmodulen eingeführt, um diese Aufgaben können Sie die oben aufgeführten allgemeinen Aufgaben mit nur ein paar Zeilen config. Für maximale Flexibilität können Sie sogar Ihr eigenes Ziel Vorbereitende gemäß ITargetPreparer oder ITargetCleaner, und konfigurieren Sie diese so, dass sie in Ihrer eigenen Testmodulkonfiguration verwendet werden.

Eine Testmodulkonfiguration für ein Testmodul ist eine erforderliche XML-Datei, die oben hinzugefügt wird Level-Modul-Quellordner mit dem Namen „AndroidTest.xml“. Die XML-Datei hat das Format einer Konfigurationsdatei, die vom Trade Federation-Harnisch für die Testautomatisierung verwendet wird. Derzeit werden über die Konfigurationen des Testmoduls die Haupt-Tags „target_preparer“ und „Test“ Tags.

Zielvorbereitende

Ein „target_preparer“-Tag definiert, wie der Name schon sagt, einen Zielersteller. (siehe ITargetPreparer) , die eine Setup-Methode bietet, die vor der Ausführung des Testmoduls aufgerufen wird. zu Testzwecken dienen, Und wenn die Klasse, auf die im Tag „target_preparer“ verwiesen wird, ebenfalls implements ITargetCleaner Die Teardown-Methode wird nach Abschluss des Testmoduls aufgerufen.

Um die integrierte allgemeine Modulkonfiguration zu verwenden, fügen Sie eine neue Datei "AndroidTest.xml" unter für Ihr Testmodul auf oberster Ebene und füllen Sie 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 Kommentarbereich oben) angezeigt wird:

    <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 die Testumgebung für Folgendes konfiguriert:

  1. vor dem Aufrufen des Testmoduls den Shell-Befehl „settings put secure“ ausführen. accessibility_enabled 1" auf dem Gerät
  2. Nach Abschluss des Testmoduls den Shell-Befehl „settings put Secure“ ausführen accessibility_enabled 0”

In diesem speziellen Beispiel werden Bedienungshilfen vor und nach der Ausführung des Testmoduls. Anhand eines einfachen Beispiels wird gezeigt, um weitere Informationen zur Verwendung des Tags "option" zu erhalten. Wie oben gezeigt, kann das Tag zwei Attribute haben: Name, Wert. Das Attribut name muss sich auf eine der Optionen, die der Ersteller anbietet.

Der genaue Zweck des Wertfelds hängt davon ab, wie der Vortragende definiert hat die Option: Dies kann ein String, eine Zahl, ein boolescher Wert oder sogar ein Dateipfad sein. Hier ist eine Zusammenfassung der drei gängigen Bereitschaftskräfte:

  • Klassenname: PushFilePreparer

    • Kurzname: push-file
    • Funktion: verschiebt beliebige Dateien im Ordner des Testlaufs in Ziel auf dem Gerät
    • Hinweise: <ph type="x-smartling-placeholder">
        </ph>
      • kann dieser Vorbereitende Daten von Ordner in Ordner oder von Datei zu Datei übertragen. das können Sie keine Dateien in einen Ordner auf dem Gerät verschieben: Sie müssen geben Sie auch den Zieldateinamen unter diesem Ordner an.
    • Optionen: <ph type="x-smartling-placeholder">
        </ph>
      • push-file:Eine Push-Spezifikation, die die lokale Datei im Pfad angibt wo es auf dem Gerät platziert werden soll. Kann wiederholt werden. Falls mehrere Dateien so konfiguriert, dass sie an denselben Remote-Pfad gesendet werden, die letzte veröffentlicht wird.
      • push: (verworfen) Eine Push-Spezifikation, die wie folgt formatiert ist: „/path/to/srcfile.txt->/path/to/destfile.txt“ oder "/path/to/srcfile.txt->/path/to/destdir/". Kann wiederholt werden. Dieser Pfad kann relativ zum Verzeichnis des Testmoduls oder zum Out Verzeichnis selbst.
      • post-push:Ein Befehl, der auf dem Gerät (mit adb shell <your command>) ausgeführt wird, nachdem alle Push-Vorgänge versucht wurden. Typische Verwendung Fall mit chmod für Berechtigungen

  • Klassenname: InstallApkSetup

    • Kurzname:install-apk
    • Funktion:verschiebt beliebige APK-Dateien in das Ziel bei Gerät
    • Optionen: <ph type="x-smartling-placeholder">
        </ph>
      • test-file-name:der Name der APK-Datei, auf der die Datei installiert werden soll .
      • install-arg:Zusätzliche Argumente, die an die Installation von „pm“ übergeben werden sollen Befehl einschließlich vorangestelltem Bindestrich, z.B. „-d“. Kann wiederholt werden

  • Klassenname: RunCommandTargetPreparer

    • Kurzname:run-command
    • Funktion:Führt vor oder nach dem Test beliebige Shell-Befehle aus Modulausführung
    • Optionen: <ph type="x-smartling-placeholder">
        </ph>
      • run-command:adb-Shell-Befehl ausführen. Kann wiederholt werden
      • teardown-command:adb-Shell-Befehl, der während der Teardown-Phase ausgeführt wird. Kann wiederholt werden

Test-Kurs

Eine Testklasse ist die Handelsföderationsklasse, die zum Ausführen des Tests verwendet 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: <ph type="x-smartling-placeholder">
        </ph>
      • native-test-device-path:Pfad auf dem Gerät, auf dem sich die nativen Tests befinden.

  • Klassenname: InstrumentationTest

    • Kurzname:Instrumentierung
    • Funktion:Ein Test, der ein Instrumentierungstestpaket auf einem bestimmten Gerät ausführt
    • Optionen: <ph type="x-smartling-placeholder">
        </ph>
      • package: Der Name des Manifestpakets der Android-Testanwendung, die ausgeführt werden soll.
      • class:Der Name der Testklasse, die ausgeführt werden soll.
      • method:Der Name der Testmethode, die ausgeführt werden soll.

  • Klassenname: AndroidJUnitTest

    • Funktion:Ein Test, der ein Instrumentierungstestpaket für eine bestimmte android.support.test.runner.AndroidJUnitRunner Dies ist die Hauptmethode zum Ausführen eines Instrumentierungstests.