Testzuordnung

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

Über Test-Mapping

Test Mapping ist ein Gerrit-basierter Ansatz, der es Entwicklern ermöglicht, Testregeln vor und nach der Übermittlung 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 jedem Quellverzeichnis abgelegt werden können.

Atest kann die TEST_MAPPING-Dateien verwenden, um Presubmit-Tests in den zugehörigen Verzeichnissen auszuführen. Mit der Testzuordnung können Sie mit einer einfachen Änderung im Android-Quellbaum dieselben Tests zu Presubmit-Prüfungen hinzufügen.

Sehen Sie sich diese Beispiele an:

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

Die Testzuordnung basiert auf dem Test Harness der Trade Federation (TF) für die Testausführung und Ergebnisberichterstattung.

Definieren Sie Testgruppen

Die Testzuordnung gruppiert Tests über eine Testgruppe . Der Name einer Testgruppe kann eine beliebige Zeichenfolge sein. Beispielsweise kann „Presubmit“ dafür sorgen, dass bei der Validierung von Änderungen eine Gruppe von Tests ausgeführt wird. Und Postsubmit- Tests können verwendet werden, um die Builds zu validieren, nachdem Änderungen zusammengeführt wurden.

Regeln für Paketerstellungsskripts

Damit das Trade Federation Test Harness die Testmodule der Testzuordnung 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:

  • allgemeine Tests – Tests, die nicht von gerätespezifischen Funktionen abhängen (z. B. herstellerspezifische Hardware, über die die meisten Geräte nicht verfügen). Die meisten Tests sollten in der General-Tests-Suite enthalten sein, auch wenn sie spezifisch für ein ABI oder Bitness oder Hardwarefunktionen wie HWASan sind (es gibt ein separates test_suites-Ziel für jedes ABI) und selbst wenn sie auf einem Gerät ausgeführt werden müssen.
  • Gerätetests – Tests, die von gerätespezifischen Funktionen 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, 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 der Fall sein sollte). sind general-tests auch wenn sie ABI-spezifisch sind).

Beispiele:

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

Konfigurieren Sie Tests zur Ausführung in einer Testsuite

Damit ein Test innerhalb einer Testsuite ausgeführt werden kann, gilt Folgendes:

  • darf keinen Build-Anbieter haben.
  • muss nach Abschluss bereinigt werden, indem beispielsweise alle während des Tests generierten temporären Dateien gelöscht werden.
  • Ändern Sie die Systemeinstellungen auf den Standard- oder Originalwert.
  • sollte nicht davon ausgehen, dass sich ein Gerät in einem bestimmten Zustand befindet, z. B. root-bereit. Für die Ausführung der meisten Tests sind keine Root-Rechte erforderlich. 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 Sie Test-Mapping-Dateien

Fügen Sie für das Verzeichnis, das eine Testabdeckung erfordert, einfach eine JSON-Datei TEST_MAPPING 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.

Folgen Sie einem Beispiel

Hier ist eine Beispieldatei TEST_MAPPING (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 festlegen

Im obigen Beispiel sind presubmit und postsubmit die Namen der einzelnen Testgruppen . 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 im Namensfeld kein name oder name verwendet werden kann. Um die auszuführenden Tests einzugrenzen, können Sie hier Optionen wie include-filter verwenden. Siehe ( Einschlussfilter-Beispielverwendung ).

Die Host- Einstellung eines Tests gibt an, ob es sich bei dem Test um einen gerätelosen Test handelt, 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-Zeichenfolgen festlegen, die dem relativen Pfad einer beliebigen Quellcodedatei entsprechen (relativ zum Verzeichnis, das die Datei TEST_MAPPING enthält). Im obigen Beispiel wird der Test CtsWindowManagerDeviceTestCases in „Presubmit“ nur ausgeführt, wenn eine Java-Datei, die mit „Window“ oder „Activity“ beginnt und im selben Verzeichnis der TEST_MAPPING-Datei oder einem ihrer Unterverzeichnisse vorhanden ist, geändert wird. Backslashes müssen mit Escapezeichen versehen werden, da sie in einer JSON-Datei vorkommen.

Mit dem Imports- Attribut können Sie Tests in andere TEST_MAPPING-Dateien einbinden, ohne den Inhalt zu kopieren. Beachten Sie, dass auch die TEST_MAPPING-Dateien in den übergeordneten Verzeichnissen des importierten Pfads einbezogen werden. Testmapping ermöglicht verschachtelte Importe; Dies 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 .

Führen Sie Tests mit Atest durch

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

  1. Gehen Sie in das Verzeichnis, das die Datei TEST_MAPPING enthält.
  2. Führen Sie den Befehl aus:
atest

Alle in den TEST_MAPPING-Dateien des aktuellen Verzeichnisses und seiner übergeordneten Verzeichnisse konfigurierten Presubmit-Tests werden ausgeführt. Atest sucht und führt zwei Tests zur Vorabeinreichung aus (A und B).

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

Quellcode strukturieren

Das folgende Beispiel zeigt, wie TEST_MAPPING-Dateien im gesamten 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 zum Ausführen von Tests in TEST_MAPPING-Dateien in diesem Verzeichnis angeben. Der folgende Befehl führt zwei Tests aus (A, B).

atest --test-mapping src/project_1

Führen Sie Postsubmit-Testregeln aus

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

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

Führen Sie nur Tests durch, die kein Gerät erfordern

Sie können die Option --host für Atest verwenden, um nur Tests auszuführen, die für den Host konfiguriert sind und 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 separaten Suiten durchgeführt.

atest [--test-mapping] --host

Identifizieren Sie Testgruppen

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

Unterverzeichnisse einschließen

Standardmäßig werden beim Ausführen von Tests in TEST_MAPPING mit Atest nur Presubmit-Tests ausgeführt, die in der TEST_MAPPING-Datei in CWD (oder einem angegebenen 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, auch diese Tests 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 (A, B) aus.

Kommentare auf Zeilenebene werden unterstützt

Sie können einen Kommentar // -Format auf Zeilenebene hinzufügen, um die Datei TEST_MAPPING mit einer Beschreibung der folgenden Einstellung zu ergänzen. ATest and Trade Federation verarbeitet TEST_MAPPING ohne Kommentare in ein gültiges JSON-Format vor. 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"
    }
  ]
}