CTS con tecnología de desarrollador

En esta página, se describen los lineamientos de uso para el CTS con tecnología de desarrollador (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 determinado nivel de API
  • Todos los requisitos MUST que se incluyen en el Documento de definición de compatibilidad de Android (CDD) para un determinado nivel de API.

Los requisitos que no son OBLIGATORIOS, como los de ALTAMENTE RECOMENDADO, DEBERÍA y PUEDE, son opcionales y no se pueden probar con el CTS.

Dado que todos los requisitos de las APIs y del CDD están vinculados a un nivel de API específico, todas las pruebas del CTS (CTS, CTS-D y CTS Verifier) están vinculadas al mismo nivel de API que sus APIs o requisitos asociados. Si una API específica está obsoleta o cambia, su prueba correspondiente debe estar obsoleta o actualizarse.

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 probándolo una vez sin sacarlo de la caja.
  • Los creadores de pruebas deben eliminar 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 debe definirse claramente en el mensaje de confirmación. Para obtener instrucciones de configuración de ejemplo, consulta Cómo configurar CTS.
  • La prueba no debe ejecutarse durante más de 6 horas a la vez. Si debe ejecutarse durante más tiempo, incluye la justificación en tu propuesta de prueba para que podamos revisarla.

A continuación, se muestra un ejemplo de un conjunto de condiciones de prueba para probar una restricción de la app:

  • El Wi-Fi es estable (para una prueba que depende de Wi-Fi).
  • El dispositivo permanece fijo durante la prueba (o no, según la prueba).
  • El dispositivo está desenchufado de cualquier fuente de alimentación y tiene un X% de batería.
  • No se ejecutan apps, servicios en primer plano ni servicios en segundo plano, excepto el CTS.
  • La pantalla está apagada mientras se ejecuta CTS.
  • El dispositivo NO es isLowRamDevice.
  • No se cambiaron las restricciones de la app o del Ahorro de batería desde el estado “listo para usar”.

Elegibilidad para la prueba

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

Proceso de envío de CTS

  1. Escribe una propuesta de prueba: Un desarrollador de apps envía una propuesta de prueba con la herramienta de seguimiento de errores de Google, en la que describe el problema que se identificó y propone una prueba para verificarlo. La propuesta debe incluir el ID de 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 usuario que la envió crea una prueba de CTS en AOSP en la rama de la versión más reciente de Android (android16-release). El equipo de Android revisa el código y, si se acepta, realiza un cherry-pick del cambio y lo combina en la rama de desarrollo interno. Para obtener más información, consulta ¿Dónde debo proponer cambios en 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 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.
  • Rebasa tus cambios en head. Esto incluye los planes de prueba 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 existente del CTS. Si no puede, te ayudará a crear un módulo nuevo.
  • Para cada módulo de prueba nuevo que se cree, crea un archivo OWNERS en el directorio del módulo de prueba nuevo.
    • Tu archivo OWNERS debe contener la siguiente información, que obtendrás 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 valor de minSDK correcto, consulta la documentación de <uses-sdk>.
  • Cuando registres nuevos métodos, clases o módulos de prueba, agrégalos al plan de pruebas del CTS-D y exclúyelos del plan de pruebas principal del CTS de la misma manera que para las pruebas nuevas.

Ejecuta la prueba del CTS-D

Ejecuta el plan de pruebas del 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 Cómo ejecutar pruebas de CTS.

Aceptación y divulgación

Una vez que se envíe una solicitud de prueba, un equipo interno la revisará para asegurarse de que pruebe un requisito de la CDD o un comportamiento documentado de la API. Si se determina que la prueba verifica un requisito o comportamiento válido, el equipo la reenviará a un ingeniero de Google para que la revise. El ingeniero de Google se comunicará contigo para brindarte comentarios sobre cómo mejorar la prueba antes de que se pueda aceptar en el CTS.

Consulta la información de las ramas y el programa de lanzamientos para obtener detalles sobre el programa de lanzamientos de CTS.