Interpretar los resultados de CTS

Los resultados de la prueba CTS se colocan en el archivo:

CTS_ROOT/android-cts/results/start_time.zip

Si ha creado el CTS usted mismo, CTS_ROOT se parece out/host/linux-x86/cts pero difiere según la plataforma. Esto refleja la ruta donde descomprimiste el CTS oficial prediseñado descargado de este sitio.

Dentro del zip, el archivo test_result.xml contiene los resultados reales.

Mostrar resultados de Android 10 y posteriores

Existe un archivo test_result.html dentro del archivo zip, puede abrirlo directamente en cualquier navegador web compatible con HTML5

Mostrar resultados anteriores a Android 10

Abra 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 usa el navegador Chrome, cambie la configuración de su navegador para habilitar la marca de línea de comando --allow-file-access-from-files .

Lea los resultados de la prueba

Los detalles de los resultados de la prueba dependen de la versión de CTS que esté utilizando:

  • CTS v1 para Android 6.0 y anteriores
  • CTS v2 para Android 7.0 y posteriores

Información del dispositivo

En CTS v1 y versiones anteriores, seleccione Información del dispositivo (enlace arriba del Resumen de prueba) para ver detalles sobre el dispositivo, el firmware (marca, modelo, compilación del 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

La sección Resumen de prueba proporciona detalles del plan de prueba ejecutado, como el nombre del plan 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 pasaron, fallaron, excedieron el tiempo de espera o no pudieron ejecutarse.

Resumen de prueba de muestra de Android 10 CTS

Resumen de la prueba de Android 10 CTS

Figura 1: Resumen de prueba de muestra de Android 10 CTS

Resumen de prueba de muestra de CTS v2

Resumen de la prueba CTS v2

Figura 2: Resumen de prueba de muestra de CTS v2

Resumen de prueba de muestra de CTS v1

Resumen de la prueba CTS v1

Figura 3: Resumen de prueba de muestra de CTS v1

Informe de prueba

La siguiente sección, el informe de prueba CTS, proporciona un resumen de las pruebas aprobadas por paquete.

A esto le siguen detalles de las pruebas reales que se ejecutaron. El informe enumera 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: pasa, falla, se agotó el tiempo de espera o no se ejecutó. En caso de falla de la prueba, se proporcionan detalles para ayudar a diagnosticar la causa.

Además, el seguimiento de la pila del error está disponible en el archivo XML, pero no se incluye en el informe para garantizar la brevedad; ver el archivo XML con un editor de texto debería proporcionar detalles del error de la prueba (busque la etiqueta [Prueba] correspondiente a la prueba fallida y busque en ella la etiqueta [StackTrace] ).

Mostrar informe de prueba de muestra de CTS v2

Informe de prueba CTS v2

Figura 4: Informe de prueba de muestra de CTS v2

Mostrar informe de prueba de muestra de CTS v1

Informe de prueba CTS v1

Figura 5: Informe de prueba de muestra de CTS v1

Revise test_result.xml para ver módulos de prueba incompletos

Para determinar la cantidad de módulos incompletos en una sesión de prueba determinada, ejecute el comando 'listar resultados'. El recuento de módulos completados y el total de módulos se enumeran para cada sesión anterior. Para determinar qué módulos están completos e incompletos, abra el archivo test_result.xml y lea el valor del atributo "hecho" para cada módulo en el informe de resultados. Los módulos con valor done = "false" no se han ejecutado hasta su finalización.

Fallos en las pruebas de clasificación

Utilice las siguientes sugerencias para clasificar los errores de las pruebas.

  • Verifique que su entorno 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.
  • Verifique la estabilidad del dispositivo, la configuración de la prueba o los problemas ambientales, si una prueba parece excesivamente inestable.
  • Vuelva a intentar la prueba de forma aislada si aún falla.
  • Verifique factores externos que causen fallas en las pruebas, como:
    • Configuración ambiental. Por ejemplo, una configuración de máquina de escritorio mal configurada puede ser la causa de que se produzcan fallas de prueba en todos los dispositivos bajo prueba (DUT) (incluidos los dispositivos de referencia).
    • Dependencias externas. Por ejemplo, si una prueba falla en todos los dispositivos en varios sitios a partir de un momento específico, la culpa podría ser una URL incorrecta.
    • Si el DUT no incluye el parche de seguridad, se espera que falle la prueba de seguridad.
  • Validar y analizar las diferencias entre dispositivos aprobados y fallidos.
  • Analice la afirmación, el registro, el informe de error y la fuente CTS . Para HostTest, la afirmación y el registro pueden ser muy genéricos, por lo que también resulta útil comprobar y adjuntar el logcat del dispositivo.
  • Envíe un parche de mejora de las pruebas para ayudar a reducir los errores de las pruebas.

Guardar resultados parciales

Tradefed no guarda resultados de pruebas parciales cuando falla la invocación de la prueba.

Cuando Tradefed no genera ningún resultado de prueba, se da a entender que ha ocurrido 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 aporta valor a la hora de investigar el problema del dispositivo.