Resumen de la Federación de Comercio

Trade Federation (Tradefed o TF para abreviar) es un marco de prueba continuo diseñado para ejecutar pruebas en dispositivos Android. Por ejemplo, Tradefed se utiliza para ejecutar el conjunto de pruebas de compatibilidad (CTS) y el conjunto de pruebas de proveedores (VTS) .

Trade Federation es una aplicación Java que se ejecuta en una computadora host y se comunica con uno o más dispositivos Android usando ddmlib (la biblioteca detrás de DDMS) sobre adb.

A continuación, enumeramos algunas de las características principales de TF, junto con un par de ejemplos de casos de uso. Dicho esto, si desea ingresar directamente y comenzar, puede dirigirse directamente a la página Comenzar aquí .

Características

  • diseño modular, flexible y escalable
  • ha incorporado soporte para ejecutar muchos tipos diferentes de pruebas de Android: instrumentación , uiautomator , native/gtest, JUnit basado en host, etc.
  • proporciona mecanismos de confiabilidad y recuperación además de adb
  • admite la programación y ejecución de pruebas en varios dispositivos en paralelo

Consulte Pruebas a través de TF para obtener la información más actualizada sobre cómo ejecutar sus pruebas existentes, como Instrumentación .

casos de uso

La modularidad de Trade Federation facilita la integración en entornos con infraestructuras de generación, prueba e informes existentes. A continuación, enumeramos algunos casos de uso demostrativos en los que tradefed podría permitir prácticas de prueba eficientes y escalables.

Primero, es útil considerar el panorama de posibles casos de uso en términos de la pregunta "¿qué partes son modificables y cuáles son estáticas?" Por ejemplo, un OEM de dispositivos puede modificar el marco, el sistema y el hardware, pero tiene poca o ninguna influencia sobre las aplicaciones existentes. Un desarrollador de aplicaciones, por otro lado, puede modificar la aplicación, pero tiene poco control sobre la mayoría de los aspectos del sistema o el marco.

Como resultado, una entidad en cada caso de uso tendrá diferentes objetivos de prueba y tendrá diferentes opciones en el caso de un conjunto de fallas de prueba. A pesar de estas diferencias, Trade Federation puede ayudar a que cada uno de sus procesos de prueba sea eficiente, flexible y escalable.

OEM del dispositivo

Un OEM de dispositivos crea hardware y, a menudo, modificará el sistema y los marcos de Android para que funcionen bien en ese hardware. El OEM podría esforzarse por lograr esos objetivos mientras mantiene la estabilidad y el rendimiento a nivel de hardware y sistema, y ​​se asegura de que los cambios en el marco no rompan la compatibilidad con las aplicaciones existentes.

El OEM podría implementar un módulo de actualización del dispositivo que se ejecutará durante la etapa de configuración de destino del ciclo de vida. Ese módulo tendría control total sobre el dispositivo durante su período de ejecución, lo que le permitiría forzar el dispositivo en el cargador de arranque, flashear y luego obligar al dispositivo a reiniciarse en el modo de espacio de usuario. Combinado con un módulo para vincularlo a un sistema de compilación continuo, esto permitiría que el OEM ejecute pruebas en su dispositivo a medida que realiza cambios en el firmware a nivel del sistema y los marcos de trabajo a nivel de Java.

Una vez que el dispositivo se haya iniciado por completo, el OEM podría aprovechar las pruebas basadas en JUnit existentes o escribir otras nuevas para verificar la funcionalidad de interés. Finalmente, podrían escribir uno o más módulos de informes de resultados para vincularlos a los repositorios de resultados de pruebas existentes, o para informar los resultados directamente (por ejemplo, por correo electrónico ).

desarrollador de aplicaciones

Un desarrollador de aplicaciones crea una aplicación que debe funcionar bien en una variedad de versiones de plataforma y una variedad de dispositivos. Si surge un problema en una versión de plataforma y/o dispositivo en particular, el único remedio es agregar una solución alternativa y seguir adelante. Para desarrolladores más grandes, el proceso de prueba podría incorporarse en una secuencia de construcción continua. Para los desarrolladores más pequeños, puede iniciarse periódicamente o manualmente.

La mayoría de los desarrolladores de aplicaciones usarían los módulos de instalación de prueba de apk que ya existen en TF. Hay una versión que se instala desde el sistema de archivos local , así como una versión que puede instalar aplicaciones descargadas desde un servicio de compilación . Es importante tener en cuenta que la última versión continuaría funcionando correctamente con muchas instancias de TF arbitrariamente ejecutándose en la misma máquina host.

Debido a la competencia de TF en el manejo de múltiples dispositivos, sería sencillo clasificar cada resultado de prueba por el tipo de dispositivo que se usó para esa prueba. Por lo tanto, TF podría generar potencialmente una matriz de compatibilidad bidimensional (o multidimensional) para cada compilación de la aplicación.

Servicio de pruebas

Un servicio de prueba podría, por ejemplo, permitir a los desarrolladores de aplicaciones enviar aplicaciones y ejecutar pruebas en dispositivos equipados con herramientas de medición de energía para determinar el uso de energía de la aplicación. Esto difiere de los dos casos de uso anteriores en que el generador de servicios no controla los dispositivos o las aplicaciones que se ejecutan.

Debido a que Trade Federation puede ejecutar cualquier clase de Java que implemente la interfaz IRemoteTest simple, es trivial escribir controladores que puedan coordinar alguna pieza externa de hardware con el caso de prueba que se está ejecutando en el dispositivo. El controlador en sí puede generar subprocesos, enviar solicitudes a otros servidores o hacer cualquier otra cosa que pueda necesitar. Además, la simplicidad y versatilidad de la interfaz de informes de resultados, ITestInvocationListener , significa que también es sencillo representar resultados de pruebas arbitrarios (incluidas, por ejemplo, métricas de potencia numérica) en la canalización estándar de informes de resultados.