Google se compromete a impulsar la igualdad racial para las comunidades afrodescendientes. Obtén información al respecto.
Se usó la API de Cloud Translation para traducir esta página.
Switch to English

Interpretación de los resultados de CTS

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

CTS_ROOT/android-cts/results/start_time.zip

Si ha creado el CTS usted mismo, CTS_ROOT 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 prediseñado descargado de este sitio.

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

Visualización de resultados de Android 10 y versiones 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 la --allow-file-access-from-files línea de comando --allow-file-access-from-files .

Leer 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 anteriores, seleccione Información del dispositivo (enlace arriba Resumen de prueba) para ver detalles sobre el dispositivo, firmware (marca, modelo, compilación de firmware, plataforma) y 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, agotaron 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] (/compatibilidad / cts / images / Q-cts-test-summary.png)
** Figura 1 **: Resumen de prueba de muestra de Android 10 CTS

Resumen de prueba de muestra de CTS v2

! [Resumen de la prueba de CTS v2] (/compatibilidad / cts / images / cts-v2-test-summary.png)
** Figura 2 **: Resumen de prueba de muestra de CTS v2

Resumen de prueba de muestra de CTS v1

! [Resumen de la prueba de CTS v1] (/compatibilidad / cts / images / cts-test-summary.png)
** 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: pasa, falla, se agotó el tiempo de espera o no se ejecutó. En caso de falla de una prueba, se proporcionan detalles para ayudar a diagnosticar la causa.

Además, el seguimiento de pila de la falla 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 debe proporcionar detalles de la falla de la prueba (busque la etiqueta [Test] 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

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 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 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 completado.

Triaging pruebas fallidas

Utilice las siguientes sugerencias para clasificar los fallos 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 del entorno, si una prueba parece excesivamente inestable.
  • 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 que ocurran 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 comenzando en un punto específico en el tiempo, una URL incorrecta puede ser la culpa.
    • Si el DUT no incluye el parche de seguridad, se espera que falle la prueba de seguridad.
  • Valide y analice las diferencias entre dispositivos que pasan y que fallan.
  • Analice la afirmación, el registro, el informe de errores y la fuente CTS . Para un 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íe un parche de mejora de la prueba para ayudar a reducir las fallas de la prueba.