Cree ejecutables de casos de prueba de IDT - AWS IoT Greengrass
Utilice el SDK del cliente IDTHabilitar comandos de la CLIEscribir registros de eventosInforme los resultados a IDTEspecificar el 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 ejecutables de casos de prueba de IDT

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

  • Para los conjuntos de pruebas que utilizan argumentos o variables de entorno de lostest.json archivos para determinar qué pruebas 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.

  • Para un conjunto de pruebas en el que desee ejecutar pruebas específicas en función de comandos especificados, cree un ejecutable de caso de prueba para cada caso de prueba del conjunto de pruebas.

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

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

  • Eltest.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 conjuntosuite.json de pruebas determina las variables de entorno que se van a configurar.

IDT inicia el proceso ejecutable de prueba requerido en función de los comandos y argumentos especificados en eltest.json archivo y pasa las variables de entorno necesarias al proceso.

Utilice el SDK del cliente IDT

Los SDK de IDT Client te permiten simplificar la forma en que escribes la lógica de prueba en tu ejecutable de prueba con comandos de API que puedes usar para interactuar con IDT y los dispositivos que se están probando. IDT ofrece actualmente los siguientes SDK:

  • SDK para Python

  • SDK for Go

  • SDK for Java

Estos SDK se encuentran en la<device-tester-extract-location>/sdks carpeta. Al crear un nuevo ejecutable de caso de prueba, debes copiar el SDK que deseas usar en la carpeta que contiene el ejecutable de caso de prueba y hacer referencia al SDK en tu código. En esta sección se proporciona una breve descripción de los comandos de API disponibles que puedes usar en los ejecutables de tu caso de prueba.

Interacción entre dispositivos

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 conectividad e interacción del dispositivo.

ExecuteOnDevice

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

CopyToDevice

Permite que los conjuntos de pruebas copien un archivo local de la máquina host que ejecuta IDT a una ubicación específica en un dispositivo que admita conexiones SSH o Docker shell.

ReadFromDevice

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

nota

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

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

Interacción IDT

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

PollForNotifications

Permite que los conjuntos de pruebas comprueben las notificaciones de IDT.

GetContextValue y GetContextString

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

SendResult

Permite que los conjuntos de pruebas informen de los resultados de los casos de prueba a IDT. Este comando debe invocarse al final de cada caso de prueba en un conjunto de pruebas.

Interacción con el anfitrión

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

PollForNotifications

Permite que los conjuntos de pruebas comprueben las notificaciones de IDT.

GetContextValue y GetContextString

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

ExecuteOnHost

Permite que los conjuntos de pruebas ejecuten comandos en la máquina local y permite a IDT gestionar el ciclo de vida de los ejecutables de los casos de prueba.

Habilitar comandos de la CLI

Elrun-suite comando IDT CLI proporciona varias opciones que permiten al ejecutor de pruebas personalizar la ejecución de la prueba. Para permitir que los ejecutores de pruebas utilicen estas opciones para ejecutar su conjunto de pruebas personalizado, implemente la compatibilidad con la CLI de IDT. Si no implementa el soporte, los ejecutores de pruebas podrán seguir ejecutándolas, pero algunas opciones de la CLI no funcionarán correctamente. Para ofrecer una experiencia de cliente ideal, le recomendamos que implemente la compatibilidad con los siguientes argumentos para elrun-suite comando en la CLI de IDT:

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 surun-suite comando, IDT lo usa para calcular el valor de la variable de entorno IDT_TEST_TIMEOUT y establece elconfig.timeoutMultiplier campo en el contexto de IDT. Para respaldar este argumento, debe hacer lo siguiente:

  • En lugar de utilizar directamente el valor de tiempo de espera deltest.json archivo, lea la variable de entorno IDT_TEST_TIMEOUT para obtener el valor de tiempo de espera calculado correctamente.

  • Recupera elconfig.timeoutMultiplier valor del contexto de IDT y aplícalo a tiempos de espera prolongados.

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

stop-on-first-failure

Especifica que IDT debe dejar de ejecutar todas las pruebas si se produce un error.

Cuando un ejecutor de pruebas especifica este argumento en surun-suite comando, IDT dejará de ejecutar las pruebas tan pronto como detecte un error. Sin embargo, si los casos de prueba se ejecutan en parallel, esto puede generar resultados inesperados. Para implementar el soporte, asegúrese de que, si IDT detecta este evento, su lógica de prueba indique a todos los casos de prueba en ejecución que se detengan, limpien los recursos temporales e informen del resultado de la prueba a IDT. Para obtener más información acerca de cómo salir anticipadamente en caso de errores, consulteEspecificar el comportamiento de salida.

group-id y test-id

Especifica que IDT debe ejecutar solo los grupos de prueba o casos de prueba seleccionados.

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

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

  • Ejecute una selección de pruebas dentro de un grupo de pruebas especificado.

