Komplexe Testkonfiguration

Für einige Testmodule sind möglicherweise benutzerdefinierte Einrichtungs- und Deaktivierungsschritte erforderlich, die nicht im Testfall selbst ausgeführt werden können. Typische Beispiele:

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

In der Vergangenheit mussten Komponententeams in der Regel einen hostseitigen Test schreiben, um solche Aufgaben auszuführen. Das erfordert ein Verständnis des Trade Federation Harness und erhöht in der Regel die Komplexität eines Testmoduls.

Aus CTS haben wir das Konzept der Testmodulkonfiguration übernommen, um solche Aufgaben zu unterstützen. Die oben aufgeführten gängigen Aufgaben können mit nur wenigen Konfigurationszeilen erledigt werden. Für maximale Flexibilität können Sie sogar einen eigenen Zielvorbereitungs-Objekt-Typ implementieren, wie von ITargetPreparer oder ITargetCleaner definiert, und ihn für die Verwendung in Ihrer eigenen Testmodulkonfiguration konfigurieren.

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

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.

Wenn Sie die integrierte gemeinsame Modulkonfiguration verwenden möchten, fügen Sie im übergeordneten Ordner Ihres Testmoduls eine neue Datei „AndroidTest.xml“ hinzu und füllen Sie sie mit dem folgenden Inhalt aus:

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

Beispielsweise können wir die folgenden Options-Tags hinzufügen (im Kommentar „insert“ oben):

    <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. Bevor das Testmodul aufgerufen wird, auf dem Gerät den Shell-Befehl „settings put secure accessibility_enabled 1“ ausführen
  2. Nach Abschluss des Testmoduls den Shell-Befehl „settings put secure“ ausführen accessibility_enabled 0”

In diesem Beispiel wird die Barrierefreiheit vor bzw. nach der Ausführung des Testmoduls aktiviert bzw. deaktiviert. Nachdem wir ein einfaches Beispiel gezeigt haben, müssen wir uns nun genauer mit der Verwendung des „option“-Tags befassen. Wie oben gezeigt, kann das Tag zwei Attribute haben: „name“ und „value“. Das Attribut „name“ muss sich auf eine der vom Ersteller angebotenen Optionen beziehen.

Der genaue Zweck des Wertfelds hängt davon ab, wie der Ersteller die Option definiert hat: Es kann sich um einen String, eine Zahl, einen booleschen Wert oder sogar um einen Dateipfad handeln. Hier ist eine Zusammenfassung der drei gängigen Bereitschaftskräfte:

  • class name: PushFilePreparer

    • Kurzname: push-file
    • Funktion: verschiebt beliebige Dateien im Ordner des Testlaufs in Ziel auf dem Gerät
    • notes:
      • Dieser Converter kann von Ordner zu Ordner oder von Datei zu Datei übertragen. Das bedeutet, dass Sie eine Datei nicht in einen Ordner auf dem Gerät übertragen können: Sie müssen auch den Zieldateinamen unter diesem Ordner angeben.
    • Optionen:
      • push-file: Eine Push-Spezifikation, die die lokale Datei für den Pfad angibt, unter dem sie auf das Gerät gepusht werden soll. Kann wiederholt werden. Falls mehrere Dateien sind so konfiguriert, dass sie an denselben Remote-Pfad gesendet werden, den 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: Befehl, der auf dem Gerät (mit adb shell <your command>) ausgeführt wird, nachdem alle Pushes versucht wurden. Ein typischer Anwendungsfall wäre die Verwendung von chmod für Berechtigungen.

  • Klassenname: InstallApkSetup

    • Kurzname:install-apk
    • Funktion:verschiebt beliebige APK-Dateien in das Ziel bei Gerät
    • options:
      • 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, einschließlich Bindestrich am Anfang, 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:
      • run-command: Zu ausführender adb-Shell-Befehl. Kann wiederholt werden
      • teardown-command: adb-Shell-Befehl, der während der Deaktivierungsphase ausgeführt werden soll. Kann wiederholt werden

Testklasse

Eine Testklasse ist die Trade Federation-Klasse, 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
    • function: Ein Test, bei dem ein natives Testpaket auf einem bestimmten Gerät ausgeführt wird.
    • options:
      • native-test-device-path: Der Pfad auf dem Gerät, unter dem sich native Tests befinden.

  • Klassenname: InstrumentationTest

    • Kurzname:Instrumentierung
    • Funktion:Ein Test, der ein Instrumentierungstestpaket auf einem bestimmten Gerät ausführt
    • options:
      • 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.