Pruebas multidispositivo

VTS admite pruebas que requieren interacción entre varios dispositivos Android.

Arquitectura

VTS usa el framework de TradeFed para obtener y pasar números de serie de dispositivos para probar módulos.

Figura 1: VTS pasa los números de serie de los dispositivos.

Los requisitos de los dispositivos, como la cantidad y los tipos de dispositivos, se especifican en la configuración del plan de prueba. Por ejemplo, puedes especificar un plan de prueba que requiera dos dispositivos Android con destinos de compilación de Sailfish.

Asignación de dispositivos

La infraestructura de prueba (por lo general, el programador de pruebas) asigna al framework de VTS los dispositivos disponibles que satisfacen los requisitos especificados en la configuración del plan de prueba. Los dispositivos asignados se reservan para el plan de prueba, incluso si el módulo de prueba no los usa. Luego, los objetos binarios del agente de VTS se envían a todos los dispositivos asignados y se ejecutan en ellos (a menos que se indique específicamente que no se ejecuten). Esto garantiza que las conexiones TCP para los comandos de shell y las RPC de HAL estén disponibles para todos los dispositivos en una secuencia de comandos de prueba.

Preparadores de pruebas

El framework ejecuta preparadores de pruebas para todos los dispositivos para los que recibió números de serie. Los preparadores de destino pueden ser de un solo dispositivo o de varios:

  • Preparadores de objetivos de un solo dispositivo (ejemplo en VtsDeviceInfoCollector):
    • Solo se puede especificar en la configuración del plan de prueba con la lista de dispositivos requerida (las versiones futuras permitirán la configuración a nivel del módulo).
    • Recibir solo un número de serie del dispositivo
    • Ejecuta tareas de preparación y limpieza en un dispositivo específico.
  • Preparadores de destino multidispositivo (ejemplo en VtsPythonVirtualenvPreparer):
    • Se puede especificar en la configuración del plan de prueba o en la configuración del módulo de prueba.
    • Cómo recibir todos los números de serie de los dispositivos
    • Ejecuta tareas de preparación y limpieza para cada dispositivo o para todos.

Módulos de prueba

Los módulos de prueba obtienen una lista de dispositivos después de que los preparadores de pruebas terminan de configurar el host o los dispositivos. Se ejecuta un módulo de prueba de Python del host para cada módulo de prueba de varios dispositivos. Se puede acceder a los dispositivos Android asignados desde los módulos de prueba de Python como una lista de objetos AndroidDevice:

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

Todos los dispositivos asignados se reservan para el plan de prueba, aunque un módulo de prueba del plan solo use un dispositivo.

Comunicación del dispositivo durante las pruebas

Las pruebas multi-Android eficaces implican la comunicación entre dispositivos asignados. Cuando desarrolles estas pruebas, debes determinar cómo establecer la comunicación entre los dispositivos asignados. En las siguientes secciones, se proporcionan tres ejemplos de comunicación (sin embargo, los desarrolladores de pruebas pueden diseñar otros modelos).

Tipo 1: Pruebas de HAL del host

Las pruebas de HAL del host pueden usar los controladores de HAL de VTS que se envían a los dispositivos de forma predeterminada:

Figura 2: Prueba de HAL del host.

En este caso, ocurre lo siguiente:

  • La lógica de prueba se ejecuta en el host.
  • La secuencia de comandos de prueba del host emite llamadas RPC a los controladores de cada dispositivo.
  • El host coordina las interacciones del dispositivo.

Tipo 2: Pruebas basadas en agentes del host

En lugar de usar agentes de VTS en el dispositivo, una prueba del host también puede enviar su propio agente (app o binario) a cada dispositivo:

Figura 3: Prueba basada en agentes del host.

En este caso, ocurre lo siguiente:

  • La lógica de prueba se ejecuta en el host.
  • La app del agente (o el objeto binario) se instala en cada dispositivo.
  • La secuencia de comandos de prueba del host envía comandos a las apps de cada dispositivo.
  • El host coordina las interacciones del dispositivo.

Por ejemplo, las pruebas de Next Billion User en el repositorio actual de VTS son pruebas multidispositivo basadas en apps y del host.

Tipo 3: Pruebas de HIDL del lado del destino

Las pruebas de HIDL multidispositivo del destino colocan toda la lógica de prueba en objetos binarios de prueba del dispositivo, lo que requiere que las pruebas sincronicen los dispositivos durante la ejecución de la prueba:

Figura 4: Prueba de HIDL basada en el destino.

En este caso, ocurre lo siguiente:

  • La lógica de prueba se ejecuta en los dispositivos.
  • El framework del host proporciona la identificación inicial del dispositivo.
  • El objeto binario de prueba del destino requiere sincronización:
    • Mismo binario de prueba para todos los dispositivos.
    • Objetos binarios de prueba diferentes para cada rol

Ejemplo: Plan de prueba multidispositivo

En este ejemplo, se especifica la configuración de dos dispositivos:

  • El dispositivo 1 incluye un proveedor de compilación y un preparador de destino VtsDeviceInfoCollector.
  • El dispositivo 2 incluye un preparador FilePusher adicional que envía un grupo de archivos relacionados dirigidos por el 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>

Ejemplo: Secuencia de comandos de prueba de Python del host

Para obtener detalles y ejemplos sobre los preparadores de pruebas, consulta Preparadores de pruebas. Para obtener un ejemplo completo de varios dispositivos del host, consulta el 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')