Zuordnung testen

Dies ist eine kurze Einführung in die Testzuordnung und eine Erklärung, wie Sie ganz einfach Tests im Android Open Source Project (AOSP) konfigurieren können.

Testzuordnung

Die Testzuordnung ist ein Gerrit-basierter Ansatz, mit dem Entwickler Testregeln vor und nach dem Senden direkt im Android-Quellbaum erstellen und die Entscheidungen der zu testenden Branches und Geräte der Testinfrastruktur selbst überlassen können. Testzuordnungsdefinitionen sind JSON-Dateien mit dem Namen TEST_MAPPING, die in einem beliebigen Quellverzeichnis abgelegt werden können.

Atest kann die TEST_MAPPING-Dateien verwenden, um Tests vor dem Senden in den verknüpften Verzeichnissen auszuführen. Mit der Testzuordnung können Sie dieselben Tests hinzufügen, um Überprüfungen vorab mit einer einfachen Änderung in der Android-Quellstruktur zu senden.

Hier einige Beispiele:

Vorabübermittlungstests zu TEST_MAPPING für services.core hinzufügen

Vorabübermittlungstests zu TEST_MAPPING für Tools/Dexter mit Importen hinzufügen

Die Testzuordnung stützt sich für die Ausführung von Tests und die Meldung von Ergebnissen auf das Trade Federation (TF) Test Harness.

Testgruppen definieren

Testen Sie die Tests mit Zuordnungsgruppen über eine Testgruppe. Der Name einer Testgruppe kann ein beliebiger String sein. Beispielsweise kann presubmit für eine Gruppe von Tests verwendet werden, die beim Validieren von Änderungen ausgeführt werden. Außerdem können postsubmit-Tests verwendet werden, um die Builds nach dem Zusammenführen von Änderungen zu validieren.

Regeln für Paket-Build-Skript

Damit das Trade Federation Test Harness die Testmodule für die Testzuordnung für einen bestimmten Build ausführen kann, muss für diese Module test_suites für Soong oder LOCAL_COMPATIBILITY_SUITE für eine der folgenden beiden Suiten festgelegt sein:

• Allgemeine Tests: Tests, die nicht von gerätespezifischen Funktionen abhängen (z. B. anbieterspezifische Hardware, die die meisten Geräte nicht haben). Die meisten Tests sollten sich in der Suite für allgemeine Tests befinden, auch wenn sie sich speziell auf ein ABI, eine Bitness oder Hardwarefunktionen wie HWASan beziehen (es gibt ein separates „test_suites“-Ziel für jedes ABI) und selbst wenn sie auf einem Gerät ausgeführt werden müssen.
• Gerätetests: Tests, die von gerätespezifischen Funktionen abhängen. In der Regel finden Sie diese Tests unter vendor/. Da sich „gerätespezifisch“ nicht auf ABI- oder SoC-Funktionen von anderen Geräten bezieht, sondern nur auf Funktionen, die nur für ein Gerät gelten, gilt dies für JUnit-Tests genauso viel wie für native GTest-Tests (die normalerweise general-tests sein sollten, auch wenn sie ABI-spezifisch sind).

Beispiele:

Android.bp: test_suites: ["general-tests"],
Android.mk: LOCAL_COMPATIBILITY_SUITE := general-tests

Tests zur Ausführung in einer Testsuite konfigurieren

Damit ein Test in einer Testsuite ausgeführt werden kann, muss der Test:

• darf keinen Build-Anbieter haben.
• nach Abschluss des Tests bereinigen, z. B. durch Löschen temporärer Dateien, die während des Tests generiert wurden.
• Systemeinstellungen auf den Standardwert oder den ursprünglichen Wert zurücksetzen.
• sollte nicht davon ausgehen, dass ein Gerät in einem bestimmten Zustand, z.B. Root-fähig ist. Die meisten Tests erfordern keine Root-Berechtigung. Wenn für einen Test Root erforderlich sein muss, sollte dies wie im folgenden Beispiel mit einer RootTargetPreparer im AndroidTest.xml angegeben werden:

<target_preparer class="com.android.tradefed.targetprep.RootTargetPreparer"/>

Testzuordnungsdateien erstellen

Fügen Sie für das Verzeichnis, für das eine Testabdeckung erforderlich ist, einfach eine TEST_MAPPING-JSON-Datei nach dem folgenden Beispiel hinzu. Diese Regeln sorgen dafür, dass die Tests in Vorabprüfungen ausgeführt werden, wenn Dateien in diesem Verzeichnis oder in einem seiner Unterverzeichnisse bearbeitet werden.

