Google se compromete a impulsar la igualdad racial para las comunidades afrodescendientes. Obtén información al respecto.
This page was translated by the Cloud Translation API.
Switch to English

Pruebas multidispositivo

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

Arquitectura

VTS utiliza el marco TradeFed para obtener y pasar las series del dispositivo a los módulos de prueba.

Figura 1. Serie de dispositivos de paso de VTS.

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

Asignación de dispositivos

La infraestructura de prueba (generalmente el programador de prueba) asigna los dispositivos disponibles que satisfacen los requisitos especificados en la configuración del plan de prueba al marco VTS. Los dispositivos asignados se reservan para el plan de prueba incluso si el módulo de prueba no los está utilizando. Los binarios del agente VTS se insertan y ejecutan en todos los dispositivos asignados (a menos que se indique específicamente que no se ejecuten). Esto asegura que las conexiones TCP para comandos de shell y HAL RPC estén disponibles para todos los dispositivos en un script de prueba.

Preparadores de exámenes

El marco ejecuta preparadores de pruebas para todos los dispositivos para los que recibió números de serie. Los preparadores de objetivos pueden ser de uno o varios dispositivos:

  • 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 de módulo).
    • Reciba solo una serie de dispositivo.
    • Ejecute tareas de preparación y limpieza en un dispositivo específico.
  • Preparadores de objetivos 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
    • Recibir todas las series de dispositivos
    • Ejecute tareas de preparación y limpieza para cada dispositivo o 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 / dispositivos. Se ejecuta un módulo de prueba de Python del lado del host para cada módulo de prueba de múltiples 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 están reservados para el plan de prueba, aunque un módulo de prueba en el plan solo usa un dispositivo.

Comunicación del dispositivo durante la prueba

Las pruebas efectivas de múltiples Android implican la comunicación entre dispositivos asignados. Al desarrollar tales pruebas, debe determinar cómo establecer la comunicación entre los dispositivos asignados. Las siguientes secciones proporcionan tres ejemplos de comunicación (sin embargo, los desarrolladores de pruebas pueden diseñar otros modelos).

Tipo 1: pruebas HAL del lado del host

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

Figura 2. Prueba HAL del lado del host.

En este escenario:

  • 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 utilizar agentes VTS en el dispositivo, una prueba del lado del host también puede enviar su propio agente (aplicación o binario) a cada dispositivo:

Figura 3. Prueba basada en agentes del lado del host.

En este escenario:

  • La lógica de prueba se ejecuta en el host.
  • La aplicación del agente (o binaria) se instala en cada dispositivo.
  • La secuencia de comandos de prueba del lado del host emite comandos a las aplicaciones en cada dispositivo.
  • El lado del host coordina las interacciones del dispositivo.

Por ejemplo, las pruebas de Next Billion User en el repositorio de VTS actual son pruebas de dispositivos múltiples, basadas en aplicaciones y del lado del host.

Tipo 3: pruebas HIDL del lado del objetivo

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

Figura 4. Prueba HIDL basada en objetivos.

En este escenario:

  • La lógica de prueba se ejecuta en dispositivos.
  • El marco del lado del host proporciona la identificación inicial del dispositivo.
  • El binario de prueba del lado objetivo requiere sincronización:
    • Misma prueba binaria para todos los dispositivos.
    • Diferentes binarios de prueba para cada rol.

Ejemplo: plan de prueba multidispositivo

Este ejemplo 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 preparadores de exámenes, consulte Preparadores de exámenes . Para obtener un ejemplo completo de varios dispositivos del lado del host, consulte el laboratorio de código 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')