Los resultados de la prueba de 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 precompilado que descargaste de este sitio.
Dentro del zip, el archivo test_result.xml contiene los resultados reales.
Cómo mostrar resultados de Android 10 y versiones posteriores
Si existe un archivo test_result.html dentro del archivo ZIP, puedes abrirlo directamente en cualquier navegador web compatible con HTML5.
Cómo 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.
Lee los resultados de la prueba
Los detalles de los resultados de la prueba dependen de la versión de 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 CTS v1 y versiones anteriores, selecciona Información del dispositivo (vínculo arriba del Resumen de prueba) para ver los detalles del dispositivo, el firmware (marca, modelo, compilación de firmware, plataforma) y el hardware del dispositivo (resolución de pantalla, teclado y tipo de pantalla). CTS v2 no muestra información del dispositivo.
Resumen de la prueba
La sección Resumen de la prueba proporciona detalles del plan de prueba 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 aprobaron, fallaron, se agotó el tiempo de espera o no se pudieron ejecutar.
Resumen de la prueba de muestra de CTS de Android 10
Figura 1: Resumen de la prueba de muestra del CTS de Android 10
Resumen de la prueba de muestra de CTS v2
Figura 2: Resumen de la prueba de muestra de CTS v2
Resumen de la prueba de muestra de CTS v1
Figura 3: Resumen de la prueba de muestra de CTS v1
Informe de pruebas
En la siguiente sección, el informe de pruebas del CTS, se proporciona un resumen de las pruebas aprobadas por paquete.
A continuación, se incluyen los 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, tiempo de espera agotado o no ejecutada. En el caso de que una prueba falle, se proporcionan detalles para ayudar a diagnosticar la causa.
Además, el seguimiento de pila de la falla está disponible en el archivo en formato XML, pero no se incluye en el informe para garantizar la brevedad. Si ves el archivo en formato 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 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 v1
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". El recuento de Módulos completados y Módulos totales se enumeran para cada sesión anterior. 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" para cada módulo en el informe de resultados. Los módulos con el valor done = "false" no se ejecutaron por completo.
Cómo clasificar las pruebas fallidas
Usa las siguientes sugerencias para clasificar las fallas de la prueba.
- Verifica que tu entorno de CTS esté configurado correctamente si una prueba falla debido a condiciones previas incorrectas. Esto incluye el entorno físico, la configuración de la máquina 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 ser demasiado inestable.
- Vuelve a realizar la prueba de forma aislada si sigue fallando.
- Verifica si hay factores externos que causan fallas en las pruebas, como los siguientes:
- Configuración del entorno Por ejemplo, una configuración incorrecta de la máquina de escritorio puede ser la causa de las fallas de prueba 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 el error 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 pasan y los que no.
- Analiza la aserción, el registro, el informe de errores y la fuente de CTS. En el caso de HostTest, la aserción y el registro pueden ser muy genéricos, por lo que es útil verificar y adjuntar el logcat del dispositivo.
- Envía un parche de mejora de prueba para ayudar a reducir los errores de prueba.
Guardar resultados parciales
Tradefed no guarda los resultados parciales de la prueba cuando falla la invocación de prueba.
Cuando Tradefed no genera ningún resultado de prueba, se da a entender que se produjo 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 poco útil, ya que no proporciona valor cuando se investiga el problema del dispositivo.