Cree un caso IDT de prueba ejecutable - Gratis RTOS
Utilice el IDT cliente SDKHabilita IDT CLI los comandosEscritura de registros de eventosInforme los resultados a IDTEspecificación del comportamiento de salida

Las traducciones son generadas a través de traducción automática. En caso de conflicto entre la traducción y la version original de inglés, prevalecerá la version en inglés.

Cree un caso IDT de prueba ejecutable

Puede crear y colocar ejecutables de casos de prueba en una carpeta de conjunto de pruebas de las siguientes maneras:

  • En el caso de los conjuntos de pruebas que utilizan argumentos o variables de entorno de los archivos test.json para determinar qué pruebas se van a ejecutar, puede crear un único ejecutable de caso de prueba para todo el conjunto de pruebas o un ejecutable de prueba para cada grupo de pruebas del conjunto de pruebas.

  • En el caso de un conjunto de pruebas en el que desee ejecutar pruebas específicas en función de comandos específicos, debe crear un ejecutable de caso de prueba para cada caso de prueba del conjunto de pruebas.

Como redactor de pruebas, puede determinar qué enfoque es adecuado para su caso de uso y estructurar el ejecutable del caso de prueba en consecuencia. Asegúrese de proporcionar la ruta de acceso correcta al ejecutable del caso de prueba en cada archivo test.json y de que el ejecutable especificado se ejecute correctamente.

Cuando todos los dispositivos estén preparados para ejecutar un caso de prueba, IDT lee los siguientes archivos:

  • El test.json para el caso de prueba seleccionado determina los procesos que se van a iniciar y las variables de entorno que se van a configurar.

  • El suite.json para el conjunto de pruebas determina las variables de entorno que se van a configurar.

IDTinicia el proceso ejecutable de prueba requerido en función de los comandos y argumentos especificados en el test.json archivo y pasa las variables de entorno requeridas al proceso.

Utilice el IDT cliente SDK

El IDT cliente le SDKs permite simplificar la forma en que escribe la lógica de prueba en su ejecutable de prueba con API comandos que puede utilizar para interactuar con IDT los dispositivos que se están probando. IDTactualmente proporciona lo siguienteSDKs:

  • IDTCliente SDK para Python

  • IDTCliente SDK para Go

  • IDTCliente SDK para Java

Se SDKs encuentran en la <device-tester-extract-location>/sdks carpeta. Al crear un nuevo ejecutable de caso de prueba, debe copiar el SDK que desee utilizar en la carpeta que contiene el ejecutable de ese caso de prueba y hacer referencia a él SDK en el código. En esta sección se proporciona una breve descripción de los API comandos disponibles que puede utilizar en los ejecutables de sus casos de prueba.

Interacción con el dispositivo

Los siguientes comandos le permiten comunicarse con el dispositivo que se está probando sin tener que implementar ninguna función adicional de administración de la conectividad e interacción del dispositivo.

ExecuteOnDevice

Permite que los conjuntos de pruebas ejecuten comandos de shell en un dispositivo que admita SSH conexiones de shell de Docker.

CopyToDevice

Permite a las suites de pruebas copiar un archivo local de la máquina host IDT para que se ejecute en una ubicación específica de un dispositivo que admita SSH conexiones de shell de Docker.

ReadFromDevice

Permite que los conjuntos de pruebas lean desde el puerto serie de los dispositivos que admiten UART conexiones.

nota

Como IDT no gestiona las conexiones directas a los dispositivos que se realizan con la información de acceso a los dispositivos procedente del contexto, recomendamos utilizar estos API comandos de interacción entre dispositivos en los ejecutables de los casos de prueba. Sin embargo, si estos comandos no cumplen los requisitos del caso de prueba, puede recuperar la información de acceso al dispositivo del IDT contexto y utilizarla para establecer una conexión directa con el dispositivo desde el conjunto de pruebas.

Para establecer una conexión directa, recupere la información de los campos device.connectivity y resource.devices.connectivity del dispositivo que se está probando y de los dispositivos de recursos, respectivamente. Para obtener más información sobre el uso del IDT contexto, consulteUsa el IDT contexto.

