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. # Uso de IDT para desarrollar y ejecutar sus propios conjuntos de pruebas A partir de la versión 4.0.1 de IDT, IDT para AWS IoT Greengrass V2 combina una configuración y un formato de resultados estandarizados con un entorno de conjuntos de pruebas que le permite desarrollar conjuntos de pruebas personalizados para sus dispositivos y el software de los dispositivos. Puede añadir pruebas personalizadas para su propia validación interna o proporcionárselas a sus clientes para la verificación de los dispositivos. Utilice IDT para desarrollar y ejecutar conjuntos de pruebas personalizados, de la siguiente manera: **Para desarrollar conjuntos de pruebas personalizados** + Cree conjuntos de pruebas con lógica de prueba personalizada para el dispositivo Greengrass que desee probar. + Proporcione a IDT sus conjuntos de pruebas personalizados para los corredores de pruebas. Incluya información sobre las configuraciones de configuración específicas de sus conjuntos de pruebas. **Ejecución de conjuntos de pruebas personalizados** + Configure el dispositivo que desea probar. + Implemente las configuraciones requeridas por los conjuntos de pruebas que desee utilizar. + Utilice IDT para ejecutar sus conjuntos de pruebas personalizados. + Vea los resultados de las pruebas y los registros de ejecución de las pruebas realizadas por IDT. ## Descargue la última versión de for AWS IoT Device Tester AWS IoT Greengrass Descargue la [última versión](idt-programmatic-download.md) de IDT y extraiga el software en una ubicación (**) del sistema de archivos en la que tenga permisos de lectura/escritura. **nota** IDT no admite la ejecución por parte de varios usuarios desde una ubicación compartida, como un directorio NFS o una carpeta compartida de red de Windows. Le recomendamos que extraiga el paquete IDT en una unidad local y ejecute el binario IDT en su estación de trabajo local. Windows tiene una limitación de longitud de ruta de 260 caracteres. Si utiliza Windows, extraiga IDT en un directorio raíz como `C:\ ` o `D:\` para mantener las rutas por debajo del límite de 260 caracteres. ## Flujo de trabajo de creación de conjuntos de prueba Los conjuntos de pruebas se componen de tres tipos de archivos: + Archivos de configuración que proporcionan a IDT información sobre cómo ejecutar el conjunto de pruebas. + Archivos ejecutables de prueba que IDT utiliza para ejecutar los casos de prueba. + Archivos adicionales necesarios para ejecutar las pruebas. Complete los siguientes pasos básicos para crear pruebas de IDT personalizadas: 1. [Cree archivos de configuración](idt-json-config.md) para su conjunto de pruebas. 1. [Cree ejecutables de casos de prueba](create-test-executables.md) que contengan la lógica de prueba de su conjunto de pruebas. 1. Verifique y documente la [información de configuración necesaria para que los ejecutores de pruebas](set-custom-idt-config.md) ejecuten el conjunto de pruebas. 1. Compruebe que IDT pueda ejecutar su conjunto de pruebas y producir los [resultados de las pruebas](run-debug-custom-tests.md) según lo esperado. Para crear rápidamente un conjunto personalizado de muestra y ejecutarlo, siga las instrucciones que se indican en [Tutorial: crear y ejecutar el ejemplo del conjunto de pruebas de IDT](build-sample-suite.md). Para empezar a crear un conjunto de pruebas personalizado en Python, consulte [Tutorial: Desarrollar un conjunto de pruebas de IDT sencillo](create-custom-tests.md). # Tutorial: crear y ejecutar el ejemplo del conjunto de pruebas de IDT La AWS IoT Device Tester descarga incluye el código fuente de un conjunto de pruebas de muestra. Puede completar este tutorial para crear y ejecutar el conjunto de pruebas de ejemplo para comprender cómo puede usar IDT AWS IoT Greengrass para ejecutar conjuntos de pruebas personalizados. En este tutorial, debe completar los siguientes pasos: 1. [Creación del conjunto de pruebas de muestra](#build-sample) 1. [Uso de IDT para ejecutar el conjunto de pruebas de muestra](#run-sample) ## Requisitos previos Necesitará lo siguiente para completar este tutorial: + **Requisitos del equipo host** + Versión más reciente de AWS IoT Device Tester + [Python](https://www.python.org/downloads/) 3.7 o posterior Para comprobar la versión de Python instalada en el equipo, ejecute el siguiente comando: ``` python3 --version ``` En Windows, si el uso de este comando devuelve un error, utilice `python --version` en su lugar. Si el número de versión devuelto es 3.7 o superior, ejecute el siguiente comando en una terminal de Powershell para configurar `python3` como alias para el comando `python`. ``` Set-Alias -Name "python3" -Value "python" ``` Si no se devuelve información sobre la versión o si la versión es inferior a 3.7, siga las instrucciones que se indican en [Descarga de Python](https://wiki.python.org/moin/BeginnersGuide/Download) para instalar Python 3.7 o superior. Para obtener más información, consulte la [documentación de Python](https://docs.python.org). + [urllib3](https://urllib3.readthedocs.io/en/latest/) Para comprobar que `urllib3` se ha instalado correctamente, ejecute el siguiente comando: ``` python3 -c 'import urllib3' ``` Si `urllib3` no está instalado, ejecute el siguiente comando para instalarlo: ``` python3 -m pip install urllib3 ``` + **Requisitos de los dispositivos** + Un dispositivo con un sistema operativo Linux y una conexión de red a la misma red que el equipo host. Le recomendamos que utilice un [Raspberry Pi](https://www.raspberrypi.org/) con el sistema operativo Raspberry Pi. Asegúrese de que tiene configurado [SSH](https://www.raspberrypi.org/documentation/remote-access/ssh/) en el Raspberry Pi para conectarse de forma remota. ## Configuración de la información del dispositivo para IDT Configure la información del dispositivo para que IDT ejecute la prueba. Debe actualizar la plantilla `device.json` ubicada en la carpeta `/configs` con la siguiente información. ``` [ { "id": "pool", "sku": "N/A", "devices": [ { "id": "", "connectivity": { "protocol": "ssh", "ip": "", "port": "", "auth": { "method": "pki | password", "credentials": { "user": "", "privKeyPath": "/path/to/private/key", "password": "" } } } } ] } ] ``` En el objeto `devices`, indique la siguiente información: `id` Un identificador único definido por el usuario para el dispositivo. `connectivity.ip` La dirección IP del dispositivo. `connectivity.port` Opcional. El número de puerto que se va a utilizar para las conexiones SSH al dispositivo. `connectivity.auth` Información de autenticación para la conexión. Esta propiedad solo se aplica si `connectivity.protocol` está establecido en `ssh`. `connectivity.auth.method` El método de autenticación que se utiliza para acceder a un dispositivo a través de un determinado protocolo de conectividad. Los valores admitidos son: + `pki` + `password` `connectivity.auth.credentials` Las credenciales que se utilizan para la autenticación. `connectivity.auth.credentials.user` El nombre de usuario utilizado para iniciar sesión en el dispositivo. `connectivity.auth.credentials.privKeyPath` La ruta completa a la clave privada que se utiliza para iniciar sesión en el dispositivo. Este valor solo se aplica si `connectivity.auth.method` está establecido en `pki`. `devices.connectivity.auth.credentials.password` La contraseña que se utiliza para iniciar sesión en el dispositivo. Este valor solo se aplica si `connectivity.auth.method` está establecido en `password`. **nota** Especifique `privKeyPath` solo si `method` está establecido en `pki` Especifique `password` solo si `method` está establecido en `password` ## Creación del conjunto de pruebas de muestra La carpeta `/samples/python` contiene ejemplos de archivos de configuración, código fuente y el SDK de cliente de IDT que puede combinar en un conjunto de pruebas mediante los scripts de creación proporcionados. El siguiente árbol de directorios muestra la ubicación de estos archivos de ejemplo: ``` ├── ... ├── tests ├── samples │ ├── ... │ └── python │ ├── configuration │ ├── src │ └── build-scripts │ ├── build.sh │ └── build.ps1 └── sdks ├── ... └── python └── idt_client ``` Para crear el conjunto de pruebas, ejecute los siguientes comandos en el equipo host: ------ #### [ Windows ] ``` cd /samples/python/build-scripts ./build.ps1 ``` ------ #### [ Linux, macOS, or UNIX ] ``` cd /samples/python/build-scripts ./build.sh ``` ------ Esto crea el conjunto de pruebas de muestra en la carpeta `IDTSampleSuitePython_1.0.0`, dentro de la carpeta `/tests`. Revise los archivos de la carpeta `IDTSampleSuitePython_1.0.0` para ver cómo está estructurado el conjunto de pruebas de muestra y consulte varios ejemplos de ejecutables de casos de prueba y archivos JSON de configuración de pruebas. **nota** El conjunto de pruebas de muestra incluye el código fuente de Python. No incluya información confidencial en el código del conjunto de pruebas. Siguiente paso: Uso de IDT para [ejecutar el conjunto de pruebas de muestra](#run-sample) que creó. ## Uso de IDT para ejecutar el conjunto de pruebas de muestra Para ejecutar el conjunto de pruebas de muestra, ejecute los siguientes comandos en el equipo host: ``` cd /bin ./devicetester_[linux | mac | win_x86-64] run-suite --suite-id IDTSampleSuitePython ``` IDT ejecuta el conjunto de pruebas de muestra y transmite los resultados a la consola. Cuando la prueba termine de ejecutarse, verá la siguiente información: ``` ========== Test Summary ========== Execution Time: 5s Tests Completed: 4 Tests Passed: 4 Tests Failed: 0 Tests Skipped: 0 ---------------------------------- Test Groups: sample_group: PASSED ---------------------------------- Path to IoT Device Tester Report: /path/to/devicetester/results/87e673c6-1226-11eb-9269-8c8590419f30/awsiotdevicetester_report.xml Path to Test Execution Logs: /path/to/devicetester/results/87e673c6-1226-11eb-9269-8c8590419f30/logs Path to Aggregated JUnit Report: /path/to/devicetester/results/87e673c6-1226-11eb-9269-8c8590419f30/IDTSampleSuitePython_Report.xml ``` ## Resolución de problemas Utilice la siguiente información para resolver cualquier problema que pueda surgir al completar el tutorial. **El caso de prueba no se ejecuta correctamente** Si la prueba no se ejecuta correctamente, IDT transmite los registros de errores a la consola para ayudarle a solucionar los problemas de la prueba. Asegúrese de que cumple con todos los [requisitos previos](#prereqs-tutorial-sample) de este tutorial. **No se puede conectar al dispositivo que se está probando** Compruebe lo siguiente: + El archivo `device.json` contiene la dirección IP, el puerto y la información de autenticación correctos. + Puede conectarse a su dispositivo a través de SSH desde su equipo host. # Tutorial: Desarrollar un conjunto de pruebas de IDT sencillo Un conjunto de pruebas combina lo siguiente: + Ejecutables de prueba que contienen la lógica de prueba + Archivos de configuración que describen el conjunto de pruebas Este tutorial le muestra cómo usar IDT AWS IoT Greengrass para desarrollar un conjunto de pruebas de Python que contenga un único caso de prueba. En este tutorial, debe completar los siguientes pasos: 1. [Creación de un directorio del conjunto de pruebas](#test-suite-dir) 1. [Creación de archivos de configuración](#test-suite-json) 1. [Creación del ejecutable del caso de prueba](#test-suite-exe) 1. [Ejecución del conjunto de pruebas](#run-test-suite) ## Requisitos previos Necesitará lo siguiente para completar este tutorial: + **Requisitos del equipo host** + Última versión de AWS IoT Device Tester + [Python](https://www.python.org/downloads/) 3.7 o posterior Para comprobar la versión de Python instalada en el equipo, ejecute el siguiente comando: ``` python3 --version ``` En Windows, si el uso de este comando devuelve un error, utilice `python --version` en su lugar. Si el número de versión devuelto es 3.7 o superior, ejecute el siguiente comando en una terminal de Powershell para configurar `python3` como alias para el comando `python`. ``` Set-Alias -Name "python3" -Value "python" ``` Si no se devuelve información sobre la versión o si la versión es inferior a 3.7, siga las instrucciones que se indican en [Descarga de Python](https://wiki.python.org/moin/BeginnersGuide/Download) para instalar Python 3.7 o superior. Para obtener más información, consulte la [documentación de Python](https://docs.python.org). + [urllib3](https://urllib3.readthedocs.io/en/latest/) Para comprobar que `urllib3` se ha instalado correctamente, ejecute el siguiente comando: ``` python3 -c 'import urllib3' ``` Si `urllib3` no está instalado, ejecute el siguiente comando para instalarlo: ``` python3 -m pip install urllib3 ``` + **Requisitos de los dispositivos** + Un dispositivo con un sistema operativo Linux y una conexión de red a la misma red que el equipo host. Le recomendamos que utilice un [Raspberry Pi](https://www.raspberrypi.org/) con el sistema operativo Raspberry Pi. Asegúrese de que tiene configurado [SSH](https://www.raspberrypi.org/documentation/remote-access/ssh/) en el Raspberry Pi para conectarse de forma remota. ## Creación de un directorio del conjunto de pruebas IDT separa de forma lógica los casos de prueba en grupos de pruebas dentro de cada conjunto de pruebas. Cada caso de prueba debe estar dentro de un grupo de prueba. Para este tutorial, cree una carpeta llamada `MyTestSuite_1.0.0` y cree el siguiente árbol de directorios dentro de esta carpeta: ``` MyTestSuite_1.0.0 └── suite └── myTestGroup └── myTestCase ``` ## Creación de archivos de configuración El conjunto de pruebas debe contener los siguientes [archivos de configuración](idt-json-config.md) necesarios:Archivos de configuración necesarios `suite.json` Contiene información sobre el conjunto de pruebas. Consulte [Configuración de suite.json](idt-json-config.md#suite-json). `group.json` Contiene información sobre un grupo de pruebas. Debe crear un archivo `group.json` para cada grupo de pruebas de su conjunto de pruebas. Consulte [Configuración de group.json](idt-json-config.md#group-json). `test.json` Contiene información sobre un caso de prueba. Debe crear un archivo `test.json` para cada caso de prueba de su conjunto de pruebas. Consulte [Configuración de test.json](idt-json-config.md#test-json). 1. En la carpeta `MyTestSuite_1.0.0/suite`, cree un archivo `suite.json` con la estructura siguiente: ``` { "id": "MyTestSuite_1.0.0", "title": "My Test Suite", "details": "This is my test suite.", "userDataRequired": false } ``` 1. En la carpeta `MyTestSuite_1.0.0/myTestGroup`, cree un archivo `group.json` con la estructura siguiente: ``` { "id": "MyTestGroup", "title": "My Test Group", "details": "This is my test group.", "optional": false } ``` 1. En la carpeta `MyTestSuite_1.0.0/myTestGroup/myTestCase`, cree un archivo `test.json` con la estructura siguiente: ``` { "id": "MyTestCase", "title": "My Test Case", "details": "This is my test case.", "execution": { "timeout": 300000, "linux": { "cmd": "python3", "args": [ "myTestCase.py" ] }, "mac": { "cmd": "python3", "args": [ "myTestCase.py" ] }, "win": { "cmd": "python3", "args": [ "myTestCase.py" ] } } } ``` El árbol de directorios de la carpeta `MyTestSuite_1.0.0` debe ser similar al siguiente: ``` MyTestSuite_1.0.0 └── suite ├── suite.json └── myTestGroup ├── group.json └── myTestCase └── test.json ``` ## Obtención del SDK de cliente de IDT Utilice el [SDK de cliente de IDT](create-test-executables.md#idt-client-sdk) para permitir que IDT interactúe con el dispositivo que se está probando e informe de los resultados de las pruebas. Para este tutorial, utilizará la versión Python del SDK. Desde la carpeta `/sdks/python/`, copie la carpeta `idt_client` a su carpeta `MyTestSuite_1.0.0/suite/myTestGroup/myTestCase`. Para comprobar que el SDK se ha copiado correctamente, ejecute el siguiente comando. ``` cd MyTestSuite_1.0.0/suite/myTestGroup/myTestCase python3 -c 'import idt_client' ``` ## Creación del ejecutable del caso de prueba Los ejecutables del caso de prueba contienen la lógica de prueba que desea ejecutar. Un conjunto de pruebas puede contener varios ejecutables de casos de prueba. Para este tutorial, creará solo un ejecutable de caso de prueba. 1. Cree el archivo del conjunto de pruebas. En la carpeta `MyTestSuite_1.0.0/suite/myTestGroup/myTestCase`, cree un archivo `myTestCase.py` con el siguiente contenido: ``` from idt_client import * def main(): # Use the client SDK to communicate with IDT client = Client() if __name__ == "__main__": main() ``` 1. Utilice las funciones del SDK del cliente para añadir la siguiente lógica de prueba al archivo `myTestCase.py`: 1. Ejecute un comando SSH en el dispositivo que se está probando. ``` from idt_client import * def main(): # Use the client SDK to communicate with IDT client = Client() # Create an execute on device request exec_req = ExecuteOnDeviceRequest(ExecuteOnDeviceCommand("echo 'hello world'")) # Run the command exec_resp = client.execute_on_device(exec_req) # Print the standard output print(exec_resp.stdout) if __name__ == "__main__": main() ``` 1. Envíe el resultado de la prueba a IDT. ``` from idt_client import * def main(): # Use the client SDK to communicate with IDT client = Client() # Create an execute on device request exec_req = ExecuteOnDeviceRequest(ExecuteOnDeviceCommand("echo 'hello world'")) # Run the command exec_resp = client.execute_on_device(exec_req) # Print the standard output print(exec_resp.stdout) # Create a send result request sr_req = SendResultRequest(TestResult(passed=True)) # Send the result client.send_result(sr_req) if __name__ == "__main__": main() ``` ## Configuración de la información del dispositivo para IDT Configure la información del dispositivo para que IDT ejecute la prueba. Debe actualizar la plantilla `device.json` ubicada en la carpeta `/configs` con la siguiente información. ``` [ { "id": "pool", "sku": "N/A", "devices": [ { "id": "", "connectivity": { "protocol": "ssh", "ip": "", "port": "", "auth": { "method": "pki | password", "credentials": { "user": "", "privKeyPath": "/path/to/private/key", "password": "" } } } } ] } ] ``` En el objeto `devices`, indique la siguiente información: `id` Un identificador único definido por el usuario para el dispositivo. `connectivity.ip` La dirección IP del dispositivo. `connectivity.port` Opcional. El número de puerto que se va a utilizar para las conexiones SSH al dispositivo. `connectivity.auth` Información de autenticación para la conexión. Esta propiedad solo se aplica si `connectivity.protocol` está establecido en `ssh`. `connectivity.auth.method` El método de autenticación que se utiliza para acceder a un dispositivo a través de un determinado protocolo de conectividad. Los valores admitidos son: + `pki` + `password` `connectivity.auth.credentials` Las credenciales que se utilizan para la autenticación. `connectivity.auth.credentials.user` El nombre de usuario utilizado para iniciar sesión en el dispositivo. `connectivity.auth.credentials.privKeyPath` La ruta completa a la clave privada que se utiliza para iniciar sesión en el dispositivo. Este valor solo se aplica si `connectivity.auth.method` está establecido en `pki`. `devices.connectivity.auth.credentials.password` La contraseña que se utiliza para iniciar sesión en el dispositivo. Este valor solo se aplica si `connectivity.auth.method` está establecido en `password`. **nota** Especifique `privKeyPath` solo si `method` está establecido en `pki` Especifique `password` solo si `method` está establecido en `password` ## Ejecución del conjunto de pruebas Después de crear el conjunto de pruebas, querrá asegurarse de que funciona como se espera. Complete los siguientes pasos para ejecutar el conjunto de pruebas con su grupo de dispositivos existente para ello. 1. Copie su carpeta `MyTestSuite_1.0.0` en `/tests`. 1. Ejecute los siguientes comandos : ``` cd /bin ./devicetester_[linux | mac | win_x86-64] run-suite --suite-id MyTestSuite ``` IDT ejecuta el conjunto de pruebas y transmite los resultados a la consola. Cuando la prueba termine de ejecutarse, verá la siguiente información: ``` time="2020-10-19T09:24:47-07:00" level=info msg=Using pool: pool time="2020-10-19T09:24:47-07:00" level=info msg=Using test suite "MyTestSuite_1.0.0" for execution time="2020-10-19T09:24:47-07:00" level=info msg=b'hello world\n' suiteId=MyTestSuite groupId=myTestGroup testCaseId=myTestCase deviceId=my-device executionId=9a52f362-1227-11eb-86c9-8c8590419f30 time="2020-10-19T09:24:47-07:00" level=info msg=All tests finished. executionId=9a52f362-1227-11eb-86c9-8c8590419f30 time="2020-10-19T09:24:48-07:00" level=info msg= ========== Test Summary ========== Execution Time: 1s Tests Completed: 1 Tests Passed: 1 Tests Failed: 0 Tests Skipped: 0 ---------------------------------- Test Groups: myTestGroup: PASSED ---------------------------------- Path to IoT Device Tester Report: /path/to/devicetester/results/9a52f362-1227-11eb-86c9-8c8590419f30/awsiotdevicetester_report.xml Path to Test Execution Logs: /path/to/devicetester/results/9a52f362-1227-11eb-86c9-8c8590419f30/logs Path to Aggregated JUnit Report: /path/to/devicetester/results/9a52f362-1227-11eb-86c9-8c8590419f30/MyTestSuite_Report.xml ``` ## Resolución de problemas Utilice la siguiente información para resolver cualquier problema que pueda surgir al completar el tutorial. **El caso de prueba no se ejecuta correctamente** Si la prueba no se ejecuta correctamente, IDT transmite los registros de errores a la consola para ayudarle a solucionar los problemas de la prueba. Antes de comprobar los registros de errores, verifique lo siguiente: + El SDK de cliente de IDT se encuentra en la carpeta correcta, tal y como se describe en [este paso](#add-idt-sdk). + Cumpla con todos los [requisitos previos](#prereqs-tutorial-custom) de este tutorial. **No se puede conectar al dispositivo que se está probando** Compruebe lo siguiente: + El archivo `device.json` contiene la dirección IP, el puerto y la información de autenticación correctos. + Puede conectarse a su dispositivo a través de SSH desde su equipo host. # Creación de archivos de configuración para el conjunto de pruebas de IDT En esta sección se describen los formatos en los que se crean los archivos de configuración que se incluyen al escribir un conjunto de pruebas personalizado.Archivos de configuración necesarios `suite.json` Contiene información sobre el conjunto de pruebas. Consulte [Configuración de suite.json](#suite-json). `group.json` Contiene información sobre un grupo de pruebas. Debe crear un archivo `group.json` para cada grupo de pruebas de su conjunto de pruebas. Consulte [Configuración de group.json](#group-json). `test.json` Contiene información sobre un caso de prueba. Debe crear un archivo `test.json` para cada caso de prueba de su conjunto de pruebas. Consulte [Configuración de test.json](#test-json).Archivos de configuración opcionales `test_orchestrator.yaml` or `state_machine.json` Define cómo se ejecutan las pruebas cuando IDT ejecuta el conjunto de pruebas. Consulte [Configuración de test\$1orchestrator.yaml](#test-orchestrator-config). A partir de la versión 4.5.1 de IDT, se utiliza el archivo `test_orchestrator.yaml` para definir el flujo de trabajo de las pruebas. En las versiones anteriores de IDT, se utiliza el archivo `state_machine.json`. Para obtener más información sobre la máquina de estados, consulte [Configure la máquina de estados IDT](idt-state-machine.md). `userdata_schema.json` Define el esquema del [archivo `userdata.json`](set-custom-idt-config.md#userdata-config-custom) que los ejecutores de pruebas pueden incluir en su configuración de ajustes. El archivo `userdata.json` se utiliza para cualquier información de configuración adicional necesaria para ejecutar la prueba, pero que no esté presente en el archivo `device.json`. Consulte [Configuración de userdata\$1schema.json](#userdata-schema-json). Los archivos de configuración se colocan en su ``, tal y como se muestra aquí. ``` └── suite ├── suite.json ├── test_orchestrator.yaml ├── userdata_schema.json ├── ├── group.json ├── └── test.json ``` ## Configuración de suite.json El archivo `suite.json` establece las variables de entorno y determina si los datos del usuario son necesarios para ejecutar el conjunto de pruebas. Utilice la siguiente plantilla para configurar el archivo `/suite/suite.json`: ``` { "id": "_", "title": "", "details": "", "userDataRequired": true | false, "environmentVariables": [ { "key": "", "value": "", }, ... { "key": "", "value": "", } ] } ``` Todos los campos que contienen valores son obligatorios tal y como se describe aquí: `id` Un ID único definido por el usuario para el conjunto de pruebas. El valor de `id` debe coincidir con el nombre de la carpeta del conjunto de pruebas en la que se encuentra el archivo `suite.json`. El nombre y la versión del conjunto también deben cumplir los siguientes requisitos: + `` no puede contener guiones bajos. + `` se indica como `x.x.x`, donde `x` es un número. El ID se muestra en los informes de prueba generados por IDT. `title` Un nombre definido por el usuario para el producto o la característica que se está probando en este conjunto de pruebas. El nombre se muestra en la CLI de IDT para los ejecutores de pruebas. `details` Una descripción corta de la finalidad del conjunto de pruebas. `userDataRequired` Define si los ejecutores de pruebas deben incluir información personalizada en un archivo `userdata.json`. Si establece este valor en `true`, también debe incluir el [archivo `userdata_schema.json`](#userdata-schema-json) en la carpeta del conjunto de pruebas. `environmentVariables` Opcional. Una matriz de variables de entorno que se va a configurar para este conjunto de pruebas. `environmentVariables.key` El nombre de la variable de entorno. `environmentVariables.value` El valor de la variable de entorno. ## Configuración de group.json El archivo `group.json` define si el grupo de prueba es obligatorio u opcional. Utilice la siguiente plantilla para configurar el archivo `/suite//group.json`: ``` { "id": "", "title": "", "details": "", "optional": true | false, } ``` Todos los campos que contienen valores son obligatorios tal y como se describe aquí: `id` Un ID único definido por el usuario para el conjunto de pruebas. El valor de `id` debe coincidir con el nombre de la carpeta del grupo de pruebas en la que se encuentra el archivo `group.json` y no debe contener guiones bajos (`_`). El ID se utiliza en los informes de prueba generados por IDT. `title` Un nombre descriptivo para el grupo de prueba. El nombre se muestra en la CLI de IDT para los ejecutores de pruebas. `details` Una descripción corta de la finalidad del grupo de pruebas. `optional` Opcional. Establézcalo en `true` para mostrar este grupo de pruebas como un grupo opcional una vez que IDT termine de ejecutar las pruebas requeridas. El valor predeterminado es `false`. ## Configuración de test.json El archivo `test.json` determina los ejecutables del caso de prueba y las variables de entorno que utiliza un caso de prueba. Para obtener más información sobre cómo crear ejecutables de casos de prueba, consulte [Cree ejecutables de casos de prueba de IDT](create-test-executables.md). Utilice la siguiente plantilla para configurar el archivo `/suite///test.json`: ``` { "id": "", "title": "", "details": "", "requireDUT": true | false, "requiredResources": [ { "name": "", "features": [ { "name": "", "version": "", "jobSlots": } ] } ], "execution": { "timeout": , "mac": { "cmd": "/path/to/executable", "args": [ "" ], }, "linux": { "cmd": "/path/to/executable", "args": [ "" ], }, "win": { "cmd": "/path/to/executable", "args": [ "" ] } }, "environmentVariables": [ { "key": "", "value": "", } ] } ``` Todos los campos que contienen valores son obligatorios tal y como se describe aquí: `id` Un ID único definido por el usuario para el caso de prueba. El valor de `id` debe coincidir con el nombre de la carpeta del grupo de pruebas en la que se encuentra el archivo `test.json` y no debe contener guiones bajos (`_`). El ID se utiliza en los informes de prueba generados por IDT. `title` Un nombre descriptivo para el caso de prueba. El nombre se muestra en la CLI de IDT para los ejecutores de pruebas. `details` Una breve descripción de la finalidad del caso de prueba. `requireDUT` Opcional. Establézcalo en `true` si se requiere un dispositivo para ejecutar esta prueba; de lo contrario, establézcalo en `false`. El valor predeterminado es `true`. Los ejecutores de las pruebas configurarán los dispositivos que utilizarán para ejecutar la prueba en su archivo `device.json`. `requiredResources` Opcional. Una matriz que proporciona información sobre los dispositivos de recursos necesarios para ejecutar esta prueba. `requiredResources.name` El nombre exclusivo que se asignará al dispositivo de recursos cuando se ejecute esta prueba. `requiredResources.features` Una matriz de características del dispositivo de recursos definidas por el usuario. `requiredResources.features.name` El nombre de la característica. La característica del dispositivo para la que desea utilizar este dispositivo. Este nombre se coteja con el nombre de la característica que proporciona el ejecutor de las pruebas en el archivo `resource.json`. `requiredResources.features.version` Opcional. La versión de la característica. Este valor se coteja con la versión de la característica proporcionada por el ejecutor de las pruebas en el archivo `resource.json`. Si no se proporciona una versión, la característica no se comprueba. Si no se necesita un número de versión para la característica, deje este campo en blanco. `requiredResources.features.jobSlots` Opcional. El número de pruebas simultáneas que puede admitir esta característica. El valor predeterminado es `1`. Si desea que IDT utilice distintos dispositivos para características individuales, le recomendamos que establezca este valor en `1`. `execution.timeout` La cantidad de tiempo (en milisegundos) que IDT espera a que la prueba termine de ejecutarse. Para obtener más información sobre cómo establecer este valor, consulte [Cree ejecutables de casos de prueba de IDT](create-test-executables.md). `execution.os` Los ejecutables del caso de prueba que se ejecutarán en función del sistema operativo del equipo host que ejecuta IDT. Los valores admitidos son `linux`, `mac` y `win`. `execution.os.cmd` La ruta al ejecutable del caso de prueba que desea ejecutar para el sistema operativo especificado. Esta ubicación debe estar en la ruta del sistema. `execution.os.args` Opcional. Los argumentos que se deben proporcionar para ejecutar el ejecutable del caso de prueba. `environmentVariables` Opcional. Una matriz de variables de entorno definidas para este caso de prueba. `environmentVariables.key` El nombre de la variable de entorno. `environmentVariables.value` El valor de la variable de entorno. Si especifica la misma variable de entorno en el archivo `test.json` y en el archivo `suite.json`, el valor del archivo `test.json` tiene prioridad. ## Configuración de test\$1orchestrator.yaml Un orquestador de pruebas es un constructo que controla el flujo de ejecución del conjunto de pruebas. Determina el estado inicial de un conjunto de pruebas, administra las transiciones de estado en función de las reglas definidas por el usuario y continúa pasando por esos estados hasta alcanzar el estado final. Si su conjunto de pruebas no incluye un orquestador de pruebas definido por el usuario, IDT lo generará. El orquestador de pruebas predeterminado realiza las siguientes funciones: + Ofrece a los ejecutores de pruebas la posibilidad de seleccionar y ejecutar grupos de pruebas específicos, en lugar de todo el conjunto de pruebas. + Si no se seleccionan grupos de pruebas específicos, ejecuta todos los grupos de pruebas del conjunto de pruebas con asignación al azar. + Genera informes e imprime un resumen de la consola que muestra los resultados de las pruebas de cada grupo y caso de prueba. Para obtener más información sobre cómo funciona el orquestador de pruebas, consulte [Configuración del orquestador de pruebas de IDT](idt-test-orchestrator.md). ## Configuración de userdata\$1schema.json El archivo `userdata_schema.json` determina el esquema en el que los ejecutores de las pruebas proporcionan los datos de usuario. Los datos de usuario son necesarios si su conjunto de pruebas requiere información que no está presente en el archivo `device.json`. Por ejemplo, es posible que las pruebas necesiten credenciales de red Wi-Fi, puertos abiertos específicos o certificados que deba proporcionar un usuario. Esta información se puede proporcionar a IDT como un parámetro de entrada denominado`userdata`, cuyo valor es un archivo `userdata.json`, que los usuarios crean en su carpeta `/config`. El formato del archivo `userdata.json` se basa en el archivo `userdata_schema.json` que se incluye en el conjunto de pruebas. Para indicar que los ejecutores de pruebas deben proporcionar un archivo `userdata.json`: 1. En el archivo `suite.json`, establezca `userDataRequired` en `true`. 1. En su ``, cree un archivo `userdata_schema.json`. 1. Edite el archivo `userdata_schema.json` para crear un [borrador del esquema JSON v4 de IETF](https://json-schema.org/specification-links.html#draft-4) válido. Cuando IDT ejecuta su conjunto de pruebas, lee automáticamente el esquema y lo usa para validar el archivo `userdata.json` proporcionado por el ejecutor de la prueba. Si es válido, el contenido del archivo `userdata.json` está disponible tanto en el [contexto de IDT](idt-context.md) como en el [contexto del orquestador de pruebas](idt-state-machine.md#state-machine-context). # Configuración del orquestador de pruebas de IDT A partir de la versión 4.5.1 de IDT, IDT incluye un nuevo componente *orquestador de pruebas*. El orquestador de pruebas es un componente de IDT que controla el flujo de ejecución del conjunto de pruebas y genera el informe de prueba una vez que IDT termina de ejecutar todas las pruebas. El orquestador de pruebas determina la selección de las pruebas y el orden en que se ejecutan en función de las reglas definidas por el usuario. Si su conjunto de pruebas no incluye un orquestador de pruebas definido por el usuario, IDT lo generará. El orquestador de pruebas predeterminado realiza las siguientes funciones: + Ofrece a los ejecutores de pruebas la posibilidad de seleccionar y ejecutar grupos de pruebas específicos, en lugar de todo el conjunto de pruebas. + Si no se seleccionan grupos de pruebas específicos, ejecuta todos los grupos de pruebas del conjunto de pruebas con asignación al azar. + Genera informes e imprime un resumen de la consola que muestra los resultados de las pruebas de cada grupo y caso de prueba. El orquestador de pruebas reemplaza al orquestador de pruebas de IDT. Le recomendamos utilizar el orquestador de pruebas para desarrollar sus conjuntos de pruebas en lugar del orquestador de pruebas de IDT. El orquestador de pruebas ofrece las siguientes características mejoradas: + Utiliza un formato declarativo en comparación con el formato imperativo que utiliza la máquina de estados de IDT. Esto le permite especificar qué pruebas desea ejecutar y cuándo quiere ejecutarlas. + Administra la gestión de grupos específicos, la generación de informes, la gestión de errores y el seguimiento de los resultados para que no tenga que gestionar estas acciones manualmente. + Utiliza el formato YAML, que admite comentarios de forma predeterminada. + Requiere un 80 por ciento menos de espacio en disco que el orquestador de pruebas para definir el mismo flujo de trabajo. + Añade una validación previa a las pruebas para comprobar que la definición del flujo de trabajo no contiene identificadores de prueba incorrectos o dependencias circulares. ## Formato del orquestador de pruebas Puede utilizar la siguiente plantilla para configurar su propio archivo `/suite/test_orchestrator.yaml`: ``` Aliases: string: context-expression ConditionalTests: - Condition: context-expression Tests: - test-descriptor Order: - - group-descriptor - group-descriptor Features: - Name: feature-name Value: support-description Condition: context-expression Tests: - test-descriptor OneOfTests: - test-descriptor IsRequired: boolean ``` Todos los campos que contienen valores son obligatorios tal y como se describe aquí: `Aliases` Opcional. Cadenas definidas por el usuario que se asignan a expresiones de contexto. Los alias le permiten generar nombres descriptivos para identificar las expresiones de contexto en la configuración de su orquestador de pruebas. Esto resulta especialmente útil si está creando expresiones contextuales complejas o expresiones que utiliza en varios lugares. Puede usar expresiones de contexto para almacenar consultas de contexto que le permitan acceder a los datos de otras configuraciones de IDT. Para obtener más información, consulte [Acceda a los datos en el contexto](idt-context.md#accessing-context-data). **Example Ejemplo** ``` Aliases: FizzChosen: "'{{$pool.features[?(@.name == 'Fizz')].value[0]}}' == 'yes'" BuzzChosen: "'{{$pool.features[?(@.name == 'Buzz')].value[0]}}' == 'yes'" FizzBuzzChosen: "'{{$aliases.FizzChosen}}' && '{{$aliases.BuzzChosen}}'" ``` `ConditionalTests` Opcional. Una lista de condiciones y los casos de prueba correspondientes que se ejecutan cuando se cumple cada condición. Cada condición puede tener varios casos de prueba; sin embargo, puede asignar un caso de prueba determinado a una sola condición. De forma predeterminada, IDT ejecuta cualquier caso de prueba que no esté asignado a una condición de esta lista. Si no especifica esta sección, IDT ejecuta todos los grupos de pruebas del conjunto de pruebas. Cada elemento de la lista `ConditionalTests` incluye los siguientes parámetros: `Condition` Una expresión de contexto que se evalúa como un valor booleano. Si el valor evaluado es verdadero, IDT ejecuta los casos de prueba que se especifican en el parámetro `Tests`. `Tests` La lista de descriptores de prueba. Cada descriptor de prueba usa el ID del grupo de pruebas y uno o más ID de casos de prueba para identificar las pruebas individuales que se van a ejecutar en un grupo de pruebas específico. El descriptor de la prueba utiliza el siguiente formato: ``` GroupId: group-id CaseIds: [test-id, test-id] # optional ``` **Example Ejemplo** En el siguiente ejemplo se utilizan expresiones de contexto genéricas que puede definir como `Aliases`. ``` ConditionalTests: - Condition: "{{$aliases.Condition1}}" Tests: - GroupId: A - GroupId: B - Condition: "{{$aliases.Condition2}}" Tests: - GroupId: D - Condition: "{{$aliases.Condition1}} || {{$aliases.Condition2}}" Tests: - GroupId: C ``` En función de las condiciones definidas, IDT selecciona los grupos de prueba de la siguiente manera: + Si `Condition1` es verdadero, IDT ejecuta las pruebas de los grupos de pruebas A, B y C. + Si `Condition2` es verdadero, IDT ejecuta las pruebas de los grupos de pruebas C y D. `Order` Opcional. El orden en que se deben ejecutar las pruebas. El orden de las pruebas se especifica a nivel de grupo de pruebas. Si no especifica esta sección, IDT ejecuta todos los grupos de pruebas aplicables en un orden aleatorio. El valor de `Order` es una lista de listas de descriptores de grupos. Cualquier grupo de pruebas que no incluya en la lista `Order` se puede ejecutar en paralelo con cualquier otro grupo de pruebas de la lista. Cada lista de descriptores de grupo contiene uno o más descriptores de grupo e identifica el orden en el que se deben ejecutar los grupos que se especifican en cada descriptor. Puede utilizar los siguientes formatos para definir descriptores de grupos individuales: + `group-id`: el ID de grupo de un grupo de pruebas existente. + `[group-id, group-id]`: lista de grupos de pruebas que se pueden ejecutar en cualquier orden relativo. + `"*"`: comodín. Esto equivale a la lista de todos los grupos de pruebas que aún no están especificados en la lista de descriptores de grupos actual. El valor de `Order` también debe cumplir los siguientes requisitos: + Los ID de los grupos de pruebas que especifique en un descriptor de grupo deben existir en su conjunto de pruebas. + Cada lista de descriptores de grupos debe incluir al menos un grupo de pruebas. + Cada lista de descriptores de grupo debe contener identificadores de grupo únicos. No puede repetir el ID de un grupo de pruebas dentro de los descriptores de grupos individuales. + Una lista de descriptores de grupo puede tener como máximo un descriptor de grupo comodín. El descriptor de grupo comodín debe ser el primer o el último elemento de la lista. **Example Ejemplos** En el caso de un conjunto de pruebas que contiene los grupos de pruebas A, B, C, D y E, en la siguiente lista de ejemplos se muestran diferentes formas de especificar que IDT debe ejecutar primero el grupo de pruebas A, después el grupo de pruebas B y, por último, ejecutar los grupos de pruebas C, D y E en cualquier orden. + ``` Order: - - A - B - [C, D, E] ``` + ``` Order: - - A - B - "*" ``` + ``` Order: - - A - B - - B - C - - B - D - - B - E ``` `Features` Opcional. La lista de características del producto que desea que IDT añada al archivo `awsiotdevicetester_report.xml`. Si no especifica esta sección, IDT no añadirá ninguna característica del producto al informe. Una característica del producto es información definida por el usuario sobre los criterios específicos que puede cumplir un dispositivo. Por ejemplo, la característica MQTT del producto puede indicar que el dispositivo publica los mensajes MQTT correctamente. En `awsiotdevicetester_report.xml`, las características del producto se establecen como `supported`, `not-supported` o como un valor personalizado, en función de si se han superado las pruebas especificadas. Cada elemento de la lista `Features` incluye los siguientes parámetros: `Name` El nombre de la característica. `Value` Opcional. El valor personalizado que desea utilizar en el informe en lugar de `supported`. Si no se especifica este valor, IDT establece el valor de la característica en `supported` o `not-supported`, en función de los resultados de las pruebas. Si prueba la misma característica con diferentes condiciones, puede utilizar un valor personalizado para cada instancia de esa característica en la lista `Features` e IDT concatena los valores de la característica para las condiciones admitidas. Para más información, consulte `Condition` Una expresión de contexto que se evalúa como un valor booleano. Si el valor evaluado es verdadero, IDT añade la característica al informe de la prueba una vez que termine de ejecutar el conjunto de pruebas. Si el valor evaluado es falso, la prueba no se incluye en el informe. `Tests` Opcional. La lista de descriptores de prueba. Para que la característica sea compatible, se deben superar todas las pruebas especificadas en esta lista. Cada descriptor de prueba de esta lista usa el ID del grupo de pruebas y uno o más ID de casos de prueba para identificar las pruebas individuales que se van a ejecutar en un grupo de pruebas específico. El descriptor de la prueba utiliza el siguiente formato: ``` GroupId: group-id CaseIds: [test-id, test-id] # optional ``` Debe especificar `Tests` o `OneOfTests` para cada característica de la lista `Features`. `OneOfTests` Opcional. La lista de descriptores de prueba. Para que la característica sea compatible, se debe superar al menos una de las pruebas especificadas en esta lista. Cada descriptor de prueba de esta lista usa el ID del grupo de pruebas y uno o más ID de casos de prueba para identificar las pruebas individuales que se van a ejecutar en un grupo de pruebas específico. El descriptor de la prueba utiliza el siguiente formato: ``` GroupId: group-id CaseIds: [test-id, test-id] # optional ``` Debe especificar `Tests` o `OneOfTests` para cada característica de la lista `Features`. `IsRequired` El valor booleano que define si la característica es obligatoria en el informe de prueba. El valor predeterminado es `false`. **Example** ## Contexto del orquestador de pruebas El contexto del orquestador de pruebas es un documento JSON de solo lectura que contiene datos que están disponibles para el orquestador de pruebas durante la ejecución. Solo se puede acceder al contexto del orquestador de pruebas desde el orquestador de pruebas y contiene información que determina el flujo de prueba. Por ejemplo, puede usar la información configurada por los ejecutores de la prueba en el archivo `userdata.json` para determinar si es necesario ejecutar una prueba específica. El contexto del orquestador de pruebas utiliza el siguiente formato: ``` { "pool": { }, "userData": { }, "config": { } } ``` `pool` Información sobre el grupo de dispositivos seleccionado para la ejecución de la prueba. Para un grupo de dispositivos seleccionados, esta información se recupera del elemento correspondiente de la matriz del grupo de dispositivos de alto nivel definido en el archivo `device.json`. `userData` Información en el archivo `userdata.json`. `config` Información en el archivo `config.json`. Puede consultar el contexto mediante la notación JSONPath. La sintaxis de las consultas JSONPath en las definiciones de estado es `{{query}}`. Al acceder a los datos desde el contexto del orquestador de pruebas, asegúrese de que cada valor se evalúe como una cadena, un número o un booleano. Para obtener más información sobre cómo utilizar la notación JSONPath para acceder a los datos desde el contexto, consulte [Uso del contexto de IDT](idt-context.md). # Configure la máquina de estados IDT **importante** A partir de la versión 4.5.1 de IDT, esta máquina de estados está obsoleta. Le recomendamos encarecidamente que utilice el nuevo orquestador de pruebas. Para obtener más información, consulte [Configuración del orquestador de pruebas de IDT](idt-test-orchestrator.md). Una máquina de estados es un constructo que controla el flujo de ejecución del conjunto de pruebas. Determina el estado inicial de un conjunto de pruebas, administra las transiciones de estado en función de las reglas definidas por el usuario y continúa pasando por esos estados hasta alcanzar el estado final. Si su conjunto de pruebas no incluye una máquina de estados definida por el usuario, IDT la generará. La máquina de estados predeterminada realiza las siguientes funciones: + Ofrece a los ejecutores de pruebas la posibilidad de seleccionar y ejecutar grupos de pruebas específicos, en lugar de todo el conjunto de pruebas. + Si no se seleccionan grupos de pruebas específicos, ejecuta todos los grupos de pruebas del conjunto de pruebas con asignación al azar. + Genera informes e imprime un resumen de la consola que muestra los resultados de las pruebas de cada grupo y caso de prueba. La máquina de estados de un conjunto de pruebas de IDT debe cumplir los siguientes criterios: + Cada estado corresponde a una acción que debe realizar IDT, como ejecutar un grupo de pruebas o crear un archivo de informe. + La transición a un estado ejecuta la acción asociada a ese estado. + Cada estado define la regla de transición para el siguiente estado. + El estado final debe ser `Succeed` o `Fail`. ## Formato de las máquinas de estados Puede utilizar la siguiente plantilla para configurar su propio archivo `/suite/state_machine.json`: ``` { "Comment": "", "StartAt": "", "States": { "": { "Type": "", // Additional state configuration } // Required states "Succeed": { "Type": "Succeed" }, "Fail": { "Type": "Fail" } } } ``` Todos los campos que contienen valores son obligatorios tal y como se describe aquí: `Comment` Una descripción de la máquina de estados. `StartAt` El nombre del estado en el que IDT comienza a ejecutar el conjunto de pruebas. El valor de `StartAt` debe estar establecido en uno de los estados enumerados en el objeto `States`. `States` Objeto que asigna los nombres de estado definidos por el usuario a estados de IDT válidos. Cada uno de los estados. *state-name*el objeto contiene la definición de un estado válido asignado a. *state-name* El objeto `States` debe incluir los estados `Succeed` y `Fail`. Para obtener información sobre los estados válidos, consulte [Estados válidos y definiciones de estado](#valid-states). ## Estados válidos y definiciones de estado En esta sección se describen las definiciones de estado de todos los estados válidos que se pueden usar en la máquina de estados de IDT. Algunos de los siguientes estados admiten configuraciones en el nivel de caso de prueba. Sin embargo, le recomendamos que configure las reglas de transición de estado en el nivel de grupo de pruebas en lugar de en el nivel del caso de prueba, a menos que sea absolutamente necesario. **Topics** + [RunTask](#state-runtask) + [Choice](#state-choice) + [Parallel](#state-parallel) + [AddProductFeatures](#state-addproductfeatures) + [Informar](#state-report) + [LogMessage](#state-logmessage) + [SelectGroup](#state-selectgroup) + [Fail](#state-fail) + [Succeed](#state-succeed) ### RunTask El estado `RunTask` ejecuta casos de prueba a partir de un grupo de pruebas definido en el conjunto de pruebas. ``` { "Type": "RunTask", "Next": "", "TestGroup": "", "TestCases": [ "" ], "ResultVar": "" } ``` Todos los campos que contienen valores son obligatorios tal y como se describe aquí: `Next` El nombre del estado al que se realizará la transición después de ejecutar las acciones en el estado actual. `TestGroup` Opcional. El ID del grupo de pruebas que se va a ejecutar. Si no se especifica este valor, IDT ejecuta el grupo de pruebas que seleccione el ejecutor de la prueba. `TestCases` Opcional. Una matriz de casos de prueba IDs del grupo especificado en`TestGroup`. En función de los valores de `TestGroup` y `TestCases`, IDT determina el comportamiento de la ejecución de la prueba de la siguiente manera: + Cuando se especifica `TestGroup` y `TestCases`, IDT ejecuta los casos de prueba especificados del grupo de pruebas. + Cuando se especifica `TestCases`, pero no se especifica `TestGroup`, IDT ejecuta los casos de prueba especificados. + Cuando se especifica `TestGroup`, pero no se especifica `TestCases`, IDT ejecuta todos los casos de prueba del grupo de pruebas especificado. + Si no se especifica `TestGroup` ni `TestCases`, IDT ejecuta todos los casos de prueba del grupo de pruebas que el ejecutor de la prueba selecciona en la CLI de IDT. Para habilitar la selección de grupos para los ejecutores de las pruebas, debe incluir los estados `RunTask` y `Choice` en el archivo `state_machine.json`. Para ver un ejemplo de cómo funciona, consulte [Ejemplo de máquina de estados: ejecutar grupos de prueba seleccionados por el usuario](#allow-specific-groups). Para obtener más información sobre cómo habilitar los comandos CLI de IDT para los ejecutores de pruebas, consulte [Habilitación de comandos de CLI de IDT](create-test-executables.md#idt-cli-coop). `ResultVar` El nombre de la variable de contexto que se va a configurar con los resultados de la prueba. No especifique este valor si no especificó ningún valor para `TestGroup`. IDT establece el valor de la variable que defina en `ResultVar` como `true` o `false` en función de lo siguiente: + Si el nombre de la variable tiene el formato `text_text_passed`, el valor se establece en función de si todas las pruebas del primer grupo de pruebas se aprobaron o se omitieron. + En todos los demás casos, el valor se establece en función de si todas las pruebas de todos los grupos de pruebas se aprobaron o se omitieron. Normalmente, se utiliza el `RunTask` estado para especificar un ID de grupo de pruebas sin especificar un caso de prueba individual IDs, de modo que IDT ejecutará todos los casos de prueba del grupo de pruebas especificado. Todos los casos de prueba ejecutados por este estado se ejecutan en paralelo, en orden aleatorio. Sin embargo, si todos los casos de prueba requieren la ejecución de un dispositivo y solo hay un dispositivo disponible, los casos de prueba se ejecutarán secuencialmente. **Error handling (Control de errores)** Si alguno de los grupos de pruebas o casos IDs de prueba especificados no es válido, este estado genera el error de `RunTaskError` ejecución. Si el estado encuentra un error de ejecución, también establece la variable `hasExecutionError` en el contexto de la máquina de estados en `true`. ### Choice El estado `Choice` le permite configurar dinámicamente el siguiente estado al que realizar la transición en función de las condiciones definidas por el usuario. ``` { "Type": "Choice", "Default": "", "FallthroughOnError": true | false, "Choices": [ { "Expression": "", "Next": "" } ] } ``` Todos los campos que contienen valores son obligatorios tal y como se describe aquí: `Default` El estado predeterminado al que se realizará la transición si no se puede evaluar ninguna de las expresiones definidas en `Choices` como `true`. `FallthroughOnError` Opcional. Especifica el comportamiento cuando el estado encuentra un error al evaluar las expresiones. Establézcalo en `true` si desea omitir una expresión si la evaluación genera un error. Si ninguna expresión coincide, la máquina de estados pasa al estado `Default`. Si no se especifica el valor `FallthroughOnError`, se establece de forma predeterminada en `false`. `Choices` Una matriz de expresiones y estados para determinar a qué estado hacer la transición después de ejecutar las acciones en el estado actual. `Choices.Expression` Una cadena de expresión que se evalúa como un valor booleano. Si la expresión se evalúa como `true`, la máquina de estados pasa al estado definido en `Choices.Next`. Las cadenas de expresión recuperan los valores del contexto de la máquina de estados y, a continuación, realizan operaciones en ellos para obtener un valor booleano. Para obtener información sobre cómo acceder al contexto de la máquina de estados, consulte [Contexto de la máquina de estados](#state-machine-context). `Choices.Next` El nombre del estado al que se realizará la transición si la expresión definida en `Choices.Expression` se evalúa como `true`. **Error handling (Control de errores)** El estado `Choice` puede requerir la gestión de errores en los siguientes casos: + Algunas variables de las expresiones de elección no existen en el contexto de la máquina de estados. + El resultado de una expresión no es un valor booleano. + El resultado de una búsqueda en JSON no es una cadena, un número ni un booleano. No puede usar un bloque `Catch` para gestionar los errores en este estado. Si quiere detener la ejecución de la máquina de estados cuando encuentre un error, debe establecer `FallthroughOnError` en `false`. Sin embargo, le recomendamos que establezca `FallthroughOnError` en `true` y, en función de su caso de uso, haga una de las siguientes opciones: + Si se espera que una variable a la que está accediendo no exista en algunos casos, utilice el valor `Default` y los bloques `Choices` adicionales para especificar el siguiente estado. + Si una variable a la que está accediendo debe existir siempre, defina el estado `Default` en `Fail`. ### Parallel El estado `Parallel` le permite definir y ejecutar nuevas máquinas de estados en paralelo entre sí. ``` { "Type": "Parallel", "Next": "", "Branches": [ ] } ``` Todos los campos que contienen valores son obligatorios tal y como se describe aquí: `Next` El nombre del estado al que se realizará la transición después de ejecutar las acciones en el estado actual. `Branches` Una matriz de definiciones de máquinas de estados para ejecutar. Cada definición de máquina de estados debe contener sus propios estados `StartAt`, `Succeed` y `Fail`. Las definiciones de máquinas de estados de esta matriz no pueden hacer referencia a estados ajenos a su propia definición. Como cada máquina de estados de la rama comparte el mismo contexto de máquina de estados, establecer variables en una rama y, a continuación, leer esas variables desde otra rama podría provocar un comportamiento inesperado. El estado `Parallel` pasa al siguiente estado solo después de ejecutar todas las máquinas de estados de rama. Cada estado que requiera un dispositivo esperará para ejecutarse hasta que el dispositivo esté disponible. Si hay varios dispositivos disponibles, este estado ejecuta casos de prueba de varios grupos en paralelo. Si no hay suficientes dispositivos disponibles, los casos de prueba se ejecutarán secuencialmente. Como los casos de prueba se ejecutan en orden aleatorio cuando se ejecutan en paralelo, se podrían usar diferentes dispositivos para ejecutar pruebas del mismo grupo de pruebas. **Error handling (Control de errores)** Asegúrese de que tanto la máquina de estados de la rama como la máquina de estados principal pasen al estado `Fail` para gestionar los errores de ejecución. Como las máquinas de estados de la rama no transmiten los errores de ejecución a la máquina de estados principal, no puede usar un bloque `Catch` para gestionar los errores de ejecución en las máquinas de estados de la rama. En su lugar, utilice el valor `hasExecutionErrors` en el contexto de la máquina de estados compartida. Para ver un ejemplo de cómo funciona, consulte [Ejemplo de máquina de estados: ejecutar dos grupos de prueba en paralelo](#run-in-parallel). ### AddProductFeatures El estado `AddProductFeatures` le permite añadir características del producto al archivo `awsiotdevicetester_report.xml` generado por IDT. Una característica del producto es información definida por el usuario sobre los criterios específicos que puede cumplir un dispositivo. Por ejemplo, la característica del producto `MQTT` puede indicar que el dispositivo publica los mensajes MQTT correctamente. En el informe, las características del producto se establecen como `supported`, `not-supported` o como un valor personalizado, en función de si se han superado las pruebas especificadas. **nota** El estado `AddProductFeatures` no genera informes por sí mismo. Este estado debe realizar la transición al [estado `Report`](#state-report) para generar informes. ``` { "Type": "Parallel", "Next": "", "Features": [ { "Feature": "", "Groups": [ "" ], "OneOfGroups": [ "" ], "TestCases": [ "" ], "IsRequired": true | false, "ExecutionMethods": [ "" ] } ] } ``` Todos los campos que contienen valores son obligatorios tal y como se describe aquí: `Next` El nombre del estado al que se realizará la transición después de ejecutar las acciones en el estado actual. `Features` Una matriz de características del producto para mostrar en el archivo `awsiotdevicetester_report.xml`. `Feature` El nombre de la característica `FeatureValue` Opcional. El valor personalizado que se utilizará en el informe en lugar de `supported`. Si no se especifica este valor, según los resultados de las pruebas, el valor de la característica se establece en `supported` o `not-supported`. Si utiliza un valor personalizado para `FeatureValue`, puede probar la misma característica con diferentes condiciones e IDT concatena los valores de la característica para las condiciones admitidas. Por ejemplo, en el siguiente fragmento se muestra la característica `MyFeature` con dos valores de característica distintos: ``` ... { "Feature": "MyFeature", "FeatureValue": "first-feature-supported", "Groups": ["first-feature-group"] }, { "Feature": "MyFeature", "FeatureValue": "second-feature-supported", "Groups": ["second-feature-group"] }, ... ``` Si ambos grupos de pruebas aprueban, el valor de la característica se establece en `first-feature-supported, second-feature-supported`. `Groups` Opcional. Matriz de grupos de prueba IDs. Para que la característica sea compatible, deben superan la prueba todas las pruebas de cada grupo de pruebas especificado. `OneOfGroups` Opcional. Una matriz de grupos de prueba IDs. Para que la característica sea compatible, deben aprobarse todas las pruebas de al menos uno de los grupos de pruebas especificados. `TestCases` Opcional. Una serie de casos de prueba IDs. Si especifica este valor, se aplicará lo siguiente: + Para que la característica sea compatible, deben superan la prueba todos los casos de prueba especificados. + `Groups` debe contener solo un ID de grupo de pruebas. + `OneOfGroups` no debe especificarse. `IsRequired` Opcional. Establézcalo en `false` para marcar esta característica como una característica opcional en el informe. El valor predeterminado es `true`. `ExecutionMethods` Opcional. Una matriz de métodos de ejecución que coinciden con el valor `protocol` especificado en el archivo `device.json`. Si se especifica este valor, los ejecutores de pruebas deben especificar un valor `protocol` que coincida con uno de los valores de esta matriz para incluir la característica en el informe. Si no se especifica este valor, la característica siempre se incluirá en el informe. Para usar el estado `AddProductFeatures`, debe establecer el valor de `ResultVar` con estado `RunTask` en uno de los siguientes valores: + Si especificó un caso de prueba individual IDs, `ResultVar` configúrelo en`group-id_test-id_passed`. + Si no especificó un caso de prueba individual IDs, `ResultVar` configúrelo en`group-id_passed`. El estado `AddProductFeatures` comprueba los resultados de las pruebas de la siguiente manera: + Si no especificó ningún caso de prueba IDs, el resultado de cada grupo de prueba se determina a partir del valor de la `group-id_passed` variable en el contexto de la máquina de estados. + Si especificó un caso de prueba IDs, el resultado de cada una de las pruebas se determina a partir del valor de la `group-id_test-id_passed` variable en el contexto de la máquina de estados. **Error handling (Control de errores)** Si un identificador de grupo proporcionado en este estado no es un identificador de grupo válido, este estado provoca un error de ejecución de `AddProductFeaturesError`. Si el estado encuentra un error de ejecución, también establece la variable `hasExecutionErrors` en el contexto de la máquina de estados en `true`. ### Informar El estado `Report` genera los archivos `suite-name_Report.xml` y `awsiotdevicetester_report.xml`. Este estado también transmite el informe a la consola. ``` { "Type": "Report", "Next": "" } ``` Todos los campos que contienen valores son obligatorios tal y como se describe aquí: `Next` El nombre del estado al que se realizará la transición después de ejecutar las acciones en el estado actual. Siempre debe pasar al estado `Report` que se encuentra al final del flujo de ejecución de la prueba para que los ejecutores de la prueba puedan ver los resultados de la prueba. Normalmente, el siguiente estado después de este estado es `Succeed`. **Error handling (Control de errores)** Si este estado tiene problemas con la generación de los informes, se produce el error de ejecución `ReportError`. ### LogMessage El estado `LogMessage` genera el archivo `test_manager.log` y transmite el mensaje de registro a la consola. ``` { "Type": "LogMessage", "Next": "" "Level": "info | warn | error" "Message": "" } ``` Todos los campos que contienen valores son obligatorios tal y como se describe aquí: `Next` El nombre del estado al que se realizará la transición después de ejecutar las acciones en el estado actual. `Level` El nivel de error en el que se va a crear el mensaje de registro. Si especifica un nivel que no es válido, este estado genera un mensaje de error y lo descarta. `Message` El mensaje para registrar. ### SelectGroup El estado `SelectGroup` actualiza el contexto de la máquina de estados para indicar qué grupos están seleccionados. Los valores establecidos por este estado se utilizan en cualquier estado `Choice` posterior. ``` { "Type": "SelectGroup", "Next": "" "TestGroups": [ " ] } ``` Todos los campos que contienen valores son obligatorios tal y como se describe aquí: `Next` El nombre del estado al que se realizará la transición después de ejecutar las acciones en el estado actual. `TestGroups` Una matriz de grupos de pruebas que se marcarán como seleccionados. Para cada ID de grupo de pruebas de esta matriz, la variable `group-id_selected` se establece `true` en el contexto. Asegúrese de proporcionar un grupo de prueba válido, IDs ya que IDT no valida la existencia de los grupos especificados. ### Fail El estado `Fail` indica que la máquina de estados no se ejecutó correctamente. Este es el estado final de la máquina de estados y cada definición de la máquina de estados debe incluir este estado. ``` { "Type": "Fail" } ``` ### Succeed El estado `Succeed` indica que la máquina de estados se ejecutó correctamente. Este es el estado final de la máquina de estados y cada definición de la máquina de estados debe incluir este estado. ``` { "Type": "Succeed" } ``` ## Contexto de la máquina de estados El contexto de la máquina de estados es un documento JSON de solo lectura que contiene datos que están disponibles para la máquina de estados durante la ejecución. Solo se puede acceder al contexto de la máquina de estados desde la máquina de estados y contiene información que determina el flujo de prueba. Por ejemplo, puede usar la información configurada por los ejecutores de la prueba en el archivo `userdata.json` para determinar si es necesario ejecutar una prueba específica. El contexto de la máquina de estados usa el siguiente formato: ``` { "pool": { }, "userData": { }, "config": { }, "suiteFailed": true | false, "specificTestGroups": [ "" ], "specificTestCases": [ "" ], "hasExecutionErrors": true } ``` `pool` Información sobre el grupo de dispositivos seleccionado para la ejecución de la prueba. Para un grupo de dispositivos seleccionados, esta información se recupera del elemento correspondiente de la matriz del grupo de dispositivos de alto nivel definido en el archivo `device.json`. `userData` Información en el archivo `userdata.json`. `config` Información del archivo `config.json`. `suiteFailed` El valor se establece en `false` cuando se inicia la máquina de estados. Si un grupo de pruebas falla en un estado `RunTask`, este valor se establece en `true` durante el resto de la ejecución de la máquina de estados. `specificTestGroups` Si el responsable de la prueba selecciona grupos de pruebas específicos para ejecutarlos en lugar de todo el conjunto de pruebas, se crea esta clave y contiene la lista de grupos IDs de pruebas específicos. `specificTestCases` Si el ejecutor de la prueba selecciona casos de prueba específicos para ejecutarlos en lugar de todo el conjunto de pruebas, se crea esta clave y contiene la lista de casos de prueba específicos IDs. `hasExecutionErrors` No se cierra cuando se inicia la máquina de estados. Si algún estado detecta errores de ejecución, se crea esta variable y se establece en `true` durante el resto de la ejecución de la máquina de estados. Puede consultar el contexto mediante la JSONPath notación. La sintaxis de las JSONPath consultas en las definiciones de estado es`{{$.query}}`. Puede utilizar JSONPath las consultas como cadenas de marcadores de posición en algunos estados. IDT reemplaza las cadenas de marcadores de posición por el valor de la JSONPath consulta evaluada en el contexto. Puede utilizar los siguientes marcadores de posición para los siguientes valores: + El valor `TestCases` en estados `RunTask`. + El valor `Expression` en estado `Choice`. Cuando accede a los datos del contexto de la máquina de estados, asegúrese de que se cumplan las siguientes condiciones: + Sus rutas de JSON deben comenzar por `$.` + Cada valor debe evaluarse como una cadena, un número o un booleano. Para obtener más información sobre el uso de la JSONPath notación para acceder a los datos del contexto, consulte. [Uso del contexto de IDT](idt-context.md) ## Errores de ejecución Los errores de ejecución son errores en la definición de la máquina de estados que esta encuentra al ejecutar un estado. IDT registra la información sobre cada error en el archivo `test_manager.log` y transmite el mensaje de registro a la consola. Puede utilizar los siguientes métodos para gestionar los errores de ejecución: + Añada un [bloque `Catch`](#catch) a la definición de estado. + Compruebe el valor del [valor `hasExecutionErrors`](#context) en el contexto de la máquina de estados. ### Catch Para usar `Catch`, añada lo siguiente a su definición de estado: ``` "Catch": [ { "ErrorEquals": [ "" ] "Next": "" } ] ``` Todos los campos que contienen valores son obligatorios tal y como se describe aquí: `Catch.ErrorEquals` Una matriz de los tipos de error que se deben capturar. Si un error de ejecución coincide con uno de los valores especificados, la máquina de estados pasa al estado especificado en `Catch.Next`. Consulte la definición de cada estado para obtener información sobre el tipo de error que genera. `Catch.Next` El siguiente estado al que se realizará la transición si el estado actual encuentra un error de ejecución que coincide con uno de los valores especificados en `Catch.ErrorEquals`. Los bloques Catch se gestionan secuencialmente hasta que uno coincide. Si los errores no coinciden con los enumerados en los bloques Catch, las máquinas de estado seguirán ejecutándose. Como los errores de ejecución son el resultado de definiciones de estado incorrectas, se recomienda que pase al estado de Error cuando un estado detecte un error de ejecución. ### hasExecutionError Cuando algunos estados encuentran errores de ejecución, además de emitir el error, también establecen el valor `hasExecutionError` en `true` en el contexto de la máquina de estados. Puede usar este valor para detectar cuándo se produce un error y, a continuación, usar un estado `Choice` para hacer la transición de la máquina de estados al estado `Fail`. Este método incluye las siguientes características: + La máquina de estados no comienza con ningún valor asignado a `hasExecutionError` y este valor no está disponible hasta que se establezca en un estado concreto. Esto significa que debe establecer explícitamente `FallthroughOnError` en `false` para los estados `Choice` que acceden a este valor para evitar que la máquina de estados se detenga si no se produce ningún error de ejecución. + Una vez establecido en `true`, `hasExecutionError` nunca se establece en falso ni se elimina del contexto. Esto significa que este valor solo es útil la primera vez que se establece en `true` y, para todos los estados posteriores, no proporciona un valor significativo. + El valor `hasExecutionError` se comparte con todas las máquinas de estados de la rama con el estado `Parallel`, lo que puede provocar resultados inesperados en función del orden en que se acceda a él. Debido a estas características, no recomendamos utilizar este método si se puede utilizar un bloque Catch en su lugar. ## Máquinas de estados de ejemplo En esta sección se proporcionan algunos ejemplos de configuraciones de máquinas de estados. **Topics** + [Ejemplo de máquina de estados: ejecutar un solo grupo de pruebas](#single-test-group) + [Ejemplo de máquina de estados: ejecutar grupos de pruebas seleccionados por el usuario](#allow-specific-groups) + [Ejemplo de máquina de estados: ejecutar un solo grupo de pruebas con características de productos](#run-with-product-features) + [Ejemplo de máquina de estados: ejecutar dos grupos de prueba en paralelo](#run-in-parallel) ### Ejemplo de máquina de estados: ejecutar un solo grupo de pruebas Esta máquina de estados: + Ejecuta el grupo de pruebas con ID `GroupA`, que debe estar presente en el conjunto de un archivo `group.json`. + Comprueba si hay errores de ejecución y pasa a `Fail` si se encuentra alguno. + Genera un informe y pasa a `Succeed` si no hay errores y a `Fail` en caso contrario. ``` { "Comment": "Runs a single group and then generates a report.", "StartAt": "RunGroupA", "States": { "RunGroupA": { "Type": "RunTask", "Next": "Report", "TestGroup": "GroupA", "Catch": [ { "ErrorEquals": [ "RunTaskError" ], "Next": "Fail" } ] }, "Report": { "Type": "Report", "Next": "Succeed", "Catch": [ { "ErrorEquals": [ "ReportError" ], "Next": "Fail" } ] }, "Succeed": { "Type": "Succeed" }, "Fail": { "Type": "Fail" } } } ``` ### Ejemplo de máquina de estados: ejecutar grupos de pruebas seleccionados por el usuario Esta máquina de estados: + Comprueba si el ejecutor de pruebas seleccionó grupos de pruebas específicos. La máquina de estados no comprueba si hay casos de prueba específicos porque los ejecutores de pruebas no pueden seleccionar casos de prueba sin seleccionar también un grupo de pruebas. + Si se seleccionan grupos de pruebas: + Ejecuta los casos de prueba dentro de los grupos de pruebas seleccionados. Para ello, la máquina de estados no especifica explícitamente ningún grupo de pruebas o casos de prueba en el estado `RunTask`. + Genera un informe después de ejecutar todas las pruebas y sale. + Si no se seleccionan grupos de pruebas: + Ejecuta las pruebas del grupo de pruebas `GroupA`. + Genera informes y sale. ``` { "Comment": "Runs specific groups if the test runner chose to do that, otherwise runs GroupA.", "StartAt": "SpecificGroupsCheck", "States": { "SpecificGroupsCheck": { "Type": "Choice", "Default": "RunGroupA", "FallthroughOnError": true, "Choices": [ { "Expression": "{{$.specificTestGroups[0]}} != ''", "Next": "RunSpecificGroups" } ] }, "RunSpecificGroups": { "Type": "RunTask", "Next": "Report", "Catch": [ { "ErrorEquals": [ "RunTaskError" ], "Next": "Fail" } ] }, "RunGroupA": { "Type": "RunTask", "Next": "Report", "TestGroup": "GroupA", "Catch": [ { "ErrorEquals": [ "RunTaskError" ], "Next": "Fail" } ] }, "Report": { "Type": "Report", "Next": "Succeed", "Catch": [ { "ErrorEquals": [ "ReportError" ], "Next": "Fail" } ] }, "Succeed": { "Type": "Succeed" }, "Fail": { "Type": "Fail" } } } ``` ### Ejemplo de máquina de estados: ejecutar un solo grupo de pruebas con características de productos Esta máquina de estados: + Ejecuta el grupo de pruebas `GroupA`. + Comprueba si hay errores de ejecución y pasa a `Fail` si se encuentra alguno. + Añade la característica `FeatureThatDependsOnGroupA` al archivo `awsiotdevicetester_report.xml`: + Si `GroupA` supera la prueba, la característica se establece en `supported`. + La característica no se marca como opcional en el informe. + Genera un informe y pasa a `Succeed` si no hay errores y a `Fail` en caso contrario. ``` { "Comment": "Runs GroupA and adds product features based on GroupA", "StartAt": "RunGroupA", "States": { "RunGroupA": { "Type": "RunTask", "Next": "AddProductFeatures", "TestGroup": "GroupA", "ResultVar": "GroupA_passed", "Catch": [ { "ErrorEquals": [ "RunTaskError" ], "Next": "Fail" } ] }, "AddProductFeatures": { "Type": "AddProductFeatures", "Next": "Report", "Features": [ { "Feature": "FeatureThatDependsOnGroupA", "Groups": [ "GroupA" ], "IsRequired": true } ] }, "Report": { "Type": "Report", "Next": "Succeed", "Catch": [ { "ErrorEquals": [ "ReportError" ], "Next": "Fail" } ] }, "Succeed": { "Type": "Succeed" }, "Fail": { "Type": "Fail" } } } ``` ### Ejemplo de máquina de estados: ejecutar dos grupos de prueba en paralelo Esta máquina de estados: + Ejecuta los grupos de pruebas `GroupA` y `GroupB` en paralelo. Las variables `ResultVar` almacenadas en el contexto por los estados `RunTask` de las máquinas de estados de la rama están disponibles para el estado `AddProductFeatures`. + Comprueba si hay errores de ejecución y pasa a `Fail` si se encuentra alguno. Esta máquina de estados no utiliza un bloque `Catch` porque ese método no detecta errores de ejecución en las máquinas de estados de la rama. + Agrega características al archivo `awsiotdevicetester_report.xml` en función de los grupos que aprueban + Si `GroupA` supera la prueba, la característica se establece en `supported`. + La característica no se marca como opcional en el informe. + Genera un informe y pasa a `Succeed` si no hay errores y a `Fail` en caso contrario. Si hay dos dispositivos configurados en el grupo de dispositivos, ambos `GroupA` y `GroupB` pueden ejecutarse al mismo tiempo. Sin embargo, si `GroupA` o `GroupB` incluyen varias pruebas, es posible que ambos dispositivos se asignen a esas pruebas. Si solo se configura un dispositivo, los grupos de prueba se ejecutarán secuencialmente. ``` { "Comment": "Runs GroupA and GroupB in parallel", "StartAt": "RunGroupAAndB", "States": { "RunGroupAAndB": { "Type": "Parallel", "Next": "CheckForErrors", "Branches": [ { "Comment": "Run GroupA state machine", "StartAt": "RunGroupA", "States": { "RunGroupA": { "Type": "RunTask", "Next": "Succeed", "TestGroup": "GroupA", "ResultVar": "GroupA_passed", "Catch": [ { "ErrorEquals": [ "RunTaskError" ], "Next": "Fail" } ] }, "Succeed": { "Type": "Succeed" }, "Fail": { "Type": "Fail" } } }, { "Comment": "Run GroupB state machine", "StartAt": "RunGroupB", "States": { "RunGroupA": { "Type": "RunTask", "Next": "Succeed", "TestGroup": "GroupB", "ResultVar": "GroupB_passed", "Catch": [ { "ErrorEquals": [ "RunTaskError" ], "Next": "Fail" } ] }, "Succeed": { "Type": "Succeed" }, "Fail": { "Type": "Fail" } } } ] }, "CheckForErrors": { "Type": "Choice", "Default": "AddProductFeatures", "FallthroughOnError": true, "Choices": [ { "Expression": "{{$.hasExecutionErrors}} == true", "Next": "Fail" } ] }, "AddProductFeatures": { "Type": "AddProductFeatures", "Next": "Report", "Features": [ { "Feature": "FeatureThatDependsOnGroupA", "Groups": [ "GroupA" ], "IsRequired": true }, { "Feature": "FeatureThatDependsOnGroupB", "Groups": [ "GroupB" ], "IsRequired": true } ] }, "Report": { "Type": "Report", "Next": "Succeed", "Catch": [ { "ErrorEquals": [ "ReportError" ], "Next": "Fail" } ] }, "Succeed": { "Type": "Succeed" }, "Fail": { "Type": "Fail" } } } ``` # Cree ejecutables de casos de prueba de IDT 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 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. IDT inicia el proceso del ejecutable de prueba requerido en función de los comandos y argumentos especificados en el archivo `test.json` y pasa las variables de entorno requeridas al proceso. ## Uso del SDK de cliente de IDT Los SDK de cliente de IDT le permiten simplificar la forma de escribir la lógica de prueba en su ejecutable de prueba con comandos de API que puede utilizar para interactuar con IDT y los dispositivos que se están probando. Actualmente, IDT ofrece los siguientes SDK: + SDK de cliente de IDT para Python + SDK de cliente de IDT para Go + SDK de cliente de IDT para Java Estos SDK se encuentran en la carpeta `/sdks`. Al crear un ejecutable de caso de prueba nuevo, debe copiar el SDK que quiere usar en la carpeta que contiene el ejecutable del caso de prueba y hacer referencia al SDK en su código. En esta sección se proporciona una breve descripción de los comandos de API disponibles que puede usar en los ejecutables de casos de prueba. **Topics** + [Interacción con el dispositivo](#api-device-interaction) + [Interacción con IDT](#api-idt-interaction) + [Interacción con el host](#api-host-interaction) ### 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 intérpretes de comandos en un dispositivo que admite conexiones de intérpretes de comandos SSH o Docker. `CopyToDevice` Permite a los conjuntos de pruebas copiar un archivo local desde la máquina host que ejecuta IDT a una ubicación específica de un dispositivo que admite conexiones de intérpretes de comandos SSH o Docker. `ReadFromDevice` Permite que los conjuntos de pruebas lean desde el puerto de serie de los dispositivos que admiten conexiones UART. **nota** Dado que IDT no gestiona las conexiones directas a los dispositivos que se realizan con información de acceso a los dispositivos procedente del contexto, recomendamos utilizar estos comandos de la API de interacción del dispositivo en los ejecutables de 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 desde el contexto de IDT 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 cómo usar el contexto de IDT, consulte [Uso del contexto de IDT](idt-context.md). ### Interacción con 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 de IDT. Para obtener más información, consulte [Uso del contexto de IDT](idt-context.md). `SendResult` Permite que los conjuntos de pruebas notifiquen los resultados de los casos de prueba a IDT. 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 los conjuntos de pruebas comprueben las notificaciones de IDT. `GetContextValue ` y `GetContextString` Permite que los conjuntos de pruebas recuperen valores del contexto de IDT. Para obtener más información, consulte [Uso del contexto de IDT](idt-context.md). `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 casos de prueba ejecutables. ## Habilitación de comandos de CLI de IDT El comando `run-suite` de la CLI de IDT 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 la CLI de IDT. Si no implementa la compatibilidad, los ejecutores de pruebas podrán seguir ejecutándolas, pero algunas opciones de CLI no funcionarán correctamente. Para ofrecer una experiencia de cliente ideal, le recomendamos que implemente la compatibilidad con los siguientes argumentos para el comando `run-suite` 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 su comando `run-suite`, IDT lo usa para calcular el valor de la variable de entorno IDT\$1TEST\$1TIMEOUT y establece el campo `config.timeoutMultiplier` en el contexto de IDT. Para que se admita este argumento, debe hacer lo siguiente: + En lugar de utilizar directamente el valor de tiempo de espera del archivo `test.json`, lea la variable de entorno IDT\$1TEST\$1TIMEOUT para obtener el valor de tiempo de espera calculado correctamente. + Recupere el valor `config.timeoutMultiplier` del contexto de IDT 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](#test-exec-exiting). `stop-on-first-failure` Especifica que IDT debe dejar de ejecutar todas las pruebas si detecta un error. Cuando un ejecutor de pruebas especifica este argumento en su comando `run-suite`, 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 la compatibilidad, asegúrese de que si IDT detecta este evento, su lógica de pruebas indique a todos los casos de prueba en ejecución que se detengan, se limpien los recursos temporales y se notifique el resultado de la prueba a IDT. Para obtener más información sobre cómo salir anticipadamente en caso de error, consulte [Especificación del comportamiento de salida](#test-exec-exiting). `group-id` y `test-id` Especifica que IDT debe ejecutar solo 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, el orquestador de prueba de su conjunto de pruebas debe incluir un conjunto específico de estados `RunTask` y `Choice` en su orquestador de prueba. Si no usa una máquina de estados personalizada, el orquestador de prueba IDT predeterminado incluye los estados necesarios y no es necesario que realice ninguna acción adicional. Sin embargo, si usa un orquestador de prueba personalizado, use [Ejemplo de máquina de estados: ejecutar grupos de pruebas seleccionados por el usuario](idt-state-machine.md#allow-specific-groups) como ejemplo para agregar los estados necesarios a su orquestador de prueba. Para obtener más información sobre los comandos de la CLI de IDT, consulte [Depurar y ejecutar conjuntos de pruebas personalizadas](run-debug-custom-tests.md). ## 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](idt-review-results-logs.md#idt-console-format). Cuando IDT termina de ejecutar el conjunto de pruebas, esta información también está disponible en el archivo `test_manager.log` ubicado en la carpeta `/results//logs`. 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 `_` ubicado en la carpeta `/results/execution-id/logs`. Para ello, recupere la ruta del archivo de registro del contexto de IDT con la consulta `testData.logFilePath`, cree un archivo en esa ruta y escriba el contenido que desee. 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 en la carpeta `/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. ## Notificación de los resultados a IDT IDT escribe los resultados de las pruebas en los archivos `awsiotdevicetester_report.xml` y `suite-name_report.xml`. Estos archivos de informes están ubicados en `/results//`. 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, consulte [Revisión de los resultados y registros de las pruebas de IDT](idt-review-results-logs.md). Para rellenar el contenido del archivo `suite-name_report.xml`, debe utilizar el comando `SendResult` para notificar los resultados de las pruebas a IDT antes de que finalice la ejecución de la prueba. Si IDT no puede localizar 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 la prueba. La ruta a esta carpeta se almacena en la `testData.testArtifactsPath` indicada en el contexto de IDT. En esta carpeta, IDT utiliza el primer archivo XML ordenado alfabéticamente que localiza como resultado de la prueba. Si la lógica de la prueba genera resultados XML JUnit, puede escribir los resultados de la prueba en un archivo XML en la carpeta de artefactos para proporcionarlos directamente a IDT, en lugar de analizarlos y, a continuación, utilizar la API para enviarlos a 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`. IDT no realiza ninguna validación de los datos que usted proporciona, con las siguientes excepciones: + IDT ignora todas las propiedades de la etiqueta `testsuites`. 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`. 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 provocar 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 IDT pueda utilizar los resultados correctos. Si bien puede utilizar un enfoque mixto para la elaboración de 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. ## 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 comunicar ningún resultado a IDT. Cuando IDT recibe un código de salida distinto de cero, lo marca indicando que el caso de prueba ha detectado 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 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 utilizó el argumento `timeout-multiplier` para especificar un multiplicador de tiempo de espera, IDT calcula el valor de tiempo de espera con el multiplicador. Para detectar este evento, utilice la variable de entorno IDT\$1TEST\$1TIMEOUT. Cuando un ejecutor de pruebas lanza una prueba, IDT establece el valor de la variable de entorno IDT\$1TEST\$1TIMEOUT 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 pruebas interrumpe IDT. Por ejemplo, pulsando Ctrl\$1C. 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 la API para comprobar el valor del booleano `CancellationRequested` en la respuesta de la API `PollForNotifications`. Cuando IDT recibe una señal de interrupción, establece el valor del booleano `CancellationRequested` 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 argumento `stop-on-first-failure` para especificar que IDT debe detenerse cuando encuentra algún error. Para detectar este evento, puede sondear periódicamente la API para comprobar el valor del booleano `CancellationRequested` en la respuesta de la API `PollForNotifications`. Cuando IDT detecta un fallo y está configurado para detenerse en el primer fallo, establece el valor del booleano `CancellationRequested` en `true`. Cuando se produce alguno de estos eventos, IDT espera 5 minutos a que los casos de prueba que se están ejecutando terminen de ejecutarse. 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 IDT no ha recibido los resultados de las pruebas antes de que finalicen los procesos, marcará los casos de prueba como tiempo de espera agotado. 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. 1. Limpiar todos los recursos temporales, como los artefactos de prueba del dispositivo que se está probando. 1. Notificar el resultado de una prueba a IDT, como un fallo o un error en la prueba. 1. Salir. # Uso del contexto de IDT Cuando IDT ejecuta un conjunto de pruebas, el conjunto de pruebas puede acceder a un conjunto de datos que se pueden utilizar para determinar cómo se ejecuta cada prueba. Estos datos se denominan contexto de IDT. Por ejemplo, la configuración de los datos de usuario proporcionada por los ejecutores de pruebas en un archivo `userdata.json` se pone a disposición de los conjuntos de pruebas en el contexto de IDT. El contexto de IDT puede considerarse un documento JSON de solo lectura. Los conjuntos de pruebas pueden recuperar datos del contexto y escribirlos en él mediante tipos de datos JSON estándar, como objetos, matrices, números, etc. ## Esquema de contexto El contexto de IDT utiliza el siguiente formato: ``` { "config": { "timeoutMultiplier": timeout-multiplier }, "device": { }, "devicePool": { }, "resource": { "devices": [ { "name": "" } ] }, "testData": { "awsCredentials": { "awsAccessKeyId": "", "awsSecretAccessKey": "", "awsSessionToken": "" }, "logFilePath": "/path/to/log/file" }, "userData": { } } ``` `config` Información del [archivo `config.json`](set-custom-idt-config.md#config-json-custom). El campo `config` también contiene el siguiente campo adicional: `config.timeoutMultiplier` El multiplicador para cualquier valor de tiempo de espera utilizado por el conjunto de pruebas. El ejecutor de pruebas especifica este valor desde la CLI de IDT. El valor predeterminado es `1`. `device` Información sobre el dispositivo seleccionado para la prueba. Esta información equivale al elemento de matriz `devices` del [archivo `device.json`](set-custom-idt-config.md#device-config-custom) del dispositivo seleccionado. `devicePool` Información sobre el grupo de dispositivos seleccionado para la ejecución de la prueba. Esta información equivale al elemento de matriz del grupo de dispositivos en el nivel superior definido en el archivo `device.json` para el grupo de dispositivos seleccionado. `resource` Información sobre los dispositivos de recursos del archivo `resource.json`. `resource.devices` Esta información equivale a la matriz `devices` definida en el archivo `resource.json`. Cada elemento `devices` incluye el siguiente campo adicional: `resource.device.name` El nombre del dispositivo de recursos. Este valor se establece en el valor `requiredResource.name` en el archivo `test.json`. `testData.awsCredentials` Las credenciales de AWS que se utilizan en la prueba para conectarse a la nube de AWS. Esta información se obtiene del archivo `config.json`. `testData.logFilePath` La ruta al archivo de registro en el que el caso de prueba escribe los mensajes de registro. El conjunto de pruebas crea este archivo si no existe. `userData` Información proporcionada por el ejecutor de la prueba en el [archivo `userdata.json`](set-custom-idt-config.md#userdata-config-custom). ## Acceda a los datos en el contexto Puede consultar el contexto mediante la notación JSONPath de sus archivos JSON y de su ejecutable de texto con las API `GetContextValue` y`GetContextString`. La sintaxis de las cadenas JSONPath para acceder al contexto IDT varía de la siguiente manera: + En `suite.json` y `test.json`, se usa `{{query}}` Es decir, no utilice el elemento raíz `$.` para iniciar la expresión. + En `test_orchestrator.yaml`, se usa `{{query}}`. Si usa la máquina de estados obsoleta, entonces en `state_machine.json`, usa `{{$.query}}`. + En los comandos de la API, se utiliza `query` o `{{$.query}}`, según el comando. Para obtener más información, consulte la documentación en línea en los SDK. En la siguiente tabla se describen los operadores de una expresión JSONPath típica: | Operator | Description | | --- |--- | | \$1 | The root element. Because the top-level context value for IDT is an object, you will typically use \$1. to start your queries. | | .childName | Accesses the child element with name childName from an object. If applied to an array, yields a new array with this operator applied to each element. The element name is case sensitive. For example, the query to access the awsRegion value in the config object is \$1.config.awsRegion. | | [start:end] | Filters elements from an array, retrieving items beginning from the iniciar index and going up to the finales index, both inclusive. | | [index1, index2, ... , indexN] | Filters elements from an array, retrieving items from only the specified indices. | | [?(expr)] | Filters elements from an array using the expr expression. This expression must evaluate to a boolean value. | Para crear expresiones de filtro, utilice la siguiente sintaxis: ``` | operator | ``` En esta sintaxis: + `jsonpath` es un JSONPath que utiliza la sintaxis JSON estándar. + `value` es cualquier valor personalizado que utilice la sintaxis JSON estándar. + `operator` es uno de los siguientes operadores: + `<` (Menor que) + `<=` (Menor o igual que) + `==` (Igual que) Si el JSONPath o el valor de la expresión es un valor de matriz, booleano o de objeto, este es el único operador binario compatible que puede utilizar. + `>=` (Mayor o igual que) + `>` (Mayor que) + `=~` (Coincidencia de expresión regular). Para usar este operador en una expresión de filtro, el JSONPath o el valor del lado izquierdo de la expresión debe evaluarse como una cadena y el lado derecho debe ser un valor de patrón que siga la sintaxis [RE2](https://github.com/google/re2/wiki/Syntax). Puede utilizar consultas JSONPath con el formato \$1\$1*query*\$1\$1 como cadenas de marcador de posición dentro de los campos `args` y `environmentVariables` en los archivos `test.json` y dentro de los campos `environmentVariables` en los archivos `suite.json`. IDT realiza una búsqueda contextual y rellena los campos con el valor evaluado de la consulta. Por ejemplo, en el archivo `suite.json`, puede utilizar cadenas de marcadores de posición para especificar los valores de las variables de entorno que cambian con cada caso de prueba e IDT rellenará las variables de entorno con el valor correcto para cada caso de prueba. Sin embargo, cuando se utilizan cadenas de marcadores de posición en los archivos `test.json` y `suite.json`, las consultas tienen en cuenta las siguientes consideraciones: + Debe escribir en minúsculas cada vez que aparezca la clave `devicePool` en la consulta. Es decir, utilizar `devicepool` en su lugar. + Para las matrices, solo puede usar matrices de cadenas. Además, las matrices utilizan un formato `item1, item2,...,itemN` no estándar. Si la matriz contiene solo un elemento, se serializa como `item`, lo que la hace que no se pueda distinguir de un campo de cadena. + No puede utilizar marcadores de posición para recuperar objetos del contexto. Debido a estas consideraciones, le recomendamos que, siempre que sea posible, utilice la API para acceder al contexto en su lógica de prueba en lugar de cadenas de marcadores de posición en los archivos `test.json` y `suite.json`. Sin embargo, en algunos casos puede ser más conveniente utilizar marcadores de posición de JSONPath para recuperar cadenas individuales y configurarlas como variables de entorno. # Configuración de los ajustes para los ejecutores de pruebas Para ejecutar conjuntos de pruebas personalizados, los ejecutores de pruebas deben configurar sus ajustes en función del conjunto de pruebas que desean ejecutar. Los ajustes se especifican en función de las plantillas del archivo de configuración que se encuentran en la carpeta `/configs/`. Si es necesario, los ejecutores de las pruebas también deben configurar las credenciales de AWS que IDT utilizará para conectarse a la nube de AWS. Como redactor de pruebas, necesitará configurar estos archivos para [depurar su conjunto de pruebas](run-debug-custom-tests.md). Debe proporcionar instrucciones a los ejecutores de pruebas para que puedan configurar los siguientes ajustes según sea necesario para ejecutar sus conjuntos de pruebas. ## Configurar device.json El archivo `device.json` contiene información sobre los dispositivos en los que se ejecutan las pruebas (por ejemplo, dirección IP, información de inicio de sesión, sistema operativo y arquitectura de la CPU). Los ejecutores de pruebas pueden proporcionar esta información mediante el siguiente archivo `device.json` de plantilla que se encuentra en la carpeta `/configs/`. ``` [ { "id": "", "sku": "", "features": [ { "name": "", "value": "", "configs": [ { "name": "", "value": "" } ], } ], "devices": [ { "id": "", "connectivity": { "protocol": "ssh | uart | docker", // ssh "ip": "", "port": , "auth": { "method": "pki | password", "credentials": { "user": "", // pki "privKeyPath": "/path/to/private/key", // password "password": "", } }, // uart "serialPort": "", // docker "containerId": "", "containerUser": "", } } ] } ] ``` Todos los campos que contienen valores son obligatorios tal y como se describe aquí: `id` Un ID alfanumérico definido por el usuario que identifica de forma única una colección de dispositivos que se conoce como *grupo de dispositivos*. Los dispositivos que pertenecen a un grupo deben tener idéntico hardware. Al ejecutar un conjunto de pruebas, los dispositivos del grupo se utilizan para paralelizar la carga de trabajo. Se utilizan varios dispositivos para ejecutar diferentes pruebas. `sku` Un valor alfanumérico que identifica de forma única el dispositivo a prueba. El SKU se utiliza para realizar un seguimiento de los dispositivos cualificados. Si desea enumerar la placa en el catálogo de dispositivos de AWS Partner, el SKU que especifique aquí debe coincidir con el SKU que utilice en el proceso de publicación. `features` Opcional. Una matriz que contenga las características compatibles del dispositivo. Las características del dispositivo son valores definidos por el usuario que se configuran en el conjunto de pruebas. Debe proporcionar a los ejecutores de las pruebas información sobre los nombres y valores de las características que desee incluir en el archivo `device.json`. Por ejemplo, si quiere probar un dispositivo que funciona como servidor MQTT para otros dispositivos, puede configurar la lógica de prueba para validar los niveles admitidos específicos para una característica denominada `MQTT_QOS`. Los ejecutores de las pruebas proporcionan el nombre de esta característica y establecen su valor en los niveles de QOS compatibles con su dispositivo. Puede recuperar la información proporcionada desde el [contexto de IDT](idt-context.md) con la consulta `devicePool.features`, o desde el [contexto del orquestador de pruebas](idt-state-machine.md#state-machine-context) con la consulta `pool.features`. `features.name` El nombre de la característica. `features.value` Los valores de la característica admitidos. `features.configs` Los ajustes de configuración de la característica, si son necesarios. `features.config.name` El nombre del ajuste de configuración. `features.config.value` Los valores de configuración admitidos. `devices` Una matriz de dispositivos en el grupo que se va a probar. Se requiere al menos un dispositivo. `devices.id` Un identificador único y definido por el usuario para el dispositivo que se está probando. `connectivity.protocol` El protocolo de comunicación que se usará para la comunicación con este dispositivo. Cada dispositivo de un grupo debe usar el mismo protocolo. Actualmente, los únicos valores que se admiten son `ssh` y `uart` para dispositivos físicos y `docker` para contenedores de Docker. `connectivity.ip` La dirección IP del dispositivo que se está probando. Esta propiedad solo se aplica si `connectivity.protocol` está establecido en `ssh`. `connectivity.port` Opcional. El número de puerto que se va a utilizar para las conexiones SSH. El valor predeterminado es 22. Esta propiedad solo se aplica si `connectivity.protocol` está establecido en `ssh`. `connectivity.auth` Información de autenticación para la conexión. Esta propiedad solo se aplica si `connectivity.protocol` está establecido en `ssh`. `connectivity.auth.method` El método de autenticación que se utiliza para acceder a un dispositivo a través de un determinado protocolo de conectividad. Los valores admitidos son: + `pki` + `password` `connectivity.auth.credentials` Las credenciales que se utilizan para la autenticación. `connectivity.auth.credentials.password` La contraseña que se utiliza para iniciar sesión en el dispositivo que se va a probar. Este valor solo se aplica si `connectivity.auth.method` está establecido en `password`. `connectivity.auth.credentials.privKeyPath` La ruta completa a la clave privada que se utiliza para iniciar sesión en el dispositivo que se está probando. Este valor solo se aplica si `connectivity.auth.method` está establecido en `pki`. `connectivity.auth.credentials.user` El nombre de usuario para iniciar sesión en el dispositivo que se está probando. `connectivity.serialPort` Opcional. El puerto serie al que está conectado el dispositivo. Esta propiedad solo se aplica si `connectivity.protocol` está establecido en `uart`. `connectivity.containerId` El ID de contenedor o el nombre del contenedor de Docker que se está probando. Esta propiedad solo se aplica si `connectivity.protocol` está establecido en `ssh`. `connectivity.containerUser` Opcional. El nombre del usuario que se va a utilizar dentro del contenedor. El valor predeterminado es el usuario proporcionado en el Dockerfile. El valor predeterminado es 22. Esta propiedad solo se aplica si `connectivity.protocol` está establecido en `ssh`. Para verificar si los ejecutores de pruebas configuran la conexión de dispositivo incorrecta para una prueba, puede recuperar `pool.Devices[0].Connectivity.Protocol` del contexto del orquestador de pruebas y compararlo con el valor esperado en un estado `Choice`. Si se utiliza un protocolo incorrecto, imprima un mensaje con el estado `LogMessage` y haga la transición al estado `Fail`. Como alternativa, puede utilizar un código de gestión de errores para informar de un fallo en la prueba para los tipos de dispositivos incorrectos. ## (Opcional) Configuración de userdata.json El archivo `userdata.json` contiene cualquier información adicional que requiera un conjunto de pruebas, pero que no esté especificada en el archivo `device.json`. El formato de este archivo depende del [archivo `userdata_scheme.json`](idt-json-config.md#userdata-schema-json) definido en el conjunto de pruebas. Si es un redactor de pruebas, asegúrese de proporcionar esta información a los usuarios que van a ejecutar los conjuntos de pruebas que escriba. ## (Opcional) Configuración de resource.json El archivo `resource.json` contiene información sobre los dispositivos que se van a utilizar como dispositivos de recursos. Los dispositivos de recursos son dispositivos que se requieren para probar ciertas capacidades de un dispositivo que se está probando. Por ejemplo, para probar la capacidad Bluetooth de un dispositivo, puede usar un dispositivo de recursos para comprobar si el dispositivo se puede conectar correctamente a él. Los dispositivos de recursos son opcionales y puede requerir tantos dispositivos de recursos como necesite. Como redactor de pruebas, utilice el [archivo test.json](idt-json-config.md#test-json) para definir las características del dispositivo de recursos que se requieren para una prueba. A continuación, los ejecutores de pruebas utilizan el archivo `resource.json` para proporcionar un grupo de dispositivos de recursos que tengan las características necesarias. Asegúrese de proporcionar esta información a los usuarios que vayan a ejecutar los conjuntos de pruebas que escriba. Los ejecutores de pruebas pueden proporcionar esta información mediante el siguiente archivo `resource.json` de plantilla que se encuentra en la carpeta `/configs/`. ``` [ { "id": "", "features": [ { "name": "", "version": "", "jobSlots": } ], "devices": [ { "id": "", "connectivity": { "protocol": "ssh | uart | docker", // ssh "ip": "", "port": , "auth": { "method": "pki | password", "credentials": { "user": "", // pki "privKeyPath": "/path/to/private/key", // password "password": "", } }, // uart "serialPort": "", // docker "containerId": "", "containerUser": "", } } ] } ] ``` Todos los campos que contienen valores son obligatorios tal y como se describe aquí: `id` Un ID alfanumérico definido por el usuario que identifica de forma única una colección de dispositivos que se conoce como *grupo de dispositivos*. Los dispositivos que pertenecen a un grupo deben tener idéntico hardware. Al ejecutar un conjunto de pruebas, los dispositivos del grupo se utilizan para paralelizar la carga de trabajo. Se utilizan varios dispositivos para ejecutar diferentes pruebas. `features` Opcional. Una matriz que contenga las características compatibles del dispositivo. La información requerida en este campo se define en los [archivos test.json](idt-json-config.md#test-json) del conjunto de pruebas y determina qué pruebas se van a ejecutar y cómo se van a ejecutar. Si el conjunto de pruebas no requiere ninguna característica, este campo no es obligatorio. `features.name` El nombre de la característica. `features.version` La versión de la característica. `features.jobSlots` Configuración para indicar cuántas pruebas pueden utilizar el dispositivo simultáneamente. El valor predeterminado es `1`. `devices` Una matriz de dispositivos en el grupo que se va a probar. Se requiere al menos un dispositivo. `devices.id` Un identificador único y definido por el usuario para el dispositivo que se está probando. `connectivity.protocol` El protocolo de comunicación que se usará para la comunicación con este dispositivo. Cada dispositivo de un grupo debe usar el mismo protocolo. Actualmente, los únicos valores que se admiten son `ssh` y `uart` para dispositivos físicos y `docker` para contenedores de Docker. `connectivity.ip` La dirección IP del dispositivo que se está probando. Esta propiedad solo se aplica si `connectivity.protocol` está establecido en `ssh`. `connectivity.port` Opcional. El número de puerto que se va a utilizar para las conexiones SSH. El valor predeterminado es 22. Esta propiedad solo se aplica si `connectivity.protocol` está establecido en `ssh`. `connectivity.auth` Información de autenticación para la conexión. Esta propiedad solo se aplica si `connectivity.protocol` está establecido en `ssh`. `connectivity.auth.method` El método de autenticación que se utiliza para acceder a un dispositivo a través de un determinado protocolo de conectividad. Los valores admitidos son: + `pki` + `password` `connectivity.auth.credentials` Las credenciales que se utilizan para la autenticación. `connectivity.auth.credentials.password` La contraseña que se utiliza para iniciar sesión en el dispositivo que se va a probar. Este valor solo se aplica si `connectivity.auth.method` está establecido en `password`. `connectivity.auth.credentials.privKeyPath` La ruta completa a la clave privada que se utiliza para iniciar sesión en el dispositivo que se está probando. Este valor solo se aplica si `connectivity.auth.method` está establecido en `pki`. `connectivity.auth.credentials.user` El nombre de usuario para iniciar sesión en el dispositivo que se está probando. `connectivity.serialPort` Opcional. El puerto serie al que está conectado el dispositivo. Esta propiedad solo se aplica si `connectivity.protocol` está establecido en `uart`. `connectivity.containerId` El ID de contenedor o el nombre del contenedor de Docker que se está probando. Esta propiedad solo se aplica si `connectivity.protocol` está establecido en `ssh`. `connectivity.containerUser` Opcional. El nombre del usuario que se va a utilizar dentro del contenedor. El valor predeterminado es el usuario proporcionado en el Dockerfile. El valor predeterminado es 22. Esta propiedad solo se aplica si `connectivity.protocol` está establecido en `ssh`. ## (Opcional) Configuración de config.json El archivo `config.json` contiene la información de configuración para IDT. Por lo general, los ejecutores de pruebas no necesitarán modificar este archivo excepto para proporcionar sus credenciales de usuario de AWS para IDT y, opcionalmente, una región de AWS. Si se proporcionan las credenciales de AWS con los permisos necesarios, AWS IoT Device Tester recopila y envía las métricas de uso a AWS. Se trata de una característica opcional que se utiliza para mejorar la funcionalidad de IDT. Para obtener más información, consulte [Métricas de uso de IDT](idt-usage-metrics.md). Los ejecutores de pruebas pueden configurar sus credenciales de AWS de una de las siguientes maneras: + **Archivo de credenciales** IDT utiliza el mismo archivo de credenciales que la AWS CLI. Para obtener más información, consulte [Configuración y archivos de credenciales](https://docs.aws.amazon.com/cli/latest/userguide/cli-config-files.html). La ubicación del archivo de credenciales varía en función del sistema operativo que utilice: + macOS, Linux: `~/.aws/credentials` + Windows: : `C:\Users\UserName\.aws\credentials` + **Variables de entorno** Las variables de entorno son las variables que mantiene el sistema operativo y utilizan los comandos del sistema. Las variables definidas durante una sesión de SSH no están disponibles una vez cerrada la sesión. IDT puede usar las variables de entorno `AWS_ACCESS_KEY_ID` y `AWS_SECRET_ACCESS_KEY` para almacenar sus credenciales de AWS. Para establecer estas variables en Linux, MacOS, o Unix, utilice : **export**: ``` export AWS_ACCESS_KEY_ID= export AWS_SECRET_ACCESS_KEY= ``` Para establecer estas variables en Windows, utilice **set**: ``` set AWS_ACCESS_KEY_ID= set AWS_SECRET_ACCESS_KEY= ``` Para configurar las credenciales de AWS para IDT, los ejecutores de pruebas editan la sección `auth` del archivo `config.json` ubicado en la carpeta `/configs/`. ``` { "log": { "location": "logs" }, "configFiles": { "root": "configs", "device": "configs/device.json" }, "testPath": "tests", "reportPath": "results", "awsRegion": "", "auth": { "method": "file | environment", "credentials": { "profile": "" } } } ] ``` Todos los campos que contienen valores son obligatorios tal y como se describe aquí: **nota** Todas las rutas de este archivo se definen en relación con **. `log.location` La ruta a la carpeta de registros en **. `configFiles.root` La ruta a la carpeta que contiene los archivos de configuración. `configFiles.device` La ruta al archivo `device.json`. `testPath` La ruta a la carpeta que contiene los conjuntos de pruebas. `reportPath` La ruta a la carpeta que contendrá los resultados de las pruebas después de que IDT ejecute un conjunto de pruebas. `awsRegion` Opcional. La región de AWS que utilizarán los conjuntos de pruebas. Si no se establece, los conjuntos de pruebas utilizarán la región predeterminada especificada en cada conjunto de pruebas. `auth.method` El método que IDT utiliza para recuperar las credenciales de AWS. Los valores admitidos son `file` para recuperar las credenciales de un archivo de credenciales y `environment` para recuperar las credenciales mediante variables de entorno. `auth.credentials.profile` El perfil de credenciales que se va a utilizar del archivo de credenciales. Esta propiedad solo se aplica si `auth.method` está establecido en `file`. # Depurar y ejecutar conjuntos de pruebas personalizadas Una vez establecida la [configuración requerida](set-custom-idt-config.md), IDT puede ejecutar su conjunto de pruebas. El tiempo de ejecución del conjunto de pruebas completa depende del hardware y de la composición del conjunto de pruebas. Como referencia, se tarda aproximadamente 30 minutos en completar el conjunto de pruebas de AWS IoT Greengrass completo en una unidad Raspberry Pi 3B. Mientras escribe su conjunto de pruebas, puede usar IDT para ejecutarla en modo de depuración, comprobar el código antes de ejecutarla o proporcionárselo a los ejecutores de pruebas. ## Ejecución de IDT en modo de depuración Como los conjuntos de pruebas dependen de IDT para interactuar con los dispositivos, proporcionar el contexto y recibir los resultados, no puede simplemente depurar sus conjuntos de pruebas en un IDE sin ninguna interacción con IDT. Para ello, la CLI de IDT proporciona el comando `debug-test-suite`, que permite ejecutar IDT en modo de depuración. Ejecute el siguiente comando para ver las opciones disponibles para `debug-test-suite`: ``` devicetester_[linux | mac | win_x86-64] debug-test-suite -h ``` Cuando se ejecuta IDT en modo de depuración, IDT no inicia realmente el conjunto de pruebas ni ejecuta orquestador de pruebas, sino que interactúa con el IDE para responder a las solicitudes realizadas desde el conjunto de pruebas que se ejecuta en el IDE e imprime los registros en la consola. IDT no agota el tiempo de espera y espera a salir hasta que se interrumpa manualmente. En el modo de depuración, IDT tampoco ejecuta el orquestador de pruebas y no generará ningún archivo de informe. Para depurar su conjunto de pruebas, debe usar su IDE para proporcionar cierta información que IDT suele obtener de los archivos JSON de configuración. Asegúrese de que proporciona la siguiente información: + Variables de entorno y argumentos para cada prueba. IDT no leerá esta información de `test.json` ni `suite.json`. + Argumentos para seleccionar los dispositivos de recursos. IDT no leerá esta información de `test.json`. Para depurar los conjuntos de pruebas, complete los pasos siguientes: 1. Cree los archivos de configuración de ajustes necesarios para ejecutar el conjunto de pruebas. Por ejemplo, si su conjunto de pruebas requiere `device.json`, `resource.json`, y `user data.json`, asegúrese de configurarlos todos según sea necesario. 1. Ejecute el siguiente comando para establecer IDT en modo de depuración y seleccione los dispositivos necesarios para ejecutar la prueba. ``` devicetester_[linux | mac | win_x86-64] debug-test-suite [options] ``` Tras ejecutar este comando, IDT espera las solicitudes del conjunto de pruebas y, a continuación, responde a ellas. IDT también genera las variables de entorno que se requieran para el proceso de casos para el SDK de cliente de IDT. 1. En su IDE, utilice la configuración `run` o `debug` para hacer lo siguiente: 1. Establecer los valores de las variables de entorno generadas por IDT. 1. Establecer el valor de cualquier variable de entorno o argumento que haya especificado en el archivo `test.json` y `suite.json`. 1. Establecer los puntos de interrupción según sea necesario. 1. Ejecute el conjunto de pruebas en su IDE. Puede depurar y volver a ejecutar el conjunto de pruebas tantas veces como sea necesario. En el modo de depuración, IDT no agota el tiempo de espera. 1. Una vez completada la depuración, interrumpa IDT para salir del modo de depuración. ## Comandos de la CLI de IDT para ejecutar pruebas En la sección siguiente se describen los comandos de la CLI de IDT. ------ #### [ IDT v4.0.0 ] `help` Enumera información acerca del comando especificado. `list-groups` Muestra los grupos de un conjunto de prueba determinado. `list-suites` Muestra los conjuntos de prueba disponibles. `list-supported-products` Enumera los productos compatibles con su versión de IDT, en este caso las versiones AWS IoT Greengrass de cualificaciones AWS IoT Greengrass y las versiones del conjunto de pruebas para la versión actual de IDT. `list-test-cases` Enumera los casos de prueba en un grupo de prueba determinado. Se admite la siguiente opción: + `group-id`. El grupo de pruebas que se va a buscar. Esta opción es necesaria y debe especificar un solo grupo. `run-suite` Ejecuta un conjunto de pruebas en un grupo de dispositivos. Estas son algunas opciones que suelen utilizarse: + `suite-id`. La versión del conjunto de pruebas que se va a ejecutar. Si no se especifica, IDT utiliza la versión más reciente de la carpeta `tests`. + `group-id`. Los grupos de pruebas que se van a ejecutar, como una lista separada por comas. Si no se especifica, IDT ejecuta todos los grupos de prueba del conjunto de pruebas. + `test-id`. Los casos de prueba que se van a ejecutar, como una lista separada por comas. Cuando se especifique, `group-id` debe especificar un solo grupo. + `pool-id`. El grupo de dispositivos que se va a probar. Los ejecutores de las pruebas deben especificar un grupo si tienen varios grupos de dispositivos definidos en el archivo `device.json`. + `timeout-multiplier`. Configura IDT para modificar el tiempo de espera de ejecución de la prueba especificado en el archivo `test.json` para una prueba con un multiplicador definido por el usuario. + `stop-on-first-failure`. Configura IDT para detener la ejecución en el primer error. Esta opción debe utilizarse con `group-id` para depurar los grupos de prueba especificados. + `userdata`. Establece el archivo que contiene la información sobre los datos del usuario necesarios para ejecutar el conjunto de pruebas. Esto solo es necesario si `userdataRequired` está establecido en verdadero en el archivo `suite.json` del conjunto de pruebas. Para obtener más información acerca de `run-suite` las opciones, utilice la opción `help`: ``` devicetester_[linux | mac | win_x86-64] run-suite -h ``` `debug-test-suite` Ejecute el conjunto de pruebas en modo de depuración. Para obtener más información, consulte [Ejecución de IDT en modo de depuración](#idt-debug-mode). ------ # Revisión de los resultados y registros de las pruebas de IDT En esta sección se describe el formato en que IDT genera los registros de la consola y los informes de las pruebas. ## Formato de mensajes de consola AWS IoT Device Tester utiliza un formato estándar para imprimir mensajes en la consola cuando inicia un conjunto de pruebas. En el fragmento siguiente se muestra un ejemplo de mensaje de consola generado por IDT. ``` time="2000-01-02T03:04:05-07:00" level=info msg=Using suite: MyTestSuite_1.0.0 executionId=9a52f362-1227-11eb-86c9-8c8590419f30 ``` La mayoría de los mensajes de consola constan de los siguientes campos: `time` Una marca de tiempo completa conforme a la norma ISO 8601 para el evento registrado. `level` El nivel de mensaje del evento registrado. Normalmente, el nivel del mensaje registrado es uno de los siguientes: `info`, `warn` o `error`. IDT emite un mensaje `panic` o `fatal` si detecta un evento esperado que provoca su cierre anticipado. `msg` El mensaje registrado. `executionId` Una cadena de ID único para el proceso de IDT actual. Este ID se utiliza para diferenciar entre ejecuciones de IDT individuales. Los mensajes de consola generados a partir de un conjunto de pruebas proporcionan información adicional sobre el dispositivo que se está probando y el conjunto de pruebas, el grupo de pruebas y los casos de prueba que ejecuta IDT. En el fragmento siguiente se muestra un ejemplo de un mensaje de consola generado por un conjunto de pruebas. ``` time="2000-01-02T03:04:05-07:00" level=info msg=Hello world! suiteId=MyTestSuite groupId=myTestGroup testCaseId=myTestCase deviceId=my-device executionId=9a52f362-1227-11eb-86c9-8c8590419f30 ``` La parte específica del mensaje de la consola para el conjunto de pruebas contiene los siguientes campos: `suiteId` El nombre del conjunto de pruebas que se está ejecutando. `groupId` El ID del grupo de pruebas que se está ejecutando. `testCaseId` El ID del caso de prueba que se está ejecutando. `deviceId` Un ID del dispositivo que se está probando y que el caso de prueba está utilizando. Para imprimir un resumen de la prueba en la consola cuando IDT termina de ejecutar una prueba, debe incluir un [estado de `Report`](idt-state-machine.md#state-report) en el orquestador de pruebas. El resumen de la prueba contiene información sobre el conjunto de pruebas, los resultados de las pruebas de cada grupo que se ejecutó y las ubicaciones de los registros y archivos de informes generados. En el siguiente ejemplo se muestra un mensaje de resumen de la prueba. ``` ========== Test Summary ========== Execution Time: 5m00s Tests Completed: 4 Tests Passed: 3 Tests Failed: 1 Tests Skipped: 0 ---------------------------------- Test Groups: GroupA: PASSED GroupB: FAILED ---------------------------------- Failed Tests: Group Name: GroupB Test Name: TestB1 Reason: Something bad happened ---------------------------------- Path to IoT Device Tester Report: /path/to/awsiotdevicetester_report.xml Path to Test Execution Logs: /path/to/logs Path to Aggregated JUnit Report: /path/to/MyTestSuite_Report.xml ``` ## Esquema de informe de AWS IoT Device Tester `awsiotdevicetester_report.xml` es un informe firmado que contiene la siguiente información: + La versión de IDT. + La versión del conjunto de pruebas. + La firma del informe y la clave utilizada para firmarlo. + El SKU del dispositivo y el grupo de dispositivos especificado en el archivo `device.json`. + La versión del producto y las características del dispositivo que se han probado. + El resumen de agregación de los resultados de las pruebas. Esta información es la misma que la que se incluye en el archivo `suite-name_report.xml`. ``` idt-version test-suite-version signature keyname execution-id start-time end-time product-name product-version device-sku device-name ssh | uart | docker ``` El archivo `awsiotdevicetester_report.xml` contiene una etiqueta `` que tiene información sobre el producto que se está probando y las características del producto que se han validado después de ejecutar un conjunto de pruebas.Atributos que se utilizan en la etiqueta `` `name` El nombre del producto que se está probando. `version` La versión del producto que se está probando. `features` Las características validadas. Las características marcadas como `required` son necesarias para que el conjunto de pruebas valide el dispositivo. En el siguiente fragmento se muestra cómo aparece esta información en el archivo `awsiotdevicetester_report.xml`. ``` ``` Las funciones marcadas como `optional` no son necesarias para la validación. Los siguientes fragmentos muestran características opcionales: ``` 
 ``` ## Esquema del informe del conjunto de pruebas El informe `suite-name_Result.xml` está en [formato XML JUnit](https://llg.cubic.org/docs/junit/). Puede integrarlo en plataformas de integración/implementación continua como [Jenkins](https://jenkins.io/), [Bamboo](https://www.atlassian.com/software/bamboo), etc. El informe contiene un resumen global de los resultados de las pruebas. ``` reason reason reason ``` La sección de informe tanto en `awsiotdevicetester_report.xml` como en `suite-name_report.xml` enumera las pruebas que se han ejecutado y los resultados. La primera etiqueta XML `` contiene el resumen de la ejecución de las pruebas. Por ejemplo: ``` ```Atributos que se utilizan en la etiqueta `` `name` El nombre del grupo de prueba. `time` El tiempo, en segundos, que se ha tardado en ejecutar el conjunto de pruebas. `tests` El número de pruebas ejecutadas. `failures` El número de pruebas que se ejecutaron, pero que no se superaron. `errors` El número de pruebas que IDT no ha podido ejecutar. `disabled` Este atributo no se utiliza y se puede omitir. Si se producen errores en pruebas, puede identificar la prueba fallido revisando las etiquetas XML ``. Las etiquetas XML `` dentro de la etiqueta `` muestran el resumen del resultado de la prueba de un grupo de prueba. Por ejemplo: ``` ``` El formato es similar a la etiqueta ``, pero con un atributo `skipped` que no se utiliza y que se puede pasar por alto. Dentro de cada etiqueta XML ``, hay etiquetas `` para cada prueba ejecutada para un grupo de prueba. Por ejemplo: ``` > ```Atributos que se utilizan en la etiqueta `` `name` El nombre de la prueba. `attempts` El número de veces que IDT ha ejecutado el caso de prueba. Cuando una prueba genera un error o si se produce un error, las etiquetas `` o `` se agregan a la etiqueta `` con información para la resolución de problemas. Por ejemplo: ``` Reason for the test failure Reason for the test execution error ``` # Métricas de uso de IDT Si proporciona AWS credenciales con los permisos necesarios, AWS IoT Device Tester recopila y envía las métricas de uso a AWS. Se trata de una característica opcional que se utiliza para mejorar la funcionalidad de IDT. IDT recopila información como la siguiente: + El Cuenta de AWS ID utilizado para ejecutar IDT + Los AWS CLI comandos de IDT utilizados para ejecutar las pruebas + El conjunto de pruebas que se ejecutan + Los conjuntos de pruebas de la carpeta ** + La cantidad de dispositivos configurados en el grupo de dispositivos + Los nombres de casos de prueba y los tiempos de ejecución + La información sobre los resultados de las pruebas, por ejemplo, si se han superado, si han fallado, si se han encontrado errores o si se han omitido + Las características del producto probadas + El comportamiento de salida de IDT, como salidas inesperadas o anticipadas Toda la información que IDT envía también se registra en un archivo `metrics.log` de la carpeta `/results//`. Puede consultar el archivo de registro para ver la información recopilada durante la ejecución de una prueba. Este archivo se genera solo si elige recopilar métricas de uso. Para deshabilitar la recopilación de métricas, no es necesario que realice ninguna acción adicional. Simplemente no almacene sus AWS credenciales y, si AWS las tiene almacenadas, no configure el `config.json` archivo para acceder a ellas. ## Configure sus AWS credenciales Si aún no tiene una Cuenta de AWS, debe [crear una](#idt-metrics-aws-account). Si ya tiene una Cuenta de AWS, solo tiene que [configurar los permisos necesarios](#idt-metrics-permissions) para su cuenta para que IDT pueda enviarle las métricas de uso AWS en su nombre. ### Paso 1: Crea una Cuenta de AWS En este paso, cree y configure una Cuenta de AWS. Si ya tiene una Cuenta de AWS, vaya directamente a [Paso 2: Configurar los permisos de IDT](#idt-metrics-permissions). Si no tiene uno Cuenta de AWS, complete los siguientes pasos para crearlo. **Para suscribirte a una Cuenta de AWS** 1. Abrir [https://portal.aws.amazon.com/billing/registro](https://portal.aws.amazon.com/billing/signup). 1. Siga las instrucciones que se le indiquen. Parte del procedimiento de registro consiste en recibir una llamada telefónica o mensaje de texto e indicar un código de verificación en el teclado del teléfono. Cuando te registras en un Cuenta de AWS, *Usuario raíz de la cuenta de AWS*se crea un. El usuario raíz tendrá acceso a todos los Servicios de AWS y recursos de esa cuenta. Como práctica recomendada de seguridad, asigne acceso administrativo a un usuario y utilice únicamente el usuario raíz para realizar [Tareas que requieren acceso de usuario raíz](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_root-user.html#root-user-tasks). Para crear un usuario administrador, elija una de las siguientes opciones. **** | Elegir una forma de administrar el administrador | Para | Haga esto | También puede | | --- | --- | --- | --- | | En IAM Identity Center (recomendado) | Usar credenciales a corto plazo para acceder a AWS.Esto se ajusta a las prácticas recomendadas de seguridad. Para obtener información sobre las prácticas recomendadas, consulta [Prácticas recomendadas de seguridad en IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html#bp-users-federation-idp) en la *Guía del usuario de IAM*. | Siga las instrucciones en [Introducción](https://docs.aws.amazon.com//singlesignon/latest/userguide/getting-started.html) en la Guía del usuario de AWS IAM Identity Center . | Configure el acceso programático [configurando el AWS CLI que se utilizará AWS IAM Identity Center](https://docs.aws.amazon.com//cli/latest/userguide/cli-configure-sso.html) en la Guía del AWS Command Line Interface usuario. | | En IAM (no recomendado) | Usar credenciales a largo plazo para acceder a AWS. | Siguiendo las instrucciones de [Crear un usuario de IAM para acceso de emergencia](https://docs.aws.amazon.com/IAM/latest/UserGuide/getting-started-emergency-iam-user.html) de la Guía del usuario de IAM. | Configure el acceso programático mediante [Administrar las claves de acceso de los usuarios de IAM](https://docs.aws.amazon.com//IAM/latest/UserGuide/id_credentials_access-keys.html) en la Guía del usuario de IAM. | ### Paso 2: Configurar los permisos de IDT En este paso, configure los permisos que IDT utiliza para ejecutar las pruebas y recopilar datos de uso de IDT. Puede usar Consola de administración de AWS o AWS Command Line Interface (AWS CLI) para crear una política de IAM y un usuario para IDT y, a continuación, adjuntar políticas al usuario. + [Configuración de permisos para IDT (consola)](#idt-metrics-permissions-console) + [Configuración de permisos para IDT (AWS CLI)](#idt-metrics-permissions-cli) **Configuración de permisos de IDT (consola)** Siga estos pasos para usar la consola para configurar permisos para IDT para AWS IoT Greengrass. 1. Inicie sesión en la [consola de IAM](https://console.aws.amazon.com/iam). 1. Crear una política administrada que conceda permisos para crear roles con permisos específicos. 1. En el panel de navegación, seleccione **Políticas** y, a continuación, **Crear política**. 1. En la pestaña **JSON**, reemplace el contenido del marcador de posición por la política siguiente. ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "iot-device-tester:SendMetrics" ], "Resource": "*" } ] } ``` ------ 1. Elija **Revisar política**. 1. En **Nombre**, ingrese **IDTUsageMetricsIAMPermissions**. En **Summary (Resumen)**, revise los permisos concedidos por la política. 1. Elija **Crear política**. 1. Cree un usuario de IAM y adjunte los permisos al usuario. 1. Cree un usuario de IAM. Siga los pasos del 1 al 5 en [Creación de usuarios de IAM (consola)](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_users_create.html#id_users_create_console) en la *Guía del usuario de IAM*. Si ya ha creado un usuario de IAM, pase directamente al siguiente paso. 1. Adjunte los permisos a su usuario de IAM: 1. En la página **Set permissions (Establecer permisos)**, elija **Attach existing policies to user directly (Adjuntar políticas existentes al usuario directamente)**. 1. Busque la IAMPermissions política de **IDTUsagemétricas** que creó en el paso anterior. Seleccione la casilla de verificación. 1. Elija **Siguiente: etiquetas**. 1. Elija **Next: Review (Siguiente: revisar)** para ver un resumen de sus opciones. 1. Seleccione la opción **Crear un usuario**. 1. Para ver las claves de acceso del usuario (clave de acceso IDs y claves de acceso secretas), selecciona **Mostrar** junto a la contraseña y la clave de acceso. Para guardar las claves de acceso, elija **Download.csv (Descargar archivo .csv)** y, a continuación, guarde el archivo en un lugar seguro. Utilizará esta información más adelante para configurar el archivo de AWS credenciales.   **Configuración de permisos de IDT (AWS CLI)** Siga estos pasos AWS CLI para configurar los permisos de IDT para AWS IoT Greengrass. 1. En su ordenador, instale y configure el AWS CLI si aún no está instalado. Siga los pasos que se indican en [Instalación de la AWS CLI](https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-install.html) en la *Guía del usuario de la AWS Command Line Interface *. **nota** AWS CLI Se trata de una herramienta de código abierto que puede utilizar para interactuar con los AWS servicios desde el shell de la línea de comandos. 1. Cree la siguiente política gestionada por el cliente que conceda permisos para gestionar el IDT y las funciones. AWS IoT Greengrass ------ #### [ Linux or Unix ] ``` aws iam create-policy --policy-name IDTUsageMetricsIAMPermissions --policy-document '{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "iot-device-tester:SendMetrics" ], "Resource": "*" } ] }' ``` ------ #### [ Windows command prompt ] ``` aws iam create-policy --policy-name IDTUsageMetricsIAMPermissions --policy-document '{\"Version\": \"2012-10-17\", \"Statement\": [{\"Effect\": \"Allow\", \"Action\": [\"iot-device-tester:SendMetrics\"], \"Resource": \"*\"}]}' ``` **nota** Este paso incluye un ejemplo de símbolo del sistema de Windows porque utiliza una sintaxis JSON diferente a la de los comandos de terminal Linux, macOS o Unix. ------ #### [ PowerShell ] ``` aws iam create-policy --policy-name IDTUsageMetricsIAMPermissions --policy-document '{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "iot-device-tester:SendMetrics" ], "Resource": "*" } ] }' ``` ------ 1. Cree un usuario de IAM y adjunte los permisos requeridos por IDT para AWS IoT Greengrass. 1. Cree un usuario de IAM. ``` aws iam create-user --user-name user-name ``` 1. Adjunte la política `IDTUsageMetricsIAMPermissions` que ha creado a su nuevo usuario de IAM. *user-name*Sustitúyalo por tu nombre de usuario de IAM y, ** en el comando, por tu ID. Cuenta de AWS ``` aws iam attach-user-policy --user-name user-name --policy-arn arn:aws:iam:::policy/IDTGreengrassIAMPermissions ``` 1. Cree una clave de acceso secreta para el usuario. ``` aws iam create-access-key --user-name user-name ``` Almacene la salida en una ubicación segura. Utilizará esta información más adelante para configurar el archivo de AWS credenciales. ## Proporcione AWS las credenciales a IDT Para permitir que IDT acceda a sus AWS credenciales y envíe las métricas a ellas AWS, haga lo siguiente: 1. Guarde las AWS credenciales de su usuario de IAM como variables de entorno o en un archivo de credenciales: 1. Para usar variables de entorno, ejecute los siguientes comandos. ------ #### [ Linux or Unix ] ``` export AWS_ACCESS_KEY_ID=access-key export AWS_SECRET_ACCESS_KEY=secret-access-key ``` ------ #### [ Windows Command Prompt (CMD) ] ``` set AWS_ACCESS_KEY_ID=access-key set AWS_SECRET_ACCESS_KEY=secret-access-key ``` ------ #### [ PowerShell ] ``` $env:AWS_ACCESS_KEY_ID="access-key" $env:AWS_SECRET_ACCESS_KEY="secret-access-key" ``` ------ 1. Para utilizar el archivo de credenciales, agregue la siguiente información al archivo `~/.aws/credentials`. ``` [profile-name] aws_access_key_id=access-key aws_secret_access_key=secret-access-key ``` 1. Configure la sección `auth` del archivo `config.json`. Para obtener más información, consulte [(Opcional) Configuración de config.json](set-custom-idt-config.md#config-json-custom).