Aviso de fin de soporte: el 7 de octubre de 2026, AWS suspenderemos el soporte para AWS IoT Greengrass Version 1. Después del 7 de octubre de 2026, ya no podrá acceder a los AWS IoT Greengrass V1 recursos. Para obtener más información, visita [Migrar desde AWS IoT Greengrass Version 1](https://docs.aws.amazon.com/greengrass/v2/developerguide/migrate-from-v1.html). 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 AWS IoT del comprobador de dispositivos para V1 AWS IoT Greengrass AWS IoT Device Tester (IDT) es un marco de pruebas descargable que le permite validar dispositivos de IoT. Dado que AWS IoT Greengrass Version 1 ha pasado al [modo de mantenimiento](https://docs.aws.amazon.com/greengrass/v1/developerguide/maintenance-policy.html), IDT for ya AWS IoT Greengrass V1 no genera informes de cualificación firmados. Ya no podrá incluir nuevos AWS IoT Greengrass V1 dispositivos en el [catálogo](https://devices.amazonaws.com/) de dispositivos a través del AWS Partner [Programa de calificación de AWS dispositivos](https://aws.amazon.com/partners/dqp/). Sin embargo, puede seguir utilizando IDT AWS IoT Greengrass V1 para probar sus dispositivos Greengrass V1. Le recomendamos que utilice [IDT para AWS IoT Greengrass V2](https://docs.aws.amazon.com/greengrass/v2/developerguide/device-tester-for-greengrass-ug.html) para calificar y publicar los dispositivos de Greengrass en el [Catálogo de dispositivos de AWS Partner](https://devices.amazonaws.com/). IDT for AWS IoT Greengrass se ejecuta en el ordenador anfitrión (Windows, macOS o Linux) conectado al dispositivo que se va a probar. Ejecuta pruebas y agrega resultados. También proporciona una interfaz de línea de comandos para administrar el proceso de pruebas. ## AWS IoT Greengrass paquete de cualificación Utilice IDT AWS IoT Greengrass para comprobar que el software AWS IoT Greengrass principal se ejecuta en su hardware y puede comunicarse con el Nube de AWS. También realiza end-to-end pruebas con AWS IoT Core. Por ejemplo, verifica que su dispositivo pueda enviar y recibir mensajes MQTT y procesarlos correctamente. ![\[Una descripción general de cómo el probador de AWS IoT dispositivos verifica que el software AWS IoT Greengrass principal se ejecuta en su hardware y puede comunicarse con el. Nube de AWS\]](http://docs.aws.amazon.com/es_es/greengrass/v1/developerguide/images/devicetester_gg.png) AWS IoT *Device Tester para AWS IoT Greengrass organizar las pruebas utilizando los conceptos de *conjuntos de pruebas* y grupos de pruebas.* + Un conjunto de pruebas es el conjunto de grupos de pruebas que se utiliza para verificar que un dispositivo funciona con versiones particulares de AWS IoT Greengrass. + Un grupo de pruebas es el conjunto de pruebas individuales relacionadas con una característica concreta, como implementaciones de grupos de Greengrass y mensajería MQTT. Para obtener más información, consulte [Utilice IDT para ejecutar el conjunto de AWS IoT Greengrass cualificaciones](idt-gg-qualification.md). ## Compatibilidad con los conjuntos de prueba A partir de la versión 4.0.0 de IDT, IDT for AWS IoT Greengrass 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 sus dispositivos. Puede agregar pruebas personalizadas para su propia validación interna o proporcionárselas a sus clientes para la verificación de los dispositivos. La forma en que un escritor de pruebas configura un conjunto de pruebas personalizado determina las configuraciones de configuración necesarias para ejecutar conjuntos de pruebas personalizados. Para obtener más información, consulte [Uso de IDT para desarrollar y ejecutar sus propios conjuntos de pruebas](idt-custom-tests.md). # Versiones compatibles de AWS IoT Device Tester para V1 AWS IoT Greengrass Al AWS IoT Greengrass Version 1 pasar al [modo de mantenimiento](https://docs.aws.amazon.com/greengrass/v1/developerguide/maintenance-policy.html), IDT for ya AWS IoT Greengrass V1 no genera informes de cualificación firmados. Le recomendamos que utilice [IDT para AWS IoT Greengrass V2](https://docs.aws.amazon.com/greengrass/v2/developerguide/device-tester-for-greengrass-ug.html). *Para obtener información sobre IDT para la AWS IoT Greengrass versión 2, consulte [Uso de AWS IoT Device Tester for AWS IoT Greengrass V2 en la AWS IoT Greengrass V2 Guía para](https://docs.aws.amazon.com/greengrass/v2/developerguide/device-tester-for-greengrass-ug.html) desarrolladores.* **nota** Cuando inicie una prueba, recibirá una notificación si IDT for no AWS IoT Greengrass es compatible con la versión AWS IoT Greengrass que está utilizando. Al descargar el software, acepta el [Acuerdo de licencia de AWS IoT Device Tester](https://docs.aws.amazon.com/greengrass/latest/developerguide/idt-license.html). ## Versiones de IDT no compatibles para AWS IoT Greengrass En este tema se enumeran las versiones no compatibles de IDT para. AWS IoT Greengrass Las versiones que no son compatibles no reciben actualizaciones ni correcciones de errores. Para obtener más información, consulte [Política de soporte de AWS IoT Device Tester para AWS IoT Greengrass V1](idt-support-policy.md). **IDT v4.4.1 para las versiones v1.11.6, v1.10.5 AWS IoT Greengrass ** Notas de la versión: + Le permite validar y calificar los dispositivos que ejecutan el software principal v1.11.6 y v1.10.5. AWS IoT Greengrass + Contiene correcciones de errores menores. Versión del conjunto de pruebas: `GGQ_1.3.1` + Publicado el 20/12/2020 **IDT v4.1.0 para las versiones v1.11.4, v1.10.4 AWS IoT Greengrass ** Notas de la versión: + Le permite validar y calificar los dispositivos que ejecutan el software principal v1.11.4 y v1.10.4. AWS IoT Greengrass + Soluciona un problema que provocaba que los registros que se muestran durante una ejecución de prueba utilizaran etiquetas redundantes. Versión del conjunto de pruebas: `GGQ_1.3.0` + Publicado el 23/06/2021 + Añade reintentos para las llamadas de API a Lambda e IAM AWS STS y mejora la gestión de los problemas de limitación o de servidor. + Añade compatibilidad con Python 3.8 a los casos de prueba de ML y Docker. **IDT v4.0.2 para las versiones v1.11.1, v1.11.0 y v1.10.3 AWS IoT Greengrass ** Notas de la versión: + Solucionó un problema que provocaba que IDT ocultara los errores de Hardware Security Integration (HSI). + Le permite desarrollar y ejecutar sus conjuntos de pruebas personalizados con Device Tester for. AWS IoT AWS IoT Greengrass Para obtener más información, consulte [Uso de IDT para desarrollar y ejecutar sus propios conjuntos de pruebas](idt-custom-tests.md). + Proporciona aplicaciones IDT con firma de código para macOS y Windows. En macOS, si aparece un mensaje de advertencia de seguridad, es posible que tenga que conceder una excepción de seguridad para IDT. Para obtener más información, consulte [Excepción de seguridad en macOS](idt-troubleshooting.md#macos-notarization-exception). AWS IoT Greengrass no proporciona un Dockerfile o una imagen de Docker para la versión 1.11.1 del software principal. AWS IoT Greengrass Para comprobar si su dispositivo cumple los requisitos de Docker, utilice una versión anterior del software AWS IoT Greengrass Core.   **IDT v3.2.0 para las versiones v1.11.0, v1.10.1, v1.10.0 AWS IoT Greengrass ** Notas de la versión: + De forma predeterminada, IDT solo ejecuta las pruebas obligatorias para la calificación. Para poder disfrutar de características adicionales, puede modificar el archivo [`device.json`](set-config.md#device-config). + Se agregó un número de puerto `device.json` que puede configurar para las conexiones SSH. + Docker solo admite el [administrador de flujos](stream-manager.md) y machine learning (ML) sin organización en contenedores. Los contenedores, Docker y Hardware Security Integration (HSI) no están disponibles para los dispositivos Docker. + Fusionamos `device-ml.json` y `device-hsm.json` y formamos `device.json`.   **IDT v3.1.3 para AWS IoT Greengrass las versiones: v1.10.x, v1.9.x, v1.8.x** Notas de la versión: + Se agregó compatibilidad con la calificación de funciones de aprendizaje automático para las versiones AWS IoT Greengrass 1.10.x y 1.9.x. Ahora puede usar IDT para validar que los dispositivos pueden realizar inferencia de ML localmente con modelos almacenados y entrenados en la nube. + Se ha agregado `--stop-on-first-failure` para el comando `run-suite`. Puede utilizar esta opción para configurar el IDT para que deje de funcionar en el primer error. Recomendamos usar esta opción durante la etapa de depuración en el nivel de grupos de prueba. + Se ha agregado una comprobación de deriva de reloj para las pruebas MQTT para asegurarse de que el dispositivo bajo prueba utilice la hora correcta del sistema. El tiempo utilizado debe estar dentro de un rango de tiempo aceptable. + Se ha agregado `--update-idt` para el comando `run-suite`. Puede utilizar esta opción para establecer la respuesta del mensaje para actualizar IDT. + Se ha agregado `--update-managed-policy` para el comando `run-suite`. Puede utilizar esta opción para establecer la respuesta para el mensaje de actualización de la política administrada. + Se ha añadido una corrección de errores para las actualizaciones automáticas de las versiones del conjunto de pruebas de IDT. La corrección garantiza que IDT pueda ejecutar los últimos conjuntos de pruebas disponibles para su versión de AWS IoT Greengrass .   **IDT v3.0.1 para AWS IoT Greengrass** Notas de la versión: + Se agregó soporte para la versión 1.10.1. AWS IoT Greengrass + Actualizaciones automáticas de las versiones del conjunto de pruebas de IDT. IDT puede descargar los últimos conjuntos de pruebas disponibles para su versión. AWS IoT Greengrass Con esta característica: + Los conjuntos de pruebas se versionan utilizando un formato `major.minor.patch`. La versión inicial del conjunto de pruebas es `GGQ_1.0.0`. + Puede descargar nuevos conjuntos de pruebas de forma interactiva en la interfaz de línea de comandos o establecer el indicador `upgrade-test-suite` cuando inicie IDT. Para obtener más información, consulte [Versiones del conjunto de pruebas](idt-gg-qualification.md#idt-test-suite-versions). + Se ha agregado `list-supported-products`. Puede utilizar este comando para mostrar las versiones del conjunto de pruebas de AWS IoT Greengrass que son compatibles con la versión instalada de IDT. + Se ha agregado `list-test-cases`. Puede utilizar este comando para mostrar los casos de prueba que están disponibles en un grupo de pruebas. + Se ha agregado `test-id` para el comando `run-suite`. Puede utilizar esta opción para ejecutar casos de prueba individuales en un grupo de pruebas.   **IDT v2.3.0 para v1.10, v1.9.x y AWS IoT Greengrass v1.8.x** Cuando se realizan pruebas en un dispositivo físico, se admiten las versiones 1.10, 1.9.x y 1.8.x. AWS IoT Greengrass Cuando se realizan pruebas en un contenedor de Docker, se admiten las versiones 1.10 y 1.9.x. AWS IoT Greengrass Notas de la versión: + Se agregó compatibilidad con [Ejecución AWS IoT Greengrass en un contenedor Docker](run-gg-in-docker-container.md). Ahora puede usar IDT para calificar y validar que sus dispositivos puedan ejecutarse en un contenedor Docker. AWS IoT Greengrass + Se agregó una [política AWS administrada](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_managed-vs-inline.html#aws-managed-policies) (`AWSIoTDeviceTesterForGreengrassFullAccess`) que define los permisos necesarios para ejecutar AWS IoT Device Tester. Si las nuevas versiones requieren permisos adicionales, AWS agréguelos a esta política administrada para no tener que actualizar sus permisos de IAM. + Se han introducido comprobaciones para validar que el entorno (por ejemplo, la conectividad de los dispositivos y la conectividad de Internet) esté configurado correctamente antes de ejecutar los casos de prueba. + Se ha mejorado el comprobador de dependencias de Greengrass en IDT para hacerlo más flexible durante la comprobación de libc en los dispositivos.   **IDT v2.2.0 para las v1.10, v1.9.x y AWS IoT Greengrass v1.8.x** Notas de la versión: + Se agregó soporte para la AWS IoT Greengrass versión 1.10. + Se ha agregado compatibilidad con el conector de [implementación de la aplicación de Greengrass Docker](docker-app-connector.md) . + Se agregó soporte para el administrador de AWS IoT Greengrass [transmisiones](stream-manager.md). + Se agregó soporte para AWS IoT Greengrass la región de China (Beijing).   **IDT v2.1.0 para AWS IoT Greengrass v1.9.x, v1.8.x y v1.7.x** Notas de la versión: + Se agregó soporte para AWS IoT Greengrass la versión 1.9.4. + Se agregó soporte para dispositivos Linux. ARMv6l   **IDT v2.0.0 para AWS IoT Greengrass v1.9.3, v1.9.2, v.1.9.1, v1.9.0, v1.8.4, v1.8.3 y v1.8.2** Notas de la versión: + Se ha eliminado la dependencia de Python para el dispositivo en proceso de prueba. + El tiempo de ejecución del conjunto de pruebas se redujo en más del 50 por ciento, lo que agiliza el proceso de cualificación. + El tamaño ejecutable se ha reducido en más del 50 por ciento, lo que hace que la descarga y la instalación sean más rápidas. + Se ha mejorado la [compatibilidad del multiplicador de tiempo de espera](idt-troubleshooting.md#test-timeout) para todos los casos de prueba. + Mensajes posteriores al diagnóstico mejorados para solucionar los errores con mayor rapidez. + Se ha actualizado la plantilla de política de permisos necesaria para ejecutar IDT. + Se agregó soporte para la versión AWS IoT Greengrass 1.9.3.   **IDT v1.3.3 para AWS IoT Greengrass v1.9.2, v1.9.1, v1.9.0, v1.8.3 y v1.8.2** Notas de la versión: + Se ha agregado compatibilidad con Greengrass v1.9.2 y v1.8.3. + Se ha añadido soporte para Greengrass OpenWrt. + Se ha añadido el inicio de sesión del dispositivo con nombre de usuario y contraseña SSH. + Se agregó una corrección de error de prueba nativa para la OpenWrt ARMv7l plataforma.   **IDT v1.2 para v1.8.1 AWS IoT Greengrass ** Notas de la versión: + Se ha añadido un multiplicador de tiempo de espera configurable para abordar y solucionar los problemas de tiempo de espera (por ejemplo, conexiones de ancho de banda bajo).   **IDT v1.1 para v1.8.0 AWS IoT Greengrass ** Notas de la versión: + Se agregó soporte para la integración de seguridad AWS IoT Greengrass de hardware (HSI). + Se agregó soporte para AWS IoT Greengrass contenedor y sin contenedor. + Se agregó la creación automática AWS IoT Greengrass de roles de servicio. + Se ha mejorado la limpieza de los recursos de prueba. + Se ha añadido el informe de resumen de ejecución de prueba.   **IDT v1.1 para v1.7.1 AWS IoT Greengrass ** Notas de la versión: + Se agregó soporte para la integración de seguridad AWS IoT Greengrass de hardware (HSI). + Se agregó soporte para AWS IoT Greengrass contenedor y sin contenedor. + Se agregó la creación automática AWS IoT Greengrass de roles de servicio. + Se ha mejorado la limpieza de los recursos de prueba. + Se ha añadido el informe de resumen de ejecución de prueba.   **IDT v1.0 para v1.6.1 AWS IoT Greengrass ** Notas de la versión: + Se agregó una corrección de error de prueba OTA para la compatibilidad de AWS IoT Greengrass versiones futuras. [Si usa IDT v1.0 para AWS IoT Greengrass v1.6.1, debe crear un rol de servicio de Greengrass.](service-role.md) En versiones posteriores, IDT crea el rol de servicio. # Utilice IDT para ejecutar el conjunto de AWS IoT Greengrass cualificaciones Puede usar AWS IoT Device Tester (IDT) AWS IoT Greengrass para comprobar que el software AWS IoT Greengrass principal se ejecuta en su hardware y se puede comunicar con él. Nube de AWS También realiza end-to-end pruebas con. AWS IoT Core Por ejemplo, verifica que su dispositivo pueda enviar y recibir mensajes MQTT y procesarlos correctamente. Al AWS IoT Greengrass Version 1 pasar al [modo de mantenimiento](https://docs.aws.amazon.com/greengrass/v1/developerguide/maintenance-policy.html), IDT for ya AWS IoT Greengrass V1 no genera informes de cualificación firmados. Si desea añadir su hardware al catálogo de AWS Partner dispositivos, ejecute el conjunto de AWS IoT Greengrass V2 requisitos para generar informes de pruebas a los que pueda enviarlos AWS IoT. Para obtener más información, consulte [AWS el Programa de cualificación de dispositivos](https://aws.amazon.com/partners/dqp/) y [las versiones compatibles de IDT para AWS IoT Greengrass V2](https://docs.aws.amazon.com/greengrass/v2/developerguide/dev-test-versions.html). Además de probar los dispositivos, IDT for AWS IoT Greengrass crea recursos (por ejemplo, AWS IoT cosas, AWS IoT Greengrass grupos, funciones Lambda, etc.) en Cuenta de AWS su interior para facilitar el proceso de calificación. Para crear estos recursos, IDT for AWS IoT Greengrass utiliza AWS las credenciales configuradas en el `config.json` archivo para realizar llamadas a la API en su nombre. Estos recursos se aprovisionarán en distintos momentos durante una prueba. Cuando se utiliza IDT AWS IoT Greengrass para ejecutar el conjunto de AWS IoT Greengrass requisitos, IDT lleva a cabo los siguientes pasos: 1. Carga y valida su dispositivo y las configuraciones de credenciales. 1. Realiza pruebas seleccionadas con los recursos locales y de la nube necesarios. 1. Depura los recursos locales y de la nube. 1. Genera informes de pruebas que indican si su dispositivo ha superado las pruebas necesarias para la cualificación. ## Versiones del conjunto de pruebas IDT for AWS IoT Greengrass organiza las pruebas en conjuntos de pruebas y grupos de pruebas. + Un conjunto de pruebas es el conjunto de grupos de pruebas que se utiliza para verificar que un dispositivo funciona con versiones particulares de AWS IoT Greengrass. + Un grupo de pruebas es el conjunto de pruebas individuales relacionadas con una característica concreta, como implementaciones de grupos de Greengrass y mensajería MQTT. A partir de IDT v3.0.0, los conjuntos de pruebas incluyen control de versiones utilizando un formato `major.minor.patch`, por ejemplo `GGQ_1.0.0`. Al descargar IDT, el paquete incluye la versión más reciente del conjunto de pruebas. **importante** IDT admite las tres últimas versiones del conjunto de pruebas para la cualificación de dispositivos. Para obtener más información, consulte [Política de soporte de AWS IoT Device Tester para AWS IoT Greengrass V1](idt-support-policy.md). Puede ejecutar `list-supported-products` para ver una lista de las versiones AWS IoT Greengrass y los conjuntos de pruebas compatibles con su versión actual de IDT. Las pruebas de versiones del conjunto de pruebas no compatibles no son válidas para la cualificación del dispositivo. IDT no imprime informes de cualificación para versiones no compatibles. ### Actualizaciones de los parámetros de configuración de IDT Las nuevas pruebas podrían introducir nuevas opciones de configuración de IDT. + Si los ajustes son opcionales, IDT continúa ejecutando las pruebas. + Si los ajustes son obligatorios, IDT se lo notifica y deja de ejecutarse. Después de configurar los ajustes, reinicie la ejecución de prueba. Los ajustes de configuración se encuentran en la carpeta `/configs`. Para obtener más información, consulte [Configure los ajustes de IDT para ejecutar el conjunto de AWS IoT Greengrass cualificación](set-config.md). Si una versión actualizada del conjunto de pruebas agrega ajustes de configuración, IDT crea una copia del archivo de configuración original en `/configs`. ## Descripciones de los grupos de pruebas ------ #### [ IDT v2.0.0 and later ] **Grupos de pruebas necesarias para la cualificación del núcleo** Estos grupos de prueba son necesarios para que su AWS IoT Greengrass dispositivo pueda incluirse en el catálogo de AWS Partner dispositivos. AWS IoT Greengrass Dependencias principales Valida que el dispositivo cumple con todos los requisitos de software y hardware del software AWS IoT Greengrass principal. El caso de prueba `Software Packages Dependencies` de este grupo de pruebas no es aplicable cuando se realizan pruebas en un [contenedor de Docker](docker-config-setup.md). Implementación Valida que las funciones de Lambda se puedan implementar en el dispositivo. MQTT Verifica la funcionalidad del router de AWS IoT Greengrass mensajes comprobando la comunicación local entre los dispositivos principales y clientes de Greengrass, que son dispositivos IoT locales. Over-the-Air (OTA) Valida que su dispositivo puede realizar correctamente una actualización OTA del software AWS IoT Greengrass principal. Este grupo de pruebas no es aplicable cuando se realizan pruebas en un [contenedor de Docker](docker-config-setup.md). Versión Comprueba que la versión AWS IoT Greengrass proporcionada es compatible con la versión de AWS IoT Device Tester que está utilizando. **Grupos de pruebas opcionales** Estos grupos de pruebas son opcionales. Si decide optar a las pruebas opcionales, su dispositivo aparece con capacidades adicionales en el catálogo de AWS Partner dispositivos. Dependencias de contenedor Valida que el dispositivo cumple todos los requisitos de software y hardware para ejecutar funciones de Lambda en modo contenedor en un núcleo de Greengrass. Este grupo de pruebas no es aplicable cuando se realizan pruebas en un [contenedor de Docker](docker-config-setup.md). Contenedor de implementación Valida que las funciones de Lambda se puedan implementar en el dispositivo y se ejecuten en modo contenedor en el núcleo de Greengrass. Este grupo de pruebas no es aplicable cuando se realizan pruebas en un [contenedor de Docker](docker-config-setup.md). Dependencias de Docker (admitidas para IDT v2.2.0 y versiones posteriores) Valida que el dispositivo cumple todas las dependencias técnicas necesarias para utilizar el conector de implementación de aplicaciones de Greengrass Docker para ejecutar contenedores. Este grupo de pruebas no es aplicable cuando se realizan pruebas en un [contenedor de Docker](docker-config-setup.md). Integración de la seguridad por hardware (HSI) Verifica que la biblioteca compartida HSI proporcionada pueda interactuar con el módulo de seguridad de hardware (HSM) e implementa correctamente el PKCS \$111 requerido. APIs La biblioteca HSM y compartida debe poder firmar una CSR, realizar las operaciones de TLS y proporcionar las longitudes de clave y el algoritmo de clave pública correctos. Dependencias de Stream Manager (admitidas para IDT v2.2.0 y versiones posteriores) Valida que el dispositivo cumpla con todas las dependencias técnicas necesarias para ejecutar el administrador de transmisiones. AWS IoT Greengrass Dependencias de machine learning (compatible con IDT v3.1.0 y versiones posteriores) Valida que el dispositivo cumpla todas las dependencias técnicas necesarias para realizar la inferencia de ML localmente. Pruebas de inferencia de machine learning (compatibles con IDT v3.1.0 y versiones posteriores) Valida que la inferencia de ML se pueda realizar en el dispositivo a prueba. Para obtener más información, consulte [Opcional: Configuración del dispositivo para la cualificación ML](idt-ml-qualification.md). Pruebas de contenedores de inferencia de machine learning (compatible con IDT v3.1.0 y versiones posteriores) Valida que la inferencia de ML se pueda realizar en el dispositivo a prueba y ejecutar en modo contenedor en un núcleo de Greengrass. Para obtener más información, consulte [Opcional: Configuración del dispositivo para la cualificación ML](idt-ml-qualification.md). ------ #### [ IDT v1.3.3 and earlier ] **Grupos de pruebas necesarias para la cualificación del núcleo** Estas pruebas son necesarias para que su AWS IoT Greengrass dispositivo pueda incluirse en el catálogo de AWS Partner dispositivos. AWS IoT Greengrass Dependencias principales Valida que el dispositivo cumple con todos los requisitos de software y hardware del software AWS IoT Greengrass principal. Combinación (interacción de seguridad de dispositivo) Verifica la funcionalidad del administrador de certificados de dispositivo y la detección IP del dispositivo de núcleo de Greengrass cambiando la información de conectividad en el grupo de Greengrass en la nube. El grupo de prueba rota el certificado del AWS IoT Greengrass servidor y verifica que AWS IoT Greengrass permita las conexiones. Implementación (obligatoria para IDT v1.2 y versiones anteriores) Valida que las funciones de Lambda se puedan implementar en el dispositivo. Device Certificate Manager (DCM) Comprueba que el administrador de certificados del AWS IoT Greengrass dispositivo pueda generar un certificado de servidor al inicio y rotar los certificados si están a punto de caducar. Detección de IP (IPD) Verifica que la información de conectividad del núcleo se actualice cuando hay cambios de dirección IP en un dispositivo de núcleo de Greengrass. Para obtener más información, consulte [Activación de la detección automática de IP](gg-core.md#ip-auto-detect). Registro Comprueba que el servicio de AWS IoT Greengrass registro puede escribir en un archivo de registro mediante una función Lambda de usuario escrita en Python. MQTT Verifica la funcionalidad del enrutador de AWS IoT Greengrass mensajes mediante el envío de mensajes sobre un tema que se enruta a dos funciones de Lambda. KCL Comprueba que AWS IoT Greengrass puede ejecutar funciones Lambda nativas (compiladas). Over-the-Air (OTA) Valida que su dispositivo puede realizar correctamente una actualización OTA del software AWS IoT Greengrass principal. Penetración Valida que el software AWS IoT Greengrass principal no se puede iniciar si la protección de enlace duro o enlace blando y la [seccomp](https://www.kernel.org/doc/Documentation/prctl/seccomp_filter.txt) no están habilitadas. También se utilizar para verificar otras características relacionadas con la seguridad. Sombra Verifica la funcionalidad de sincronización de nube de sombra y sombra local. Administrador de trabajos Valida que los mensajes MQTT se pongan en cola con la configuración predeterminada del administrador de trabajos. Servicio de intercambio de token (TES) Comprueba que AWS IoT Greengrass puede cambiar su certificado principal por credenciales válidas. AWS Versión Comprueba que la versión AWS IoT Greengrass proporcionada es compatible con la versión de AWS IoT Device Tester que está utilizando. **Grupos de pruebas opcionales** Estas pruebas son opcionales. Si decide optar a las pruebas opcionales, su dispositivo aparece con capacidades adicionales en el catálogo de AWS Partner dispositivos. Dependencias de contenedor Comprueba que el dispositivo cumpla todas las dependencias necesarias para ejecutar funciones de Lambda en el modo contenedor. Integración de la seguridad por hardware (HSI) Verifica que la biblioteca compartida HSI proporcionada pueda interactuar con el módulo de seguridad de hardware (HSM) e implementa correctamente el PKCS \$111 requerido. APIs La biblioteca HSM y compartida debe poder firmar una CSR, realizar las operaciones de TLS y proporcionar las longitudes de clave y el algoritmo de clave pública correctos. Acceso a recursos locales Verifica la función de acceso a los recursos locales (LRA) AWS IoT Greengrass proporcionando acceso a los archivos y directorios locales propiedad de varios usuarios y grupos de Linux a las funciones de Lambda en contenedores a través del LRA. AWS IoT Greengrass APIs Las funciones de Lambda deben permitir o denegar el acceso a los recursos locales en función de la configuración del acceso al recurso local. Network Verifica que se puedan establecer conexiones de conector desde una función de Lambda. Estas conexiones de socket se deben permitir o denegar en función de la configuración del núcleo de Greengrass. ------ # Requisitos previos para ejecutar el paquete de AWS IoT Greengrass calificación En esta sección se describen los requisitos previos para utilizar AWS IoT Device Tester (IDT) AWS IoT Greengrass para ejecutar el conjunto de requisitos. AWS IoT Greengrass ## Descargue la última versión de Device Tester para AWS IoT AWS IoT Greengrass Descargue la [última versión](dev-test-versions.md) de IDT y extraiga el software en una ubicación de su sistema de archivos en la que tenga permisos de lectura y 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. ## Cree y configure un Cuenta de AWS Antes de poder utilizar IDT para AWS IoT Greengrass, debe realizar los siguientes pasos: 1. [Cree un Cuenta de AWS.]() Si ya tiene uno Cuenta de AWS, vaya al paso 2. 1. [Configurar permisos de IDT.]() Estos permisos de cuenta permiten a IDT acceder a AWS los servicios y crear AWS recursos, como AWS IoT cosas, grupos de Greengrass y funciones de Lambda, en su nombre. Para crear estos recursos, IDT for AWS IoT Greengrass utiliza AWS las credenciales configuradas en el `config.json` archivo para realizar llamadas a la API en su nombre. Estos recursos se aprovisionarán en distintos momentos durante una prueba. **nota** Aunque la mayoría de las pruebas cumplen los requisitos para el [Nivel gratuito de Amazon Web Services](https://aws.amazon.com/free), debe proporcionar una tarjeta de crédito cuando se cree una Cuenta de AWS. Para obtener más información, consulte [¿Por qué necesito un método de pago si mi cuenta está cubierta por la capa gratuita?](https://aws.amazon.com/premiumsupport/knowledge-center/free-tier-payment-method/). ### Paso 1: Crea una Cuenta de AWS En este paso, cree y configure una Cuenta de AWS. Si ya tiene uno Cuenta de AWS, vaya a[Paso 2: Configurar los permisos de IDT](#configure-idt-permissions). #### Inscríbase en una Cuenta de AWS 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). AWS te envía un correo electrónico de confirmación una vez finalizado el proceso de registro. En cualquier momento, puede ver la actividad de su cuenta actual y administrarla accediendo a [https://aws.amazon.com/](https://aws.amazon.com/)y seleccionando **Mi cuenta**. #### Creación de un usuario con acceso administrativo Después de crear un usuario administrativo Cuenta de AWS, asegúrelo Usuario raíz de la cuenta de AWS AWS IAM Identity Center, habilite y cree un usuario administrativo para no usar el usuario root en las tareas diarias. **Proteja su Usuario raíz de la cuenta de AWS** 1. Inicie sesión [Consola de administración de AWS](https://console.aws.amazon.com/)como propietario de la cuenta seleccionando el **usuario root** e introduciendo su dirección de Cuenta de AWS correo electrónico. En la siguiente página, escriba su contraseña. Para obtener ayuda para iniciar sesión con el usuario raíz, consulte [Iniciar sesión como usuario raíz](https://docs.aws.amazon.com/signin/latest/userguide/console-sign-in-tutorials.html#introduction-to-root-user-sign-in-tutorial) en la *Guía del usuario de AWS Sign-In *. 1. Active la autenticación multifactor (MFA) para el usuario raíz. Para obtener instrucciones, consulte [Habilitar un dispositivo MFA virtual para el usuario Cuenta de AWS raíz (consola)](https://docs.aws.amazon.com/IAM/latest/UserGuide/enable-virt-mfa-for-root.html) en la Guía del usuario de *IAM*. **Creación de un usuario con acceso administrativo** 1. Activar IAM Identity Center. Consulte las instrucciones en [Activar AWS IAM Identity Center](https://docs.aws.amazon.com//singlesignon/latest/userguide/get-set-up-for-idc.html) en la *Guía del usuario de AWS IAM Identity Center *. 1. En IAM Identity Center, conceda acceso administrativo a un usuario. Para ver un tutorial sobre su uso Directorio de IAM Identity Center como fuente de identidad, consulte [Configurar el acceso de los usuarios con la configuración predeterminada Directorio de IAM Identity Center en la](https://docs.aws.amazon.com//singlesignon/latest/userguide/quick-start-default-idc.html) Guía del *AWS IAM Identity Center usuario*. **Inicio de sesión como usuario con acceso de administrador** + Para iniciar sesión con el usuario de IAM Identity Center, use la URL de inicio de sesión que se envió a la dirección de correo electrónico cuando creó el usuario de IAM Identity Center. Para obtener ayuda para iniciar sesión con un usuario del Centro de identidades de IAM, consulte [Iniciar sesión en el portal de AWS acceso](https://docs.aws.amazon.com/signin/latest/userguide/iam-id-center-sign-in-tutorial.html) en la *Guía del AWS Sign-In usuario*. **Concesión de acceso a usuarios adicionales** 1. En IAM Identity Center, cree un conjunto de permisos que siga la práctica recomendada de aplicar permisos de privilegios mínimos. Para conocer las instrucciones, consulte [Create a permission set](https://docs.aws.amazon.com//singlesignon/latest/userguide/get-started-create-a-permission-set.html) en la *Guía del usuario de AWS IAM Identity Center *. 1. Asigne usuarios a un grupo y, a continuación, asigne el acceso de inicio de sesión único al grupo. Para conocer las instrucciones, consulte [Add groups](https://docs.aws.amazon.com//singlesignon/latest/userguide/addgroups.html) en la *Guía del usuario de AWS IAM Identity Center *. ### Paso 2: Configurar los permisos de IDT En este paso, configure los permisos que IDT for AWS IoT Greengrass utiliza para ejecutar 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 de prueba para IDT y, a continuación, adjuntar políticas al usuario. Si ya ha creado un usuario de prueba para IDT, vaya a [Configuración de su dispositivo para ejecutar pruebas de IDT](device-config-setup.md) o [Opcional: configurar su contenedor Docker para IDT para AWS IoT Greengrass](docker-config-setup.md). + [Configuración de permisos para IDT (consola)](#configure-idt-permissions-console) + [Configuración de permisos para IDT (AWS CLI)](#configure-idt-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": [ { "Sid": "ManageRolePoliciesForIDTGreengrass", "Effect": "Allow", "Action": [ "iam:DetachRolePolicy", "iam:AttachRolePolicy" ], "Resource": [ "arn:aws:iam::*:role/idt-*", "arn:aws:iam::*:role/GreengrassServiceRole" ], "Condition": { "ArnEquals": { "iam:PolicyARN": [ "arn:aws:iam::aws:policy/service-role/AWSGreengrassResourceAccessRolePolicy", "arn:aws:iam::aws:policy/service-role/GreengrassOTAUpdateArtifactAccess", "arn:aws:iam::aws:policy/service-role/AWSLambdaBasicExecutionRole" ] } } }, { "Sid": "ManageRolesForIDTGreengrass", "Effect": "Allow", "Action": [ "iam:CreateRole", "iam:DeleteRole", "iam:PassRole", "iam:GetRole" ], "Resource": [ "arn:aws:iam::123456789012:role/idt-*", "arn:aws:iam::123456789012:role/GreengrassServiceRole" ] } ] } ``` ------ **importante** La siguiente política concede permiso para crear y administrar los roles precisados por IDT para AWS IoT Greengrass. Esto incluye permisos para adjuntar las siguientes políticas AWS administradas: [AWSGreengrassResourceAccessRolePolicy](https://console.aws.amazon.com/iam/home#/policies/arn:aws:iam::aws:policy/service-role/AWSGreengrassResourceAccessRolePolicy) [Greengrass OTAUpdate ArtifactAccess](https://console.aws.amazon.com/iam/home#/policies/arn:aws:iam::aws:policy/service-role/GreengrassOTAUpdateArtifactAccess) [AWSLambdaBasicExecutionRole](https://console.aws.amazon.com/iam/home#/policies/arn:aws:iam::aws:policy/service-role/AWSLambdaBasicExecutionRole) 1. Elija **Siguiente: Etiquetas**. 1. Elija **Siguiente: Revisar**. 1. En **Nombre**, escriba **IDTGreengrassIAMPermissions**. 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 requeridos por IDT para AWS IoT Greengrass. 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*. 1. Adjunte los permisos a su usuario de IAM: 1. En la página **Establecer permisos**, elija **Adjuntar políticas existentes directamente**. 1. Busque la **IDTGreengrassIAMPermissions**política que creó en el paso anterior. Seleccione la casilla de verificación. 1. Busque la **AWSIoTDeviceTesterForGreengrassFullAccess**política. Seleccione la casilla de verificación. **nota** [AWSIoTDeviceTesterForGreengrassFullAccess](https://console.aws.amazon.com/iam/home#/policies/arn:aws:iam::aws:policy/AWSIoTDeviceTesterForGreengrassFullAccess)Se trata de una política AWS gestionada que define los permisos que IDT necesita para crear y acceder a AWS los recursos utilizados para las pruebas. Para obtener más información, consulte [AWS política gestionada para AWS IoT Device Tester](#idt-managed-policy). 1. Elija **Next: Tags (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), seleccione **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. Utilice esta información más adelante para configurar su archivo de credenciales de AWS . 1. Siguiente paso: Configure su [dispositivo físico](device-config-setup.md).   **Configuración de permisos de IDT (AWS CLI)** Siga estos pasos AWS CLI para configurar los permisos de IDT para AWS IoT Greengrass. Si ya ha configurado permisos en la consola, vaya a [Configuración de su dispositivo para ejecutar pruebas de IDT](device-config-setup.md) o [Opcional: configurar su contenedor Docker para IDT para AWS IoT Greengrass](docker-config-setup.md). 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 una política administrada por el cliente que conceda permisos para administrar IDT y roles de AWS IoT Greengrass . ------ #### [ Linux, macOS, or Unix ] ``` aws iam create-policy --policy-name IDTGreengrassIAMPermissions --policy-document '{ "Version":"2012-10-17", "Statement": [ { "Sid": "ManageRolePoliciesForIDTGreengrass", "Effect": "Allow", "Action": [ "iam:DetachRolePolicy", "iam:AttachRolePolicy" ], "Resource": [ "arn:aws:iam::*:role/idt-*", "arn:aws:iam::*:role/GreengrassServiceRole" ], "Condition": { "ArnEquals": { "iam:PolicyARN": [ "arn:aws:iam::aws:policy/service-role/AWSGreengrassResourceAccessRolePolicy", "arn:aws:iam::aws:policy/service-role/GreengrassOTAUpdateArtifactAccess", "arn:aws:iam::aws:policy/service-role/AWSLambdaBasicExecutionRole" ] } } }, { "Sid": "ManageRolesForIDTGreengrass", "Effect": "Allow", "Action": [ "iam:CreateRole", "iam:DeleteRole", "iam:PassRole", "iam:GetRole" ], "Resource": [ "arn:aws:iam::123456789012:role/idt-*", "arn:aws:iam::123456789012:role/GreengrassServiceRole" ] } ] }' ``` ------ #### [ Windows command prompt ] ``` aws iam create-policy --policy-name IDTGreengrassIAMPermissions --policy-document '{\"Version\": \"2012-10-17\", \"Statement\": [{\"Sid\": \"ManageRolePoliciesForIDTGreengrass\",\"Effect\": \"Allow\",\"Action\": [\"iam:DetachRolePolicy\", \"iam:AttachRolePolicy\"], \"Resource\": [\"arn:aws:iam::*:role/idt-*\",\"arn:aws:iam::*:role/GreengrassServiceRole\"],\"Condition\": {\"ArnEquals\": {\"iam:PolicyARN\": [\"arn:aws:iam::aws:policy/service-role/AWSGreengrassResourceAccessRolePolicy\",\"arn:aws:iam::aws:policy/service-role/GreengrassOTAUpdateArtifactAccess\",\"arn:aws:iam::aws:policy/service-role/AWSLambdaBasicExecutionRole\"]}}},{\"Sid\": \"ManageRolesForIDTGreengrass\",\"Effect\": \"Allow\",\"Action\": [\"iam:CreateRole\",\"iam:DeleteRole\", \"iam:PassRole\", \"iam:GetRole\"],\"Resource\": [\"arn:aws:iam::*:role/idt-*\",\"arn:aws:iam::*:role/GreengrassServiceRole\"]}]}' ``` **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. ------ 1. Cree un usuario de IAM y adjunte los permisos requeridos por IDT para AWS IoT Greengrass. 1. Cree un usuario de IAM. En esta configuración de ejemplo, el usuario se denomina `IDTGreengrassUser`. ``` aws iam create-user --user-name IDTGreengrassUser ``` 1. Asocie la política `IDTGreengrassIAMPermissions` que creó en el paso 2 a su usuario de IAM. Sustituya ** el comando por el ID de su. Cuenta de AWS ``` aws iam attach-user-policy --user-name IDTGreengrassUser --policy-arn arn:aws:iam:::policy/IDTGreengrassIAMPermissions ``` 1. Asocie la política `AWSIoTDeviceTesterForGreengrassFullAccess` a su usuario de IAM. ``` aws iam attach-user-policy --user-name IDTGreengrassUser --policy-arn arn:aws:iam::aws:policy/AWSIoTDeviceTesterForGreengrassFullAccess ``` **nota** [AWSIoTDeviceTesterForGreengrassFullAccess](https://console.aws.amazon.com/iam/home#/policies/arn:aws:iam::aws:policy/AWSIoTDeviceTesterForGreengrassFullAccess)Se trata de una política AWS gestionada que define los permisos que IDT necesita para crear y acceder a AWS los recursos utilizados para las pruebas. Para obtener más información, consulte [AWS política gestionada para AWS IoT Device Tester](#idt-managed-policy). 1. Cree una clave de acceso secreta para el usuario. ``` aws iam create-access-key --user-name IDTGreengrassUser ``` Almacene la salida en una ubicación segura. Esta información se utiliza más adelante para configurar el archivo de AWS credenciales. 1. Siguiente paso: Configure su [dispositivo físico](device-config-setup.md). ## AWS política gestionada para AWS IoT Device Tester La política [AWSIoTDeviceTesterForGreengrassFullAccess](https://console.aws.amazon.com/iam/home#/policies/arn:aws:iam::aws:policy/AWSIoTDeviceTesterForGreengrassFullAccess)gestionada permite a IDT ejecutar operaciones y recopilar métricas de uso. Esta política concede los siguientes permisos de IDT: + `iot-device-tester:CheckVersion`. Compruebe si un conjunto de versiones AWS IoT Greengrass, el conjunto de pruebas y las versiones de IDT son compatibles. + `iot-device-tester:DownloadTestSuite`. Descargue los conjuntos de pruebas. + `iot-device-tester:LatestIdt`. Obtenga información sobre la última versión de IDT que está disponible para descarga. + `iot-device-tester:SendMetrics`. Publique los datos de uso que IDT recopila sobre las pruebas. + `iot-device-tester:SupportedVersion`. Obtenga la lista de AWS IoT Greengrass las versiones de los conjuntos de pruebas compatibles con IDT. Esta información se muestra en la ventana de línea de comandos. # Configuración de su dispositivo para ejecutar pruebas de IDT Para configurar el dispositivo, debe instalar AWS IoT Greengrass las dependencias, configurar el software AWS IoT Greengrass principal, configurar el ordenador host para acceder al dispositivo y configurar los permisos de usuario en el dispositivo. ## Verifica AWS IoT Greengrass las dependencias del dispositivo que se está probando Antes de que IDT for AWS IoT Greengrass pueda probar sus dispositivos, asegúrese de que lo ha configurado tal y como se describe en [Primeros pasos](https://docs.aws.amazon.com/greengrass/latest/developerguide/gg-gs.html) con. AWS IoT Greengrass Para obtener información sobre las plataformas admitidas, consulte [Plataformas compatibles](https://docs.aws.amazon.com/greengrass/latest/developerguide/what-is-gg.html#gg-platforms). ## Configure el software AWS IoT Greengrass IDT para probar AWS IoT Greengrass la compatibilidad de su dispositivo con una versión específica de AWS IoT Greengrass. IDT ofrece dos opciones para realizar pruebas AWS IoT Greengrass en sus dispositivos: + Descargue y utilice una versión del [software de AWS IoT Greengrass Core](what-is-gg.md#gg-core-download-tab). IDT instala el software. + Utilice una versión del software AWS IoT Greengrass principal que ya esté instalada en su dispositivo. **nota** Cada versión de AWS IoT Greengrass tiene una versión IDT correspondiente. Debe descargar la versión de IDT que corresponda a la versión que AWS IoT Greengrass está utilizando. Estas opciones se describen en las siguientes secciones. Solo tiene que hacer una. ### Opción 1: descargue el software AWS IoT Greengrass principal y configure AWS IoT Device Tester para usarlo Puede descargar el software AWS IoT Greengrass principal desde la página de descargas del [software AWS IoT Greengrass principal](what-is-gg.md#gg-core-download-tab). 1. Busque la arquitectura y la distribución de Linux correctas y, a continuación, elija **Download (Descargar)**. 1. Copie el archivo tar.gz en `/products/greengrass/ggc`. **nota** No cambie el nombre del archivo AWS IoT Greengrass tar.gz. No coloque varios archivos en este directorio para el mismo sistema operativo y arquitectura. Por ejemplo, tener los archivos `greengrass-linux-armv7l-1.7.1.tar.gz` y `greengrass-linux-armv7l-1.8.1.tar.gz` en dicho directorio hará que las pruebas devuelvan un error. ### Opción 2: utilice una instalación existente de AWS IoT Greengrass con AWS IoT Device Tester Configure IDT para probar el software AWS IoT Greengrass principal instalado en su dispositivo añadiendo el `greengrassLocation` atributo al `device.json` archivo de la carpeta. `/configs` Por ejemplo: ``` "greengrassLocation" : "" ``` Para obtener más información acerca del archivo `device.json`, consulte [Configurar device.json](set-config.md#device-config). En los dispositivos Linux, la ubicación predeterminada del software AWS IoT Greengrass principal es`/greengrass`. **nota** El dispositivo debe tener una instalación del software AWS IoT Greengrass Core que no se haya iniciado. Asegúrese de haber añadido el usuario de `ggc_user` y `ggc_group` en el dispositivo. Para obtener más información, consulte [Configuración del entorno para AWS IoT Greengrass](https://docs.aws.amazon.com/greengrass/latest/developerguide/module1.html). ## Configuración del equipo host para acceder a un dispositivo en pruebas IDT se ejecuta en su equipo host y debe poder utilizar SSH para conectarse a su dispositivo. Existen dos opciones para permitir que IDT obtenga acceso SSH a los dispositivos sometidos a la prueba: 1. Siga las instrucciones que se indican aquí para crear un par de claves SSH y autorizar su clave para iniciar sesión en su dispositivo en proceso de prueba sin especificar una contraseña. 1. Proporcione un nombre de usuario y una contraseña para cada dispositivo en el archivo `device.json`. Para obtener más información, consulte [Configurar device.json](set-config.md#device-config). Puede utilizar cualquier implementación SSL para crear una clave SSH. Las siguientes instrucciones muestran cómo utilizar [SSH-KEYGEN](https://www.ssh.com/ssh/keygen/) o [Pu TTYgen](https://www.ssh.com/ssh/putty/windows/puttygen) (para Windows). Si utiliza otra implementación de SSL, consulte la documentación de dicha aplicación. IDT utiliza claves SSH para autenticar con su dispositivo bajo prueba. **Para crear una clave SSH con SSH-KEYGEN, realice el siguiente procedimiento:** 1. Cree una clave de SSH. Puede utilizar el comando **ssh-keygen** de Open SSH para crear un par de claves SSH. Si ya tiene un par de claves SSH en su equipo host, es una práctica recomendada crear un par de claves SSH específicamente para IDT. De esta forma, una vez completadas las pruebas, el equipo host ya no podrá conectarse a su dispositivo sin introducir una contraseña. También le permite restringir el acceso al dispositivo remoto únicamente a aquellos que lo necesiten. **nota** Windows no tiene instalado un cliente SSH. Para obtener más información sobre la instalación de un cliente SSH en Windows, consulte [Download SSH Client Software](https://www.ssh.com/ssh/#sec-Download-client-software). El comando **ssh-keygen** le solicita un nombre y la ruta para almacenar el par de claves. De forma predeterminada, los archivos de par de claves se denominan `id_rsa` (clave privada) y `id_rsa.pub` (clave pública). En macOS y Linux, la ubicación predeterminada de estos archivos es `~/.ssh/`. En Windows, la ubicación predeterminada es `C:\Users\\.ssh`. Cuando se le solicite, introduzca una frase clave para proteger la clave SSH. Para obtener más información, consulte la sección acerca de [cómo generar una nueva clave SSH](https://www.ssh.com/ssh/keygen/). 1. Añada claves SSH autorizadas a su dispositivo en proceso de prueba. IDT debe utilizar su clave privada de SSH para iniciar sesión en el dispositivo a prueba. Para autorizar que su clave privada de SSH inicie sesión en el dispositivo a prueba, use el comando **ssh-copy-id** en su equipo host. Este comando añade su clave pública al archivo `~/.ssh/authorized_keys` que se encuentra en su dispositivo a prueba. Por ejemplo: **\$1 ssh-copy-id **@**** ¿Dónde *remote-ssh-user* está el nombre de usuario que se utiliza para iniciar sesión en el dispositivo que *remote-device-ip* se está probando y la dirección IP del dispositivo que se está probando? Por ejemplo: **ssh-copy-id pi@192.168.1.5** Cuando se le solicite, introduzca la contraseña para el nombre de usuario que ha especificado en el comando **ssh-copy-id**. **ssh-copy-id** presupone que la clave pública se denomina `id_rsa.pub` y se almacena en la ubicación predeterminada (en macOS y Linux, `~/.ssh/` y en Windows, `C:\Users\\.ssh`). Si asignó a la clave pública un nombre diferente o la almacenó en otra ubicación, debe especificar la ruta completa a su clave pública SSH utilizando la opción **-i** para **ssh-copy-id** (por ejemplo: **ssh-copy-id -i \$1/my/path/myKey.pub**). Para obtener más información acerca de la creación de claves de SSH y la copia de las claves públicas, consulte [SSH-COPY-ID](https://www.ssh.com/ssh/copy-id). **Para crear una clave SSH con Pu TTYgen (solo para Windows)** 1. Asegúrese de que tiene el servidor y el cliente de OpenSSH instalados en su dispositivo en proceso de prueba. Para obtener más información, consulte [OpenSSH](https://www.openssh.com/). 1. Instala [Pu TTYgen](https://www.puttygen.com/) en el dispositivo que estés probando. 1. Abre PuTTYgen. 1. Elija **Generate** (Generar) y mueva el cursor del ratón dentro del cuadro para generar una clave privada. 1. En el menú **Conversions** (Conversiones), elija **Export OpenSSH key** (Exportar clave OpenSSH) y guarde la clave privada con una extensión de archivo `.pem`. 1. Añada la clave pública al archivo `/home//.ssh/authorized_keys` en el dispositivo en proceso de prueba. 1. Copia el texto de la clave pública de la TTYgen ventana Pu. 1. Utilice PuTTY para crear una sesión en su dispositivo en proceso de prueba. 1. En un símbolo del sistema o en una ventana de Windows PowerShell, ejecute el siguiente comando: **C:/**/putty.exe -ssh **@**** 1. Cuando se le solicite, escriba la contraseña de su dispositivo. 1. Utilice vi u otro editor de texto para añadir la clave pública al archivo `/home//.ssh/authorized_keys` en su dispositivo en proceso de prueba. 1. Actualice el archivo `device.json` con su nombre de usuario, la dirección IP y la ruta al archivo de clave privada que acaba de guardar en el equipo host para cada dispositivo en proceso de prueba. Para obtener más información, consulte [Configurar device.json](set-config.md#device-config). Asegúrese de proporcionar la ruta completa y el nombre de archivo a la clave privada y utilizar barras diagonales (“/”). Por ejemplo, para la ruta de Windows `C:\DT\privatekey.pem`, utilice `C:/DT/privatekey.pem` en el archivo `device.json`. ## Configuración de los permisos de usuario en el dispositivo IDT realiza operaciones en diversos directorios y archivos en un dispositivo que se está probando. Algunas de estas operaciones requieren permisos elevados (usando **sudo**). Para automatizar estas operaciones, IDT for AWS IoT Greengrass debe poder ejecutar comandos con sudo sin que se le pida una contraseña. Siga estos pasos en el dispositivo a prueba para permitir acceso a sudo sin que se le solicite una contraseña. **nota** `username` hace referencia al usuario de SSH que utiliza IDT para obtener acceso al dispositivo bajo prueba. **Para añadir el usuario al grupo sudo** 1. En el dispositivo bajo prueba, ejecute `sudo usermod -aG sudo `. 1. Cierre la sesión y, a continuación, vuelva a iniciar sesión para que los cambios surtan efecto. 1. Para comprobar que su nombre de usuario se haya añadido correctamente, ejecute **sudo echo test**. Si no se le solicita una contraseña, el usuario se ha configurado correctamente. 1. Añada el archivo `/etc/sudoers` y agregue la siguiente línea al final del archivo: ` ALL=(ALL) NOPASSWD: ALL` ## Configurar el dispositivo para probar características opcionales En los temas siguientes se describe cómo configurar los dispositivos para ejecutar pruebas de IDT para características opcionales. Siga estos pasos de configuración solo si desea probar estas características. De lo contrario, siga en [Configure los ajustes de IDT para ejecutar el conjunto de AWS IoT Greengrass cualificación](set-config.md). **Topics** + [Verifica AWS IoT Greengrass las dependencias del dispositivo que se está probando](#install-gg-dependencies) + [Configure el software AWS IoT Greengrass](#config-gg) + [Configuración del equipo host para acceder a un dispositivo en pruebas](#configure-host) + [Configuración de los permisos de usuario en el dispositivo](#root-access) + [Configurar el dispositivo para probar características opcionales](#optional-feature-config) + [Opcional: configurar su contenedor Docker para IDT para AWS IoT Greengrass](docker-config-setup.md) + [Opcional: Configuración del dispositivo para la cualificación ML](idt-ml-qualification.md) # Opcional: configurar su contenedor Docker para IDT para AWS IoT Greengrass AWS IoT Greengrass proporciona una imagen de Docker y un Dockerfile que facilitan la ejecución del software AWS IoT Greengrass principal en un contenedor de Docker. Tras configurar el AWS IoT Greengrass contenedor, puede ejecutar pruebas de IDT. Actualmente, solo se admiten arquitecturas Docker x86\$164 para ejecutar IDT AWS IoT Greengrass. Esta función requiere IDT v2.3.0 o posterior. El proceso de configuración del contenedor de Docker para ejecutar las pruebas de IDT depende de si se utiliza la imagen de Docker o el Dockerfile que proporciona. AWS IoT Greengrass + [Uso de la imagen de Docker](#docker-config-setup-docker-image). La imagen de Docker tiene el software principal y las dependencias instalados AWS IoT Greengrass . + [Utilice el archivo Dockerfile](#docker-config-setup-dockerfile). El Dockerfile contiene el código fuente que puede usar para crear imágenes de contenedores personalizadas. AWS IoT Greengrass La imagen se puede modificar para ejecutarla en arquitecturas de plataforma distintas o para reducir su tamaño. **nota** AWS IoT Greengrass no proporciona Dockerfiles ni imágenes de Docker para AWS IoT Greengrass la versión 1.11.1 del software principal. Para ejecutar pruebas de IDT en tus propias imágenes de contenedor personalizadas, tu imagen debe incluir las dependencias definidas en el Dockerfile proporcionado por. AWS IoT Greengrass Las siguientes funciones no están disponibles cuando se ejecuta AWS IoT Greengrass en un contenedor de Docker: + [Conectores](connectors.md) que se ejecutan en el modo **Contenedor de Greengrass**. Para ejecutar un conector en un contenedor de Docker, el conector debe ejecutarse en modo **Sin contenedor**. Para buscar conectores compatibles con el modo **Sin contenedor**, consulte [conectores de Greengrass proporcionados por AWS](connectors-list.md). Algunos de estos conectores tienen un parámetro de modo de aislamiento que debe establecer en **Sin contenedor**. + [Dispositivos locales y recursos de volumen](access-local-resources.md). Las funciones de Lambda definidas por el usuario que se ejecutan en el contenedor de Docker deben obtener acceso directamente a los dispositivos y volúmenes del dispositivo principal. ## Configura la imagen de Docker proporcionada por AWS IoT Greengrass Siga estos pasos para configurar la imagen de AWS IoT Greengrass Docker para ejecutar las pruebas de IDT. **Requisitos previos** Antes de empezar este tutorial, debe hacer lo siguiente. + Debe instalar el software y las versiones siguientes en su ordenador host en función de la versión AWS Command Line Interface (AWS CLI) que elija. ------ #### [ AWS CLI version 2 ] + [Docker](https://docs.docker.com/install/), versión 18.09 o superior. Es posible que las versiones anteriores también funcionen, pero recomendamos la 18.09 o una versión posterior. + AWS CLI versión 2.0.0 o posterior. + Para instalar la AWS CLI versión 2, consulte [Instalación de la AWS CLI versión 2](https://docs.aws.amazon.com/cli/latest/userguide/install-cliv2.html). + Para configurar el AWS CLI, consulte [Configuración del AWS CLI](https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-configure.html). **nota** Para actualizar a una AWS CLI versión 2 posterior en un equipo con Windows, debe repetir el proceso de [instalación de MSI](https://docs.aws.amazon.com/cli/latest/userguide/install-cliv2-windows.html). ------ #### [ AWS CLI version 1 ] + [Docker](https://docs.docker.com/install/), versión 18.09 o superior. Es posible que las versiones anteriores también funcionen, pero recomendamos la 18.09 o una versión posterior. + [Python](https://www.python.org/downloads/), versión 3.6 o superior. + [pip](https://pip.pypa.io/en/stable/installing), versión 18.1 o posterior. + AWS CLI versión 1.17.10 o posterior + Para instalar la AWS CLI versión 1, consulte [Instalación de la AWS CLI versión](https://docs.aws.amazon.com/cli/latest/userguide/install-cliv1.html) 1. + Para configurar el AWS CLI, consulte [Configuración del AWS CLI](https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-configure.html). + Para actualizar a la última versión de la AWS CLI versión 1, ejecute el siguiente comando. ``` pip install awscli --upgrade --user ``` **nota** Si utiliza la [instalación MSI](https://docs.aws.amazon.com/cli/latest/userguide/install-windows.html#msi-on-windows) de la AWS CLI versión 1 en Windows, tenga en cuenta lo siguiente: Si la instalación de la AWS CLI versión 1 no puede instalar botocore, intente usar la instalación de [Python y pip](https://docs.aws.amazon.com/cli/latest/userguide/awscli-install-windows.html#awscli-install-windows-pip). Para actualizar a una AWS CLI versión 1 posterior, debe repetir el proceso de instalación de MSI. ------ + Para acceder a los recursos de Amazon Elastic Container Registry (Amazon ECR), debe conceder el siguiente permiso. + Amazon ECR exige que los usuarios concedan el `ecr:GetAuthorizationToken` permiso mediante una política AWS Identity and Access Management (IAM) antes de poder autenticarse en un registro y enviar o extraer imágenes de un repositorio de Amazon ECR. Para obtener más información, consulte los [ejemplos de políticas de repositorios de Amazon ECR](https://docs.aws.amazon.com/AmazonECR/latest/userguide/repository-policy-examples.html) y el [Acceso a un repositorio de Amazon ECR](https://docs.aws.amazon.com/AmazonECR/latest/userguide/security_iam_id-based-policy-examples.html#security_iam_id-based-policy-examples-access-one-bucket) en la *Guía del usuario de Amazon Elastic Container Registry*.   1. Descargar la imagen de Docker y configurar el contenedor. Puede descargar la imagen preinstalada de [Docker Hub](https://hub.docker.com/r/amazon/aws-iot-greengrass) o [Amazon Elastic Container Registry](https://docs.aws.amazon.com/AmazonECR/latest/userguide/what-is-ecr.html)(Amazon ECR) y ejecutarla en plataformas de Windows, macOS y Linux (x86\$164). Para descargar la imagen de Docker de Amazon ECR, complete todos los pasos de [Paso 1: Obtenga la imagen del AWS IoT Greengrass contenedor de Amazon ECR](run-gg-in-docker-container.md#docker-pull-image). A continuación, vuelva a este tema para continuar con la configuración. 1. Solo usuarios de Linux: asegúrese de que el usuario que ejecuta IDT tiene permiso para ejecutar comandos Docker. Para obtener más información, consulte [Manage Docker as a non-root user](https://docs.docker.com/install/linux/linux-postinstall/#manage-docker-as-a-non-root-user) en la documentación de Docker. 1. Para ejecutar el AWS IoT Greengrass contenedor, utilice el comando correspondiente a su sistema operativo: ------ #### [ Linux ] ``` docker run --rm --init -it -d --name aws-iot-greengrass \ -p 8883:8883 \ -v : \ : ``` + **Sustitúyalo por la ruta al archivo de configuración del núcleo en el host y ** por la ruta en la que está montado el volumen en el contenedor. El archivo de configuración del kernel en el host generalmente se encuentra en `/proc/config.gz` o `/boot/config-`. Puede correr `uname -r` para encontrar el ** valor. **Ejemplo:** para montar el archivo de configuración desde `/boot/config-` ``` -v /boot/config-4.15.0-74-generic:/boot/config-4.15.0-74-generic \ ``` **Ejemplo:** para montar el archivo de configuración desde `proc/config.gz` ``` -v /proc/config.gz:/proc/config.gz \ ``` + Reemplace**: ** en el comando por el nombre del repositorio y la etiqueta de la imagen de destino. **Ejemplo:** para apuntar a la última versión del software AWS IoT Greengrass Core ``` 216483018798.dkr.ecr.us-west-2.amazonaws.com/aws-iot-greengrass:latest ``` Para obtener la lista de imágenes de AWS IoT Greengrass Docker, ejecute el siguiente comando. ``` aws ecr list-images --region us-west-2 --registry-id 216483018798 --repository-name aws-iot-greengrass ``` ------ #### [ macOS ] ``` docker run --rm --init -it -d --name aws-iot-greengrass \ -p 8883:8883 \ : ``` + Sustituya**: ** en el comando por el nombre del repositorio y la etiqueta de la imagen de destino. **Ejemplo:** para apuntar a la última versión del software AWS IoT Greengrass Core ``` 216483018798.dkr.ecr.us-west-2.amazonaws.com/aws-iot-greengrass:latest ``` Para obtener la lista de imágenes de AWS IoT Greengrass Docker, ejecute el siguiente comando: ``` aws ecr list-images --region us-west-2 --registry-id 216483018798 --repository-name aws-iot-greengrass ``` ------ #### [ Windows ] ``` docker run --rm --init -it -d --name aws-iot-greengrass \ -p 8883:8883 \ : ``` + Sustituya**: ** en el comando por el nombre del repositorio y la etiqueta de la imagen de destino. **Ejemplo:** para apuntar a la última versión del software AWS IoT Greengrass Core ``` 216483018798.dkr.ecr.us-west-2.amazonaws.com/aws-iot-greengrass:latest ``` Para obtener la lista de imágenes de AWS IoT Greengrass Docker, ejecute el siguiente comando: ``` aws ecr list-images --region us-west-2 --registry-id 216483018798 --repository-name aws-iot-greengrass ``` ------ **importante** Cuando realices pruebas con IDT, no incluyas el `--entrypoint /greengrass-entrypoint.sh \` argumento que se usa para ejecutar la imagen para uso general AWS IoT Greengrass . 1. Siguiente paso: [configure AWS las credenciales y el `device.json` archivo](set-config.md). ## Configure el dockerfile proporcionado por AWS IoT Greengrass Siga estos pasos para configurar la imagen de Docker creada a partir del AWS IoT Greengrass Dockerfile para ejecutar las pruebas de IDT. 1. Desde [AWS IoT Greengrass Software Docker](what-is-gg.md#gg-docker-download), descargue el paquete Dockerfile en su equipo host y extráigalo. 1. Abra `README.md`. Los tres pasos siguientes hacen referencia a las secciones de este archivo. 1. Asegúrese de que cumpla los requisitos de la sección **Requisitos previos**. 1. **Solo para usuarios de Linux: complete los pasos **Habilitar la protección de enlaces simbólicos y enlaces duros y** Habilitar el reenvío de red. IPv4 ** 1. Para crear la imagen de Docker, complete todos los pasos del **Paso 1. Cree la imagen de Docker AWS IoT Greengrass **. A continuación, vuelva a este tema para continuar con la configuración. 1. Para ejecutar el AWS IoT Greengrass contenedor, utilice el comando correspondiente a su sistema operativo: ------ #### [ Linux ] ``` docker run --rm --init -it -d --name aws-iot-greengrass \ -p 8883:8883 \ -v : \ : ``` + **Sustitúyalo por la ruta al archivo de configuración del núcleo en el host y ** por la ruta en la que está montado el volumen en el contenedor. El archivo de configuración del kernel en el host generalmente se encuentra en `/proc/config.gz` o `/boot/config-`. Puede correr `uname -r` para encontrar el ** valor. **Ejemplo:** para montar el archivo de configuración desde `/boot/config-` ``` -v /boot/config-4.15.0-74-generic:/boot/config-4.15.0-74-generic \ ``` **Ejemplo:** para montar el archivo de configuración desde `proc/config.gz` ``` -v /proc/config.gz:/proc/config.gz \ ``` + Reemplace**: ** en el comando por el nombre del repositorio y la etiqueta de la imagen de destino. **Ejemplo:** para apuntar a la última versión del software AWS IoT Greengrass Core ``` 216483018798.dkr.ecr.us-west-2.amazonaws.com/aws-iot-greengrass:latest ``` Para obtener la lista de imágenes de AWS IoT Greengrass Docker, ejecute el siguiente comando. ``` aws ecr list-images --region us-west-2 --registry-id 216483018798 --repository-name aws-iot-greengrass ``` ------ #### [ macOS ] ``` docker run --rm --init -it -d --name aws-iot-greengrass \ -p 8883:8883 \ : ``` + Sustituya**: ** en el comando por el nombre del repositorio y la etiqueta de la imagen de destino. **Ejemplo:** para apuntar a la última versión del software AWS IoT Greengrass Core ``` 216483018798.dkr.ecr.us-west-2.amazonaws.com/aws-iot-greengrass:latest ``` Para obtener la lista de imágenes de AWS IoT Greengrass Docker, ejecute el siguiente comando: ``` aws ecr list-images --region us-west-2 --registry-id 216483018798 --repository-name aws-iot-greengrass ``` ------ #### [ Windows ] ``` docker run --rm --init -it -d --name aws-iot-greengrass \ -p 8883:8883 \ : ``` + Sustituya**: ** en el comando por el nombre del repositorio y la etiqueta de la imagen de destino. **Ejemplo:** para apuntar a la última versión del software AWS IoT Greengrass Core ``` 216483018798.dkr.ecr.us-west-2.amazonaws.com/aws-iot-greengrass:latest ``` Para obtener la lista de imágenes de AWS IoT Greengrass Docker, ejecute el siguiente comando: ``` aws ecr list-images --region us-west-2 --registry-id 216483018798 --repository-name aws-iot-greengrass ``` ------ **importante** Cuando realices pruebas con IDT, no incluyas el `--entrypoint /greengrass-entrypoint.sh \` argumento que se usa para ejecutar la imagen para uso general AWS IoT Greengrass . 1. Siguiente paso: [configure AWS las credenciales y el `device.json` archivo](set-config.md). ## Solución de problemas con la configuración de su contenedor Docker para IDT para AWS IoT Greengrass Utilice la siguiente información para solucionar problemas relacionados con la ejecución de un contenedor Docker para que IDT lo pruebe. AWS IoT Greengrass ### ADVERTENCIA: Error al cargar configfile:/home/user/.docker/config.json - stat /home///.docker/config.json: permiso denegado Si obtiene este error al ejecutar comandos de `docker` en Linux, ejecute el siguiente comando. Sustituya ** el siguiente comando por el usuario que ejecuta IDT. ``` sudo chown : /home//.docker -R sudo chmod g+rwx /home//.docker -R ``` # Opcional: Configuración del dispositivo para la cualificación ML IDT for AWS IoT Greengrass ofrece pruebas de calificación de aprendizaje automático (ML) para validar que sus dispositivos pueden realizar inferencias de aprendizaje automático de forma local mediante modelos entrenados en la nube. Para ejecutar pruebas de cualificación de ML, primero debe configurar los dispositivos como se describe en [Configuración de su dispositivo para ejecutar pruebas de IDT](device-config-setup.md). A continuación, siga los pasos de este tema para instalar dependencias para los marcos de ML que desea ejecutar. Es necesario IDT v3.1.0 o posterior para realizar pruebas de cualificación de ML. ## Instalación de dependencias del marco de ML Todas las dependencias del marco de ML deben instalarse en el directorio `/usr/local/lib/python3.x/site-packages`. Para asegurarse de que están instalados en el directorio correcto, le recomendamos que utilice permisos raíz de `sudo` al instalar las dependencias. Los entornos virtuales no son compatibles con las pruebas de cualificación. **nota** Si está probando funciones de Lambda que se ejecutan con la [creación de contenedores](lambda-group-config.md#lambda-containerization-considerations) (en modo **contenedor de Greengrass**), la creación de enlaces simbólicos para las bibliotecas Python en `/usr/local/lib/python3.x` no se admite. Para evitar errores, debe instalar las dependencias en el directorio correcto. Siga los pasos para instalar las dependencias para su marco de destino: + [Instale MXNet las dependencias](#ml-qualification-mxnet-dependencies) + [Instale TensorFlow las dependencias](#ml-qualification-tensorflow-dependencies) + [Instalar dependencias DLR](#ml-qualification-dlr-dependencies)   ## Instale las dependencias de Apache MXNet Las pruebas de cualificación IDT para este marco tienen las siguientes dependencias: + Python 3.6 o Python 3.7. **nota** Si está utilizando Python 3.6, debe crear un enlace simbólico desde binarios de Python 3.7 a Python 3.6. Esto configura su dispositivo para que cumpla con el requisito de Python para AWS IoT Greengrass. Por ejemplo: ``` sudo ln -s path-to-python-3.6/python3.6 path-to-python-3.7/python3.7 ``` + Apache MXNet v1.2.1 o posterior. + NumPy. La versión debe ser compatible con la MXNet suya. ### ¿Instalando MXNet Siga las instrucciones de la MXNet documentación para realizar la [instalación MXNet](https://mxnet.apache.org/get_started/?platform=linux&language=python&processor=cpu&environ=pip&). **nota** Si en el dispositivo están instalados Python 2.x y Python 3.x, use Python 3.x en los comandos que ejecute para instalar las dependencias. ### Validar la instalación MXNet Elija una de las siguientes opciones para validar la MXNet instalación. #### Opción 1: SSH en su dispositivo y ejecutar scripts 1. SSH en su dispositivo. 1. Ejecute los siguientes scripts para comprobar que las dependencias están instaladas correctamente. ``` sudo python3.7 -c "import mxnet; print(mxnet.__version__)" ``` ``` sudo python3.7 -c "import numpy; print(numpy.__version__)" ``` El resultado imprime el número de versión y el script debe salir sin errores. #### Opción 2: Ejecutar la prueba de dependencia IDT 1. Asegúrese de que `device.json` esté configurado para la cualificación de ML. Para obtener más información, consulte [Configurar device.json para cualificación de ML](set-config.md#device-json-ml-qualification). 1. Ejecute la prueba de dependencias para el marco. ``` devicetester_[linux | mac | win_x86-64] run-suite --group-id mldependencies --test-id mxnet_dependency_check ``` El resumen de la prueba muestra un resultado `PASSED` para `mldependencies`.   ## Instale TensorFlow las dependencias Las pruebas de cualificación IDT para este marco tienen las siguientes dependencias: + Python 3.6 o Python 3.7. **nota** Si está utilizando Python 3.6, debe crear un enlace simbólico desde binarios de Python 3.7 a Python 3.6. Esto configura su dispositivo para que cumpla con el requisito de Python para AWS IoT Greengrass. Por ejemplo: ``` sudo ln -s path-to-python-3.6/python3.6 path-to-python-3.7/python3.7 ``` + TensorFlow 1.x. ### Instalando TensorFlow Siga las instrucciones de la TensorFlow documentación para instalar TensorFlow 1.x [con pip](https://www.tensorflow.org/install/pip) o [desde](https://www.tensorflow.org/install/source) el código fuente. **nota** Si en el dispositivo están instalados Python 2.x y Python 3.x, use Python 3.x en los comandos que ejecute para instalar las dependencias. ### Validar la instalación TensorFlow Elija una de las siguientes opciones para validar la TensorFlow instalación. #### Opción 1: SSH en su dispositivo y ejecutar un script 1. SSH en su dispositivo. 1. Ejecute el siguiente script para comprobar que la dependencia está instalada correctamente. ``` sudo python3.7 -c "import tensorflow; print(tensorflow.__version__)" ``` El resultado imprime el número de versión y el script debe salir sin errores. #### Opción 2: Ejecutar la prueba de dependencia IDT 1. Asegúrese de que `device.json` esté configurado para la cualificación de ML. Para obtener más información, consulte [Configurar device.json para cualificación de ML](set-config.md#device-json-ml-qualification). 1. Ejecute la prueba de dependencias para el marco. ``` devicetester_[linux | mac | win_x86-64] run-suite --group-id mldependencies --test-id tensorflow_dependency_check ``` El resumen de la prueba muestra un resultado `PASSED` para `mldependencies`.   ## Instalación de las dependencias de Amazon SageMaker AI Neo Deep Learning Runtime (DLR) Las pruebas de cualificación IDT para este marco tienen las siguientes dependencias: + Python 3.6 o Python 3.7. **nota** Si está utilizando Python 3.6, debe crear un enlace simbólico desde binarios de Python 3.7 a Python 3.6. Esto configura su dispositivo para que cumpla con el requisito de Python para AWS IoT Greengrass. Por ejemplo: ``` sudo ln -s path-to-python-3.6/python3.6 path-to-python-3.7/python3.7 ``` + SageMaker DLR AI Neo. + numpy. Después de instalar las dependencias de prueba DLR, debe [compilar el modelo](#ml-qualification-dlr-compile-model). ### Instalación de DLR Siga las instrucciones de la documentación de DLR para [instalar el DLR Neo](https://neo-ai-dlr.readthedocs.io/en/latest/install.html#building-on-linux). **nota** Si en el dispositivo están instalados Python 2.x y Python 3.x, use Python 3.x en los comandos que ejecute para instalar las dependencias. ### Validación de la instalación de DLR Elija una de las siguientes opciones para validar la instalación de DLR. #### Opción 1: SSH en su dispositivo y ejecutar scripts 1. SSH en su dispositivo. 1. Ejecute los siguientes scripts para comprobar que las dependencias están instaladas correctamente. ``` sudo python3.7 -c "import dlr; print(dlr.__version__)" ``` ``` sudo python3.7 -c "import numpy; print(numpy.__version__)" ``` El resultado imprime el número de versión y el script debe salir sin errores. #### Opción 2: Ejecutar la prueba de dependencia IDT 1. Asegúrese de que `device.json` esté configurado para la cualificación de ML. Para obtener más información, consulte [Configurar device.json para cualificación de ML](set-config.md#device-json-ml-qualification). 1. Ejecute la prueba de dependencias para el marco. ``` devicetester_[linux | mac | win_x86-64] run-suite --group-id mldependencies --test-id dlr_dependency_check ``` El resumen de la prueba muestra un resultado `PASSED` para `mldependencies`. ## Compilar el modelo DLR Debe compilar el modelo DLR antes de poder usarlo para pruebas de cualificación de ML. Para los pasos, elija una de las siguientes opciones. ### Opción 1: usar Amazon SageMaker AI para compilar el modelo Siga estos pasos para usar la SageMaker IA para compilar el modelo de aprendizaje automático proporcionado por IDT. Este modelo está preentrenado con Apache. MXNet 1. Compruebe que su tipo de dispositivo sea compatible con la SageMaker IA. Para obtener más información, consulta las [opciones del dispositivo de destino](https://docs.aws.amazon.com/sagemaker/latest/APIReference/API_OutputConfig.html#sagemaker-Type-OutputConfig-TargetDevice) en la *referencia de la API de Amazon SageMaker AI*. Si tu tipo de dispositivo no es compatible actualmente con la SageMaker IA, sigue los pasos que se indican[Opción 2: Utilice TVM para compilar el modelo DLR](#ml-qualification-compile-dlr-option-2). **nota** La ejecución de la prueba de DLR con un modelo compilado por la SageMaker IA puede tardar entre 4 y 5 minutos. No detenga IDT durante este tiempo. 1. Descargue el archivo tarball que contiene el modelo de DLR sin compilar y previamente entrenado MXNet : + [dlr-noncompiled-model-1.0.tar.gz](https://docs.aws.amazon.com/greengrass/latest/developerguide/download-dlr-noncompiled-model-1.0.html) 1. Descomprima el tarball. Este comando genera la siguiente estructura de directorios. ![\[El directorio resnet18 contiene tres archivos.\]](http://docs.aws.amazon.com/es_es/greengrass/v1/developerguide/images/idt/idt-ml-qualification-dlr-uncompiled.png) 1. Saque `synset.txt` del directorio `resnet18`. Anote la nueva ubicación. Copie este archivo en el directorio del modelo compilado más adelante. 1. Comprima el contenido del directorio `resnet18`. ``` tar cvfz model.tar.gz resnet18v1-symbol.json resnet18v1-0000.params ``` 1. Suba el archivo comprimido a un bucket de Amazon S3 de su cuenta y Cuenta de AWS, a continuación, siga los pasos de [Compilar un modelo (consola)](https://docs.aws.amazon.com/sagemaker/latest/dg/neo-job-compilation-console.html) para crear un trabajo de compilación. 1. En **Configuración de entrada**, utilice los siguientes valores: + En **Configuración de entrada de datos**, escriba `{"data": [1, 3, 224, 224]}`. + En **Marco de machine learning**, elija `MXNet`. 1. En **Configuración de salida**, utilice los siguientes valores: + En **Ubicación de salida de S3**, escriba la ruta de acceso al bucket de Amazon S3 o carpeta donde desea almacenar el modelo compilado. + En **Dispositivo de destino**, elija el tipo de dispositivo. 1. Descargue el modelo compilado desde la ubicación de salida especificada y, a continuación, descomprima el archivo. 1. Copie `synset.txt` en el directorio del modelo compilado. 1. Cambie el nombre del directorio del modelo compilado a `resnet18`. El directorio del modelo compilado debe tener la siguiente estructura de directorios. ![\[El directorio del modelo compilado resnet18 contiene cuatro archivos.\]](http://docs.aws.amazon.com/es_es/greengrass/v1/developerguide/images/idt/idt-ml-qualification-dlr-compiled-sm.png) ### Opción 2: Utilice TVM para compilar el modelo DLR Siga estos pasos para utilizar TVM para compilar el modelo de ML proporcionado por IDT. Este modelo viene previamente entrenado con Apache MXNet, por lo que debe instalarlo MXNet en el ordenador o dispositivo en el que vaya a compilar el modelo. Para instalarlo MXNet, siga las instrucciones de la [ MXNet documentación](https://mxnet.apache.org/get_started/?platform=linux&language=python&processor=cpu&environ=pip&). **nota** Le recomendamos que compile el modelo en el dispositivo de destino. Esta práctica es opcional, pero puede ayudar a garantizar la compatibilidad y mitigar posibles problemas.   1. Descargue el archivo tarball que contiene el MXNet modelo de DLR sin compilar y previamente entrenado: + [dlr-noncompiled-model-1.0.tar.gz](https://docs.aws.amazon.com/greengrass/latest/developerguide/download-dlr-noncompiled-model-1.0.html) 1. Descomprima el tarball. Este comando genera la siguiente estructura de directorios. ![\[El directorio resnet18 contiene tres archivos.\]](http://docs.aws.amazon.com/es_es/greengrass/v1/developerguide/images/idt/idt-ml-qualification-dlr-uncompiled.png) 1. Siga las instrucciones de la documentación de TVM para [compilar e instalar TVM desde el origen para su plataforma](https://docs.tvm.ai/install/from_source.html). 1. Una vez compilado TVM, ejecute la compilación TVM para el modelo resnet18. Los siguientes pasos se basan en la [explicación de inicio rápido para compilar modelos de aprendizaje profundo](https://tvm.apache.org/docs/tutorial/relay_quick_start.html#sphx-glr-tutorials-get-started-relay-quick-start-py) en la documentación de TVM. 1. Abra el archivo `relay_quick_start.py` desde el repositorio de TVM clonado. 1. Actualice el código que [define una red neuronal en relé](https://tvm.apache.org/docs/tutorial/relay_quick_start.html#define-neural-network-in-relay). Puede utilizar una de las siguientes opciones: + Opción 1: Utilice `mxnet.gluon.model_zoo.vision.get_model` para obtener el módulo de relé y los parámetros: ``` from mxnet.gluon.model_zoo.vision import get_model block = get_model('resnet18_v1', pretrained=True) mod, params = relay.frontend.from_mxnet(block, {"data": data_shape}) ``` + Opción 2: Desde el modelo no compilado que descargó en el paso 1, copie los siguientes archivos en el mismo directorio que el archivo `relay_quick_start.py`. Estos archivos contienen el módulo de relé y los parámetros. + `resnet18v1-symbol.json` + `resnet18v1-0000.params` 1. Actualice el código que [guarda y carga el módulo compilado](https://tvm.apache.org/docs/tutorial/relay_quick_start.html#save-and-load-compiled-module) para utilizar el siguiente código. ``` from tvm.contrib import util path_lib = "deploy_lib.so" # Export the model library based on your device architecture lib.export_library("deploy_lib.so", cc="aarch64-linux-gnu-g++") with open("deploy_graph.json", "w") as fo: fo.write(graph) with open("deploy_param.params", "wb") as fo: fo.write(relay.save_param_dict(params)) ``` 1. Compile el modelo: ``` python3 tutorials/relay_quick_start.py --build-dir ./model ``` Este comando genera los archivos siguientes. + `deploy_graph.json` + `deploy_lib.so` + `deploy_param.params` 1. Copie los archivos de modelo generados en un directorio denominado `resnet18`. Este es su directorio de modelo compilado. 1. Copie el directorio del modelo compilado en el equipo host. A continuación, copie `synset.txt` del modelo sin compilar que descargó en el paso 1 en el directorio del modelo compilado. El directorio del modelo compilado debe tener la siguiente estructura de directorios. ![\[El directorio del modelo compilado resnet18 contiene cuatro archivos.\]](http://docs.aws.amazon.com/es_es/greengrass/v1/developerguide/images/idt/idt-ml-qualification-dlr-compiled-tvm.png) A continuación, [configure](set-config.md) sus credenciales y su archivo. AWS `device.json` # Configure los ajustes de IDT para ejecutar el conjunto de AWS IoT Greengrass cualificación Antes de ejecutar las pruebas, debe configurar los ajustes de AWS las credenciales y los dispositivos del equipo host. ## Configure sus AWS credenciales Debe configurar sus credenciales de usuario de IAM en el archivo ` /configs/config.json`. Utilice las credenciales del IDT del AWS IoT Greengrass usuario creado en[Cree y configure un Cuenta de AWS](dev-tst-prereqs.md#config-aws-account-for-idt). Puede especificar sus credenciales de una de las dos formas siguientes: + Archivo de credenciales + Variables de entorno ### Configure AWS las credenciales con un 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` Añada sus AWS credenciales al `credentials` archivo en el siguiente formato: ``` [default] aws_access_key_id = aws_secret_access_key = ``` Para configurar IDT AWS IoT Greengrass para que utilice AWS las credenciales del `credentials` archivo, edítelo `config.json` de la siguiente manera: ``` { "awsRegion": "us-west-2", "auth": { "method": "file", "credentials": { "profile": "default" } } } ``` **nota** Si no usa el `default` AWS perfil, asegúrese de cambiar el nombre del perfil en el `config.json` archivo. Para obtener más información, consulte [Perfiles con nombre](https://docs.aws.amazon.com/cli/latest/userguide/cli-configure-profiles.html). ### Configure AWS las credenciales con variables de entorno Las variables de entorno son las variables que mantiene el sistema operativo y utilizan los comandos del sistema. No se guardan si cierra la sesión de SSH. IDT for AWS IoT Greengrass puede usar las variables de `AWS_SECRET_ACCESS_KEY` entorno `AWS_ACCESS_KEY_ID` y las variables de entorno para almacenar sus AWS credenciales. 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 IDT para utilizar las variables de entorno, edite la sección `auth` de su archivo `config.json`. A continuación se muestra un ejemplo: ``` { "awsRegion": "us-west-2", "auth": { "method": "environment" } } ``` ## Configurar device.json Además de AWS las credenciales, IDT for AWS IoT Greengrass necesita información sobre los dispositivos en los que se ejecutan las pruebas (por ejemplo, la dirección IP, la información de inicio de sesión, el sistema operativo y la arquitectura de la CPU). Debe proporcionar esta información utilizando la plantilla `device.json` ubicada en ` /configs/device.json`: ------ #### [ Physical device ] ``` [ { "id": "", "sku": "", "features": [ { "name": "os", "value": "linux | ubuntu | openwrt" }, { "name": "arch", "value": "x86_64 | armv6l | armv7l | aarch64" }, { "name": "container", "value": "yes | no" }, { "name": "docker", "value": "yes | no" }, { "name": "streamManagement", "value": "yes | no" }, { "name": "hsi", "value": "yes | no" }, { "name": "ml", "value": "mxnet | tensorflow | dlr | mxnet,dlr,tensorflow | no" }, *********** Remove the section below if the device is not qualifying for ML **************, { "name": "mlLambdaContainerizationMode", "value": "container | process | both" }, { "name": "processor", "value": "cpu | gpu" }, ****************************************************************************************** ], *********** Remove the section below if the device is not qualifying for HSI *************** "hsm": { "p11Provider": "/path/to/pkcs11ProviderLibrary", "slotLabel": "", "slotUserPin": "", "privateKeyLabel": "", "openSSLEngine": "/path/to/openssl/engine" }, ******************************************************************************************** *********** Remove the section below if the device is not qualifying for ML **************** "machineLearning": { "dlrModelPath": "/path/to/compiled/dlr/model", "environmentVariables": [ { "key": "", "value": "" } ], "deviceResources": [ { "name": "", "path": "", "type": "device | volume" } ] }, ****************************************************************************************** "kernelConfigLocation": "", "greengrassLocation": "", "devices": [ { "id": "", "connectivity": { "protocol": "ssh", "ip": "", "port": 22, "auth": { "method": "pki | password", "credentials": { "user": "", "privKeyPath": "/path/to/private/key", "password": "" } } } } ] } ] ``` **nota** Especifique `privKeyPath` solo si `method` está establecido en `pki` Especifique `password` solo si `method` está establecido en `password` ------ #### [ Docker container ] ``` [ { "id": "", "sku": "", "features": [ { "name": "os", "value": "linux | ubuntu | openwrt" }, { "name": "arch", "value": "x86_64" }, { "name": "container", "value": "no" }, { "name": "docker", "value": "no" }, { "name": "streamManagement", "value": "yes | no" }, { "name": "hsi", "value": "no" }, { "name": "ml", "value": "mxnet | tensorflow | dlr | mxnet,dlr,tensorflow | no" }, *********** Remove the section below if the device is not qualifying for ML **************, { "name": "mlLambdaContainerizationMode", "value": "process" }, { "name": "processor", "value": "cpu | gpu" }, ****************************************************************************************** ], *********** Remove the section below if the device is not qualifying for ML **************** "machineLearning": { "dlrModelPath": "/path/to/compiled/dlr/model", "environmentVariables": [ { "key": "", "value": "" } ], "deviceResources": [ { "name": "", "path": "", "type": "device | volume" } ] }, ****************************************************************************************** "kernelConfigLocation": "", "greengrassLocation": "", "devices": [ { "id": "", "connectivity": { "protocol": "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 placas cualificadas. Si quieres incluir tu placa en el catálogo de AWS Partner dispositivos, el SKU que especifiques aquí debe coincidir con el SKU que utilices en el proceso de publicación. `features` Una matriz que contenga las características compatibles del dispositivo. Todas las características son obligatorias. `os` y `arch` Combinaciones de sistemas operativos (SO) compatibles: + `linux`, `x86_64` + `linux`, `armv6l` + `linux`, `armv7l` + `linux`, `aarch64` + `ubuntu`, `x86_64` + `openwrt`, `armv7l` + `openwrt`, `aarch64` Si utilizas IDT para probar la AWS IoT Greengrass ejecución en un contenedor Docker, solo se admite la arquitectura Docker x86\$164. `container` Valida que el dispositivo cumple todos los requisitos de software y hardware para ejecutar funciones de Lambda en modo contenedor en un núcleo de Greengrass. El valor válido es `yes` o `no`. `docker` Valida que el dispositivo cumple todas las dependencias técnicas necesarias para utilizar el conector de implementación de aplicaciones de Greengrass Docker para ejecutar contenedores. El valor válido es `yes` o `no`. `streamManagement` Valida que el dispositivo cumpla con todas las dependencias técnicas necesarias para ejecutar Stream Manager. AWS IoT Greengrass El valor válido es `yes` o `no`. `hsi` Verifica que la biblioteca compartida HSI proporcionada pueda interactuar con el módulo de seguridad de hardware (HSM) e implementa correctamente el PKCS \$111 requerido. APIs La biblioteca HSM y compartida debe poder firmar una CSR, realizar las operaciones de TLS y proporcionar las longitudes de clave y el algoritmo de clave pública correctos. El valor válido es `yes` o `no`. `ml` Valida que el dispositivo cumpla todas las dependencias técnicas necesarias para realizar la inferencia de ML localmente. El valor válido puede ser cualquier combinación de `mxnet`, `tensorflow`, `dlr` y `no` (por ejemplo, `mxnet`, `mxnet,tensorflow`, `mxnet,tensorflow,dlr` o `no`). `mlLambdaContainerizationMode` Valida que el dispositivo cumple todas las dependencias técnicas necesarias para realizar la inferencia ML en modo contenedor en un dispositivo Greengrass. El valor válido es `container`, `process` o `both`. `processor` Valida que el dispositivo cumpla con todos los requisitos de hardware del tipo de procesador especificado. El valor válido es `cpu` o `gpu`. Si no quiere utilizar la característica `container`, `docker`, `streamManager`, `hsi` o `ml`, puede establecer el `value` correspondiente en `no`. Docker solo admite la calificación de características para `streamManagement` y `ml`. `machineLearning` Opcional. Información de configuración para pruebas de cualificación ML. Para obtener más información, consulte [Configurar device.json para cualificación de ML](#device-json-ml-qualification). `hsm` Opcional. Información de configuración para realizar pruebas con un módulo de seguridad AWS IoT Greengrass de hardware (HSM). De lo contrario, la propiedad `hsm` debe omitirse. Para obtener más información, consulte [Integración de la seguridad de hardware](hardware-security.md). Esta propiedad solo se aplica si `connectivity.protocol` está establecido en `ssh`. `hsm.p11Provider` La ruta absoluta a la biblioteca que puede cargar libdl de la implementación de PKCS\$111. `hsm.slotLabel` La etiqueta de ranura que se utiliza para identificar el módulo de hardware. `hsm.slotUserPin` El PIN de usuario utilizado para autenticar el AWS IoT Greengrass núcleo en el módulo. `hsm.privateKeyLabel` Es la etiqueta que se utiliza para identificar la clave en el módulo de hardware. `hsm.openSSLEngine` La ruta absoluta al archivo `.so` del motor de OpenSSL que habilita la compatibilidad con PKCS\$111 en OpenSSL. Utilizado por el agente de actualización de la AWS IoT Greengrass OTA. `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. Actualmente, los únicos valores que se admiten son `ssh` 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.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 `docker`. `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.auth.credentials.privKeyPath` La ruta completa a la clave privada que se utiliza para iniciar sesión en el dispositivo que se está probando. `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`. `greengrassLocation` La ubicación del software AWS IoT Greengrass principal en sus dispositivos. En el caso de los dispositivos físicos, este valor solo se utiliza cuando se utiliza una instalación existente de AWS IoT Greengrass. Utilice este atributo para indicar a IDT que utilice la versión del software AWS IoT Greengrass Core instalado en sus dispositivos. Al ejecutar pruebas en un contenedor Docker a partir de una imagen de Docker o un Dockerfile proporcionados por AWS IoT Greengrass, establezca este valor en. `/greengrass` `kernelConfigLocation` Opcional. La ruta al archivo de configuración del núcleo. AWS IoT Device Tester utiliza este archivo para comprobar si los dispositivos tienen habilitadas las funciones requeridas del núcleo. Si no se especifica, IDT utiliza las siguientes rutas para buscar el archivo de configuración del núcleo: `/proc/config.gz` y. `/boot/config-` AWS IoT Device Tester utiliza la primera ruta que encuentra. ## Configurar device.json para cualificación de ML En esta sección se describen las propiedades opcionales del archivo de configuración del dispositivo que se aplican a la cualificación de ML. Si tiene previsto ejecutar pruebas para la cualificación de ML, debe definir las propiedades que se aplican a su caso de uso. Puede utilizar la plantilla `device-ml.json` para definir los ajustes de configuración del dispositivo. Esta plantilla contiene las propiedades de ML opcionales. También puede usar `device.json` y agregar las propiedades de cualificación de ML. Estos archivos se encuentran en `/configs` e incluyen propiedades de cualificación de ML. Si utiliza `device-ml.json`, debe cambiar el nombre del archivo a `device.json` antes de ejecutar pruebas de IDT. Para obtener información acerca de las propiedades de configuración de dispositivos que no se aplican a la cualificación de ML, consulte [Configurar device.json](#device-config).   `ml` en la matriz `features` Los marcos de ML que admite la placa. Esta propiedad requiere IDT v3.1.0 o una versión posterior. + Si la placa solo admite un marco, especifíquelo. Por ejemplo: ``` { "name": "ml", "value": "mxnet" } ``` + Si la placa admite varios marcos, especifique los marcos como lista separada por comas. Por ejemplo: ``` { "name": "ml", "value": "mxnet,tensorflow" } ``` `mlLambdaContainerizationMode` en la matriz `features` El [modo de creación de contenedores](lambda-group-config.md#lambda-containerization-considerations) con el que desea probar. Esta propiedad requiere IDT v3.1.0 o una versión posterior. + Elija `process` para ejecutar el código de inferencia de ML con una función de Lambda que no esté en un contenedor. Esta opción requiere la AWS IoT Greengrass versión 1.10.x o posterior. + Elija `container` para ejecutar el código de inferencia ML con una función de Lambda en un contenedor. + Elija `both` para ejecutar el código de inferencia ML con ambos modos. Esta opción requiere la versión 1.10.x o AWS IoT Greengrass posterior. `processor` en la matriz `features` Indica el acelerador de hardware compatible con la placa. Esta propiedad requiere IDT v3.1.0 o una versión posterior. + Elija `cpu` si la placa utiliza una CPU como procesador. + Elija `gpu` si la placa utiliza una GPU como procesador. `machineLearning` Opcional. Información de configuración para pruebas de cualificación ML. Esta propiedad requiere IDT v3.1.0 o una versión posterior. `dlrModelPath` Necesario para usar el marco `dlr`. La ruta absoluta al directorio de modelo compilado DLR, que debe haberse denominado `resnet18`. Para obtener más información, consulte [Compilar el modelo DLR](idt-ml-qualification.md#ml-qualification-dlr-compile-model). A continuación, se muestra una ruta de ejemplo en macOS: `/Users//Downloads/resnet18`. `environmentVariables` Una matriz de pares clave-valor que puede pasar dinámicamente la configuración a las pruebas de inferencia de ML. Opcional para dispositivos de CPU. Puede usar esta sección para agregar variables de entorno específicas del marco requeridas por el tipo de dispositivo. Para obtener información sobre estos requisitos, consulte el sitio web oficial del marco o el dispositivo. Por ejemplo, para ejecutar pruebas de MXNet inferencia en algunos dispositivos, es posible que se requieran las siguientes variables de entorno. ``` "environmentVariables": [ ... { "key": "PYTHONPATH", "value": "$MXNET_HOME/python:$PYTHONPATH" }, { "key": "MXNET_HOME", "value": "$HOME/mxnet/" }, ... ] ``` El `value` campo puede variar en función de la MXNet instalación. Si está probando funciones de Lambda que se ejecutan con [creación de contenedores](lambda-group-config.md#lambda-containerization-considerations) en dispositivos GPU, agregue variables de entorno para la biblioteca de GPU. Esto permite que la GPU realice cálculos. Para utilizar diferentes bibliotecas de GPU, consulte la documentación oficial de la biblioteca o dispositivo. Configure las siguientes claves si la característica `mlLambdaContainerizationMode` está establecida en `container` o `both`. ``` "environmentVariables": [ { "key": "PATH", "value": ":$PATH" }, { "key": "LD_LIBRARY_PATH", "value": "" }, ... ] ``` `deviceResources` Requerido por los dispositivos de GPU. Contiene [recursos locales](access-local-resources.md#lra-resource-types) a los que se puede acceder mediante funciones de Lambda. Utilice esta sección para agregar recursos de volumen y dispositivos locales. + Para recursos de dispositivo, especifique `"type": "device"`. Para los dispositivos GPU, los recursos del dispositivo deben ser archivos de dispositivo relacionados con la GPU bajo `/dev`. **nota** El directorio `/dev/shm` es una excepción. Se puede configurar solo como un recurso de volumen. + Para recursos de volumen, especifique `"type": "volume"`. # Ejecute el conjunto AWS IoT Greengrass de cualificaciones Después de [configurar los ajustes necesarios](set-config.md), puede iniciar las pruebas. El tiempo de ejecución del conjunto completo de pruebas depende de su hardware. Como referencia, se tarda aproximadamente 30 minutos en completar el conjunto de pruebas completo en una unidad Raspberry Pi 3B. Los comandos `run-suite` de ejemplo siguientes muestran cómo ejecutar las pruebas de cualificación para un grupo de dispositivos. Un grupo de dispositivos es un conjunto de dispositivos idénticos. ------ #### [ IDT v3.0.0 and later ] Ejecute todos los grupos de prueba en un conjunto de pruebas especificado. ``` devicetester_[linux | mac | win_x86-64] run-suite --suite-id GGQ_1.0.0 --pool-id ``` Utilice el `list-suites` comando para enumerar los conjuntos de pruebas que se encuentran en la carpeta `tests`. Ejecute un grupo de pruebas específico en un conjunto de pruebas. ``` devicetester_[linux | mac | win_x86-64] run-suite --suite-id GGQ_1.0.0 --group-id --pool-id ``` Utilice el comando `list-groups` para enumerar los grupos de prueba en un conjunto de pruebas. Ejecute un caso de prueba específico en un grupo de prueba. ``` devicetester_[linux | mac | win_x86-64] run-suite --group-id --test-id ``` Ejecute varios casos de prueba en un grupo de prueba. ``` devicetester_[linux | mac | win_x86-64] run-suite --group-id --test-id , ``` Enumere los casos de prueba en un grupo de prueba. ``` devicetester_[linux | mac | win_x86-64] list-test-cases --group-id ``` Las opciones del comando `run-suite` son opcionales. Por ejemplo, puede omitir `pool-id` solo si tiene un grupo de dispositivos definido en el archivo `device.json`. O bien, puede omitir `suite-id` si desea ejecutar la última versión del conjunto de pruebas en la carpeta `tests`. **nota** IDT le pregunta si está disponible en línea una versión más reciente del conjunto de pruebas. Para obtener más información, consulte [Establezca el comportamiento de actualización predeterminado](#idt-update-behavior). Para obtener más información acerca de `run-suite` y otros comandos IDT, consulte [IDT para comandos AWS IoT Greengrass](#bk-cli). ------ #### [ IDT v2.3.0 and earlier ] Ejecute todos los grupos de prueba en un conjunto especificado. ``` devicetester_[linux | mac | win_x86-64] run-suite --suite-id GGQ_1 --pool-id ``` Ejecute un grupo de prueba específico. ``` devicetester_[linux | mac | win_x86-64] run-suite --suite-id GGQ_1 --group-id --pool-id ``` `suite-id` y `pool-id` son opcionales si ejecuta un único conjunto de pruebas en un único grupo de dispositivos. Esto significa que solo tiene un grupo de dispositivos definido en su archivo `device.json`. ------ ## Compruebe las dependencias de Greengrass Le recomendamos que ejecute el grupo de pruebas del comprobador de dependencias para asegurarse de que todas las dependencias de Greengrass están instaladas antes de ejecutar grupos de pruebas relacionados. Por ejemplo: + Ejecute `ggcdependencies` antes de ejecutar los grupos de prueba de cualificación del núcleo. + Ejecute `containerdependencies` antes de ejecutar grupos de prueba específicos de contenedor. + Ejecute `dockerdependencies` antes de ejecutar grupos de prueba específicos de Docker. + Ejecute `ggcstreammanagementdependencies` antes de ejecutar los grupos de prueba específicos del administrador de secuencias. ## Establezca el comportamiento de actualización predeterminado Al iniciar una ejecución de prueba, IDT comprueba en línea una versión más reciente del conjunto de pruebas. Si hay alguna disponible, IDT le pedirá que actualice a la última versión disponible. Puede establecer la marca `upgrade-test-suite` (o `u`) para controlar el comportamiento de actualización predeterminado. Los valores válidos son: + `y`. IDT descarga y utiliza la última versión disponible. + `n` (predeterminada). IDT utiliza la versión especificada en la opción `suite-id`. Si no se especifica `suite-id`, IDT utiliza la versión más reciente en la carpeta `tests`. Si no incluye la marca `upgrade-test-suite`, IDT le preguntará cuándo hay una actualización disponible y esperará 30 segundos a la entrada (`y` o `n`). Si no se introduce ninguna entrada, el valor predeterminado es `n` y continúa ejecutando las pruebas. Los siguientes ejemplos muestran casos de uso comunes para esta característica: **Utilizar automáticamente las últimas pruebas disponibles para un grupo de pruebas.** ``` devicetester_linux run-suite -u y --group-id mqtt --pool-id DevicePool1 ``` **Ejecutar pruebas en una versión específica del conjunto de pruebas.** ``` devicetester_linux run-suite -u n --suite-id GGQ_1.0.0 --group-id mqtt --pool-id DevicePool1 ``` **Solicitar actualizaciones en tiempo de ejecución.** ``` devicetester_linux run-suite --pool-id DevicePool1 ``` ## IDT para comandos AWS IoT Greengrass Los comandos IDT se encuentran en el directorio `/bin`. Úselos para las siguientes operaciones: ------ #### [ IDT v3.0.0 and later ] `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` Muestra los productos compatibles, en este caso AWS IoT Greengrass las versiones, y las versiones del conjunto de pruebas de 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. Las siguientes son algunas de las opciones admitidas: + `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. Debe especificar un grupo si tiene varios grupos de dispositivos definidos en el archivo `device.json`. + `upgrade-test-suite`. Controla cómo se manejan las actualizaciones de la versión del conjunto de pruebas. A partir de IDT v3.0.0, IDT comprueba en línea las versiones actualizadas del conjunto de pruebas. Para obtener más información, consulte [Versiones del conjunto de pruebas](idt-gg-qualification.md#idt-test-suite-versions). + `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. No utilice esta opción cuando ejecute un conjunto de pruebas completo para generar un informe de cualificación. + `update-idt`. Establece la respuesta del mensaje para actualizar IDT. `Y` detiene la ejecución de la prueba si IDT detecta que hay una versión más reciente. `N` continúa la ejecución de la prueba. + `update-managed-policy`. `Y` si que la entrada detiene la ejecución de la prueba si IDT detecta que la política administrada del usuario no está actualizada. `N` si la entrada continúa la ejecución de la prueba. 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 ``` ------ #### [ IDT v2.3.0 and earlier ] `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. `run-suite` Ejecuta un conjunto de pruebas en un grupo de dispositivos. 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 ``` ------ # Descripción de los resultados y de los registros En esta sección se describe cómo ver e interpretar registros e informes de resultados de IDT. ## Ver los resultados Mientras ejecuta, IDT escribe errores en la consola, en archivos de registro y en informes de prueba. Una vez que IDT completa el conjunto de pruebas de cualificación, genera dos informes de prueba. Estos informes se pueden encontrar en `/results//`. Ambos informes capturan los resultados de la ejecución del conjunto de pruebas de cualificación. Este `awsiotdevicetester_report.xml` es el informe de la prueba de calificación que debe enviar AWS para incluir su dispositivo en el catálogo de AWS Partner dispositivos. El informe contiene los componentes siguientes: + La versión de IDT. + La AWS IoT Greengrass versión que se probó. + El SKU y el grupo de dispositivos especificado en el archivo `device.json`. + Las características del grupo de dispositivos especificado en el archivo `device.json`. + El resumen de agregación de los resultados de las pruebas. + Un desglose de los resultados de las pruebas por bibliotecas que se probaron en función de las características de los dispositivos (por ejemplo, acceso a recursos locales, shadow, MQTT, etc.). El `GGQ_Result.xml` informe está en [formato JUnit XML](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 los componentes siguientes: + Resumen de agregación de los resultados de pruebas. + Desglose de los resultados de las pruebas según la AWS IoT Greengrass funcionalidad que se probó. ## Interpretación de los informes de IDT La sección de informe en `awsiotdevicetester_report.xml` o `awsiotdevicetester_report.xml` enumera las pruebas que se ejecutaron 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 cualificación. `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. 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 solicitar la cualificación de la placa. En el siguiente fragmento se muestra cómo aparece esta información en el archivo `awsiotdevicetester_report.xml`. ``` ``` Las características marcadas como `optional` no son necesarias para la cualificación. Los siguientes fragmentos muestran características opcionales: ``` 
 ``` Si no hay fallos en las pruebas ni errores en relación con las funciones requeridas, el dispositivo cumple los requisitos técnicos para funcionar AWS IoT Greengrass y puede interoperar con AWS IoT los servicios. Si quieres incluir tu dispositivo en el catálogo de AWS Partner dispositivos, puedes utilizar este informe como prueba de aptitud. 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 ``` ## Visualización de registros IDT genera registros a partir de la ejecución de pruebas en `/results//logs`. Se generan dos conjuntos de registros: `test_manager.log` Registros generados a partir del componente Test Manager de AWS IoT Device Tester (por ejemplo, registros relacionados con la configuración, la secuenciación de las pruebas y la generación de informes). `.log (for example, ota.log)` Son los registros del grupo de pruebas, incluidos los registros del dispositivo bajo prueba. Cuando una prueba devuelve un error, se crea un archivo tar.gz que contiene los registros del dispositivo sometido a prueba para la prueba (por ejemplo, `ota_prod_test_1_ggc_logs.tar.gz`). Para obtener más información, consulte [IDT para la solución de problemas AWS IoT Greengrass](idt-troubleshooting.md). # Uso de IDT para desarrollar y ejecutar sus propios conjuntos de pruebas A partir de la versión 4.0.0 de IDT, IDT for AWS IoT Greengrass 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 Device Tester para AWS IoT AWS IoT Greengrass Descargue la [última versión](dev-test-versions.md) de IDT y extraiga el software en una ubicación de su sistema de archivos en la que tenga permisos de lectura y 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 JSON 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 JSON](idt-json-config.md) para su conjunto de pruebas. 1. [Cree ejecutables de casos de prueba](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-config-custom.md) ejecuten el conjunto de pruebas. 1. Compruebe que IDT pueda ejecutar su conjunto de pruebas y producir los [resultados de las pruebas](run-tests-custom.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 descarga de AWS IoT Device Tester 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 y comprender cómo puede utilizar AWS IoT Device Tester 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** + Ú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. ## 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. 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 JSON 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 JSON](#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 JSON El conjunto de pruebas debe contener los siguientes [archivos de configuración JSON](idt-json-config.md) necesarios:Archivos JSON 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](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. # Cree archivos de configuración IDT para su conjunto de pruebas. En esta sección se describen los formatos en los que se crean los archivos de configuración JSON que se incluyen al escribir un conjunto de pruebas personalizado.Archivos JSON 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 JSON opcionales `state_machine.json` Define cómo se ejecutan las pruebas cuando IDT ejecuta el conjunto de pruebas. Consulte [Configuración de state\$1machine.json](#state-machine-json). `userdata_schema.json` Define el esquema del [archivo `userdata.json`](set-config-custom.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 JSON se colocan en su archivo ``, tal y como se muestra aquí. ``` └── suite ├── suite.json ├── state_machine.json ├── 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 identificador ú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 identificador 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](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 identificador único definido por el usuario para el caso de pruebas. El valor de `id` debe coincidir con el nombre de la carpeta del caso de pruebas en la que se encuentra el archivo `test.json` y no debe contener guiones bajos (`_`). El identificador 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](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 state\$1machine.json 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. Para obtener más información sobre cómo funciona la máquina de estados de IDT, consulte [Configure la máquina de estados IDT](idt-state-machine.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 [IDT como en el contexto](idt-context.md) de la [máquina de estados](idt-state-machine.md#state-machine-context). # Configure la máquina de estados IDT 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 estado. *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 `statemachine.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](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 de acceso correcta al ejecutable del caso de prueba en cada archivo `test.json` y de que el ejecutable especificado se ejecute correctamente. Cuando todos los dispositivos estén preparados para ejecutar un caso de prueba, IDT lee los siguientes archivos: + El `test.json` para el caso de prueba seleccionado determina los procesos que se van a iniciar y las variables de entorno que se van a configurar. + El `suite.json` para el conjunto de pruebas determina las variables de entorno que se van a configurar. IDT inicia el proceso de 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. ## Utilice el SDK de cliente de IDT El cliente IDT le SDKs permite simplificar la forma en que escribe la lógica de prueba en su ejecutable de prueba con comandos de API que puede usar para interactuar con IDT y sus dispositivos bajo prueba. Actualmente, IDT ofrece lo siguiente: SDKs + SDK de cliente de IDT para Python + SDK de cliente de IDT para Go Se SDKs encuentran en la `/sdks` carpeta. 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, la máquina de estados de su conjunto de pruebas debe incluir un conjunto específico de estados `RunTask` y `Choice` en su máquina de estados. Si no utiliza una máquina de estados personalizada, la máquina de estados de IDT predeterminada incluye los estados necesarios y no es necesario que realice ninguna acción adicional. Sin embargo, si utiliza una máquina de estados personalizada, use [Ejemplo de máquina de estados: ejecutar grupos de pruebas seleccionados por el usuario](idt-state-machine.md#allow-specific-groups) como ejemplo para añadir los estados necesarios a su máquina de estados. Para obtener más información sobre los comandos de la CLI de IDT, consulte [Depurar y ejecutar conjuntos de pruebas personalizadas](run-tests-custom.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 [Revise 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 las pruebas produce resultados JUnit XML, puede escribirlos en un archivo XML de 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`](gg-core.md#config-json). 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-config-custom.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 AWS credenciales utilizadas por la prueba para conectarse a la AWS nube. 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-config-custom.md#userdata-config-custom). ## Acceso a los datos del contexto Puede consultar el contexto mediante la JSONPath notación de sus archivos JSON y de su ejecutable de texto con la tecla `GetContextValue` y `GetContextString` APIs. La sintaxis de JSONPath las cadenas 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 `statemachine.json`, se 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. SDKs En la siguiente tabla se describen los operadores de una JSONPath expresión típica: | Operador | Descripción | | --- |--- | | \$1 | El elemento raíz. Como el valor de contexto de nivel superior de IDT es un objeto, se suele utilizar \$1. para iniciar las consultas. | | .childName | Accede al elemento secundario con el nombre childName desde un objeto. Si se aplica a una matriz, genera una nueva matriz con este operador aplicado a cada elemento. El nombre del elemento distingue entre mayúsculas y minúsculas. Por ejemplo, la consulta para acceder al valor awsRegion del objeto config es \$1.config.awsRegion. | | [start:end] | Filtra los elementos de una matriz y los recupera desde el índice start hasta el índice end, ambos incluidos. | | [index1, index2, ... , indexN] | Filtra los elementos de una matriz y los recupera únicamente de los índices especificados. | | [?(expr)] | Filtra los elementos de una matriz con la expresión expr. Esta expresión debe evaluarse en un valor booleano. | Para crear expresiones de filtro, utilice la siguiente sintaxis: ``` | operator | ``` En esta sintaxis: + `jsonpath`es una 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 valor JSONPath o de la expresión es un valor matricial, 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 valor JSONPath o del lado izquierdo de la expresión debe dar como resultado una cadena y el lado derecho debe ser un valor de patrón que siga la RE2 sintaxis.](https://github.com/google/re2/wiki/Syntax) Puede utilizar JSONPath consultas con el formato \$1\$1*query*\$1\$1 como cadenas de marcadores de posición dentro de los `environmentVariables` campos `args` y de los `test.json` archivos y dentro de los `environmentVariables` campos de los `suite.json` archivos. 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 JSONPath marcadores de posición 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 JSON que se encuentran en la carpeta `/configs/`. Si es necesario, los ejecutores de pruebas también deben configurar AWS las credenciales que IDT utilizará para conectarse a la AWS nube. Como redactor de pruebas, necesitará configurar estos archivos para [depurar su conjunto de pruebas](run-tests-custom.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 calificados. Si quieres incluir tu placa en el catálogo de AWS Partner dispositivos, la SKU que especifiques aquí debe coincidir con la que utilizaste 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 de la máquina de estados](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 `docker`. `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 `docker`. Para comprobar si los ejecutores de las pruebas configuran una conexión de dispositivo incorrecta para una prueba, puede recuperar `pool.Devices[0].Connectivity.Protocol` del contexto de la máquina de estados y realizar una comparación 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 `docker`. `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 `docker`. ## (Opcional) Configuración de config.json El archivo `config.json` contiene la información de configuración para IDT. Por lo general, los corredores de pruebas no necesitarán modificar este archivo excepto para proporcionar sus credenciales de AWS usuario para IDT y, si lo desean, una AWS región. Si se proporcionan AWS las 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 y 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 AWS credenciales 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 `AWS_SECRET_ACCESS_KEY` entorno `AWS_ACCESS_KEY_ID` y para almacenar AWS las credenciales 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 AWS las credenciales de IDT, los ejecutores de pruebas editan la `auth` sección del `config.json` archivo ubicado en la `/configs/` carpeta. ``` { "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 de**. `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 AWS región que utilizarán las suites 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 utiliza IDT para recuperar AWS las credenciales. 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-config-custom.md), IDT puede ejecutar su conjunto de pruebas. El tiempo de ejecución del conjunto de pruebas completo depende del hardware y de la composición del conjunto de pruebas. Como referencia, se necesitan aproximadamente 30 minutos para completar el conjunto completo de pruebas de AWS IoT Greengrass calificación en una Raspberry Pi 3B. Mientras escribe su conjunto de pruebas, puede usar IDT para ejecutarlo en modo de depuración, comprobar el código antes de ejecutarlo 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 la máquina de estados, 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 la máquina de estados y no genera 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` Muestra los productos compatibles con su versión de IDT, en este caso AWS IoT Greengrass las versiones, y las versiones del conjunto de pruebas de AWS IoT Greengrass cualificación disponibles 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). ------ # Revise 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 los 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 identificador 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 la máquina de estados. 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 ``` ## AWS IoT Esquema de informes de 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 `suite-name_Result.xml` informe está en [formato JUnit XML](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 comandos de la CLI de IDT para ejecutar 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 archivo `config.jso` n 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 uno Cuenta de AWS, vaya a[Paso 2: Configurar los permisos de IDT](#idt-metrics-permissions). #### Inscríbase en una Cuenta de AWS Si no tiene uno Cuenta de AWS, complete los siguientes pasos para crearlo. **Para suscribirse 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). AWS te envía un correo electrónico de confirmación una vez finalizado el proceso de registro. En cualquier momento, puede ver la actividad de su cuenta actual y administrarla accediendo a [https://aws.amazon.com/](https://aws.amazon.com/)y seleccionando **Mi cuenta**. #### Creación de un usuario con acceso administrativo Después de crear un usuario administrativo Cuenta de AWS, asegúrelo Usuario raíz de la cuenta de AWS AWS IAM Identity Center, habilite y cree un usuario administrativo para no usar el usuario root en las tareas diarias. **Proteja su Usuario raíz de la cuenta de AWS** 1. Inicie sesión [Consola de administración de AWS](https://console.aws.amazon.com/)como propietario de la cuenta seleccionando el **usuario root** e introduciendo su dirección de Cuenta de AWS correo electrónico. En la siguiente página, escriba su contraseña. Para obtener ayuda para iniciar sesión con el usuario raíz, consulte [Iniciar sesión como usuario raíz](https://docs.aws.amazon.com/signin/latest/userguide/console-sign-in-tutorials.html#introduction-to-root-user-sign-in-tutorial) en la *Guía del usuario de AWS Sign-In *. 1. Active la autenticación multifactor (MFA) para el usuario raíz. Para obtener instrucciones, consulte [Habilitar un dispositivo MFA virtual para el usuario Cuenta de AWS raíz (consola)](https://docs.aws.amazon.com/IAM/latest/UserGuide/enable-virt-mfa-for-root.html) en la Guía del usuario de *IAM*. **Creación de un usuario con acceso administrativo** 1. Activar IAM Identity Center. Consulte las instrucciones en [Activar AWS IAM Identity Center](https://docs.aws.amazon.com//singlesignon/latest/userguide/get-set-up-for-idc.html) en la *Guía del usuario de AWS IAM Identity Center *. 1. En IAM Identity Center, conceda acceso administrativo a un usuario. Para ver un tutorial sobre su uso Directorio de IAM Identity Center como fuente de identidad, consulte [Configurar el acceso de los usuarios con la configuración predeterminada Directorio de IAM Identity Center en la](https://docs.aws.amazon.com//singlesignon/latest/userguide/quick-start-default-idc.html) Guía del *AWS IAM Identity Center usuario*. **Inicio de sesión como usuario con acceso de administrador** + Para iniciar sesión con el usuario de IAM Identity Center, use la URL de inicio de sesión que se envió a la dirección de correo electrónico cuando creó el usuario de IAM Identity Center. Para obtener ayuda para iniciar sesión con un usuario del Centro de identidades de IAM, consulte [Iniciar sesión en el portal de AWS acceso](https://docs.aws.amazon.com/signin/latest/userguide/iam-id-center-sign-in-tutorial.html) en la *Guía del AWS Sign-In usuario*. **Concesión de acceso a usuarios adicionales** 1. En IAM Identity Center, cree un conjunto de permisos que siga la práctica recomendada de aplicar permisos de privilegios mínimos. Para conocer las instrucciones, consulte [Create a permission set](https://docs.aws.amazon.com//singlesignon/latest/userguide/get-started-create-a-permission-set.html) en la *Guía del usuario de AWS IAM Identity Center *. 1. Asigne usuarios a un grupo y, a continuación, asigne el acceso de inicio de sesión único al grupo. Para conocer las instrucciones, consulte [Add groups](https://docs.aws.amazon.com//singlesignon/latest/userguide/addgroups.html) en la *Guía del usuario de AWS IAM Identity Center *. ### 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 **Siguiente: Etiquetas**. 1. Elija **Siguiente: Revisar**. 1. En **Nombre**, escriba **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 **Establecer permisos**, elija **Adjuntar políticas existentes 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. Si ya ha configurado permisos en la consola, vaya a [Configuración de su dispositivo para ejecutar pruebas de IDT](device-config-setup.md) o [Opcional: configurar su contenedor Docker para IDT para AWS IoT Greengrass](docker-config-setup.md). 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, macOS, 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. ------ 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 el siguiente comando: ``` AWS_ACCESS_KEY_ID=access-key AWS_SECRET_ACCESS_KEY=secret-access-key ``` 1. Para utilizar el archivo de credenciales, añada la siguiente información a `.aws/credentials file:` ``` [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-config-custom.md#config-json-custom). # IDT para la solución de problemas AWS IoT Greengrass IDT for AWS IoT Greengrass escribe estos errores en varias ubicaciones según el tipo de error. Los errores se escriben en la consola, en los archivos de registro y en los informes de prueba. ## Códigos de error En la siguiente tabla se muestran los códigos de error generados por IDT para AWS IoT Greengrass. | Código de error | Nombre del código de error | Causa raíz posible | Solución de problemas | | --- | --- | --- | --- | | 101 | InternalError | Se ha producido un error interno. | Compruebe los registros en el directorio `/results`. Si no puede solucionar el problema, póngase en contacto con [AWS Developer Support](https://aws.amazon.com/premiumsupport/plans/developers/). | | 102 | TimeoutError | La prueba no se puede completar en un período de tiempo limitado. Esto puede ocurrir si: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/es_es/greengrass/v1/developerguide/idt-troubleshooting.html) | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/es_es/greengrass/v1/developerguide/idt-troubleshooting.html) | | 103 | PlatformNotSupportError | Se ha definido una combinación incorrecta de sistema operativo y arquitecta en `device.json`. | Cambie la configuración a una de las combinaciones admitidas: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/es_es/greengrass/v1/developerguide/idt-troubleshooting.html) Para obtener más información, consulte [Configurar device.json](set-config.md#device-config). | | 104 | VersionNotSupportError | La versión de software AWS IoT Greengrass principal no es compatible con la versión de IDT que está utilizando. | Utilice el **device\$1tester\$1bin version** comando para buscar la versión compatible del software AWS IoT Greengrass principal. Por ejemplo, si usa macOS, utilice: **./devicetester\$1mac\$1x86\$164 version**. Para encontrar la versión del software AWS IoT Greengrass Core que está utilizando: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/es_es/greengrass/v1/developerguide/idt-troubleshooting.html) Puede probar una versión diferente del software AWS IoT Greengrass Core. Para obtener más información, consulte [Empezar con AWS IoT Greengrass](gg-gs.md). | | 105 | LanguageNotSupportError | IDT SDKs solo admite Python para AWS IoT Greengrass bibliotecas. | Asegúrese de que: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/es_es/greengrass/v1/developerguide/idt-troubleshooting.html) | | 106 | ValidationError | Algunos campos en `device.json` o `config.json` no son válidos. | Compruebe el mensaje de error en la parte derecha del código de error del informe. [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/es_es/greengrass/v1/developerguide/idt-troubleshooting.html) | | 107 | SSHConnectionFalló | La máquina de pruebas no puede conectarse al dispositivo configurado. | Compruebe que los siguientes campos de su archivo `device.json` son correctos: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/es_es/greengrass/v1/developerguide/idt-troubleshooting.html) Para obtener más información, consulte [Configurar device.json](set-config.md#device-config). | | 108 | RunCommandError | Una prueba no ha podido ejecutar un comando en el dispositivo que se está probando. | Compruebe que se permite el acceso raíz al usuario configurado en `device.json`. Algunos dispositivos requieren una contraseña cuando se ejecutan comandos con acceso raíz. Asegúrese de que el acceso raíz se conceda sin contraseña. Para obtener más información, consulte la documentación de su dispositivo. Intente ejecutar manualmente en su dispositivo el comando que ha generado el error y compruebe si también se produce un error. | | 109 | PermissionDeniedError | No hay acceso raíz. | Establezca el acceso raíz para el usuario configurado en el dispositivo. | | 110 | CreateFileError | No es posible crear un archivo. | Compruebe el espacio en disco del dispositivo y los permisos de directorio. | | 111 | CreateDirError | No se puede crear un directorio. | Compruebe el espacio en disco del dispositivo y los permisos de directorio. | | 112 | InvalidPathError | La ruta al software AWS IoT Greengrass principal es incorrecta. | Compruebe que la ruta del mensaje de error es válida. No edite ningún archivo del directorio `devicetester_greengrass_`. | | 113 | InvalidFileError | Un archivo no es válido. | Compruebe que el archivo en el mensaje de error es válido. | | 114 | ReadFileError | El archivo especificado no se puede leer. | Compruebe lo siguiente: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/es_es/greengrass/v1/developerguide/idt-troubleshooting.html) Si está realizando las pruebas en macOS, aumente el límite de archivos abiertos. El límite predeterminado es 256, que es suficiente para las pruebas. | | 115 | FileNotFoundError | No se ha encontrado un archivo necesario. | Compruebe lo siguiente: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/es_es/greengrass/v1/developerguide/idt-troubleshooting.html) | | 116 | OpenFileFailed | No se puede abrir el archivo especificado. | Compruebe lo siguiente: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/es_es/greengrass/v1/developerguide/idt-troubleshooting.html) Si está realizando las pruebas en macOS, aumente el límite de archivos abiertos. El límite predeterminado es 256, que es suficiente para las pruebas. | | 117 | WriteFileFailed | No se ha podido escribir el archivo (puede ser el DUT o la máquina de pruebas). | Compruebe que existe el directorio especificado en el mensaje de error y que tiene permiso de escritura. | | 118 | FileCleanUpError | Una prueba no ha podido eliminar el archivo o el directorio especificado, o no pudo desmontar el archivo especificado en el dispositivo remoto. | Si el archivo binario se sigue ejecutando, puede que el archivo esté bloqueado. Detenga el proceso y elimine el archivo especificado. | | 119 | InvalidInputError | Configuración no válida. | Compruebe que el archivo `suite.json` es válido. | | 120 | InvalidCredentialError | AWS Credenciales no válidas. | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/es_es/greengrass/v1/developerguide/idt-troubleshooting.html) | | 121 | AWSSessionError | No se pudo crear una AWS sesión. | Este error puede producirse si AWS las credenciales no son válidas o si la conexión a Internet es inestable. Intente utilizarla AWS CLI para llamar a una operación AWS de API. | | 122 | AWSApiCallError | Se ha producido un error en la AWS API. | Esto puede deberse a un problema de red. Compruebe su red antes de volver a ejecutar el grupo de pruebas. | | 123 | IpNotExistError | La dirección IP no está incluida en la información de conectividad. | Compruebe la conexión a Internet. Puede usar la AWS IoT Greengrass consola para comprobar la información de conectividad del AWS IoT Greengrass elemento principal que se utiliza en la prueba. Si hay 10 puntos de enlace incluidos en la información de conectividad, puede eliminar algunos o todos ellos y volver a ejecutar la prueba. Para obtener más información, consulte la sección sobre [información de conectividad](https://docs.aws.amazon.com/cli/latest/reference/greengrass/get-connectivity-info.html). | | 124 | OTAJobNotCompleteError | No se completó un trabajo de OTA. | Compruebe la conexión a Internet y vuelva a ejecutar el grupo de pruebas de OTA. | | 125 | CreateGreengrassServiceRoleError | Se ha producido alguno de los siguientes errores: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/es_es/greengrass/v1/developerguide/idt-troubleshooting.html) | Configure el rol AWS IoT Greengrass de servicio. Para obtener más información, consulte [Rol de servicio de Greengrass](service-role.md). | | 126 | DependenciesNotPresentError | Una o varias dependencias necesarias para la prueba específica no están presentes en el dispositivo. | Compruebe el registro de prueba para ver qué dependencias faltan en su dispositivo: `/results//logs/` | | 127 | No válido HSMConfiguration | La configuración de HSM/PKCS proporcionada no es correcta. | Proporcione la configuración necesaria para interactuar con el HSM utilizando PKCS\$111 en su archivo `device.json`. | | 128 | OTAJobNotSuccededError | El trabajo de OTA no se ha podido realizar correctamente. | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/es_es/greengrass/v1/developerguide/idt-troubleshooting.html) | | 129 | NoConnectivityError | Se ha producido un error del agente host al conectar a Internet. | Compruebe la conexión de red y la configuración del firewall. Pruebe de nuevo el grupo de prueba después de que se resuelva el problema de conectividad. | | 130 | NoPermissionError | El usuario de IAM para el que se ejecuta IDT AWS IoT Greengrass no tiene permiso para crear los AWS recursos necesarios para ejecutar IDT. | Consulte en [Plantilla de política de permisos](https://docs.aws.amazon.com/greengrass/latest/developerguide/policy-template.html) la plantilla que concede los permisos necesarios para ejecutar IDT para AWS IoT Greengrass. | | 131 | LeftoverAgentExistError | Su dispositivo está ejecutando AWS IoT Greengrass procesos cuando intenta iniciar IDT for. AWS IoT Greengrass | Asegúrese de que no haya ningún demonio de Greengrass ejecutándose en su dispositivo. [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/es_es/greengrass/v1/developerguide/idt-troubleshooting.html) Si utiliza una instalación existente o AWS IoT Greengrass está configurada para que se inicie automáticamente tras el reinicio, debe detener el daemon tras el reinicio y antes de ejecutar el conjunto de pruebas. | | 132 | DeviceTimeOffsetError | El dispositivo tiene la hora incorrecta. | Ajuste el dispositivo a la hora correcta. | | 133 | No válido MLConfiguration | La configuración de ML proporcionada es incorrecta. | En el archivo `device.json`, proporcione la configuración correcta necesaria para ejecutar las pruebas de inferencia de ML. Para obtener más información, consulte [Opcional: Configuración del dispositivo para la cualificación ML](idt-ml-qualification.md). | ## Resolver errores de IDT AWS IoT Greengrass Al utilizar IDT, debe disponer de los archivos de configuración correctos antes de ejecutar IDT para. AWS IoT Greengrass Si obtiene errores de análisis y de configuración, el primer paso es localizar y utilizar una plantilla de configuración adecuada para su entorno. Si continúa teniendo problemas, consulte el siguiente proceso de depuración. **Topics** + [¿Dónde puedo buscar los errores?](#where-to-look) + [Errores de procesamiento](#parse-error) + [Error por ausencia de un parámetro obligatorio](#param-missing) + [Error por la imposibilidad de iniciar una prueba](#could-not-start-test) + [Error por falta de autorización para acceder a un recurso](#not-authorized-to-access-resource) + [Errores de permiso denegado](#pwd-sudo) + [Errores de conexión SSH](#ssh-connect-errors) + [Errores de tiempo de espera](#test-timeout) + [Errores No se encuentra el comando al realizar las pruebas](#cmd-not-found) + [Excepción de seguridad en macOS](#macos-notarization-exception) ### ¿Dónde puedo buscar los errores? Los errores de alto nivel se muestran en la consola durante la ejecución y se muestra un resumen de las pruebas fallidas con el error una vez completadas todas las pruebas. `awsiotdevicetester_report.xml` contiene un resumen de todos los errores que han provocado fallos en una prueba. Los archivos de registro de cada ejecución de prueba se almacenan en un directorio determinado con un UUID para la ejecución de pruebas que se muestra en la consola durante la ejecución de la prueba. El directorio de registros de prueba se encuentra en `/results//logs/`. Este directorio contiene los siguientes archivos que son útiles para la depuración. | Archivos | Descripción | | --- | --- | | test\$1manager.log | Todos los registros escritos en la consola durante la ejecución de las pruebas. Al final de este archivo se encuentra un resumen de los resultados que incluye una lista de las pruebas con errores. La advertencia y los registros de errores en este archivo pueden proporcionarle información acerca de los errores que se producen. | | \$1\$1.log | Registros detallados para la prueba específica. | | \$1ggc\$1logs.tar.gz | Una colección comprimida de todos los registros que el daemon AWS IoT Greengrass principal generó durante la prueba. Para más información, consulte [Solución de problemas AWS IoT Greengrass](https://docs.aws.amazon.com/greengrass/latest/developerguide/gg-troubleshooting.html). | | \$1ota\$1logs.tar.gz | Colección comprimida de registros generados por el agente AWS IoT Greengrass OTA durante la prueba. Solo para pruebas OTA. | | \$1basic\$1assertion\$1publisher\$1ggad\$1logs.tar.gz | Colección comprimida de registros generada por el dispositivo del editor de AWS IoT durante la prueba. | | \$1basic\$1assertion\$1subscriber\$1ggad\$1logs.tar.gz | Colección comprimida de registros generados por el dispositivo del suscriptor de AWS IoT durante la prueba. | ### Errores de procesamiento Ocasionalmente, un error tipográfico en una configuración de JSON puede dar lugar a errores de análisis. En la mayoría de los casos, el problema es resultado de omitir un paréntesis, una coma o unas comillas en el archivo JSON. IDT realiza la validación JSON e imprime información de depuración. Imprime la línea en la que se produjo el error, el número de línea y el número de la columna del error de sintaxis. Esta información debería ser suficiente para ayudarte a corregir el error, pero si sigues sin poder localizarlo, puedes realizar la validación manualmente en tu IDE, en un editor de texto como Atom o Sublime, o mediante una herramienta en línea similar JSONLint. ### Error por ausencia de un parámetro obligatorio Dado que se han añadido nuevas características a IDT, es posible que se hayan introducido cambios en los archivos de configuración. Utilizar un archivo de configuración antiguo podría romper la configuración. Si esto ocurre, el archivo `.log` en `/results//logs` enumera explícitamente todos los parámetros que faltan. IDT también valida los esquemas del archivo de configuración JSON para asegurarse de que se ha utilizado la última versión compatible. ### Error por la imposibilidad de iniciar una prueba Es posible que encuentre errores que apuntan a errores durante el inicio de la prueba. Existen varias causas posibles, por lo que debe hacer lo siguiente: + Asegúrese de que el nombre del grupo que ha incluido en el comando de ejecución existe realmente. Al nombre del grupo se hace referencia directamente desde el archivo `device.json`. + Asegúrese de que el dispositivo o dispositivos del grupo tienen parámetros de configuración correctos. ### Error por falta de autorización para acceder a un recurso Es posible que vea el mensaje de error ` is not authorized to access this resource` en la salida del terminal o en el archivo `test_manager.log` en `/results//logs`. Para resolver este problema, asocie la política administrada `AWSIoTDeviceTesterForGreengrassFullAccess` al usuario de prueba. Para obtener más información, consulte [Cree y configure un Cuenta de AWS](dev-tst-prereqs.md#config-aws-account-for-idt). ### Errores de permiso denegado IDT realiza operaciones en diversos directorios y archivos en un dispositivo que se está probando. Algunas de estas operaciones requieren acceso raíz. Para automatizar estas operaciones, IDT debe ser capaz de ejecutar comandos con sudo sin escribir una contraseña. Siga estos pasos para permitir acceso sudo sin escribir una contraseña. **nota** `user` y `username` hacen referencia al usuario SSH que utiliza IDT para acceder al dispositivo a prueba. 1. Use **sudo usermod -aG sudo **** para añadir el usuario SSH al grupo sudo. 1. Cierre la sesión y, a continuación, vuelva a iniciar sesión para que los cambios surtan efecto. 1. Añada el archivo `/etc/sudoers` y, a continuación, agregue la siguiente línea al final del archivo: ` ALL=(ALL) NOPASSWD: ALL` **nota** Le recomendamos que utilice **sudo visudo** al editar `/etc/sudoers`. ### Errores de conexión SSH Cuando IDT no se puede conectar a un dispositivo a prueba, los errores de conexión se registran en `/results//logs/.log`. Los mensajes de error de SSH aparecen en la parte superior de este archivo de registro ya que la conexión a un dispositivo bajo prueba es una de las primeras operaciones que realiza IDT. La mayoría de las configuraciones de Windows utilizan la aplicación de TTy terminal Pu para conectarse a los hosts Linux. Esta aplicación requiere que los archivos de clave privada PEM estándar se conviertan en un formato propio de Windows denominado PPK. Cuando IDT está configurado en su archivo `device.json`, utilice solo archivos PEM. Si utiliza un archivo PPK, IDT no puede crear una conexión SSH con el AWS IoT Greengrass dispositivo y no puede ejecutar pruebas. ### Errores de tiempo de espera Puede aumentar el tiempo de espera de cada prueba especificando un multiplicador de tiempo de espera, que se aplicará al valor predeterminado de cada tiempo de espera de la prueba. Cualquier valor configurado para esta marca debe ser superior o igual a 1,0. Para utilizar el multiplicador de tiempo de espera, utilice la marca `--timeout-multiplier` al ejecutar las pruebas. Por ejemplo: ``` ./devicetester_linux run-suite --suite-id GGQ_1.0.0 --pool-id DevicePool1 --timeout-multiplier 2.5 ``` Para obtener más información, ejecute `run-suite --help`. ### Errores No se encuentra el comando al realizar las pruebas Necesitas una versión anterior de la biblioteca OpenSSL (libssl1.0.0) para ejecutar pruebas en los dispositivos. AWS IoT Greengrass La mayoría de distribuciones de Linux actuales utilizan libssl versión 1.0.2 o posterior (v1.1.0). Por ejemplo, en una Raspberry Pi, ejecute los siguientes comandos para instalar la versión requerida de libssl: 1. ``` wget http://ftp.us.debian.org/debian/pool/main/o/openssl/libssl1.0.0_1.0.2l-1~bpo8+1_armhf.deb ``` 1. ``` sudo dpkg -i libssl1.0.0_1.0.2l-1~bpo8+1_armhf.deb ``` ### Excepción de seguridad en macOS Cuando ejecuta IDT en una máquina host que usa macOS 10.15, el ticket de certificación notarial de IDT no se detecta correctamente y se bloquea la ejecución de IDT. Para ejecutar IDT, tendrá que conceder una excepción de seguridad al `devicetester_mac_x86-64` ejecutable. **Para conceder una excepción de seguridad de IDT ejecutable** 1. Abra **Preferencias del sistema** desde el menú de Apple. 1. Seleccione **Seguridad y privacidad**, a continuación, en la pestaña **General**, haga clic en el icono del candado para realizar cambios en la configuración de seguridad. 1. Busque el mensaje `"devicetester_mac_x86-64" was blocked from use because it is not from an identified developer.` y seleccione **Permitir de todos modos** . 1. Acepte la advertencia de seguridad. Si tiene alguna pregunta acerca de la política de compatibilidad con IDT, póngase en contacto con el [Servicio de atención al cliente de AWS](https://aws.amazon.com/contact-us/). # Política de soporte de AWS IoT Device Tester para AWS IoT Greengrass V1 AWS IoT [Device Tester (IDT) for AWS IoT Greengrass es un marco de pruebas descargable que le permite validar y [calificar](https://aws.amazon.com/partners/dqp/) sus AWS IoT Greengrass dispositivos para su inclusión en el AWS Partner catálogo de dispositivos.](https://devices.amazonaws.com/) Le recomendamos que utilice la versión más reciente de AWS IoT Greengrass un IDT para probar o calificar sus dispositivos. Para obtener más información, consulte [Versiones de IDT admitidas por AWS IoT Greengrass V2](https://docs.aws.amazon.com/greengrass/v2/developerguide/dev-test-versions.html) en la *Guía del desarrollador de AWS IoT Greengrass Version 2 *. También puedes usar cualquiera de las versiones compatibles de AWS IoT Greengrass un IDT para probar o calificar tus dispositivos. Aunque puede seguir utilizando [versiones no compatibles de IDT](dev-test-versions.md#idt-unsupported-versions), dichas versiones no reciben actualizaciones ni correcciones de errores. **importante** A partir del 4 de abril de 2022, AWS IoT Device Tester (IDT) AWS IoT Greengrass V1 dejará de generar informes de calificación firmados. Ya no puedes incluir nuevos AWS IoT Greengrass V1 dispositivos en el [catálogo](https://devices.amazonaws.com/) de dispositivos a través del AWS Partner Programa de [calificación de AWS dispositivos](https://aws.amazon.com/partners/programs/dqp/). Si bien no puede calificar los dispositivos Greengrass V1, puede seguir usando IDT AWS IoT Greengrass V1 para probar sus dispositivos Greengrass V1. Le recomendamos que utilice [IDT para AWS IoT Greengrass V2](https://docs.aws.amazon.com/greengrass/v2/developerguide/device-tester-for-greengrass-ug.html) para calificar y publicar los dispositivos de Greengrass en el [Catálogo de dispositivos de AWS Partner](https://devices.amazonaws.com/). Si tiene alguna pregunta acerca de la política de compatibilidad, póngase en contacto con el [servicio de atención al cliente de AWS](https://aws.amazon.com/contact-us/).