IDTinteracción

Los siguientes comandos permiten que sus conjuntos de pruebas se comuniquen conIDT.

PollForNotifications

Permite que los conjuntos de pruebas comprueben las notificaciones deIDT.

GetContextValue y GetContextString

Permite que los conjuntos de pruebas recuperen valores del IDT contexto. Para obtener más información, consulte Usa el IDT contexto.

SendResult

Permite que los conjuntos de pruebas informen a los resultados de los casos de pruebaIDT. Debe llamarse a este comando al final de cada caso de prueba en un conjunto de pruebas.

Interacción con el host

El siguiente comando permite que sus conjuntos de pruebas se comuniquen con la máquina host.

PollForNotifications

Permite que las suites de pruebas comprueben las notificaciones deIDT.

GetContextValue y GetContextString

Permite que los conjuntos de pruebas recuperen valores del IDT contexto. Para obtener más información, consulte Usa el IDT contexto.

ExecuteOnHost

Permite a los conjuntos de pruebas ejecutar comandos en la máquina local y IDT gestionar el ciclo de vida del ejecutable del caso de prueba.

Habilita IDT CLI los comandos

El run-suite comando IDT CLI proporciona varias opciones que permiten al ejecutor de pruebas personalizar la ejecución de las pruebas. Para permitir que los ejecutores de pruebas utilicen estas opciones para ejecutar su conjunto de pruebas personalizado, debe implementar la compatibilidad con IDTCLI. Si no implementas la compatibilidad, los ejecutores de pruebas podrán seguir realizando pruebas, pero algunas CLI opciones no funcionarán correctamente. Para ofrecer una experiencia de cliente ideal, se recomienda implementar la compatibilidad con los siguientes argumentos para el run-suite comando en IDTCLI:

timeout-multiplier

Especifica un valor superior a 1,0 que se aplicará a todos los tiempos de espera durante la ejecución de las pruebas.

Los ejecutores de pruebas pueden usar este argumento para aumentar el tiempo de espera de los casos de prueba que desean ejecutar. Cuando un ejecutor de pruebas especifica este argumento en su run-suite comando, lo IDT usa para calcular el valor de la variable de TIMEOUT entorno IDT TEST _ _ y establece el config.timeoutMultiplier campo en el IDT contexto. Para que se admita este argumento, debe hacer lo siguiente:

  • En lugar de utilizar directamente el valor de tiempo de espera del test.json archivo, lee la variable de TIMEOUT entorno IDT TEST _ _ para obtener el valor de tiempo de espera calculado correctamente.

  • Recupere el config.timeoutMultiplier valor del IDT contexto y aplíquelo a los tiempos de espera prolongados.

Para obtener más información sobre cómo salir anticipadamente debido a eventos de tiempo de espera, consulte Especificación del comportamiento de salida.

stop-on-first-failure

Especifica que IDT deben dejar de ejecutarse todas las pruebas si se produce un error.

Cuando un ejecutor de pruebas especifique este argumento en su run-suite comando, IDT dejará de ejecutar las pruebas en cuanto detecte un error. Sin embargo, si los casos de prueba se ejecutan en paralelo, esto puede generar resultados inesperados. Para implementar el soporte, asegúrate de que, si IDT se produce este evento, tu lógica de pruebas indique a todos los casos de prueba en ejecución que se detengan, agoten los recursos temporales y notifiquen el resultado de la prueba aIDT. Para obtener más información sobre cómo salir anticipadamente en caso de error, consulte Especificación del comportamiento de salida.

group-id y test-id

Especifica que solo se IDT deben ejecutar los grupos de pruebas o los casos de prueba seleccionados.

Los ejecutores de pruebas pueden usar estos argumentos con su run-suite comando para especificar el siguiente comportamiento de ejecución de la prueba:

  • Ejecutar todas las pruebas dentro de los grupos de pruebas especificados.

  • Ejecutar una selección de pruebas desde un grupo de pruebas especificado.

