Testzuordnung

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 Presubmit- und Postsubmit-Testregeln direkt im Android-Quellbaum erstellen und die Entscheidungen über zu testende Branches und Geräte 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 Zuordnungsgruppen mit einer Testgruppe. Der Name einer Testgruppe kann beliebig 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 nur für ein Gerät gelten. Dies gilt sowohl für JUnit- als auch für GTest-Tests, die in der Regel als 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 für die 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 Standard- oder ursprünglichen Wert zurückgesetzt werden.

  • Es darf nicht davon ausgegangen werden, dass sich ein Gerät in einem bestimmten Status befindet, z. B. dass es root-bereit ist. Für die meisten Tests sind keine Root-Berechtigungen erforderlich. Wenn für einen Test Root-Berechtigungen erforderlich sind, muss dies mit RootTargetPreparer in der AndroidTest.xml angegeben werden, 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 Presubmit-Prü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 den Namen des Trade Federation-Integrationstests (Ressourcenpfad zur Test-XML-Datei, z. B. uiautomator/uiautomator-demo) als Wert des Attributs name festlegen. Für das Feld name können die Klasse name oder die Testmethode name nicht verwendet werden. Mit Optionen wie include-filter können Sie die auszuführenden Tests eingrenzen. 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 in Escapezeichen gesetzt werden, da 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. Mit der Testzuordnung sind verschachtelte Importe möglich. Das bedeutet, dass zwei TEST_MAPPING-Dateien ineinander importiert werden können und die enthaltenen Tests mit der Testzuordnung zusammengeführt werden können.

Das options-Attribut 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 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 sucht nach zwei Tests für die Vorabüberprüfung (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

Mit diesem Befehl können Sie auch die in TEST_MAPPING definierten Testregeln nach der Einreichung in src_path (Standardeinstellung: aktuelles Arbeitsverzeichnis) und den übergeordneten Verzeichnissen ausfü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 ausgeführt, die sich auf Dateien im Verzeichnis src/project_1 beziehen, 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 //-Formatkommentar auf Zeilenebene hinzufügen, um die TEST_MAPPING-Datei um eine Beschreibung der nachfolgenden 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"
    }
  ]
}