Einrichtung testen

Testsuite

Damit ein Test Teil von VTS ist, muss er in Android.bp über die folgende Einstellung verfügen.

test_suites: ["vts"],

Darüber hinaus ermöglicht das Hinzufügen des Tests zur Suite general-tests dass er Teil einer Test Mapping Suite ist, die bei Prüfungen vor der Übermittlung verwendet wird.

Testkonfiguration

In den meisten Fällen wird die Testkonfiguration, eine XML-Datei, die von Trade Federation zum Ausführen eines VTS-Tests verwendet wird, während des Builds automatisch generiert. Sie können die Testkonfiguration jedoch anpassen.

Erstellen Sie eine benutzerdefinierte Testkonfigurationsdatei

Das Erstellen einer neuen Test-XML-Datei von Grund auf kann kompliziert sein, da es erforderlich ist, die Funktionsweise des Testsystems und die Unterschiede zwischen den einzelnen Testläufern zu verstehen. Die automatisch generierte Testkonfigurationsdatei soll diesen Prozess vereinfachen.

Wenn Sie die Test-XML-Datei anpassen müssen, können Sie die automatisch generierte Datei als Ausgangspunkt verwenden.

Um die automatisch generierte Testkonfigurationsdatei zu finden, führen Sie zunächst den Befehl make aus, um die Konfiguration zu erstellen, wie unten gezeigt.

$ m VtsHalUsbV1_1TargetTest

In Ihrem Build-Out-Verzeichnis können Sie anhand des Modulnamens nach der Konfigurationsdatei suchen, wie unten gezeigt.

$ find out/ -name VtsHalUsbV1_1TargetTest.config

Es können mehrere Kopien der Datei vorhanden sein und Sie können jede davon verwenden. Kopieren Sie die .config Datei in das Verzeichnis, in dem sich die Android.bp Datei befindet.

Wenn die Android.bp Datei nur ein Testmodul enthält, können Sie die XML-Datei in AndroidTest.xml umbenennen. Das Build-System verwendet diese dann automatisch als Konfigurationsdatei des Testmoduls. Andernfalls fügen Sie dem Modul ein test_config Attribut hinzu, wie im folgenden Beispiel gezeigt.

test_config: "VtsHalUsbV1_1TargetTest.xml",

Jetzt verfügen Sie über eine Testkonfigurationsdatei, mit der Sie arbeiten und die Anpassung implementieren können.

Erzwingen Sie die Ausführung des Tests mit ADB-Root

Die meisten VTS-Tests erfordern zur Ausführung Root-Rechte. Wenn die Testkonfigurationsdatei automatisch generiert wird, können Sie Android.bp das folgende Attribut hinzufügen.

require_root: true,

Wenn die Testkonfigurationsdatei angepasst ist, fügen Sie Folgendes zur Test-XML-Datei hinzu.

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

Stoppen Sie das Framework während des Tests

Für die Ausführung vieler VTS-Tests ist kein Android-Framework erforderlich. Wenn Sie den Test bei angehaltenem Framework ausführen, kann der Test stabil ausgeführt werden, ohne dass Geräteflakes beeinträchtigt werden. Wenn die Testkonfigurationsdatei automatisch generiert wird, können Sie Android.bp das folgende Attribut hinzufügen.

disable_framework: true,

Wenn die Testkonfigurationsdatei angepasst ist, fügen Sie Folgendes zur Test-XML-Datei hinzu.

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

Fügen Sie zusätzliche Testargumente hinzu

Die Ausführung einiger gtest-Tests kann mehr Zeit in Anspruch nehmen. In solchen Fällen können Sie Test-Runner-Optionen in der XML-Datei hinzufügen.

Beispielsweise ermöglicht die Einstellung native-test-timeout im folgenden Eintrag, dass der Test mit einer Zeitüberschreitung von 3 Minuten statt der Standardzeit von 1 Minute ausgeführt wird.

   <test class="com.android.tradefed.testtype.GTest" >
       <option name="native-test-device-path" value="/data/local/tmp" />
       <option name="module-name" value="VtsHalNfcV1_0TargetTest" />
       <option name="native-test-timeout" value="180000"/>
   </test>

Mindest-API-Level erforderlich

