Los resultados de las pruebas del CTS se colocan en el archivo:
CTS_ROOT/android-cts/results/start_time.zip
Si compilaste el CTS por tu cuenta, CTS_ROOT se parece a out/host/linux-x86/cts, pero difiere según la plataforma. Esto refleja la ruta en la que descomprimiste el CTS oficial prediseñado que descargaste de este sitio.
Dentro del archivo ZIP, el archivo test_result.xml contiene los resultados reales.
Mostrar los resultados de Android 10 y versiones posteriores
Existe un archivo test_result.html dentro del archivo ZIP, que puedes abrir directamente en cualquier navegador web compatible con HTML5.
Mostrar resultados anteriores a Android 10
Abre el archivo test_result.xml en cualquier navegador web compatible con HTML5 para ver los resultados de la prueba.
Si este archivo muestra una página en blanco cuando usas el navegador Chrome, cambia la configuración del navegador para habilitar la marca de línea de comandos --allow-file-access-from-files.
Cómo leer los resultados de la prueba
Los detalles de los resultados de las pruebas dependen de la versión del CTS que uses:
- CTS v1 para Android 6.0 y versiones anteriores
- CTS v2 para Android 7.0 y versiones posteriores
Información del dispositivo
En el CTS v1 y versiones anteriores, selecciona Device Information (vínculo sobre el resumen de la prueba) para ver detalles sobre el dispositivo, el firmware (marca, modelo, compilación de firmware, plataforma) y el hardware del dispositivo (resolución de pantalla, teclado, tipo de pantalla). CTS v2 no muestra información del dispositivo.
Resumen de la prueba
En la sección Resumen de la prueba, se proporcionan detalles del plan de pruebas ejecutado, como el nombre del plan de CTS y las horas de inicio y finalización de la ejecución. También presenta un resumen agregado de la cantidad de pruebas que se aprobaron, fallaron, agotaron el tiempo de espera o no se pudieron ejecutar.
Resumen de la prueba de muestra del CTS de Android 10
Figura 1: Resumen de la prueba de muestra del CTS de Android 10
Resumen de la prueba de ejemplo de CTS v2
Figura 2: Resumen de la prueba de muestra de CTS v2
Resumen de la prueba de ejemplo de CTS v1
Figura 3: Resumen de la prueba de muestra de CTS v1
Informe de prueba
En la siguiente sección, el informe de la prueba del CTS, se proporciona un resumen de las pruebas aprobadas por paquete.
A continuación, se incluyen detalles de las pruebas reales que se ejecutaron. En el informe, se enumeran el paquete de prueba, el conjunto de pruebas, el caso de prueba y las pruebas ejecutadas. Muestra el resultado de la ejecución de la prueba: aprobada, fallida, agotamiento del tiempo de espera o no ejecutada. En caso de que falle una prueba, se proporcionan detalles para ayudar a diagnosticar la causa.
Además, el registro de seguimiento de la falla está disponible en el archivo XML, pero no se incluye en el informe para garantizar la brevedad. Si ves el archivo XML con un editor de texto, deberías obtener detalles de la falla de la prueba (busca la etiqueta [Test] correspondiente a la prueba fallida y, dentro de ella, busca la etiqueta [StackTrace]).
Mostrar el informe de prueba de muestra de CTS v2
Figura 4: Informe de prueba de muestra de CTS v2
Mostrar el informe de prueba de muestra de CTS versión 1
Figura 5: Informe de prueba de muestra de CTS v1
Revisa test_result.xml para ver si hay módulos de prueba incompletos
Para determinar la cantidad de módulos incompletos en una sesión de prueba determinada, ejecuta el comando "list results". En cada sesión anterior, se indica la cantidad de módulos completados y la cantidad total de módulos. Para determinar qué módulos están completos y cuáles no, abre el archivo test_result.xml y lee el valor del atributo "done" de cada módulo en el informe de resultados. Los módulos con el valor done = "false" no se ejecutaron hasta completarse.
Cómo priorizar los errores de las pruebas
Usa las siguientes sugerencias para priorizar las fallas de las pruebas.
- Si una prueba falla debido a condiciones previas incorrectas, verifica que tu entorno de CTS esté configurado correctamente. Esto incluye el entorno físico, la configuración de la computadora de escritorio y la configuración del dispositivo Android.
- Verifica la estabilidad del dispositivo, la configuración de la prueba o los problemas del entorno si una prueba parece demasiado inestable.
- Si la prueba sigue fallando, vuelve a intentarla de forma aislada.
- Verifica si hay factores externos que provoquen fallas en las pruebas, como los siguientes:
- Configuración del entorno Por ejemplo, una configuración incorrecta de una máquina de escritorio puede ser la causa de las fallas de las pruebas que se producen en todos los dispositivos en prueba (DUT), incluidos los dispositivos de referencia.
- Dependencias externas Por ejemplo, si una prueba falla en todos los dispositivos de varios sitios a partir de un momento específico, es posible que la causa sea una URL incorrecta.
- Si el DUT no incluye el parche de seguridad, se espera que falle la prueba de seguridad.
- Valida y analiza las diferencias entre los dispositivos que superan la prueba y los que no.
- Analiza la aserción, el registro, el informe de errores y el código fuente del CTS. En el caso de un HostTest, la aserción y el registro pueden ser muy genéricos, por lo que también es útil verificar y adjuntar el logcat del dispositivo.
- Envía un parche de mejora de la prueba para ayudar a reducir los errores de prueba.
Cómo guardar resultados parciales
Tradefed no guarda los resultados parciales de las pruebas cuando falla la invocación de la prueba.
Cuando Tradefed no genera ningún resultado de prueba, se entiende que ocurrió un problema grave durante la ejecución de la prueba, lo que hace que el resultado de la prueba no sea confiable. El resultado parcial se considera inútil, ya que no proporciona valor cuando se investiga un problema del dispositivo.