CTS desarrollado por desarrolladores

En esta página, se describen los lineamientos de uso del CTS desarrollado por desarrolladores (CTS-D).

Cobertura de la prueba

CTS-D, como CTS y El verificador del CTS solo puede aplicar lo siguiente:

• Todas las APIs públicas que se describen en el SDK para desarrolladores (developer.android.com) para un nivel de API determinado.
• Se requieren todos los requisitos que se incluyen en la guía de compatibilidad de Android Documento de definición (CDD) para un nivel de API determinado.

Son opcionales los requisitos que no son DEBEN (como RECOMENDACIÓN ESPECÍFICA, DEBERÍA, PUEDE) y no pueden probarse con el CTS.

Debido a que todos los requisitos de API y CDD están vinculados a un nivel de API específico, todos los CTS pruebas (CTS, CTS-D y Verifier) están vinculadas al mismo nivel de API que su las APIs o los requisitos asociados. Si una API específica deja de estar disponible o se modifica, la prueba correspondiente debe quedar obsoleta o actualizada.

Reglas de creación de pruebas de CTS

• Una prueba debe producir el mismo resultado objetivo de manera coherente.
• Una prueba debe determinar si un dispositivo aprueba o falla. una vez de inmediato.
• Los creadores de pruebas deben quitar todos los factores posibles que podrían afectar los resultados de las pruebas.
• Si un dispositivo necesita una determinada condición, entorno o configuración de hardware, esa configuración deben definirse claramente en el mensaje de confirmación. Por ejemplo, en las instrucciones de configuración, consulta Cómo configurar el CTS.
• La prueba no debe ejecutarse durante más de 6 horas a la vez. Si necesita ejecutarse durante incluye la justificación en tu propuesta de prueba para que podamos revisarla.

El siguiente es un conjunto de ejemplo de condiciones de prueba para probar una app restricción:

• La conexión Wi-Fi es estable (para una prueba que se basa en Wi-Fi).
• El dispositivo permanece quieto durante la prueba (o no, según la prueba).
• El dispositivo está desconectado de cualquier fuente de alimentación con un X por ciento del nivel de batería.
• No se están ejecutando apps ni servicios en primer plano ni servicios en segundo plano, excepto por del CTS
• La pantalla se apaga mientras se ejecuta CTS.
• El dispositivo NO es isLowRamDevice.
• No se modificaron las restricciones de apps ni del Ahorro de batería desde el listo para usar.

Elegibilidad de la prueba

Aceptamos nuevas pruebas que imponen un comportamiento que no está probado por el CTS existente, Pruebas del verificador del CTS o del CTS-D. Cualquier prueba que verifique un comportamiento fuera del alcance de nuestra cobertura de prueba se rechazará.

Proceso de envío de CTS

1. Escribe una propuesta de prueba: Un desarrollador de apps envía una propuesta de prueba usando Herramienta de seguimiento de errores de Google, describir el problema que se identificó y proponer una prueba para verificar por él. La propuesta debe incluir el ID de requisito del CDD asociado. El equipo de Android revisa la propuesta.
2. Desarrollar una prueba del CTS: Después de que se aprueba una propuesta, el remitente crea un CTS prueba en AOSP en la rama principal (AOSP/main). El equipo de Android revisa el código.
3. Publicar prueba: Envía tu lista de cambios el AOSP/main y, luego, selecciona cuidadosamente más reciente de la rama androidx-tests-dev. La prueba ahora está disponible de forma pública.

Lineamientos para la escritura de pruebas de CTS-D

• Sigue la Guía de estilo de código Java.
• Sigue todos los pasos que se describen en Desarrollo de CTS.
• Agrega tus pruebas al plan de prueba adecuado:
  • Usa include-filters para agregar nuevas pruebas al plan de prueba de CTS-D: platform/cts/tools/cts-tradefed/res/config/cts-developer.xml.
  • Utiliza exclude-filters para excluir las pruebas nuevas del plan de prueba principal del CTS: platform/cts/tools/cts-tradefed/res/config/cts-developer-exclude.xml.
• Controla todas las advertencias y sugerencias de errorprone en build_error.log.
• Cambia la base de tus cambios a head. Esto incluye cts-developer.xml y cts-developer-exclude.xml planes de prueba.
• Trabaja con tu contacto de ingeniería de Google para determinar si tu caso de prueba pueden incluirse en un módulo de CTS existente. Si no puede, ellos te ayudarán crea un módulo nuevo.
• Para cada módulo de prueba nuevo, crea un archivo OWNERS en el módulo de prueba nuevo. .
  • Tu archivo OWNERS debe contener la siguiente información, obtenida de el propietario de prueba de Google con el que trabajas:
  • # Bug component: xxx
  • LDAP del propietario de prueba de Google
• En AndroidTest.xml, especifica los siguientes parámetros. Consulta los archivos de muestra (1, 2) para ver ejemplos:
  • Instant_app o not_instant_app
  • secondary_user o not_secondary_user
  • all_foldable_states o no_foldable_states
• Para especificar el minSDK correcto, consulta la clase <uses-sdk> documentación.
• Cuando ingreses nuevos métodos, clases o módulos de prueba, agrégalos al CTS-D de prueba y excluirlos del plan de prueba principal de CTS del mismo modo que para pruebas nuevas.

Ejecuta tu prueba de CTS-D

Ejecuta el plan de prueba de CTS-D desde la línea de comandos usando run cts --plan cts-developer.

Para ejecutar un caso de prueba específico, usa run cts --include-filter "test_module_name test_name".

Para obtener información sobre cómo ejecutar todo el CTS, consulta Cómo ejecutar pruebas del CTS.

Aceptación y autorización

Una vez que se envíe la solicitud de prueba, un equipo interno la revisará para asegurarse de que comprueba un requisito de CDD o un comportamiento documentado de la API. Si la prueba es determinado para verificar un requisito o comportamiento válido, el equipo reenviaremos este caso de prueba a un ingeniero de Google para que lo revise. El equipo de el ingeniero se comunicará contigo para darte comentarios sobre cómo se puede mejorar la prueba antes de que pueda aceptarse en el CTS.

Consulta Información de las sucursales y el programa de lanzamientos para obtener detalles sobre el programa de lanzamientos de CTS.