Para admitir estos argumentos, la máquina de estados de su conjunto de pruebas debe incluir un conjunto específico de estados RunTask y Choice en su máquina de estados. Si no utiliza una máquina de estados personalizada, la máquina de IDT estados predeterminada incluye los estados necesarios y no es necesario que realice ninguna acción adicional. Sin embargo, si utiliza una máquina de estados personalizada, use Ejemplo de máquina de estados: ejecutar grupos de pruebas seleccionados por el usuario como ejemplo para añadir los estados necesarios a su máquina de estados.

Para obtener más información sobre IDT CLI los comandos, consulteDepuración y ejecución de conjuntos de pruebas personalizados.

Escritura de registros de eventos

Mientras se ejecuta la prueba, se envían datos a stdout y stderr para escribir registros de eventos y mensajes de error en la consola. Para obtener más información sobre el formato de los mensajes de la consola, consulte Formato de mensajes de consola.

Cuando IDT termine de ejecutar el conjunto de pruebas, esta información también estará disponible en el test_manager.log archivo ubicado en la <devicetester-extract-location>/results/<execution-id>/logs carpeta.

Puede configurar cada caso de prueba para que escriba los registros de la ejecución de la prueba, incluidos los registros del dispositivo que se está probando, en el archivo <group-id>_<test-id> ubicado en la carpeta <device-tester-extract-location>/results/execution-id/logs. Para ello, recupere la ruta del archivo de registro del IDT contexto de la testData.logFilePath consulta, cree un archivo en esa ruta y escriba el contenido que desee en él. IDTactualiza automáticamente la ruta en función del caso de prueba que se esté ejecutando. Si decide no crear el archivo de registro para un caso de prueba, no se generará ningún archivo para ese caso de prueba.

También puede configurar el ejecutable de texto para crear archivos de registro adicionales en la carpeta <device-tester-extract-location>/logs según sea necesario. Le recomendamos que especifique prefijos únicos para los nombres de los archivos de registro para que sus archivos no se sobrescriban.

Informe los resultados a IDT

IDTescribe los resultados de las pruebas en los archivos awsiotdevicetester_report.xml y en los suite-name_report.xml archivos. Estos archivos de informes están ubicados en <device-tester-extract-location>/results/<execution-id>/. Ambos informes capturan los resultados de la ejecución del conjunto de pruebas. Para obtener más información sobre los esquemas que se IDT utilizan en estos informes, consulte Revise los resultados y los registros de las IDT pruebas

Para rellenar el contenido del suite-name_report.xml archivo, debe utilizar el SendResult comando para informar de los resultados de las pruebas IDT antes de que finalice la ejecución de la prueba. Si IDT no puede localizar los resultados de una prueba, se emite un error para el caso de prueba. El siguiente extracto de Python muestra los comandos a los que se debe enviar el resultado de una prueba: IDT

request-variable = SendResultRequest(TestResult(result))
client.send_result(request-variable)

Si no publica los resultados a través deAPI, IDT busca los resultados de las pruebas en la carpeta de artefactos de prueba. La ruta a esta carpeta se guarda en testData.testArtifactsPath el archivo del IDT contexto. En esta carpeta, IDT utiliza el primer XML archivo ordenado alfabéticamente que encuentre como resultado de la prueba.

Si la lógica de las pruebas arroja JUnit XML resultados, puede escribirlos en un XML archivo de la carpeta de artefactos para proporcionárselos directamente, IDT en lugar de analizarlos y luego utilizarlos API para enviarlos. IDT

Si utiliza este método, asegúrese de que la lógica de la prueba resuma con precisión los resultados de la prueba y formatee el archivo de resultados con el mismo formato que el archivo suite-name_report.xml. IDTno realiza ninguna validación de los datos que usted proporciona, con las siguientes excepciones:

  • IDTignora todas las propiedades de la testsuites etiqueta. En su lugar, calcula las propiedades de la etiqueta a partir de los resultados de otros grupos de pruebas notificados.

  • Debe haber al menos una etiqueta testsuite en testsuites.

