Tests multi-appareils

VTS est compatible avec les tests qui nécessitent une interaction entre plusieurs appareils Android.

Architecture

VTS utilise le framework TradeFed pour obtenir et transmettre les numéros de série des appareils aux modules de test.

Figure 1. VTS transmettant les numéros de série des appareils

Les exigences concernant les appareils, telles que le nombre et les types d'appareils, sont spécifiées dans la configuration du plan de test. Par exemple, vous pouvez spécifier un plan de test qui nécessite deux appareils Android avec des cibles de compilation Sailfish.

Allocation d'appareils

L'infrastructure de test (généralement le planificateur de test) alloue les appareils disponibles qui répondent aux exigences spécifiées dans la configuration du plan de test au framework VTS. Les appareils alloués sont réservés au plan de test, même si le module de test ne les utilise pas. Les binaires de l'agent VTS sont ensuite transférés et exécutés sur tous les appareils alloués (sauf si vous êtes invité à ne pas les exécuter). Cela garantit que les connexions TCP pour les commandes shell et les RPC HAL sont disponibles pour tous les appareils dans un script de test.

Préparateurs de tests

Le framework exécute des préparateurs de test pour tous les appareils pour lesquels il a reçu des numéros de série. Les préparateurs cibles peuvent être sur un seul appareil ou sur plusieurs:

  • Préparateurs de cibles pour un seul appareil (exemple dans VtsDeviceInfoCollector) :
    • Ne peut être spécifié que dans la configuration du plan de test avec la liste des appareils requise (les futures versions permettront la configuration au niveau du module).
    • Ne recevez qu'un seul numéro de série d'appareil.
    • Exécutez des tâches de préparation et de nettoyage sur un appareil spécifique.
  • Préparateurs de cibles multi-appareils (exemple sur VtsPythonVirtualenvPreparer) :
    • Peut être spécifié dans la configuration du plan de test ou du module de test
    • Recevoir tous les numéros de série des appareils
    • Exécutez les tâches de préparation et de nettoyage pour chaque appareil ou pour tous les appareils.

Modules de test

Les modules de test obtiennent une liste d'appareils une fois que les préparateurs de test ont terminé de configurer l'hôte/les appareils. Un module de test Python côté hôte s'exécute pour chaque module de test multi-appareil. Les appareils Android alloués sont accessibles à partir des modules de test Python sous la forme d'une liste d'objets AndroidDevice:

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

Tous les appareils alloués sont réservés au plan de test, même si un module de test du plan n'utilise qu'un seul appareil.

Communication de l'appareil lors des tests

Les tests multi-Android efficaces impliquent la communication entre les appareils alloués. Lorsque vous développez de tels tests, vous devez déterminer comment établir la communication entre les appareils alloués. Les sections suivantes fournissent trois exemples de communication (les développeurs de tests sont toutefois libres de concevoir d'autres modèles).

Type 1: tests HAL côté hôte

Les tests HAL côté hôte peuvent utiliser les pilotes HAL VTS qui sont transmis aux appareils par défaut:

Figure 2. Test HAL côté hôte.

Dans ce scénario:

  • La logique de test s'exécute sur l'hôte.
  • Le script de test côté hôte émet des appels RPC aux pilotes de chaque appareil.
  • Le côté hôte coordonne les interactions des appareils.

Type 2: Tests basés sur des agents côté hôte

Au lieu d'utiliser des agents VTS sur l'appareil, un test côté hôte peut également transférer son propre agent (application ou binaire) vers chaque appareil:

Figure 3. Test côté hôte, basé sur un agent.

Dans ce scénario:

  • La logique de test s'exécute sur l'hôte.
  • L'application (ou le binaire) de l'agent s'installe sur chaque appareil.
  • Le script de test côté hôte envoie des commandes aux applications sur chaque appareil.
  • Le côté hôte coordonne les interactions des appareils.

Par exemple, les tests pour le milliard d'utilisateurs suivant dans le dépôt VTS actuel sont des tests multi-appareils côté hôte, basés sur l'application.

Type 3: Tests HIDL côté cible

Les tests HIDL multi-appareils côté cible placent toute la logique de test sur les binaires de test côté appareil, ce qui nécessite que les tests synchronisent les appareils pendant l'exécution des tests:

Figure 4. Test HIDL basé sur la cible.

Dans ce scénario:

  • La logique de test s'exécute sur les appareils.
  • Le framework côté hôte fournit une identification initiale de l'appareil.
  • Le binaire de test côté cible nécessite une synchronisation:
    • Même binaire de test pour tous les appareils.
    • Binaires de test différents pour chaque rôle.

Exemple: Plan de test multi-appareil

Cet exemple spécifie la configuration de deux appareils:

  • L'appareil 1 inclut un fournisseur de compilation et un préparateur de cible VtsDeviceInfoCollector.
  • L'appareil 2 inclut un préparateur FilePusher supplémentaire qui transfère un groupe de fichiers associés gérés par l'hôte sur l'appareil.
<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>

Exemple: Script de test Python côté hôte

Pour en savoir plus et obtenir des exemples sur les préparateurs de tests, consultez la section Préparateurs de tests. Pour obtenir un exemple multi-appareil complet côté hôte, consultez l'atelier de programmation 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')