Test multi-dispositivo

VTS supporta i test che richiedono l'interazione tra più dispositivi Android.

Architettura

VTS utilizza il framework TradeFed per ottenere e trasmettere i numeri di serie dei dispositivi ai moduli di test.

Figura 1. VTS passing device serials.

I requisiti dei dispositivi, come il numero di dispositivi e i tipi di dispositivi, sono specificati nella configurazione del piano di test. Ad esempio, puoi specificare un piano di test che richiede due dispositivi Android con target di build Sailfish.

Allocazione dei dispositivi

L'infrastruttura di test (di solito lo scheduler di test) alloca i dispositivi disponibili che soddisfano i requisiti specificati nella configurazione del piano di test al framework VTS. I dispositivi allocati sono riservati al piano di test anche se il modulo di test non li utilizza. I file binari dell'agente VTS vengono poi inviati ed eseguiti su tutti i dispositivi allocati (a meno che non sia stato specificato di non eseguirli). In questo modo, le connessioni TCP per i comandi shell e le RPC HAL sono disponibili per tutti i dispositivi in uno script di test.

Preparatori di test

Il framework esegue i preparatori dei test per tutti i dispositivi per i quali ha ricevuto i numeri di serie. I preparatori di target possono essere singoli o multi-dispositivo:

  • Preparatori di target per un singolo dispositivo (esempio in VtsDeviceInfoCollector):
    • Può essere specificato solo nella configurazione del piano di test con l'elenco dei dispositivi richiesti (le versioni future consentiranno la configurazione a livello di modulo).
    • Ricevi un solo numero di serie del dispositivo.
    • Esegui attività di preparazione e pulizia su un dispositivo specifico.
  • Preparatori di target multi-dispositivo (esempio in VtsPythonVirtualenvPreparer):
    • Può essere specificato nella configurazione del piano di test o nella configurazione del modulo di test
    • Ricevere tutti i numeri di serie dei dispositivi
    • Esegui le attività di preparazione e pulizia per ogni dispositivo o per tutti i dispositivi.

Moduli di test

I moduli di test ricevono un elenco di dispositivi dopo che i preparatori del test hanno terminato la configurazione dell'host/dei dispositivi. Per ogni modulo di test multi-dispositivo viene eseguito un modulo di test Python lato host. I dispositivi Android allocati sono accessibili dai moduli di test Python come elenco di oggetti AndroidDevice:

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

Tutti i dispositivi allocati sono riservati al piano di test, anche se un modulo di test nel piano utilizza un solo dispositivo.

Comunicazione del dispositivo durante il test

Test multi-Android efficaci prevedono la comunicazione tra i dispositivi allocati. Quando sviluppi questi test, devi determinare come stabilire la comunicazione tra i dispositivi allocati. Le sezioni seguenti forniscono tre esempi di comunicazione (tuttavia, gli sviluppatori dei test sono liberi di progettare altri modelli).

Tipo 1: test HAL lato host

I test HAL lato host possono utilizzare i driver HAL VTS che vengono inviati ai dispositivi per impostazione predefinita:

Figura 2. Test HAL lato host.

In questo scenario:

  • La logica di test viene eseguita sull'host.
  • Lo script di test lato host invia chiamate RPC ai driver su ogni dispositivo.
  • Il lato host coordina le interazioni con il dispositivo.

Tipo 2: test basati su agenti lato host

Anziché utilizzare agenti VTS sul dispositivo, un test lato host può anche eseguire il push del proprio agente (app o binario) su ciascun dispositivo:

Figura 3. Test basato sull'agente lato host.

In questo scenario:

  • La logica di test viene eseguita sull'host.
  • L'app (o il binario) dell'agente viene installata su ogni dispositivo.
  • Lo script di test lato host invia comandi alle app su ogni dispositivo.
  • Il lato host coordina le interazioni con il dispositivo.

Ad esempio, i test Next Billion User nel repository VTS attuale sono test lato host, basati su app e multi-dispositivo.

Tipo 3: test HIDL lato target

I test HIDL multidevice lato target inseriscono tutta la logica di test nei file binari di test lato dispositivo, il che richiede la sincronizzazione dei dispositivi durante l'esecuzione del test:

Figura 4. Test HIDL basato sul target.

In questo scenario:

  • La logica di test viene eseguita sui dispositivi.
  • Il framework lato host fornisce l'identificazione iniziale del dispositivo.
  • Il binario di test lato target richiede la sincronizzazione:
    • Lo stesso binario di test per tutti i dispositivi.
    • Binari di test diversi per ogni ruolo.

Esempio: piano di test su più dispositivi

Questo esempio specifica la configurazione per due dispositivi:

  • Il dispositivo 1 include un fornitore di build e VtsDeviceInfoCollector uno strumento di preparazione del target.
  • Il dispositivo 2 include un preparatore FilePusher aggiuntivo che trasferisce un gruppo di file correlati basati sull'host al dispositivo.
<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>

Esempio: script di test Python lato host

Per dettagli ed esempi sui preparatori di test, vedi Preparatori di test. Per un esempio completo di più dispositivi lato host, consulta il 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')