Pruebas multidispositivo

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

Arquitectura

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

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

Los requisitos del dispositivo, como la cantidad y los tipos de dispositivos, se especifican en la configuración del plan de pruebas. Por ejemplo, puedes especificar un plan de pruebas que requiera dos dispositivos Android con objetivos 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 pruebas. Los dispositivos asignados se reservan para el plan de pruebas, 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 multidispositivo:

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

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 lado del host para cada módulo de prueba multidispositivo. 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 pruebas, aunque un módulo de prueba en el plan solo use un dispositivo.

Comunicación con el dispositivo durante las pruebas

Las pruebas efectivas de varios dispositivos Android implican la comunicación entre los dispositivos asignados. Cuando desarrolles este tipo de 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 lado del host

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

Figura 2: Prueba de HAL del lado del host

En esta situación, sucede lo siguiente:

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

Tipo 2: Pruebas basadas en agentes del lado del host

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

Figura 3: Prueba basada en agentes del lado del host

En esta situación, sucede 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 lado del host emite comandos a las apps de cada dispositivo.
  • El lado del host coordina las interacciones del dispositivo.

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

Tipo 3: Pruebas de HIDL del lado del destino

Las pruebas de HIDL multidispositivo del lado del destino colocan toda la lógica de prueba en objetos binarios de prueba integrados en el 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 esta situación, sucede lo siguiente:

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

Ejemplo: Plan de pruebas multidispositivo

En este ejemplo, se especifica la configuración para 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 controlados 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 lado del host

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