Tests multi-appareils

VTS prend en charge 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 séries de périphériques.

Les exigences relatives aux appareils, telles que le nombre d'appareils 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 build Sailfish.

Attribution des appareils

L'infrastructure de test (généralement le planificateur de test) alloue au framework VTS les appareils disponibles qui satisfont aux exigences spécifiées dans la configuration du plan de test. 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 poussés et exécutés sur tous les appareils alloués (sauf indication contraire spécifique de ne pas s'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 tests pour tous les appareils pour lesquels il a reçu des numéros de série. Les préparateurs cibles peuvent être mono ou multi-appareils :

  • Préparateurs cibles à appareil unique (exemple sur VtsDeviceInfoCollector ) :
    • Peut être spécifié uniquement dans la configuration du plan de test avec la liste de périphériques requise (les versions futures permettront la configuration au niveau du module).
    • Recevez un seul numéro de série de périphérique.
    • Exécutez des tâches de préparation et de nettoyage sur un périphérique spécifique.
  • Préparateurs de cibles multi-périphériques (exemple sur VtsPythonVirtualenvPreparer ) :
    • Peut être spécifié dans la configuration du plan de test ou dans la configuration du module de test
    • Recevez toutes les séries d'appareils
    • Exécutez des tâches de préparation et de nettoyage pour chaque appareil ou pour tous les appareils.

Modules de tests

Les modules de test obtiennent une liste de périphériques une fois que les préparateurs de tests ont fini de configurer l'hôte/les périphériques. Un module de test Python côté hôte s'exécute pour chaque module de test multi-périphériques. 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 pendant les tests

Des tests multi-Android efficaces impliquent une communication entre les appareils attribués. Lors du développement 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 VTS HAL 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 vers les pilotes de chaque périphérique.
  • Le côté hôte coordonne les interactions avec les 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 envoyer son propre agent (application ou binaire) sur chaque appareil :

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

Dans ce scénario:

  • La logique de test s'exécute sur l'hôte.
  • L'application agent (ou binaire) 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 avec les appareils.

Par exemple, les tests Next Billion User dans le référentiel VTS actuel sont des tests multi-appareils côté hôte, basés sur des applications.

Type 3 : tests HIDL côté cible

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

Figure 4. Test HIDL basé sur la cible.

Dans ce scénario:

  • La logique de test s’exécute sur les appareils.
  • Le cadre côté hôte fournit une identification initiale du périphérique.
  • Le binaire de test côté cible nécessite une synchronisation :
    • Même binaire de test pour tous les appareils.
    • Différents binaires de test pour chaque rôle.

Exemple : plan de test multi-appareils

Cet exemple spécifie la configuration pour deux appareils :

  • Le périphérique 1 comprend un fournisseur de build et un préparateur cible VtsDeviceInfoCollector .
  • Le périphérique 2 comprend un préparateur FilePusher supplémentaire qui transmet un groupe de fichiers associés pilotés par l'hôte vers le périphérique.
<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 plus de détails et des exemples sur les préparateurs de tests, voir Préparateurs de tests . Pour un exemple complet multi-périphériques côté hôte, reportez-vous à 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')