CTS con tecnología de desarrollador

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

Cobertura de pruebas

Al igual que el CTS y el verificador del CTS, el CTS-D 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
  • Todos los requisitos MUST que se incluyen en el Documento de definición de compatibilidad (CDD) de Android para un nivel de API determinado

Los requisitos que no son MUST, como STRONGLY RECOMMENDED, SHOULD y MAY, son opcionales y no se pueden probar con el CTS.

Debido a que todos los requisitos de las APIs y el CDD están vinculados a un nivel de API específico, todas las pruebas de CTS (CTS, CTS-D y verificador del CTS) están vinculadas al mismo nivel de API que sus APIs o requisitos asociados. Si una API específica está obsoleta o cambió, su prueba correspondiente debe estar 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 pasa o falla la prueba probándolo una vez.
  • Los creadores de pruebas deben quitar todos los factores posibles que puedan afectar los resultados de las pruebas.
  • Si un dispositivo necesita una condición, un entorno o una configuración de hardware determinados, esa configuración debe definirse claramente en el mensaje de confirmación. Para obtener instrucciones de configuración de ejemplo, consulta Cómo configurar el CTS.
  • La prueba no debe ejecutarse durante más de seis horas a la vez. Si necesitas ejecutarla durante más tiempo, incluye el razonamiento en tu propuesta de prueba para que podamos revisarla.

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

  • La red Wi-Fi es estable (para una prueba que depende de la red Wi-Fi).
  • El dispositivo permanece inmóvil durante la prueba (o no, según la prueba).
  • El dispositivo está desconectado de cualquier fuente de alimentación con un nivel de batería de X por ciento.
  • No se ejecutan apps, servicios en primer plano ni servicios en segundo plano, excepto el CTS.
  • La pantalla está apagada mientras se ejecuta el CTS.
  • El dispositivo NO es isLowRamDevice.
  • El Ahorro de batería y las restricciones de la app no se cambiaron desde el estado inicial.

Elegibilidad de la prueba

Aceptamos pruebas nuevas que apliquen un comportamiento que no se pruebe con las pruebas existentes de CTS, verificador del CTS o CTS-D. Se rechaza cualquier prueba que verifique un comportamiento fuera del alcance de nuestra cobertura de pruebas.

Proceso de envío del CTS

  1. Escribe una propuesta de prueba: Un desarrollador de apps envía una propuesta de prueba con Issue Tracker de Google, en la que se describe el problema identificado y se propone una prueba para verificarlo. La propuesta debe incluir el ID del requisito de CDD asociado. El equipo de Android revisa la propuesta.
  2. Desarrolla una prueba de CTS: Después de que se aprueba una propuesta, el remitente crea una prueba de CTS en el AOSP en la rama de la versión más reciente de Android (android17-release). El equipo de Android revisa el código y, si se acepta, selecciona el cambio y lo combina en la rama de desarrollo interna. Para obtener más detalles, consulta ¿Dónde debo proponer cambios en el AOSP?.

Lineamientos para escribir 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 pruebas adecuado:
    • Usa include-filters para agregar tus pruebas nuevas al plan de pruebas de CTS-D: platform/cts/tools/cts-tradefed/res/config/cts-developer.xml.
    • Usa exclude-filters para excluir tus pruebas nuevas del plan de pruebas principal de CTS: platform/cts/tools/cts-tradefed/res/config/cts-developer-exclude.xml.
  • Controla todas las advertencias y sugerencias de errorprone en build_error.log.
  • Rebasa tus cambios a head. Esto incluye los planes de pruebas cts-developer.xml y cts-developer-exclude.xml.
  • Trabaja con tu contacto de ingeniería de Google para determinar si tu caso de prueba se puede incluir en un módulo de CTS existente. Si no es así, te ayudarán a crear un módulo nuevo.
  • Para cada módulo de prueba nuevo creado, crea un archivo OWNERS en el directorio del módulo de prueba nuevo.
    • Tu archivo OWNERS debe contener la siguiente información, obtenida del propietario de la prueba de Google con el que trabajas:
    • # Bug component: xxx
    • LDAP del propietario de la 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 documentación de <uses-sdk>.
  • Cuando registres métodos, clases o módulos de prueba nuevos, agrégalos al plan de pruebas de CTS-D y exclúyelos del plan de pruebas principal de CTS de la misma manera que para las pruebas nuevas.

Ejecuta tu prueba de CTS-D

Ejecuta el plan de pruebas de CTS-D desde la línea de comandos con 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 el CTS completo, consulta Ejecuta pruebas de CTS.

Aceptación y lanzamiento

Después de que se envía una solicitud de prueba, un equipo interno la revisa para asegurarse de que pruebe un requisito de CDD o un comportamiento de API documentado. Si se determina que la prueba verifica un requisito o comportamiento válido, el equipo reenvía este caso de prueba a un ingeniero de Google para que lo revise más. El ingeniero de Google se comunicará contigo para darte comentarios sobre cómo se puede mejorar la prueba antes de que se pueda aceptar en el CTS.

Consulta Programa de lanzamientos e información de las ramas para obtener detalles sobre el programa de lanzamientos del CTS.