Para respaldar estos argumentos, el orquestador de pruebas de su conjunto de pruebas debe incluir un conjuntoRunTask yChoice estados específicos en su orquestador de pruebas. Si no utiliza una máquina de estados personalizada, el orquestador de pruebas IDT predeterminado incluye los estados necesarios para usted y no necesita realizar ninguna acción adicional. Sin embargo, si utiliza un orquestador de pruebas personalizado, utilíceloMáquina de estado de ejemplo: Ejecutar grupos de prueba seleccionados por el usuario como ejemplo para añadir los estados requeridos en su orquestador de pruebas.

Para obtener más información acerca de los comandos de la CLI de IDT, consulteDepurar y ejecutar conjuntos de pruebas personalizadas.

Escribir registros de eventos

Mientras se ejecuta la prueba, se envían datos a la consolastdout ystderr se escriben registros de eventos y mensajes de error en ella. Para obtener información acerca del formato de los mensajes de la consola, consulteFormato de mensajes de consola.

Cuando el IDT termine de ejecutar el conjunto de pruebas, esta información también estará disponible en eltest_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 su ejecución de prueba, incluidos los registros del dispositivo que se está probando, en el<group-id>_<test-id> archivo que se encuentra en la<device-tester-extract-location>/results/execution-id/logs carpeta. Para ello, recupere la ruta al archivo de registro del contexto IDT con latestData.logFilePath consulta, cree un archivo en esa ruta y escriba el contenido que desee en él. IDT actualiza 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 según sea necesario en la<device-tester-extract-location>/logs carpeta. Le recomendamos que especifique prefijos únicos para los nombres de los archivos de registro para que no se sobrescriban.

Informe los resultados a IDT

IDT escribe los resultados de las pruebas enawsiotdevicetester_report.xml y en lossuite-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 IDT utiliza para estos informes, consulteRevisar los resultados y registros de las pruebas IDT

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

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

Si no notifica los resultados a través de la API, IDT busca los resultados de las pruebas en la carpeta de artefactos de prueba. La ruta a esta carpeta se almacena en eltestData.testArtifactsPath archivo en el contexto IDT. En esta carpeta, IDT utiliza el primer archivo XML ordenado alfabéticamente que encuentra como resultado de la prueba.

Si su lógica de prueba produce resultados XML de JUnit, puede escribir los resultados de la prueba en un archivo XML de la carpeta artefactos para proporcionar los resultados directamente a IDT en lugar de analizar los resultados y, a continuación, utilizar la API para enviarlos a IDT.

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

  • IDT ignora todas las propiedades de latestsuites etiqueta. En su lugar, calcula las propiedades de las etiquetas a partir de los resultados de otros grupos de prueba informados.

  • Debe existir al menos unatestsuite etiqueta en su interiortestsuites.

Dado que 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 generar informes erróneos si IDT lee el archivo incorrecto. Le recomendamos que utilice el mismo nombre para el archivo de resultados XML 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 que IDT los utilice. Si bien puede utilizar un enfoque mixto para generar informes en su conjunto de pruebas, es decir, utilizar un archivo de resultados XML para algunos casos de prueba y enviar los resultados a través de la API para otros, no recomendamos este enfoque.

Especificar el comportamiento de salida

Configure su ejecutable de texto para que salga siempre con un código de salida igual a 0, incluso si un caso de prueba indica un error o el resultado de un error. Utilice códigos de salida distintos de cero únicamente para indicar que un caso de prueba no se ejecutó o si el ejecutable del caso de prueba no pudo comunicar ningún resultado a IDT. Cuando IDT recibe un código de salida distinto de cero, indica que el caso de prueba ha encontrado un error que ha impedido su ejecución.

IDT podrí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 detectar 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 eltest.json archivo. Si el ejecutor de la prueba utilizó eltimeout-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 entorno IDT_TEST_TIMEOUT en el valor del 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 interrumpe el IDT. Por ejemplo, pulsandoCtrl+C.

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

Como alternativa, puedes sondear periódicamente la API para comprobar el valor delCancellationRequested booleano en la respuesta de laPollForNotifications API. Cuando IDT recibe una señal de interrupción, establece el valor delCancellationRequested booleano entrue.

Se detiene en el primer error

Se produce cuando un caso de prueba que se ejecuta en parallel con el caso de prueba actual falla y el ejecutor de la prueba utiliza elstop-on-first-failure argumento para especificar que IDT debe detenerse cuando se produce algún error.

Para detectar este evento, puedes sondear periódicamente la API para comprobar el valor delCancellationRequested booleano en la respuesta de laPollForNotifications API. Cuando IDT detecta un error y se configura para detenerse en el primer error, establece el valor delCancellationRequested booleano entrue.

Cuando se produce alguno de estos eventos, IDT espera 5 minutos hasta que los casos de prueba que se estén ejecutando actualmente terminen de ejecutarse. Si todos los casos de prueba en ejecución no salen en 5 minutos, el IDT obliga a detener cada uno de sus procesos. Si IDT no 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 se encuentren con uno de los eventos:

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

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

  3. Informe el resultado de una prueba a IDT, como una falla o un error en la prueba.

  4. Salida.