Test-Mapping

Dies ist eine kurze Einführung in das Test-Mapping und eine Erläuterung, wie Sie mit dem einfachen Konfigurieren von Tests im Android Open Source Project (AOSP) beginnen können.

Was ist Test-Mapping?

Test Mapping ist ein Gerrit-basierter Ansatz, der es Entwicklern ermöglicht, Pre- und Post-Submit-Testregeln direkt im Android-Quellbaum zu erstellen und die Entscheidungen über zu testende Zweige und Geräte der Testinfrastruktur selbst zu überlassen. 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 Presubmit-Tests in den zugeordneten Verzeichnissen auszuführen. Mit Test-Mapping können Sie den gleichen Satz von Tests hinzufügen, um Prüfungen mit einer einfachen Änderung innerhalb der Android-Quellstruktur vorab einzureichen.

Siehe diese Beispiele:

Fügen Sie Presubmit-Tests zu TEST_MAPPING für services.core hinzu

Fügen Sie Presubmit-Tests zu TEST_MAPPING für Tools/Dexter hinzu, die Importe verwenden

Test Mapping stützt sich auf den Trade Federation (TF) Test Harness für die Testausführung und die Ergebnisberichterstattung.

Testgruppen definieren

Test-Mapping gruppiert Tests über eine Testgruppe . Der Name einer Testgruppe kann eine beliebige Zeichenfolge sein. Beispielsweise kann Presubmit für eine Gruppe von Tests verwendet werden, die beim Validieren von Änderungen ausgeführt werden. Und Postsubmit- Tests können verwendet werden, um die Builds zu validieren, nachdem die Änderungen zusammengeführt wurden.

Paketerstellungsskriptregeln

Damit der Trade Federation Test Harness die Testmodule von Test Mapping für einen bestimmten Build ausführen kann, muss für diese Module test_suite für Soong oder LOCAL_COMPATIBILITY_SUITE für Make auf eine dieser beiden Suiten festgelegt sein:

• General-Tests – Tests, die nicht von gerätespezifischer Funktionalität abhängen (z. B. herstellerspezifische Hardware, die die meisten Geräte nicht haben). Die meisten Tests sollten in der General-Tests-Suite enthalten sein, auch wenn sie spezifisch für eine ABI oder Bitanzahl oder Hardwarefunktionen wie HWAAn sind (es gibt ein separates test_suites-Ziel für jede ABI) und selbst wenn sie auf einem Gerät ausgeführt werden müssen.
• Gerätetests - Tests, die von gerätespezifischer Funktionalität abhängen. Typischerweise sind diese Tests unter vendor/ zu finden. Da sich „gerätespezifisch“ nicht auf ABI- oder SoC-Funktionen bezieht, die andere Geräte möglicherweise haben oder nicht haben, sondern nur auf Funktionen, die für ein Gerät einzigartig sind, gilt dies für JUnit-Tests genauso wie für native GTest-Tests (was normalerweise general-tests sein, auch wenn sie ABI-spezifisch sind).

Beispiele:

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

Konfigurieren von Tests zur Ausführung in einer Testsuite

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

• darf keinen Build-Provider haben.
• muss nach Abschluss des Tests aufgeräumt werden, indem beispielsweise alle temporären Dateien gelöscht werden, die während des Tests generiert wurden.
• Ändern Sie die Systemeinstellungen auf die Standard- oder Originalwerte.
• sollte ein Gerät nicht in einem bestimmten Zustand annehmen, z. B. root-bereit. Die meisten Tests erfordern keine Root-Rechte, um ausgeführt zu werden. Wenn ein Test Root erfordern muss, sollte er dies mit einem RootTargetPreparer in seiner AndroidTest.xml angeben, wie im folgenden Beispiel:

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

Erstellen von Test-Mapping-Dateien

Fügen Sie für das Verzeichnis, das eine Testabdeckung erfordert, einfach eine TEST_MAPPING-JSON-Datei hinzu, die dem folgenden Beispiel ähnelt. Diese Regeln stellen sicher, dass die Tests in Presubmit-Prüfungen ausgeführt werden, wenn Dateien in diesem Verzeichnis oder einem seiner Unterverzeichnisse berührt werden.

Nach einem Beispiel

Hier ist eine TEST_MAPPING -Beispieldatei (im JSON-Format, aber mit unterstützten 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": "CtsWindowManagerDeviceTestCases"
    }
  ],
  "imports": [
    {
      "path": "frameworks/base/services/core/java/com/android/server/am"
    }
  ]
}