Beispiel ansehen

Hier ist eine Beispieldatei TEST_MAPPING im JSON-Format, wobei Kommentare unterstützt werden:

{
  "presubmit": [
    // JUnit test with options and file patterns.
    {
      "name": "CtsWindowManagerDeviceTestCases",
      "options": [
        {
          "include-annotation": "android.platform.test.annotations.RequiresDevice"
        }
      ],
      "file_patterns": ["(/|^)Window[^/]*\\.java", "(/|^)Activity[^/]*\\.java"]
    },
    // Device-side GTest with options.
    {
      "name" : "hello_world_test",
      "options": [
        {
          "native-test-flag": "\"servicename1 servicename2\""
        },
        {
          "native-test-timeout": "6000"
        }
      ]
    }
    // Host-side GTest.
    {
      "name" : "net_test_avrcp",
      "host" : true
    }
  ],
  "postsubmit": [
    {
      "name": "CtsWindowManagerDeviceTestCases"
    }
  ],
  "imports": [
    {
      "path": "frameworks/base/services/core/java/com/android/server/am"
    }
  ]
}

Attribute festlegen

Im obigen Beispiel sind presubmit und postsubmit die Namen der einzelnen Testgruppen. Weitere Informationen über Testgruppen finden Sie unter Testgruppen definieren.

Der Name des Testmoduls oder der Name des Trade Federation-Integrationstests (Ressourcenpfad zur Test-XML-Datei, z.B. uiautomator/uiautomator-demo) kann im Wert des Attributs name festgelegt werden. Beachten Sie, dass das Feld name weder die Klasse name noch die Testmethode name verwenden kann. Wenn Sie die auszuführenden Tests eingrenzen möchten, können Sie hier Optionen wie include-filter verwenden. Weitere Informationen finden Sie unter Anwendungsbeispiel für Filter einschließen.

Die host-Einstellung eines Tests gibt an, ob es sich bei dem Test um einen gerätelosen Test handelt, der auf dem Host ausgeführt wird. Der Standardwert ist false, was bedeutet, dass für den Test ein Gerät erforderlich ist. Die unterstützten Testtypen sind HostGTest für GTest-Binärdateien und HostTest für JUnit-Tests.

Mit dem Attribut file_patterns können Sie eine Liste von Regex-Strings festlegen, um den relativen Pfad jeder Quellcodedatei (relativ zu dem Verzeichnis mit der Datei TEST_MAPPING) abgleichen zu können. Im obigen Beispiel wird der Test CtsWindowManagerDeviceTestCases in der Vorabübermittlung nur dann ausgeführt, wenn eine Java-Datei mit einem Fenster oder einer Aktivität beginnt, die sich im selben Verzeichnis der Datei TEST_MAPPING oder in einem ihrer Unterverzeichnisse befindet. Umgekehrte Schrägstriche (\) müssen wie in einer JSON-Datei mit Escapezeichen versehen werden.

Mit dem Attribut imports können Sie Tests in andere TEST_MAPPING-Dateien aufnehmen, ohne den Inhalt kopieren zu müssen. Beachten Sie, dass die TEST_MAPPING-Dateien in den übergeordneten Verzeichnissen des importierten Pfads ebenfalls enthalten sind. Die Testzuordnung ermöglicht verschachtelte Importe. Das bedeutet, dass sich zwei TEST_MAPPING-Dateien gegenseitig importieren und die Testzuordnung die enthaltenen Tests ordnungsgemäß zusammenführen kann.

Das Attribut options enthält zusätzliche Befehlszeilenoptionen von TradeFed.

Führen Sie folgenden Befehl aus, um eine vollständige Liste der verfügbaren Optionen für einen bestimmten Test zu erhalten:

tradefed.sh run commandAndExit [test_module] --help

Weitere Informationen zur Funktionsweise von Optionen finden Sie unter Umgang mit Trade-Fed-Optionen .

Tests mit Atest ausführen

So führen Sie die Testregeln für das Vorabsenden lokal aus:

1. Wechseln Sie zu dem Verzeichnis, das die Datei TEST_MAPPING enthält.
2. Führen Sie den folgenden Befehl aus:

atest

