Test 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 des séries d'appareils aux modules de test.

Figure 1. VTS transmettant les périodiques des appareils.

Les exigences de l'appareil, 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 les périphériques disponibles qui satisfont aux exigences spécifiées dans la configuration du plan de test au cadre VTS. Les appareils alloués sont réservés pour le plan de test même si le module de test ne les utilise pas. Les binaires de l'agent VTS sont ensuite poussés vers et exécutés sur tous les périphériques alloués (sauf indication contraire 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 périphériques 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 de cibles peuvent être mono ou multi-appareils:

  • Préparateurs de cible à un seul appareil (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 appareil en série.
    • Exécutez les 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 dans la configuration du module de test
    • Recevoir toutes les séries d'appareils
    • Exécutez les tâches de préparation et de nettoyage pour chaque appareil ou tous les appareils.

Modules de test

Les modules de test obtiennent une liste des périphériques une fois que les préparateurs de test ont terminé la configuration de l'hôte / des périphériques. Un module de test Python côté hôte s'exécute pour chaque module de test multi-périphérique. 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 pour le plan de test, même si un module de test du plan n'utilise qu'un seul appareil.

Communication de l'appareil pendant le test

Des tests multi-Android efficaces impliquent une communication entre les appareils alloués. Lors du développement de tels tests, vous devez déterminer comment établir la communication entre les périphériques alloués. Les sections suivantes fournissent trois exemples de communication (cependant, les développeurs de tests sont 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 poussés vers les périphériques 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 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 pousser son propre agent (application ou binaire) sur chaque appareil:

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

Dans ce scénario:

  • La logique de test s'exécute sur l'hôte.
  • L'application d'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, lestests Next Billion User dans le référentiel 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-périphériques côté cible placent toute la logique de test sur des 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.
  • La structure côté hôte fournit l'identification initiale du périphérique.
  • Le binaire de test côté cible nécessite une synchronisation:
    • Même test binaire pour tous les appareils.
    • Différents binaires de test pour chaque rôle.

Exemple: plan de test multi-appareil

Cet exemple spécifie la configuration pour deux appareils:

  • Le périphérique 1 comprend un fournisseur de build et VtsDeviceInfoCollector préparateur de cible VtsDeviceInfoCollector .
  • Le périphérique 2 comprend un préparateur FilePusher supplémentaire qui pousse 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 de plusieurs périphériques côté hôte, reportez-vous au laboratoire de codes 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')