Uso de la consola CTS v2
Para Android 7.0 o superior, use CTS v2.
Selección de planes
Los planes de prueba disponibles incluyen lo siguiente:
- cts : ejecuta CTS desde una instalación de CTS preexistente.
- cts-camera : ejecuta CTS-camera desde una instalación de CTS preexistente.
- cts-java : ejecuta pruebas de Core Java desde una instalación de CTS preexistente.
- cts-pdk : ejecuta pruebas útiles para validar una compilación de fusión de PDK.
- todo : configuración común para suites de compatibilidad.
Otras configuraciones disponibles incluyen las siguientes:
- basic-reporters — Configuración con reporteros CTS básicos.
- collect-tests-only: ejecuta CTS desde una instalación de CTS preexistente.
- common-compatibility-config — Configuración común para suites de compatibilidad.
- cts-filtered-sample — Configuración común para suites de compatibilidad.
- cts-known-failures — Configuración con fallas conocidas de CTS.
- cts-preconditions — Configuraciones de condiciones previas de CTS.
- host : ejecuta una única prueba basada en host en un dispositivo existente.
- instrument : ejecuta una sola prueba de instrumentación de Android en un dispositivo existente.
- native-benchmark : ejecuta una prueba de esfuerzo nativa en un dispositivo existente.
- native-stress : ejecuta una prueba de estrés nativo en un dispositivo existente.
- recarga : una prueba falsa que espera dispositivos casi descargados y los retiene para cargarlos.
- testdef : ejecuta las pruebas contenidas en los archivos test_def.xml en un dispositivo existente.
- util/wifi — Configuración de la utilidad para configurar Wi-Fi en el dispositivo.
- util/wipe : borra los datos del usuario en el dispositivo.
Todos estos planes y configuraciones se pueden ejecutar con el comando run cts .
Referencia de comandos de la consola CTS v2
Esta tabla resume los comandos de la consola CTS v2 para varios usos.
| Anfitrión | Descripción |
|---|---|
help | Mostrar un resumen de los comandos más utilizados |
help all | Mostrar la lista completa de comandos disponibles |
version | Mostrar la versión. |
exit | Salga con gracia de la consola CTS. La consola se cierra cuando finalizan todas las pruebas que se están ejecutando actualmente. |
extdir | El archivo de descargas comprimido se descomprime en Si desea descomprimir en el directorio actual, no use la opción |
| Correr | Descripción |
run cts | En Android 10, ejecute el plan CTS predeterminado y CTS-Instant juntos (es decir, la invocación completa de CTS). Para Android 9 o inferior, ejecute solo el plan CTS predeterminado. Utilice esta opción integral (incluidas las condiciones previas) para la validación del dispositivo. Consulte cts.xml para ver las inclusiones. La consola CTS puede aceptar otros comandos mientras se realizan las pruebas. Si no hay dispositivos conectados, la máquina de escritorio CTS (o host) esperará a que se conecte un dispositivo antes de iniciar las pruebas. Si hay más de un dispositivo conectado, el host CTS elegirá un dispositivo automáticamente. |
run cts-instant | Para Android 9, ejecute el plan CTS-Instant predeterminado. |
run cts --module-parameter INSTANT_APP | En Android 10, ejecute el plan CTS-Instant predeterminado. |
run cts --module-parameter INSTANT_APP --module/-m test_module_name | En Android 10, ejecute el módulo o los módulos de prueba CTS-Instant especificados. |
run retry | Solo para Android 9 o superior. Vuelva a intentar todas las pruebas que fallaron o que no se ejecutaron en las sesiones anteriores. Por ejemplo, |
run cts-sim | Para Android 11 o versiones superiores. Ejecuta el subconjunto de pruebas en un dispositivo con tarjeta SIM. |
--device-token | Para Android 8.1 o versiones inferiores. Especifica que un dispositivo dado tiene el token dado. Por ejemplo, |
--enable-token-sharding | Solo para Android 10 o superior . Coincide automáticamente con la prueba que requiere el tipo de SIM respectivo. No es necesario proporcionar un número de serie del dispositivo para ejecutar casos de prueba relacionados con SIM. SIM compatibles: |
run cts-dev | Ejecute el plan CTS predeterminado (es decir, la invocación completa de CTS) pero omita las condiciones previas para ahorrar tiempo de ejecución para el desarrollo iterativo de una nueva prueba. Esto omite la verificación y la configuración de la configuración del dispositivo, como enviar archivos multimedia o verificar la conexión Wi-Fi, como se hace cuando se usa la opción La consola CTS puede aceptar otros comandos mientras se realizan las pruebas. Si no hay dispositivos conectados, la máquina de escritorio CTS (o host) esperará a que se conecte un dispositivo antes de iniciar las pruebas. Si hay más de un dispositivo conectado, el host CTS elegirá un dispositivo automáticamente. |
--subplan subplan_name | Ejecute el subplan especificado. |
--module/-m test_module_name --test/-t test_name | Ejecute el módulo especificado y pruebe. Por ejemplo, run cts -m Gesture --test android.gesture.cts.GestureTest#testGetStrokes ejecuta el paquete, la clase o la prueba específicos. |
--retry | Vuelva a intentar todas las pruebas que fallaron o que no se ejecutaron en las sesiones anteriores. Use los list results para obtener la identificación de la sesión. |
--retry-type NOT_EXECUTED | Vuelva a intentar solo las pruebas que no se ejecutaron en las sesiones anteriores. Use los list results para obtener la identificación de la sesión. |
--shards number_of_shards | Para Android 8.1 o versiones inferiores . Fragmente una ejecución de CTS en un número determinado de fragmentos independientes, para ejecutarse en varios dispositivos en paralelo. |
--shard-count number_of_shards | Para Android 9 . Fragmente una ejecución de CTS en un número determinado de fragmentos independientes, para ejecutarse en varios dispositivos en paralelo. |
--serial/-s deviceID | Ejecute CTS en el dispositivo específico. |
--include-filter "test_module_name test_name" | Ejecutar con los módulos especificados o paquetes de prueba, clases y casos. Por ejemplo, run cts --include-filter "CtsCalendarcommon2TestCases android.calendarcommon2.cts.Calendarcommon2Test#testStaticLinking" incluye el módulo especificado.Esta opción de comando no se admite cuando se ejecuta el reintento. |
--exclude-filter "test_module_name test_name" | Excluya los módulos especificados, o paquetes de prueba, clases y casos, de la ejecución. Por ejemplo, run cts --exclude-filter "CtsCalendarcommon2Test android.calendarcommon2.cts.Calendarcommon2Test#testStaticLinking" excluye el módulo especificado. |
--log-level-display/-l log_level | Ejecutar con el nivel de registro mínimo especificado que se muestra en STDOUT . Valores válidos: [ VERBOSE , DEBUG , INFO , WARN , ERROR , ASSERT ]. |
--abi abi_name | Fuerce la ejecución de la prueba en el ABI dado, 32 o 64. De forma predeterminada, CTS ejecuta una prueba una vez para cada ABI que admite el dispositivo. |
--logcat-on-failure ,--bugreport-on-failure ,--screenshoot-on-failure | Da más visibilidad a las fallas y puede ayudar con el diagnóstico. |
--device-token | Especifica que un dispositivo dado tiene el token dado, como --device-token 1a2b3c4d:sim-card . |
--skip-device-info | Omite la recopilación de información sobre el dispositivo. |
--skip-preconditions | Omita las condiciones previas para ahorrar tiempo de ejecución para el desarrollo iterativo de una nueva prueba. Esto omite la verificación y la configuración de la configuración del dispositivo, como enviar archivos multimedia o verificar la conexión Wi-Fi. |
| Lista | Descripción |
list modules | Enumere todos los módulos de prueba disponibles en el repositorio. |
list plans o list configs | Enumere todos los planes de prueba disponibles (configuraciones) en el repositorio. |
list subplans | Enumere todos los subplanes disponibles en el repositorio. |
list invocations | Enumere los comandos 'ejecutar' que se están ejecutando actualmente en los dispositivos. |
list commands | Enumere todos los comandos 'ejecutar' actualmente en la cola esperando ser asignados a los dispositivos. |
list results | Enumere los resultados de CTS almacenados actualmente en el repositorio. |
list devices | Enumere los dispositivos conectados actualmente y su estado. Los dispositivos 'disponibles' están funcionando, dispositivos inactivos, disponibles para ejecutar pruebas. Los dispositivos 'no disponibles' son dispositivos visibles a través de adb, pero que no responden a los comandos de adb y no se asignarán para las pruebas. Los dispositivos 'asignados' son dispositivos que actualmente ejecutan pruebas. |
| Vertedero | Descripción |
dump logs | Vuelca los registros tradefed para todas las invocaciones en ejecución. |
| Agregar | Descripción |
add subplan --name/-n subplan_name | Crear un subplan derivado de la sesión anterior; esta opción genera un subplan que se puede utilizar para ejecutar un subconjunto de pruebas. La única opción requerida es --session . Otros son opcionales pero, cuando se incluyen, deben ir seguidos de un valor. La opción --result-type es repetible; por ejemplo add subplan --session 0 --result-type passed --result-type failed es válido. |