Tests auf verschiedenen Geräten

VTS unterstützt Tests, die eine Interaktion zwischen mehreren Android-Geräten erfordern.

Architektur

VTS verwendet das TradeFed-Framework, um Geräteseriennummern abzurufen und an Testmodule zu übergeben.

Abbildung 1. Seriennummern von Geräten, die den VTS-Test bestehen.

Geräteanforderungen wie Anzahl der Geräte und Gerätetypen werden in der Testplankonfiguration angegeben. Sie können beispielsweise einen Testplan angeben, für den zwei Android-Geräte mit Sailfish-Build-Zielen erforderlich sind.

Gerätezuweisung

Die Testinfrastruktur (in der Regel der Test-Scheduler) weist dem VTS-Framework verfügbare Geräte zu, die die in der Testplan-Konfiguration angegebenen Anforderungen erfüllen. Zugewiesene Geräte sind für den Testplan reserviert, auch wenn das Testmodul sie nicht verwendet. VTS-Agent-Binärdateien werden dann auf alle zugewiesenen Geräte übertragen und dort ausgeführt, sofern nicht ausdrücklich anders angegeben. So wird sichergestellt, dass TCP-Verbindungen für Shell-Befehle und HAL-RPCs für alle Geräte in einem Testskript verfügbar sind.

Prüfungsvorbereitung

Das Framework führt Test-Preparer für alle Geräte aus, für die es Seriennummern erhalten hat. Zielvorbereiter können für ein einzelnes Gerät oder für verschiedene Geräte sein:

  • Vorbereiter für Einzelgeräte (Beispiel unter VtsDeviceInfoCollector):
    • Kann nur in der Testplan-Konfiguration mit der erforderlichen Geräteliste angegeben werden (in zukünftigen Versionen wird die Konfiguration auf Modulebene möglich sein).
    • Sie erhalten nur eine Geräteseriennummer.
    • Vorbereitungs- und Bereinigungsaufgaben auf einem bestimmten Gerät ausführen
  • Multi-Device-Target-Preparer (Beispiel unter VtsPythonVirtualenvPreparer):
    • Kann in der Testplan- oder Testmodulkonfiguration angegeben werden
    • Alle Geräteseriennummern erhalten
    • Führen Sie Vorbereitungs- und Bereinigungsaufgaben für jedes Gerät oder alle Geräte aus.

Module testen

Testmodule erhalten eine Liste von Geräten, nachdem die Testvorbereiter die Einrichtung des Hosts/der Geräte abgeschlossen haben. Für jedes Testmodul für verschiedene Geräte wird ein hostseitiges Python-Testmodul ausgeführt. Auf zugewiesene Android-Geräte kann über Python-Testmodule als Liste von AndroidDevice-Objekten zugegriffen werden:

devices = self.android_devices
device1 = devices[0]
device1_serial = device1.serial

Alle zugewiesenen Geräte sind für den Testplan reserviert, auch wenn in einem Testmodul im Plan nur ein Gerät verwendet wird.

Gerätekommunikation während des Tests

Für effektive Multi-Android-Tests ist die Kommunikation zwischen zugewiesenen Geräten erforderlich. Bei der Entwicklung solcher Tests müssen Sie festlegen, wie die Kommunikation zwischen den zugewiesenen Geräten erfolgen soll. In den folgenden Abschnitten finden Sie drei Kommunikationsbeispiele. Testentwickler können jedoch auch andere Modelle entwerfen.

Typ 1: Hostseitige HAL-Tests

Hostseitige HAL-Tests können VTS-HAL-Treiber verwenden, die standardmäßig auf Geräte übertragen werden:

Abbildung 2. Hostseitiger HAL-Test.

In diesem Szenario:

  • Die Testlogik wird auf dem Host ausgeführt.
  • Das hostseitige Testskript sendet RPC-Aufrufe an die Treiber auf jedem Gerät.
  • Die Hostseite koordiniert Geräteinteraktionen.

Typ 2: Hostseitige agentenbasierte Tests

Anstatt VTS-Agents auf dem Gerät zu verwenden, kann ein Host-seitiger Test auch einen eigenen Agent (App oder Binärdatei) auf jedes Gerät übertragen:

