CTS impulsado por desarrolladores

Esta página describe las pautas de uso de CTS impulsado por desarrolladores (CTS-D).

Cobertura de prueba

CTS-D, al igual que 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 DEBEN estar incluidos en el Documento de definición de compatibilidad (CDD) de Android para un determinado nivel de API.

Los requisitos que no son OBLIGATORIOS, como MUY RECOMENDADO, 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 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 queda obsoleta o cambia, su prueba correspondiente debe quedar obsoleta o actualizarse.

Reglas de creación de pruebas CTS

  • Una prueba debe producir el mismo resultado objetivo de manera consistente.
  • Una prueba debe determinar si un dispositivo pasa o falla probándolo una vez fuera 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/configuración de hardware, esa configuración debe definirse claramente 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 revisarla.

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

  • Wifi es estable (para una prueba que depende de Wifi).
  • El dispositivo permanece estacionario 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 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 ahorro de batería/aplicaciones no se han modificado desde el estado "listo para usar".

Elegibilidad para la prueba

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 pruebas será rechazada.

Proceso de presentación de CTS

  1. Escriba una propuesta de prueba: un desarrollador de aplicaciones envía una propuesta de prueba utilizando Google Issue Tracker , describiendo el problema que se ha identificado y proponiendo una prueba para comprobarlo. La propuesta debe incluir el ID del requisito de DDC 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/principal). El equipo de Android revisa el código.
  3. Publicar prueba: envíe su CL en AOSP/main y luego selecciónelo en la última rama androidx-tests-dev . La prueba ya está disponible públicamente.

Pautas de redacción del examen CTS-D

  • Siga la Guía de estilo del código Java .
  • Siga todos los pasos descritos en Desarrollo CTS .
  • Agregue sus pruebas al plan de pruebas apropiado:
    • Utilice include-filters para agregar sus nuevas pruebas al plan de pruebas CTS-D: platform/cts/tools/cts-tradefed/res/config/cts-developer.xml .
    • Utilice exclude-filters 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 errorprone en build_error.log .
  • 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 es posible, le 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
    • Propietario de prueba de Google ldap
  • 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 <uses-sdk> .
  • Al incorporar nuevos métodos, clases o módulos de prueba, agréguelos al plan de prueba CTS-D y exclúyalos del plan de prueba CTS principal 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 su revisión adicional. El ingeniero de Google se comunicará con usted para brindarle comentarios sobre cómo se puede mejorar la prueba antes de que se pueda aceptar en CTS.

Consulte Calendario de lanzamientos e información de sucursales para obtener detalles sobre el calendario de lanzamientos de CTS.