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 mithilfe der TEST_MAPPING-Dateien Tests vor dem Senden im verknüpfte Verzeichnisse. Mit der Testzuordnung können Sie dieselben Tests mit nur minimalen Änderungen im Android-Quellbaum den Vorabüberprüfungen hinzufügen.

Hier einige Beispiele:

Die Testzuordnung basiert auf dem Trade Federation (TF) Test-Harnisch für Testdurchführung und Ergebnisberichte.

Testgruppen definieren

Testen Sie die Zuordnungsgruppen mit einer Testgruppe. Der Name einer Testgruppe kann eine beliebige Zeichenfolge. presubmit kann beispielsweise der Name einer Gruppe von Tests sein, die bei der Validierung von Änderungen ausgeführt werden. Mit postsubmit können Sie Ihre nach dem Zusammenführen der Änderungen.

Regeln für das Paket-Build-Script

Damit die Trade Federation zum Ausführen von Testmodulen für einen bestimmten Build benötigen, test_suites ist für Song oder einen LOCAL_COMPATIBILITY_SUITE-Satz festgelegt für Make in eine der folgenden beiden Suiten:

  • general-tests ist für Tests gedacht, die nicht von gerätespezifischen (z. B. anbieterspezifische Hardware, die von den meisten Geräten 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 auf einem Gerät gibt. zu JUnit-Tests und GTest-Tests, die in der Regel als general-tests, 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.
  • Die Bereinigung muss nach Abschluss erfolgen, z. B. durch Löschen temporärer Dateien, die während des Tests generiert wurden.
  • Die Systemeinstellungen müssen auf den Standard- oder ursprünglichen Wert zurückgesetzt werden.

  • Nicht davon ausgehen, dass sich ein Gerät in einem bestimmten Zustand befindet, z. B. „root-fähig“ Die meisten Tests erfordern keine Root-Berechtigung. Wenn für einen Test Stammverzeichnis enthält, sollte es angeben, dass RootTargetPreparer in seiner AndroidTest.xml, 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 ansehen

Hier ist eine Beispieldatei TEST_MAPPING im JSON-Format, aber mit Kommentaren. unterstützt):

{
  "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

Im Beispiel sind presubmit und postsubmit die Namen der einzelnen Elemente. Testgruppe. Weitere Informationen zu Testgruppen finden Sie unter Testgruppen definieren.

Du kannst den Namen des Testmoduls oder des Gewerkschafts-Integrationstests name (Ressourcenpfad zur Test-XML-Datei, z. B. uiautomator/uiautomator-demo) im Wert des Attributs name. Beachten Sie, dass das Feld name Verwenden Sie die Klasse name oder die Testmethode name. Mit Optionen wie include-filter können Sie die auszuführenden Tests eingrenzen. Weitere Informationen finden Sie unter Verwendungsbeispiel für 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. Folgende Testtypen werden unterstützt: HostGTest für GTest-Binärprogramme und HostTest für JUnit Tests durchführen.

Mit dem Attribut file_patterns können Sie eine Liste mit Strings für reguläre Ausdrücke erstellen. zum Abgleich des relativen Pfads einer Quellcodedatei (relativ zum Verzeichnis mit der Datei TEST_MAPPING). 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 werden ebenfalls eingeschlossen. Mithilfe der Testzuordnung können verschachtelte Importe erfolgen. Das bedeutet, dass zwei TEST_MAPPING-Dateien ineinander importiert werden können und die enthaltenen Tests mithilfe der Testzuordnung zusammengeführt werden 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 finden Sie unter Umgang mit Optionen in Tradefed finden Sie weitere Informationen zur Funktionsweise der Optionen.

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 der übergeordneten Verzeichnisse konfiguriert sind, werden ausgeführt. Atest findet zwei Tests und führt sie aus zur Vorabübermittlung (A und B).

Dies ist die einfachste Methode, um Tests vor dem Senden in TEST_MAPPING auszuführen. im aktuellen Arbeitsverzeichnis (CWD) und in übergeordneten Verzeichnissen. Atest sucht und verwendet die Datei TEST_MAPPING in CWD und alle zugehörigen übergeordneten Elemente Verzeichnisse enthalten.

Quellcode strukturieren

Dieses Beispiel zeigt, wie Sie TEST_MAPPING-Dateien im gesamten Quellstruktur:

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

Postsubmit-Testregeln 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, die kein Gerät erfordern

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, für die ein Gerät benötigt wird, oder für Tests, die auf einem Host ausgeführt werden, für den kein . Die Tests werden in zwei separaten Suiten ausgeführt:

atest [--test-mapping] --host

Testgruppen identifizieren

Sie können Testgruppen im Befehl „Atest“ angeben. Der folgende Befehl wird ausgeführt: alle postsubmit-Tests, die sich auf Dateien im Verzeichnis src/project_1 beziehen, die enthält nur einen Test (C).

Alternativ können Sie :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

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 --include-subdir-Option 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 TEST_MAPPING zu vervollständigen mit einer Beschreibung der Einstellung. ATest und Handelsföderation Vorverarbeiten von TEST_MAPPING 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"
    }
  ]
}