Como IDT utiliza la misma carpeta de artefactos para todos los casos de prueba y no elimina los archivos de resultados entre las ejecuciones de las pruebas, este método también puede provocar informes erróneos si IDT lee el archivo incorrecto. Le recomendamos que utilice el mismo nombre para el archivo de XML resultados generado en todos los casos de prueba para sobrescribir los resultados de cada caso de prueba y asegurarse de que los resultados correctos estén disponibles para su IDT uso. Aunque puede utilizar un enfoque mixto para la elaboración de informes en su conjunto de pruebas, es decir, utilizar un archivo de XML resultados para algunos casos de prueba y enviar los resultados a través del conjunto de pruebas API para otros, no recomendamos este enfoque.

Especificación del comportamiento de salida

Configure el ejecutable de texto para que siempre salga con un código de salida de 0, incluso si un caso de prueba informa de un fallo o un resultado de error. Utilice códigos de salida distintos de cero únicamente para indicar que un caso de prueba no se ha ejecutado o si el ejecutable del caso de prueba no ha podido comunicarle ningún resultado. IDT Cuando IDT recibe un código de salida distinto de cero, indica que el caso de prueba ha detectado un error que ha impedido su ejecución.

IDTpodría solicitar o esperar que un caso de prueba deje de ejecutarse antes de que finalice en los siguientes eventos. Utilice esta información para configurar el ejecutable del caso de prueba para que detecte cada uno de estos eventos del caso de prueba:

Timeout (Tiempo de espera)

Se produce cuando un caso de prueba se ejecuta durante más tiempo que el valor de tiempo de espera especificado en el archivo test.json. Si el ejecutor de la prueba usó el timeout-multiplier argumento para especificar un multiplicador de tiempo de espera, IDT calcula el valor del tiempo de espera con el multiplicador.

Para detectar este evento, utilice la variable de entorno IDT _ _TEST. TIMEOUT Cuando un ejecutor de pruebas lanza una prueba, IDT establece el valor de la variable de TIMEOUT entorno IDT TEST _ _ en el valor de tiempo de espera calculado (en segundos) y pasa la variable al ejecutable del caso de prueba. Puede leer el valor de la variable para configurar un temporizador adecuado.

Interrumpir

Se produce cuando el ejecutor de la prueba interrumpeIDT. Por ejemplo, pulsando Ctrl+C.

Como los terminales propagan las señales a todos los procesos secundarios, solo tiene que configurar un controlador de señales en sus casos de prueba para detectar las señales de interrupción.

Como alternativa, puede sondear periódicamente API para comprobar el valor del CancellationRequested booleano en la respuesta. PollForNotifications API Cuando IDT recibe una señal de interrupción, establece el valor del CancellationRequested booleano en. true

Detención en el primer fallo

Se produce cuando un caso de prueba que se está ejecutando en paralelo con el caso de prueba actual falla y el ejecutor de la prueba utiliza el stop-on-first-failure argumento para especificar que IDT debe detenerse cuando encuentra algún error.

Para detectar este evento, puedes sondear periódicamente el API valor del CancellationRequested booleano en la PollForNotifications API respuesta. Cuando IDT detecta un error y está configurado para detenerse en el primer error, establece el valor del CancellationRequested booleano en. true

Cuando se produce alguno de estos eventos, IDT espera 5 minutos a que terminen de ejecutarse todos los casos de prueba que se estén ejecutando actualmente. Si todos los casos de prueba en ejecución no se cierran en 5 minutos, IDT obliga a detener cada uno de sus procesos. Si no IDT ha recibido los resultados de las pruebas antes de que finalicen los procesos, marcará los casos de prueba como agotados. Como práctica recomendada, debe asegurarse de que los casos de prueba realicen las siguientes acciones cuando detecten alguno de estos eventos:

  1. Dejar de ejecutar la lógica de prueba normal.

  2. Limpiar todos los recursos temporales, como los artefactos de prueba del dispositivo que se está probando.

  3. Informe el resultado de una prueba aIDT, por ejemplo, una falla o un error en la prueba.

  4. Salir.