Zuordnung testen

Dies ist eine kurze Einführung in die Testzuordnung und eine Erklärung, wie Sie mit der Konfiguration von Tests im Android Open Source Project (AOSP) begonnen.

Testzuordnung

Die Testzuordnung ist ein Gerrit-basierter Ansatz, mit dem Entwickler vorab direkt in der Android-Quellstruktur und Änderungen nach dem Senden Entscheidungen von Branches und Geräten, die getestet werden sollen. Testzuordnungsdefinitionen sind JSON-Dateien mit dem Namen TEST_MAPPING, die Sie in einem beliebigen Quellverzeichnis.

Atest kann mithilfe der TEST_MAPPING-Dateien Tests vor dem Senden im verknüpfte Verzeichnisse. Mit der Testzuordnung können Sie dieselben Tests „presubmit“ prüft mit einer minimalen Änderung in der Android-Quellstruktur.

Hier einige Beispiele:

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

Testgruppen definieren

Testen Sie die Zuordnung von Tests mit einer Testgruppe. Der Name einer Testgruppe kann eine beliebige Zeichenfolge. So kann z. B. presubmit der Name für eine Gruppe von Tests sein, beim Validieren von Änderungen ausgeführt. Mit postsubmit können Sie Ihre nach dem Zusammenführen der Änderungen.

Regeln für Paket-Build-Skript

Damit die Trade Federation zum Ausführen von Testmodulen für einen bestimmten Build benötigen, müssen diese test_suites festgelegt für Soong oder LOCAL_COMPATIBILITY_SUITE 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 sich in der general-tests-Suite befinden, auch wenn sie für bestimmte ABIs, Bitness- oder Hardwarefunktionen wie HWASan (es gibt ein separates test_suites-Ziel für jedes ABI), und selbst wenn es auf einem Gerät.
  • device-tests ist für Tests vorgesehen, die von gerätespezifischen Funktionen abhängen. In der Regel 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 Standardwert oder auf 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“ 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 ähnlich wie das Beispiel. Diese Regeln stellen sicher, dass die Tests „presubmit“ prüft, wenn Dateien in diesem Verzeichnis oder in einer der Unterverzeichnisse

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": "CtsWindowManagerDeviceTestCases"
    }
  ],
  "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 findest du unter Testgruppen definieren. zu Testgruppen.

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. Um die auszuführenden Tests einzugrenzen, Verwenden Sie Optionen wie include-filter. Weitere Informationen finden Sie unter (Verwendungsbeispiel für include-filter).

Die Einstellung „host“ eines Tests gibt an, ob es sich um einen Test ohne Geräte handelt ob sie auf dem Host läuft oder nicht. Der Standardwert ist false, was bedeutet, dass der 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 Test CtsWindowManagerDeviceTestCases wird nur dann in der Vorabübermittlung ausgeführt, wenn eine Java-Datei beginnt mit Window oder Activity, die sich im selben Verzeichnis wie der TEST_MAPPING-Datei oder in einem ihrer Unterverzeichnisse geändert wird. Umgekehrte Schrägstriche `` müssen maskiert werden, wie sie sich in einer JSON-Datei befinden.

Mit dem Attribut imports können Sie Tests in anderen TEST_MAPPING-Dateien einschließen ohne die Inhalte zu kopieren. Die TEST_MAPPING-Dateien in der übergeordneten Datei des importierten Pfads sind ebenfalls enthalten. Testzuordnung ermöglicht verschachtelte Importe zu erstellen. Das bedeutet, dass zwei TEST_MAPPING-Dateien sich gegenseitig importieren können und Testzuordnung die enthaltenen Tests zusammenführen.

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

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 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 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 der aktuellen Konfiguration konfiguriert wurden und seine übergeordneten Verzeichnisse ausgeführt werden. 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 der Struktur

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

Du kannst ein Zielverzeichnis angeben, um Tests in TEST_MAPPING-Dateien auszuführen. -Verzeichnis. Mit dem folgenden Befehl werden zwei Tests (A, B) ausgeführt:

atest --test-mapping src/project_1

Postsubmit-Testregeln ausführen

Sie können diesen Befehl auch verwenden, um die in den TEST_MAPPING in src_path (Standardeinstellung ist CWD) und in dessen übergeordneten Verzeichnissen:

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 die Tests auszuführen, die für die kein Gerät benötigen. Ohne diese Option führt Atest beide Tests aus, für solche, die ein Gerät benötigen, und solche, die auf dem Host ausgeführt werden. Die Tests werden in zwei separaten Suiten ausgeführt:

atest [--test-mapping] --host

Testgruppen identifizieren

Sie können Testgruppen im Atest-Befehl 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. Die folgenden werden vier Tests ausgeführt (A, B, C, X):

atest --test-mapping src/project_1:all

Unterverzeichnisse einschließen

Standardmäßig werden Tests in TEST_MAPPING mit Atest nur vor dem Senden ausgeführt Tests, die in der Datei TEST_MAPPING in CWD (oder eines angegebenen Verzeichnisses) und seiner übergeordneten Verzeichnisse. Wenn Sie Tests in allen TEST_MAPPING-Dateien in den Unterverzeichnissen befindet, verwenden Sie die Option --include-subdir, z. B. festlegen, dass Atest diese Tests ebenfalls einschließt.

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. Beibehalten Die JSON-Datei ist sauber, nur Kommentar im //-Format auf Zeilenebene wird unterstützt.

Beispiel:

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