Los resultados de la prueba de CTS se encuentran en el archivo:
CTS_ROOT/android-cts/results/start_time.zip
Si compilaste el CTS por tu cuenta, CTS_ROOT se parece a lo siguiente:
out/host/linux-x86/cts, pero difiere según la plataforma. Esto refleja la ruta en la que
descomprimeste el CTS oficial compilado previamente
descargado 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
Existe un archivo test_result.html dentro del archivo ZIP, puedes abrirlo directamente en cualquier navegador web compatible con HTML5
Cómo mostrar resultados de versiones anteriores a Android 10
Para ver la prueba, abre el archivo test_result.xml en cualquier navegador web compatible con HTML5 resultados
Si este archivo muestra una página en blanco cuando usas el navegador Chrome, sigue estos pasos:
cambiar 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 sobre el Resumen de la prueba) para ver detalles acerca del dispositivo, firmware (marca, modelo, compilación de firmware, plataforma), y el hardware del dispositivo (resolución de la pantalla, teclado y tipo de pantalla). CTS v2 no mostrar información del dispositivo.
Resumen de la prueba
La sección Resumen de la prueba proporciona detalles del plan de prueba ejecutado, como el CTS el nombre del plan y las horas de inicio y finalización de la ejecución. También presenta un agregado un resumen de la cantidad de pruebas que se aprobaron, fallaron, agotaron el tiempo de espera o no se pudieron ejecutado.
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 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 prueba
La siguiente sección, el informe de pruebas del CTS, brinda un resumen de las pruebas aprobadas por .
A continuación, se detallan los detalles de las pruebas que se ejecutaron. El informe Incluye el paquete de prueba, el conjunto de pruebas, el caso de prueba y las pruebas ejecutadas. Muestra resultado de la ejecución de la prueba: aprobada, fallida, tiempo de espera agotado o no ejecutada. En la se proporcionan detalles sobre el caso de prueba fallida para ayudar a diagnosticar la causa.
Además, el seguimiento de pila del error está disponible en el archivo en formato XML, pero no en el informe para garantizar la brevedad, es decir, visualizar el archivo en formato XML con un editor de texto. debes proporcionar los detalles de la prueba fallida (busca la etiqueta [Test]). correspondiente a la prueba con errores y busca en ella 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 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 lo siguiente: el comando “list results”. La cantidad de módulos completados y totales de módulos para cada sesión anterior. Para determinar qué módulos están completos y cuáles incompleto, abre el archivo test_result.xml y lee el valor de “done” para cada módulo del informe de resultados. Módulos con el valor Listo = "falso" no se hayan ejecutado hasta su finalización.
Fallas en las pruebas de clasificación
Usa las siguientes sugerencias para clasificar las fallas de las pruebas.
- Verifica 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 Configuración del dispositivo Android.
- Verificar la estabilidad del dispositivo, la configuración de la prueba o los problemas del entorno. Si una prueba es demasiado inestable.
- Vuelve a realizar la prueba aislada si aún falla.
- Verifica si hay factores externos que causen fallas en las pruebas, como los siguientes:
- Configuración del entorno. Por ejemplo, una máquina de escritorio mal configurada configuración puede ser la causa de que se produzcan fallas en las pruebas en todos los dispositivos Prueba (DUT) (incluidos los dispositivos de referencia)
- Las 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 una URL incorrecta tener la culpa.
- Si el DUT no incluye la seguridad del error, se espera que falle la prueba de seguridad.
- Valida y analiza las diferencias entre los dispositivos con aprobación y los que fallan.
- Analiza la aserción, el registro, el informe de errores y el Fuente de CTS. Para una HostTest, la aserción y el registro pueden ser muy genéricos, por lo que es útil revisa y adjunta el logcat del dispositivo.
- Envía un parche de mejora de prueba para ayudar a reducir las pruebas fallidas.
Guardar resultados parciales
Tradefed no guarda los resultados parciales de la prueba cuando falla la invocación de prueba.
Cuando Tradefed no genera resultados de pruebas, se insinúa que hubo un problema grave ocurrieron 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 investigar el problema del dispositivo.