Einige VTS-Tests können nur auf Geräten mit minimaler API-Ebene ausgeführt werden. Wenn die Testkonfigurationsdatei automatisch generiert wird, können Sie Android.bp das folgende Attribut hinzufügen.

test_min_api_level: 29,

Wenn die Testkonfigurationsdatei angepasst ist, fügen Sie den folgenden Befehl zur Test-XML-Datei hinzu.

   <object type="module_controller" class="com.android.tradefed.testtype.suite.module.MinApiLevelModuleController">
       <option name="min-api-level" value="29" />
   </object>

Android 12 definiert die Eigenschaften ro.board.first_api_level und ro.board.api_level , um die API-Ebene der Anbieterbilder auf diesen Geräten anzuzeigen. Durch die Kombination dieser Eigenschaften mit ro.product.first_api_level wählen Testsuiten geeignete Testfälle für die Geräte aus.

Android 13 definiert ro.vendor.api_level , das automatisch festgelegt wird, indem die erforderliche Anbieter-API-Ebene mithilfe der Eigenschaften ro.product.first_api_level , ro.board.first_api_level und ro.board.api_level berechnet wird.

ro.board.first_api_level

Die Eigenschaft ro.board.first_api_level ist die API-Ebene, wenn die Anbieter-Images für einen SoC erstmals mit dieser Eigenschaft veröffentlicht werden. Dies hängt nicht von der startenden API-Ebene des Geräts ab, sondern nur von der ersten API-Ebene des SoC, die diesen Wert definiert. Der Wert bleibt für die gesamte Lebensdauer des SoC bestehen.

Um ro.board.first_api_level festzulegen, können Gerätehersteller BOARD_SHIPPING_API_LEVEL in ihrer device.mk Datei definieren, wie im folgenden Beispiel gezeigt:

  # BOARD_SHIPPING_API_LEVEL sets ro.product.first_api_level to indicate
  # the first api level that the device has been commercially launched on.
  BOARD_SHIPPING_API_LEVEL := 23

Die Eigenschaft „ro.board.first_api_level“ wird automatisch für vendor/build.prop auf dem Gerät definiert. Die Eigenschaft wird vom init -Prozess des Anbieters festgelegt.

ro.board.api_level

Die Eigenschaft ro.board.api_level ist die aktuelle API-Ebene der Anbieter-Images für einen SoC. Wenn die API-Ebene des Anbieter-Images mit ro.board.first_api_level aktualisiert wird, muss das Gerät, das den SoC verwendet, die Eigenschaft ro.board.api_level mit der aktuellen API-Ebene des Anbieter-Images definieren, anstatt ro.board.first_api_level zu aktualisieren . Wenn diese Eigenschaft nicht festgelegt ist, wird standardmäßig ro.board.first_api_level verwendet.

Um ro.board.api_level festzulegen, definieren Sie BOARD_API_LEVEL in der Datei device.mk mit dem gewünschten Wert.

ro.vendor.api_level

Die Eigenschaft ro.vendor.api_level wurde in Android 13 eingeführt, um die API-Ebene anzuzeigen, die die Anbieterbilder unterstützen müssen. Dies wird automatisch auf das Minimum von ro.board.api_level (oder ro.board.first_api_level , wenn ro.board.api_level nicht definiert ist) und ro.product.first_api_level gesetzt. Tests zur Anbieterimplementierung, die ein Anbieter-Image-Upgrade erfordern, können durch Verweis auf diese Eigenschaft von den Anbieteranforderungen für das SoC ausgeschlossen werden.

Sharding-Prozess mit VTS

Für Android Version 10 oder höher können Sie den Sharding-Prozess auf mehreren Geräten durchführen, während Sie sowohl mit VTS- als auch mit CTS-on-GSI-Plänen testen, indem Sie die folgenden Anweisungen befolgen.

run vts --shard-count <number of devices> -s <device serial> ...

Dieser Befehl teilt den VTS-Plan in Shards auf und führt sie auf mehreren Geräten aus.

run cts-on-gsi --shard-count <number of devices> -s <device serial> -s ...

Dieser Befehl teilt den CTS-on-GSI-Plan in Shards auf und führt sie auf mehreren Geräten aus.

