Zuordnung testen

In diesem Artikel erhalten Sie eine kurze Einführung in die Testzuordnung und eine Erklärung dazu, wie Sie mit der Konfiguration von Tests im Android Open Source Project (AOSP) beginnen.

Testzuordnung

Die Testzuordnung ist ein Gerrit-basierter Ansatz, mit dem Entwickler Vorab- und Nachsende-Testregeln direkt im Android-Quellbaum erstellen und die Entscheidungen von zu testenden Branches und Geräten der Testinfrastruktur überlassen können. Testzuordnungsdefinitionen sind JSON-Dateien mit dem Namen TEST_MAPPING, die Sie in ein beliebiges Quellverzeichnis ablegen können.

Atest kann die TEST_MAPPING-Dateien verwenden, um Vorabtests in den zugehörigen Verzeichnissen auszuführen. Mit der Testzuordnung können Sie dieselben Tests mit nur minimalen Änderungen im Android-Quellbaum den Vorabüberprüfungen hinzufügen.

Hier einige Beispiele:

Für die Testzuordnung wird der Trade Federation (TF) Test Harness für die Ausführung von Tests und die Berichterstellung zu den Ergebnissen verwendet.

Testgruppen definieren

Testen Sie die Zuordnung von Tests mit einer Testgruppe. Der Name einer Testgruppe kann ein beliebiger String sein. presubmit kann beispielsweise der Name einer Gruppe von Tests sein, die bei der Validierung von Änderungen ausgeführt werden. Mit postsubmit können die Builds nach dem Zusammenführen von Änderungen validiert werden.

Regeln für das Paket-Build-Script

Damit der Trade Federation-Test-Harness Testmodule für einen bestimmten Build ausführen kann, müssen diese Module eine test_suites für Soong oder eine LOCAL_COMPATIBILITY_SUITE für Make für eine dieser beiden Suites haben:

  • general-tests ist für Tests gedacht, die nicht von gerätespezifischen Funktionen abhängen, z. B. von anbieterspezifischer Hardware, die die meisten Geräte nicht haben. Die meisten Tests sollten in der general-tests-Suite enthalten sein, auch wenn sie für ein bestimmtes ABI, eine bestimmte Bitanzahl oder Hardwarefunktionen wie HWASan spezifisch sind (für jedes ABI gibt es ein separates test_suites-Ziel) und auch wenn sie auf einem Gerät ausgeführt werden müssen.
  • device-tests ist für Tests gedacht, die von gerätespezifischen Funktionen abhängen. Normalerweise finden Sie diese Tests unter vendor/. Gerätespezifisch bezieht sich nur auf Funktionen, die es nur für ein Gerät gibt. Daher gilt dies sowohl für JUnit- als auch GTest-Tests (die normalerweise mit general-tests gekennzeichnet werden 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 er:

  • Es darf keinen Buildanbieter haben.
  • Nach dem Test muss eine Bereinigung erfolgen, z. B. durch Löschen aller temporären Dateien, die während des Tests erstellt wurden.
  • Die Systemeinstellungen müssen auf den Standardwert oder den ursprünglichen Wert zurückgesetzt werden.

  • Nicht davon ausgehen, dass sich ein Gerät in einem bestimmten Zustand befindet, z. B. „root-fähig“ Für die meisten Tests sind keine Root-Berechtigungen erforderlich. Wenn für einen Test Root erforderlich sein muss, sollte er dies mit RootTargetPreparer in seinem AndroidTest.xml angeben, wie im folgenden Beispiel:

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

Testzuordnungsdateien erstellen

Fügen Sie für das Verzeichnis, für das eine Testabdeckung erforderlich ist, eine TEST_MAPPING-JSON-Datei hinzu, die dem Beispiel ähnelt. Mit diesen Regeln wird sichergestellt, dass die Tests in den Vorabprüfungen ausgeführt werden, wenn Dateien in diesem Verzeichnis oder in einem seiner Unterverzeichnisse geändert werden.

Beispiel folgen

Hier ist eine Beispieldatei für TEST_MAPPING (im JSON-Format, aber mit Kommentaren):

{
  "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": "CtsDeqpTestCases",
      "options": [
        {
          // Use regex in include-filter which is supported in AndroidJUnitTest
          "include-filter": "dEQP-EGL.functional.color_clears.*"
        }
      ]
    }
  ],
  "imports": [
    {
      "path": "frameworks/base/services/core/java/com/android/server/am"
    }
  ]
}

Attribute festlegen

