Interpretación de 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 a out/host/linux-x86/cts pero difiere según la plataforma. Esto refleja la ruta en la que ha descomprimido el CTS oficial precompilado descargado de este sitio.

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

Visualización de Android 10 y resultados posteriores

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

Visualización de 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 el indicador de línea de comando --allow-file-access-from-files .

Lectura de 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 versiones anteriores
  • CTS v2 para Android 7.0 y posterior

Información del dispositivo

En CTS v1 y versiones anteriores, seleccione Información del dispositivo (enlace arriba del Resumen de la 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, expiraron o no pudieron ejecutarse.

Resumen de prueba de muestra de Android 10 CTS

Resumen de 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 los 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: aprobado, fallido, agotado o no ejecutado. En caso de que falle una prueba, se proporcionan detalles para ayudar a diagnosticar la causa.

Además, el seguimiento de la pila de la falla está disponible en el archivo XML, pero no se incluye en el informe para garantizar la brevedad; la visualización del archivo XML con un editor de texto debería proporcionar detalles de la falla de la prueba (busque la etiqueta [Prueba] correspondiente a la prueba fallida y busque dentro de 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

Revisando test_result.xml para módulos de prueba incompletos

Para determinar el número de módulos incompletos en una sesión de prueba dada, 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 o 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 hecho = "falso" no se han ejecutado hasta su finalización.

Fallos en las pruebas de clasificación

Use las siguientes sugerencias para clasificar las fallas en 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 escamosa.
  • Vuelva a intentar la prueba de forma aislada si sigue fallando.
  • Verifique los factores externos que causan 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 las fallas de prueba que ocurren 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, es posible que la falla sea una URL incorrecta.
    • Si el DUT no incluye el parche de seguridad, se espera que falle la prueba de seguridad.
  • Valide y analice las diferencias entre dispositivos aprobados y defectuosos.
  • Analice la aserción, el registro, el informe de errores y la fuente CTS . Para 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íe un parche de mejora de prueba para ayudar a reducir las fallas de prueba.

Guardar resultados parciales

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

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