Pruebas multidispositivo

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

Arquitectura

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

Figura 1: Números de serie de dispositivos que superan la VTS.

Los requisitos del dispositivo, 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 pruebas 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 pruebas. Los dispositivos asignados se reservan para el plan de pruebas, incluso si el módulo de prueba no los usa. Luego, los archivos 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 exámenes

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

  • Preparadores de destino de un solo dispositivo (ejemplo en VtsDeviceInfoCollector):
    • Solo se puede 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).
    • Recibe solo un número de serie del dispositivo.
    • Ejecuta tareas de preparación y limpieza en un dispositivo específico.
  • Preparadores de destino para varios dispositivos (ejemplo en VtsPythonVirtualenvPreparer):
    • Se puede especificar en la configuración del plan de pruebas o en la configuración del módulo de pruebas.
    • Recibe todos los números de serie de los dispositivos
    • Ejecuta 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 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 pruebas, aunque un módulo de prueba del plan solo use un dispositivo.

Comunicación con el dispositivo durante las pruebas

Las pruebas efectivas en varios dispositivos Android implican la comunicación entre los 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 lado 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 lado 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 lado del host.

En este caso, ocurre lo siguiente:

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

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

Tipo 3: Pruebas de HIDL del lado del destino

Las pruebas de HIDL multidispositivo del destino colocan toda la lógica de prueba en los archivos 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 dispositivo de destino requiere sincronización:
    • El mismo archivo binario de prueba para todos los dispositivos.
    • Hay diferentes archivos binarios de prueba para cada rol.

Ejemplo: Plan de pruebas 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 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 de varios dispositivos 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')