Attribute setzen

Im obigen Beispiel sind presubmit und postsubmit die Namen jeder Testgruppe . Weitere Informationen zu Testgruppen finden Sie unter Definieren von Testgruppen.

Der Name des Testmoduls oder der Trade Federation-Integrationstestname (Ressourcenpfad zur Test-XML-Datei, z. B. uiautomator/uiautomator-demo ) kann im Wert des name festgelegt werden. Beachten Sie, dass das Namensfeld keinen name oder Testmethodennamen name darf. Um die auszuführenden Tests einzugrenzen, können Sie hier Optionen wie include-filter verwenden. Siehe ( Beispiel für die Verwendung des Include-Filters ).

Die Hosteinstellung eines Tests gibt an, ob der Test ein geräteloser Test ist, der auf dem Host ausgeführt wird oder nicht. Der Standardwert ist false , was bedeutet, dass für die Ausführung des Tests 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 für den Abgleich mit dem relativen Pfad einer beliebigen Quellcodedatei (relativ zu dem Verzeichnis, das die Datei TEST_MAPPING enthält) festlegen. Im obigen Beispiel wird der Test CtsWindowManagerDeviceTestCases nur dann im Presubmit ausgeführt, wenn eine Java-Datei, die mit Window oder Activity beginnt, die sich im selben Verzeichnis wie die TEST_MAPPING-Datei oder einem ihrer Unterverzeichnisse befindet, geändert wird. Backslashes \ müssen wie in einer JSON-Datei maskiert werden.

Mit dem Attribut imports können Sie Tests in andere TEST_MAPPING-Dateien einfügen, ohne den Inhalt zu kopieren. Beachten Sie, dass die TEST_MAPPING-Dateien in den übergeordneten Verzeichnissen des importierten Pfads ebenfalls eingeschlossen werden. Test-Mapping ermöglicht verschachtelte Importe; das bedeutet, dass zwei TEST_MAPPING-Dateien einander importieren können und Test Mapping die enthaltenen Tests ordnungsgemäß zusammenführen kann.

Das Optionsattribut enthält zusätzliche TradeFed -Befehlszeilenoptionen.

Um eine vollständige Liste der verfügbaren Optionen für einen bestimmten Test zu erhalten, führen Sie Folgendes aus:

tradefed.sh run commandAndExit [test_module] --help

Weitere Informationen zur Funktionsweise von Optionen finden Sie unter TradeFed Option Handling .

Laufende Tests mit Atest

So führen Sie die Presubmit-Testregeln lokal aus:

1. Wechseln Sie in das Verzeichnis, 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 wird zwei Tests für die Vorabübermittlung (A und B) lokalisieren und ausführen.

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

Quellcode strukturieren

Das folgende Beispiel zeigt, wie TEST_MAPPING-Dateien im Quellbaum 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. Der folgende Befehl führt zwei Tests aus (A, B).

atest --test-mapping src/project_1

Postsubmit-Testregeln werden ausgeführt

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

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 für den Host konfigurierte Tests auszuführen, die kein Gerät erfordern. Ohne diese Option führt Atest beide Tests aus, diejenigen, die ein Gerät erfordern, und diejenigen, die auf dem Host ausgeführt werden und kein Gerät erfordern. Die Tests werden in zwei getrennten Suiten durchgeführt.

atest [--test-mapping] --host

Testgruppen identifizieren

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

Oder Sie können :all verwenden, um alle Tests unabhängig von der Gruppe auszuführen. Der folgende Befehl führt vier Tests aus (A, B, C, X):

atest --test-mapping src/project_1:all

Inklusive Unterverzeichnisse

Standardmäßig werden beim Ausführen von Tests in TEST_MAPPING mit Atest nur Presubmit-Tests ausgeführt, die in der Datei TEST_MAPPING in CWD (oder einem bestimmten Verzeichnis) und seinen ü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, diese Tests ebenfalls einzuschließen.

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, 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 ergänzen. ATest und Trade Federation werden TEST_MAPPING ohne Kommentare in ein gültiges JSON-Format vorverarbeiten. Um die JSON-Datei sauber und leicht lesbar zu halten, werden nur Kommentare im // -Format auf Zeilenebene unterstützt.

Beispiel:

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