,

Testsuite

Damit ein Test Teil von VTS ist, muss er in Android.bp über die folgende Einstellung verfügen.

test_suites: ["vts"],

Darüber hinaus ermöglicht das Hinzufügen des Tests zur Suite general-tests dass er Teil einer Test Mapping Suite ist, die bei Prüfungen vor der Übermittlung verwendet wird.

Testkonfiguration

In den meisten Fällen wird die Testkonfiguration, eine XML-Datei, die von Trade Federation zum Ausführen eines VTS-Tests verwendet wird, während des Builds automatisch generiert. Sie können die Testkonfiguration jedoch anpassen.

Erstellen Sie eine benutzerdefinierte Testkonfigurationsdatei

Das Erstellen einer neuen Test-XML-Datei von Grund auf kann kompliziert sein, da es erforderlich ist, die Funktionsweise des Testsystems und die Unterschiede zwischen den einzelnen Testläufern zu verstehen. Die automatisch generierte Testkonfigurationsdatei soll diesen Prozess vereinfachen.

Wenn Sie die Test-XML-Datei anpassen müssen, können Sie die automatisch generierte Datei als Ausgangspunkt verwenden.

Um die automatisch generierte Testkonfigurationsdatei zu finden, führen Sie zunächst den Befehl make aus, um die Konfiguration zu erstellen, wie unten gezeigt.

$ m VtsHalUsbV1_1TargetTest

In Ihrem Build-Out-Verzeichnis können Sie anhand des Modulnamens nach der Konfigurationsdatei suchen, wie unten gezeigt.

$ find out/ -name VtsHalUsbV1_1TargetTest.config

Es können mehrere Kopien der Datei vorhanden sein und Sie können jede davon verwenden. Kopieren Sie die .config Datei in das Verzeichnis, in dem sich die Android.bp Datei befindet.

Wenn die Android.bp Datei nur ein Testmodul enthält, können Sie die XML-Datei in AndroidTest.xml umbenennen. Das Build-System verwendet diese dann automatisch als Konfigurationsdatei des Testmoduls. Andernfalls fügen Sie dem Modul ein test_config Attribut hinzu, wie im folgenden Beispiel gezeigt.

test_config: "VtsHalUsbV1_1TargetTest.xml",

Jetzt verfügen Sie über eine Testkonfigurationsdatei, mit der Sie arbeiten und die Anpassung implementieren können.

Erzwingen Sie die Ausführung des Tests mit ADB-Root

Die meisten VTS-Tests erfordern zur Ausführung Root-Rechte. Wenn die Testkonfigurationsdatei automatisch generiert wird, können Sie Android.bp das folgende Attribut hinzufügen.

require_root: true,

Wenn die Testkonfigurationsdatei angepasst ist, fügen Sie Folgendes zur Test-XML-Datei hinzu.

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

Stoppen Sie das Framework während des Tests

Für die Ausführung vieler VTS-Tests ist kein Android-Framework erforderlich. Wenn Sie den Test bei angehaltenem Framework ausführen, kann der Test stabil ausgeführt werden, ohne dass Geräteflakes beeinträchtigt werden. Wenn die Testkonfigurationsdatei automatisch generiert wird, können Sie Android.bp das folgende Attribut hinzufügen.

disable_framework: true,

Wenn die Testkonfigurationsdatei angepasst ist, fügen Sie Folgendes zur Test-XML-Datei hinzu.

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

Fügen Sie zusätzliche Testargumente hinzu

Die Ausführung einiger gtest-Tests kann mehr Zeit in Anspruch nehmen. In solchen Fällen können Sie Test-Runner-Optionen in der XML-Datei hinzufügen.

Beispielsweise ermöglicht die Einstellung native-test-timeout im folgenden Eintrag, dass der Test mit einer Zeitüberschreitung von 3 Minuten statt der Standardzeit von 1 Minute ausgeführt wird.

   <test class="com.android.tradefed.testtype.GTest" >
       <option name="native-test-device-path" value="/data/local/tmp" />
       <option name="module-name" value="VtsHalNfcV1_0TargetTest" />
       <option name="native-test-timeout" value="180000"/>
   </test>

Mindest-API-Level erforderlich