Abbildung 3. Hostseitiger, agentbasierter Test.

In diesem Szenario:

  • Die Testlogik wird auf dem Host ausgeführt.
  • Die Agent-App (oder das Binärprogramm) wird auf jedem Gerät installiert.
  • Das hostseitige Testskript sendet Befehle an Apps auf jedem Gerät.
  • Die Hostseite koordiniert Geräteinteraktionen.

Die Next Billion User-Tests im aktuellen VTS-Repository sind beispielsweise Host-seitige, App-basierte Tests auf mehreren Geräten.

Typ 3: HIDL-Tests auf der Zielseite

Bei HIDL-Tests für mehrere Geräte auf der Zielseite befindet sich die gesamte Testlogik in geräteseitigen Testbinärdateien. Daher müssen die Geräte während der Testausführung synchronisiert werden:

Abbildung 4. Zielbasierter HIDL-Test

In diesem Szenario:

  • Die Testlogik wird auf Geräten ausgeführt.
  • Das Host-seitige Framework bietet eine erste Geräteidentifizierung.
  • Für die Test-Binärdatei auf dem Zielgerät ist eine Synchronisierung erforderlich:
    • Dasselbe Test-Binärprogramm für alle Geräte.
    • Für jede Rolle sind unterschiedliche Testbinärdateien erforderlich.

Beispiel: Testplan für mehrere Geräte

In diesem Beispiel wird die Konfiguration für zwei Geräte angegeben:

  • Gerät 1 enthält einen Build-Anbieter und einen VtsDeviceInfoCollector-Zielvorbereiter.
  • Gerät 2 enthält einen zusätzlichen FilePusher-Vorbereiter, der eine Gruppe von hostgesteuerten zugehörigen Dateien auf das Gerät überträgt.
<configuration description="VTS Codelab Plan">
  ...
<device name="device1">
<build_provider class="com.android.compatibility.common.tradefed.build.CompatibilityBuildProvider" />
<target_preparer class="com.android.tradefed.targetprep.VtsDeviceInfoCollector" />
</device>
<device name="device2" >
<build_provider class="com.android.compatibility.common.tradefed.build.CompatibilityBuildProvider" />
<target_preparer class="com.android.tradefed.targetprep.VtsDeviceInfoCollector" />
<target_preparer class="com.android.compatibility.common.tradefed.targetprep.VtsFilePusher">
<option name="push-group" value="HostDrivenTest.push" />
</target_preparer>
</device>
<option name="compatibility:include-filter" value="VtsCodelabHelloWorldMultiDeviceTest" />
</configuration>

Beispiel: Hostseitiges Python-Testskript

Details und Beispiele zu Testvorbereitern finden Sie unter Testvorbereiter. Ein vollständiges Beispiel für die Hostseite mit mehreren Geräten finden Sie im Codelab „hello_world_multi“. 

def setUpClass(self):
logging.info('number of device: %s', self.android_devices)
asserts.assertEqual(len(self.android_devices), 2, 'number of device is wrong.')
self.dut1 = self.android_devices[0]
self.dut2 = self.android_devices[1]
self.shell1 = self.dut1.shell
self.shell2 = self.dut2.shell

def testSerialNotEqual(self):
'''Checks serial number from two device not being equal.'''
command = 'getprop | grep ro.serial'
res1 = self.shell1.Execute(command)
res2 = self.shell2.Execute(command)

def getSerialFromShellOutput(output):
'''Get serial from getprop query'''
return output[const.STDOUT][0].strip().split(' ')[-1][1:-1]
serial1 = getSerialFromShellOutput(res1)
serial2 = getSerialFromShellOutput(res2)

logging.info('Serial number of device 1 shell output: %s', serial1)
logging.info('Serial number of device 2 shell output: %s', serial2)
asserts.assertNotEqual(serial1, serial2, 'serials from two devices should not be the same')
asserts.assertEqual(serial1, self.dut1.serial, 'serial got from device system property is different from allocated serial')
asserts.assertEqual(serial2, self.dut2.serial, 'serial got from device system property is different from allocated serial')