In diesem Beispiel sind presubmit und postsubmit die Namen der Testgruppen. Weitere Informationen zu Testgruppen finden Sie unter Testgruppen definieren.

Sie können den Namen des Testmoduls oder des Trade Federation-Integrationstests (Ressourcenpfad zur Test-XML-Datei, z. B. uiautomator/uiautomator-demo) im Wert des Attributs name festlegen. Für das Feld name können die Klasse name oder die Testmethode name nicht verwendet werden. Verwenden Sie Optionen wie include-filter, um die auszuführenden Tests einzugrenzen. Beispiel für die Verwendung von include-filter

Die host-Einstellung eines Tests gibt an, ob es sich um einen gerätelosen Test handelt, der auf dem Host ausgeführt wird. Der Standardwert ist false. Das 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 regulären Ausdrucksstrings festlegen, die mit dem relativen Pfad einer Quellcodedatei (relativ zum Verzeichnis mit der TEST_MAPPING-Datei) abgeglichen werden. Im Beispiel wird Test CtsWindowManagerDeviceTestCases im Presubmit-Verfahren nur ausgeführt, wenn eine Java-Datei mit Window oder Activity beginnt und sich im selben Verzeichnis wie die TEST_MAPPING-Datei oder in einem ihrer Unterverzeichnisse befindet. Die umgekehrten Schrägstriche (\) müssen mit Escapezeichen versehen werden, wie sie sich in einer JSON-Datei befinden.

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

Das Attribut options enthält zusätzliche Tradefed-Befehlszeilenoptionen.

Eine vollständige Liste der verfügbaren Optionen für einen bestimmten Test erhalten Sie mit folgendem Befehl:

tradefed.sh run commandAndExit [test_module] --help

Weitere Informationen zur Funktionsweise von Optionen finden Sie unter Optionen in Tradefed.

Tests mit Atest ausführen

So führen Sie die Testregeln vor dem Einreichen lokal aus:

  1. Rufen Sie das Verzeichnis auf, das die Datei TEST_MAPPING enthält.

  2. Führen Sie den folgenden Befehl aus:

    atest

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

Dies ist die einfachste Möglichkeit, Presubmit-Tests in TEST_MAPPING-Dateien im aktuellen Arbeitsverzeichnis und in übergeordneten Verzeichnissen auszuführen. Atest sucht die TEST_MAPPING-Datei im aktuellen Arbeitsverzeichnis und in allen übergeordneten Verzeichnissen und verwendet sie.

Quellcode strukturieren

In diesem Beispiel wird gezeigt, wie Sie TEST_MAPPING-Dateien im gesamten Quellbaum konfigurieren 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, B) ausgeführt:

atest --test-mapping src/project_1

Testregeln nach der Einreichung ausführen

Sie können diesen Befehl auch verwenden, um die in TEST_MAPPING in src_path (standardmäßig CWD) und deren übergeordneten Verzeichnissen definierten Postsubmit-Testregeln auszuführen:

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

Nur Tests ausführen, für die kein Gerät erforderlich ist

Mit der Option --host für Atest können Sie nur die Tests ausführen, die für den Host konfiguriert sind und für die kein Gerät erforderlich ist. Ohne diese Option führt Atest sowohl Tests aus, für die ein Gerät erforderlich ist, als auch solche, die auf einem Host ausgeführt werden, für den kein Gerät erforderlich ist. Die Tests werden in zwei separaten Suiten ausgeführt:

atest [--test-mapping] --host

Testgruppen identifizieren

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

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

atest --test-mapping src/project_1:all

Unterverzeichnisse einschließen

Wenn Sie mit Atest Tests in TEST_MAPPING ausführen, werden standardmäßig nur Presubmit-Tests ausgeführt, die in der TEST_MAPPING-Datei im aktuellen Arbeitsverzeichnis (oder im angegebenen Verzeichnis) und in den übergeordneten Verzeichnissen konfiguriert sind. Wenn Sie Tests in allen TEST_MAPPING-Dateien in den Unterverzeichnissen ausführen möchten, verwenden Sie die Option --include-subdir, um Atest zu zwingen, auch diese Tests einzubeziehen.

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 (A, B) aus.

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 ergänzen. ATest und die Trade Federation verarbeiten TEST_MAPPING vorab in ein gültiges JSON-Format ohne Kommentare. Um die JSON-Datei übersichtlich zu halten, wird nur der Formatkommentar // auf Zeilenebene unterstützt.

Beispiel:

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