Einige VTS-Tests können nur auf Geräten mit minimaler API-Ebene ausgeführt werden. Wenn die Testkonfigurationsdatei automatisch generiert wird, können Sie Android.bp das folgende Attribut hinzufügen.

test_min_api_level: 29,

Wenn die Testkonfigurationsdatei angepasst ist, fügen Sie den folgenden Befehl zur Test-XML-Datei hinzu.

   <object type="module_controller" class="com.android.tradefed.testtype.suite.module.MinApiLevelModuleController">
       <option name="min-api-level" value="29" />
   </object>

Android 12 definiert die Eigenschaften ro.board.first_api_level und ro.board.api_level , um die API-Ebene der Anbieterbilder auf diesen Geräten anzuzeigen. Durch die Kombination dieser Eigenschaften mit ro.product.first_api_level wählen Testsuiten geeignete Testfälle für die Geräte aus.

Android 13 definiert ro.vendor.api_level , das automatisch festgelegt wird, indem die erforderliche Anbieter-API-Ebene mithilfe der Eigenschaften ro.product.first_api_level , ro.board.first_api_level und ro.board.api_level berechnet wird.

ro.board.first_api_level

Die Eigenschaft ro.board.first_api_level ist die API-Ebene, wenn die Anbieter-Images für einen SoC erstmals mit dieser Eigenschaft veröffentlicht werden. Dies hängt nicht von der startenden API-Ebene des Geräts ab, sondern nur von der ersten API-Ebene des SoC, die diesen Wert definiert. Der Wert bleibt für die gesamte Lebensdauer des SoC bestehen.

Um ro.board.first_api_level festzulegen, können Gerätehersteller BOARD_SHIPPING_API_LEVEL in ihrer device.mk Datei definieren, wie im folgenden Beispiel gezeigt:

  # BOARD_SHIPPING_API_LEVEL sets ro.product.first_api_level to indicate
  # the first api level that the device has been commercially launched on.
  BOARD_SHIPPING_API_LEVEL := 23

Die Eigenschaft „ro.board.first_api_level“ wird automatisch für vendor/build.prop auf dem Gerät definiert. Die Eigenschaft wird vom init -Prozess des Anbieters festgelegt.

ro.board.api_level

Die Eigenschaft ro.board.api_level ist die aktuelle API-Ebene der Anbieter-Images für einen SoC. Wenn die API-Ebene des Anbieter-Images mit ro.board.first_api_level aktualisiert wird, muss das Gerät, das den SoC verwendet, die Eigenschaft ro.board.api_level mit der aktuellen API-Ebene des Anbieter-Images definieren, anstatt ro.board.first_api_level zu aktualisieren . Wenn diese Eigenschaft nicht festgelegt ist, wird standardmäßig ro.board.first_api_level verwendet.

Um ro.board.api_level festzulegen, definieren Sie BOARD_API_LEVEL in der Datei device.mk mit dem gewünschten Wert.

ro.vendor.api_level

Die Eigenschaft ro.vendor.api_level wurde in Android 13 eingeführt, um die API-Ebene anzuzeigen, die die Anbieterbilder unterstützen müssen. Dies wird automatisch auf das Minimum von ro.board.api_level (oder ro.board.first_api_level , wenn ro.board.api_level nicht definiert ist) und ro.product.first_api_level gesetzt. Tests zur Anbieterimplementierung, die ein Anbieter-Image-Upgrade erfordern, können durch Verweis auf diese Eigenschaft von den Anbieteranforderungen für das SoC ausgeschlossen werden.

Sharding-Prozess mit VTS

Für Android Version 10 oder höher können Sie den Sharding-Prozess auf mehreren Geräten durchführen, während Sie sowohl mit VTS- als auch mit CTS-on-GSI-Plänen testen, indem Sie die folgenden Anweisungen befolgen.

run vts --shard-count <number of devices> -s <device serial> ...

Dieser Befehl teilt den VTS-Plan in Shards auf und führt sie auf mehreren Geräten aus.

run cts-on-gsi --shard-count <number of devices> -s <device serial> -s ...

Dieser Befehl teilt den CTS-on-GSI-Plan in Shards auf und führt sie auf mehreren Geräten aus.