CTS impulsado por desarrolladores

Esta página describe las pautas de uso para Developer-Powered CTS (CTS-D).

Cobertura de prueba

CTS-D, como CTS y CTS Verifier, solo puede hacer cumplir lo siguiente:

  • Todas las API públicas que se describen en el SDK para desarrolladores (developer.android.com) para un determinado nivel de API.
  • Todos los requisitos OBLIGATORIOS 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 IMPRESCINDIBLES, como MUY RECOMENDABLE, DEBERÍA, PUEDE, son opcionales y no se pueden probar con CTS.

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

Reglas de creación de pruebas CTS

  • Una prueba debe producir el mismo resultado objetivo consistentemente.
  • Una prueba debe determinar si un dispositivo pasa o falla probando ese dispositivo una vez fuera de la caja.
  • Los creadores de las 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/configuración de hardware, esa configuración debe estar claramente definida en el mensaje de confirmación. Para obtener instrucciones de configuración de ejemplo, consulte Configuración de CTS .
  • La prueba no debe durar más de 6 horas seguidas. Si necesita ejecutarse por más tiempo, incluya el razonamiento en su propuesta de prueba para que podamos revisarlo.

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

  • Wifi es estable (para una prueba que se basa en Wifi).
  • El dispositivo permanece estacionario durante la prueba (o no, dependiendo de la prueba).
  • El dispositivo está desenchufado de cualquier fuente de alimentación con un X por ciento del nivel de batería.
  • No se están ejecutando aplicaciones, servicios en primer plano ni servicios en segundo plano, excepto CTS.
  • La pantalla está apagada mientras se ejecuta CTS.
  • El dispositivo NO es isLowRamDevice .
  • Las restricciones de aplicaciones/ahorro de batería no se han cambiado desde el estado "listo para usar".

Prueba de elegibilidad

Aceptamos nuevas pruebas que imponen un comportamiento que no está probado por las pruebas CTS, CTS Verifier o CTS-D existentes. Cualquier prueba que verifique un comportamiento fuera del alcance de nuestra cobertura de prueba será rechazada.

Proceso de envío de CTS

  1. Escriba una propuesta de prueba: un desarrollador de aplicaciones envía una propuesta de prueba mediante Google Issue Tracker , 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. Desarrollar una prueba CTS: después de que se aprueba una propuesta, el remitente crea una prueba CTS en AOSP en la rama principal (AOSP/maestra). El equipo de Android revisa el código.
  3. Publicar prueba: envíe su CL en AOSP/master y luego selecciónela en la rama más reciente androidx-tests-dev . La prueba ya está disponible públicamente.

Pautas de redacción del examen CTS-D

  • Siga la Guía de estilo de código Java .
  • Siga todos los pasos descritos en Desarrollo CTS .
  • Agregue sus pruebas al plan de prueba apropiado:
    • Utilice include-filters para agregar sus nuevas pruebas al plan de prueba de CTS-D: platform/cts/tools/cts-tradefed/res/config/cts-developer.xml .
    • Use exclude-filters de exclusión para excluir sus nuevas pruebas del plan de prueba principal de CTS: platform/cts/tools/cts-tradefed/res/config/cts-developer-exclude.xml .
  • Maneje todas las advertencias y sugerencias propensas a build_error.log errorprone
  • Vuelva a basar sus cambios en head . Esto incluye los planes de prueba cts-developer.xml y cts-developer-exclude.xml .
  • Trabaje con su contacto de ingeniería de Google para determinar si su caso de prueba se puede incluir en un módulo CTS existente. Si no puede, lo ayudarán a crear un nuevo módulo.
  • Para cada nuevo módulo de prueba creado, cree un archivo OWNERS en el directorio del nuevo módulo de prueba.
    • Su archivo OWNERS debe contener la siguiente información, obtenida del propietario de la prueba de Google con el que está trabajando:
    • # Bug component: xxx
    • Ldap del propietario de la prueba de Google
  • En AndroidTest.xml , especifique los siguientes parámetros. Consulte 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, consulte la documentación de <uses-sdk> .
  • Al registrar nuevos métodos de prueba, clases o módulos, agréguelos al plan de prueba CTS-D y exclúyalos del plan de prueba principal de CTS de la misma manera que para las pruebas nuevas.

Ejecute su prueba CTS-D

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

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

Para obtener información sobre cómo ejecutar el CTS completo, consulte Ejecutar pruebas de CTS .

Aceptación y liberación

Una vez que se envía una solicitud de prueba, un equipo interno la revisará 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 enviará este caso de prueba a un ingeniero de Google para una revisión adicional. El ingeniero de Google se comunicará con usted con comentarios sobre cómo se puede mejorar la prueba antes de que se pueda aceptar en CTS.

Consulte el cronograma de lanzamiento y la información de la sucursal para obtener detalles sobre el cronograma de lanzamiento de CTS.