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 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 Zuordnungsgruppen mit einer Testgruppe. Der Name einer Testgruppe kann beliebig sein. 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 das Paket-Build-Script

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 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. 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.
  • 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.

  • Nicht davon ausgehen, dass sich ein Gerät in einem bestimmten Zustand befindet, z. B. „root-fähig“ 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 ä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 folgen

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 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. Siehe Beispiel für die Verwendung von 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 andere TEST_MAPPING-Dateien einfügen, ohne den Inhalt 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 zur Funktionsweise von Optionen finden Sie unter Optionen in Tradefed.

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 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 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 ausführen möchten, können Sie mit der Option --include-subdir Atest dazu zwingen, diese Tests ebenfalls 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 //-Formatkommentar auf Zeilenebene hinzufügen, um die TEST_MAPPING-Datei um eine Beschreibung der nachfolgenden Einstellung zu ergänzen. 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"
    }
  ]
}