Alle Vorabübermittlungstests, die in den TEST_MAPPING-Dateien des aktuellen Verzeichnisses und seiner übergeordneten Verzeichnisse konfiguriert sind, werden ausgeführt. Atest sucht zwei Tests zum Vorabsenden (A und B) und führt sie aus.

Dies ist die einfachste Methode, um Vorabtests in TEST_MAPPING-Dateien im aktuellen Arbeitsverzeichnis (CWD) und in übergeordneten Verzeichnissen auszuführen. Atest sucht und verwendet die Datei TEST_MAPPING in CWD und allen übergeordneten Verzeichnissen.

Quellcode der Struktur

Das folgende Beispiel zeigt, wie TEST_MAPPING-Dateien in der Quellstruktur konfiguriert werden können.

src
├── project_1
│   └── TEST_MAPPING
├── project_2
│   └── TEST_MAPPING
└── TEST_MAPPING

Inhalt von src/TEST_MAPPING:

{
  "presubmit": [
    {
      "name": "A"
    }
  ]
}

Inhalt von src/project_1/TEST_MAPPING:

{
  "presubmit": [
    {
      "name": "B"
    }
  ],
  "postsubmit": [
    {
      "name": "C"
    }
  ],
  "other_group": [
    {
      "name": "X"
    }
  ]}

Inhalt von src/project_2/TEST_MAPPING:

{
  "presubmit": [
    {
      "name": "D"
    }
  ],
  "import": [
    {
      "path": "src/project_1"
    }
  ]}

Zielverzeichnisse angeben

Sie können ein Zielverzeichnis angeben, um Tests in TEST_MAPPING-Dateien in diesem Verzeichnis auszuführen. Mit dem folgenden Befehl werden zwei Tests (A und B) ausgeführt.

atest --test-mapping src/project_1

Postsubmit-Testregeln ausführen

Sie können diesen Befehl auch verwenden, um die in TEST_MAPPING in src_path (Standardeinstellung für CWD) und den zugehörigen übergeordneten Verzeichnissen definierten Nachsende-Testregeln auszuführen:

atest [--test-mapping] [src_path]:postsubmit

Nur Tests ausführen, die kein Gerät erfordern

Sie können die Option --host für Atest verwenden, um nur Tests auszuführen, die für den Host konfiguriert wurden, für den kein Gerät erforderlich ist. Ohne diese Option führt Atest beide Tests aus – sowohl die Tests, die ein Gerät erfordern, als auch die, die auf dem Host ausgeführt werden, ohne dass ein Gerät erforderlich ist. Die Tests werden in zwei separaten Suiten ausgeführt.

atest [--test-mapping] --host

Testgruppen identifizieren

Sie können Testgruppen im Atest-Befehl angeben. Mit dem folgenden Befehl werden alle postsubmit-Tests ausgeführt, die sich auf Dateien im Verzeichnis src/project_1 beziehen, das nur einen Test (C) enthält.

Sie können auch :all verwenden, um alle Tests unabhängig von der Gruppe auszuführen. Mit dem folgenden Befehl werden vier Tests (A, B, C, X) ausgeführt:

atest --test-mapping src/project_1:all

Unterverzeichnisse einschließen

Standardmäßig werden beim Ausführen von Tests in TEST_MAPPING mit Atest nur Tests vor dem Senden ausgeführt, die in der Datei TEST_MAPPING im CWD (oder im angegebenen Verzeichnis) und in dessen übergeordneten Verzeichnissen konfiguriert wurden. Wenn Sie Tests in allen TEST_MAPPING-Dateien in den Unterverzeichnissen ausführen möchten, verwenden Sie die Option --include-subdir, damit Atest diese Tests ebenfalls einschließt.

atest --include-subdir

Ohne die Option --include-subdir führt Atest nur Test A aus. Mit der Option --include-subdir führt Atest zwei Tests aus (A und B).

Kommentare auf Zeilenebene werden unterstützt

Sie können einen Kommentar im //-Format auf Zeilenebene hinzufügen, um die Datei TEST_MAPPING mit einer Beschreibung der folgenden Einstellung zu erweitern. ATest und Trade Federation werden TEST_MAPPING ohne Kommentare in einem gültigen JSON-Format vorverarbeiten. Damit die JSON-Datei sauber und einfach zu lesen ist, wird nur Kommentar im //-Format auf Zeilenebene unterstützt.

Beispiel:

{
  // For presubmit test group.
  "presubmit": [
    {
      // Run test on module A.
      "name": "A"
    }
  ]
}