지원 종료 공지: 2026년 10월 7일에는에 대한 지원을 중단할 AWS 예정입니다 AWS IoT Greengrass Version 1. 2026년 10월 7일 이후에는 더 이상 AWS IoT Greengrass V1 리소스에 액세스할 수 없습니다. 자세한 내용은 [에서 마이그레이션 AWS IoT Greengrass Version 1](https://docs.aws.amazon.com/greengrass/v2/developerguide/migrate-from-v1.html)을 참조하세요. 기계 번역으로 제공되는 번역입니다. 제공된 번역과 원본 영어의 내용이 상충하는 경우에는 영어 버전이 우선합니다. # AWS IoT Greengrass V1용 AWS IoT 디바이스 테스터 사용 AWS IoT 디바이스 테스터(IDT)는 IoT 디바이스를 검증할 수 있는 다운로드 가능한 테스트 프레임워크입니다. AWS IoT Greengrass Version 1 가 [유지 관리 모드로](https://docs.aws.amazon.com/greengrass/v1/developerguide/maintenance-policy.html) 전환되었으므로 용 IDT는 더 이상 서명된 검증 보고서를 생성 AWS IoT Greengrass V1 하지 않습니다. 더 이상 AWS IoT Greengrass V1 디바이스 검증 프로그램을 통해 [AWS Partner 디바이스 카탈로그](https://devices.amazonaws.com/)에 나열할 새 디바이스를 검증할 수 없습니다. [AWS](https://aws.amazon.com/partners/dqp/) 그러나 용 IDT를 계속 사용하여 Greengrass V1 디바이스를 테스트 AWS IoT Greengrass V1 할 수 있습니다. [AWS Partner 장치 카탈로그](https://devices.amazonaws.com/)에서 Greengrass 장치를 검증하고 등재하려면 [AWS IoT Greengrass V2용 IDT](https://docs.aws.amazon.com/greengrass/v2/developerguide/device-tester-for-greengrass-ug.html)를 사용하는 것이 좋습니다. 용 IDT는 테스트할 디바이스에 연결된 호스트 컴퓨터(Windows, macOS 또는 Linux)에서 AWS IoT Greengrass 실행됩니다. 이 IDT는 테스트를 실행하고 결과를 집계합니다. 또한 테스트 프로세스를 관리하기 위한 명령줄 인터페이스를 제공합니다. ## AWS IoT Greengrass 검증 제품군 용 IDT AWS IoT Greengrass 를 사용하여 AWS IoT Greengrass 코어 소프트웨어가 하드웨어에서 실행되고와 통신할 수 있는지 확인합니다 AWS 클라우드. 또한를 사용하여 end-to-end 테스트를 수행합니다 AWS IoT Core. 예를 들어 장치가 MQTT 메시지를 송수신하고 올바르게 처리할 수 있는지 확인합니다. ![\[AWS IoT 디바이스 테스터가 AWS IoT Greengrass 코어 소프트웨어가 하드웨어에서 실행되고와 통신할 수 있는지 확인하는 방법에 대한 개요입니다 AWS 클라우드.\]](http://docs.aws.amazon.com/ko_kr/greengrass/v1/developerguide/images/devicetester_gg.png) AWS IoT 용 디바이스 테스터는 테스트 *제품군* 및 *테스트 그룹의* 개념을 사용하여 테스트를 AWS IoT Greengrass 구성합니다. + 테스트 제품군은 장치가 AWS IoT Greengrass의 특정 버전에서 작동하는지 확인하는 데 사용되는 테스트 그룹 집합입니다. + 테스트 그룹은 Greengrass 그룹 배포 및 MQTT 메시징 같은 특정 기능과 관련된 개별 테스트 집합입니다. 자세한 내용은 [IDT를 사용하여 AWS IoT Greengrass 검증 제품군 실행](idt-gg-qualification.md) 단원을 참조하십시오. ## 사용자 지정 테스트 제품군 IDT v4.0.0부터 용 IDT는 표준화된 구성 설정 및 결과 형식을 디바이스 및 디바이스 소프트웨어에 대한 사용자 지정 테스트 제품군을 개발할 수 있는 테스트 제품군 환경과 AWS IoT Greengrass 결합합니다. 사용자 지정 테스트를 자체 내부 검증을 위해 추가하거나 디바이스 검증을 위해 고객에게 제공할 수 있습니다. 테스트 작성자가 사용자 지정 테스트 제품군을 구성하는 방법에 따라 사용자 지정 테스트 제품군을 실행하는 데 필요한 설정 구성이 결정됩니다. 자세한 내용은 [IDT를 사용하여 자체 테스트 제품군 개발 및 실행](idt-custom-tests.md) 단원을 참조하십시오. # Device AWS IoT Tester for AWS IoT Greengrass V1 지원 버전 AWS IoT Greengrass Version 1 가 [유지 관리 모드로](https://docs.aws.amazon.com/greengrass/v1/developerguide/maintenance-policy.html) 전환되었으므로 용 IDT는 더 이상 서명된 검증 보고서를 생성 AWS IoT Greengrass V1 하지 않습니다. [AWS IoT Greengrass V2용 IDT](https://docs.aws.amazon.com/greengrass/v2/developerguide/device-tester-for-greengrass-ug.html) 사용을 권장합니다. IDT for AWS IoT Greengrass V2에 대한 자세한 내용은 *AWS IoT Greengrass V2 개발자 안내서*의 [용 AWS IoT 디바이스 테스터 사용을 AWS IoT Greengrass V2](https://docs.aws.amazon.com/greengrass/v2/developerguide/device-tester-for-greengrass-ug.html) 참조하세요. **참고** 용 IDT AWS IoT Greengrass 가 사용 중인 버전과 호환되지 않는 경우 테스트 실행을 시작할 때 알림을 받게 AWS IoT Greengrass 됩니다. 소프트웨어를 다운로드하면 [AWS IoT Device Tester 라이선스 계약](https://docs.aws.amazon.com/greengrass/latest/developerguide/idt-license.html)에 동의하는 것입니다. ## 용에 대해 지원되지 않는 IDT 버전 AWS IoT Greengrass 이 주제에서는 지원되지 않는 IDT 버전을 나열합니다 AWS IoT Greengrass. 지원되지 않는 버전에는 버그 수정 또는 업데이트가 제공되지 않습니다. 자세한 내용은 [용 AWS IoT 디바이스 테스터에 대한 지원 정책 AWS IoT Greengrass V1](idt-support-policy.md) 단원을 참조하십시오. ** AWS IoT Greengrass 버전 v1.11.6, v1.10.5용 IDT v4.4.1** 릴리스 정보: + AWS IoT Greengrass 코어 소프트웨어 v1.11.6 및 v1.10.5를 실행하는 디바이스를 검증하고 검증할 수 있습니다. + 사소한 버그 수정 사항을 포함합니다. 테스트 제품군 버전: `GGQ_1.3.1` + 2021년 12월 20일 출시 ** AWS IoT Greengrass 버전 v1.11.4, v1.10.4용 IDT v4.1.0** 릴리스 정보: + AWS IoT Greengrass 코어 소프트웨어 v1.11.4 및 v1.10.4를 실행하는 디바이스를 검증하고 검증할 수 있습니다. + 테스트 실행 중에 표시되는 로그가 중복 태그를 사용하던 문제를 수정합니다. 테스트 제품군 버전: `GGQ_1.3.0` + 2021년 6월 23일 출시 + Lambda, IAM 및에 대한 API 호출 재시도를 추가하여 제한 또는 서버 문제에 대한 처리를 AWS STS 개선합니다. + ML 및 Docker 테스트 케이스에 Python 3.8에 대한 지원을 추가합니다. ** AWS IoT Greengrass 버전 v1.11.1, v1.11.0, v1.10.3용 IDT v4.0.2** 릴리스 정보: + IDT가 하드웨어 보안 통합(HSI) 오류를 마스킹하는 문제를 수정했습니다. + 용 AWS IoT 디바이스 테스터를 사용하여 사용자 지정 테스트 제품군을 개발하고 실행할 수 있습니다 AWS IoT Greengrass. 자세한 내용은 [IDT를 사용하여 자체 테스트 제품군 개발 및 실행](idt-custom-tests.md) 단원을 참조하십시오. + macOS 및 Windows용 코드 서명 IDT 애플리케이션을 제공합니다. macOS에서 보안 경고 메시지가 표시되면 IDT에 보안 예외를 부여해야 할 수 있습니다. 자세한 내용은 [macOS에서의 보안 예외](idt-troubleshooting.md#macos-notarization-exception) 단원을 참조하십시오. AWS IoT Greengrass 는 코어 소프트웨어 버전 1.11.1에 AWS IoT Greengrass 대한 Dockerfile 또는 Docker 이미지를 제공하지 않습니다. 장치의 Docker 검증을 테스트하려면 이전 버전의 AWS IoT Greengrass 코어 소프트웨어를 사용하십시오.   ** AWS IoT Greengrass 버전 v1.11.0, v1.10.1, v1.10.0용 IDT v3.2.0** 릴리스 정보: + 기본적으로 IDT는 검증을 위한 필수 테스트만 실행합니다. 추가 기능을 검증하려면 [`device.json`](set-config.md#device-config) 파일을 수정하면 됩니다. + `device.json`에 SSH 연결용으로 구성할 수 있는 포트 번호를 추가했습니다. + Docker는 컨테이너화 없이 [스트림 관리자](stream-manager.md) 및 기계 학습(ML)만 지원합니다. Docker 장치에는 컨테이너, 도커 및 HSI(하드웨어 보안 통합)를 사용할 수 없습니다. + `device-ml.json`과 `device-hsm.json`을 `device.json`으로 병합했습니다.   ** AWS IoT Greengrass 버전용 IDT v3.1.3: v1.10.x, v1.9.x, v1.8.x** 릴리스 정보: + AWS IoT Greengrass v1.10.x 및 v1.9.x에 대한 ML 기능 검증 지원이 추가되었습니다. 이제 IDT를 사용하여 장치가 클라우드에 저장되고 교육된 모델을 사용하여 로컬로 ML 추론을 수행할 수 있는지 확인할 수 있습니다. + `run-suite` 명령에 대한 `--stop-on-first-failure`가 추가되었습니다. 이 옵션을 사용하여 첫 번째 실패 시 실행을 중지하도록 IDT를 구성할 수 있습니다. 테스트 그룹 수준에서 디버깅 스테이지가 진행되는 동안 이 옵션을 사용하는 것이 좋습니다. + 테스트 중인 장치가 올바른 시스템 시간을 사용하는지 확인하기 위해 MQTT 테스트에 대한 클록 드리프트 검사가 추가되었습니다. 사용 시간은 허용 가능한 시간 범위 내에 있어야 합니다. + `run-suite` 명령에 대한 `--update-idt`가 추가되었습니다. 이 옵션을 사용하여 IDT를 업데이트하라는 프롬프트에 대한 응답을 설정할 수 있습니다. + `run-suite` 명령에 대한 `--update-managed-policy`가 추가되었습니다. 이 옵션을 사용하여 관리형 정책을 업데이트하라는 프롬프트에 대한 응답을 설정할 수 있습니다. + IDT 테스트 제품군 버전의 자동 업데이트에 대한 버그 수정이 추가되었습니다. IDT는 사용 중인 AWS IoT Greengrass 버전에 사용할 수 있는 최신 테스트 제품군을 실행할 수 있습니다.   **용 IDT v3.0.1 AWS IoT Greengrass** 릴리스 정보: + AWS IoT Greengrass v1.10.1에 대한 지원이 추가되었습니다. + IDT 테스트 제품군 버전의 자동 업데이트. IDT는 AWS IoT Greengrass 버전에 사용할 수 있는 최신 테스트 제품군을 다운로드할 수 있습니다. 이 기능의 내용은 다음과 같습니다. + 테스트 제품군은 `major.minor.patch` 형식을 사용하여 버전이 지정됩니다. 초기 테스트 제품군 버전은 `GGQ_1.0.0`입니다. + 새 테스트 제품군을 명령줄 인터페이스에서 대화식으로 다운로드하거나 IDT를 시작할 때 `upgrade-test-suite` 플래그를 설정할 수 있습니다. 자세한 내용은 [테스트 제품군 버전](idt-gg-qualification.md#idt-test-suite-versions) 단원을 참조하십시오. + `list-supported-products` 추가. 이 명령을 사용하여 설치된 IDT 버전에서 지원하는 테스트 제품군 버전과 AWS IoT Greengrass 를 나열할 수 있습니다. + `list-test-cases` 추가. 이 명령을 사용하여 테스트 그룹에서 사용할 수 있는 테스트 케이스를 나열할 수 있습니다. + `run-suite` 명령에 대한 `test-id`가 추가되었습니다. 이 옵션을 사용하여 테스트 그룹에서 개별 테스트 케이스를 실행할 수 있습니다.   **v1.10, v AWS IoT Greengrass 1.9.x 및 v1.8.x용 IDT v2.3.0** 물리적 디바이스에서 테스트하는 경우 AWS IoT Greengrass v1.10, v1.9.x 및 v1.8.x가 지원됩니다. Docker 컨테이너에서 테스트하는 경우 AWS IoT Greengrass v1.10 및 v1.9.x가 지원됩니다. 릴리스 정보: + [Docker 컨테이너 AWS IoT Greengrass 에서 실행](run-gg-in-docker-container.md) 지원이 추가되었습니다. 이제 IDT를 사용하여 디바이스가 Docker 컨테이너 AWS IoT Greengrass 에서 실행될 수 있는지 검증하고 검증할 수 있습니다. + AWS IoT 디바이스 테스터를 실행하는 데 필요한 권한을 정의하는 [AWS 관리형 정책](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_managed-vs-inline.html#aws-managed-policies)(`AWSIoTDeviceTesterForGreengrassFullAccess`)이 추가되었습니다. 새 릴리스에 추가 권한이 필요한 경우 AWS 는 IAM 권한을 업데이트할 필요가 없도록이 관리형 정책에 추가합니다. + 테스트 사례를 실행하기 전에 사용자 환경(예: 장치 연결 및 인터넷 연결)이 올바르게 설정되어 있는지 확인하는 검사가 도입되었습니다. + IDT의 Greengrass 종속성 확인 프로그램이 장치에서 보다 유연하게 libc를 확인할 수 있도록 개선되었습니다.   **v AWS IoT Greengrass 1.10, v1.9.x 및 v1.8.x용 IDT v2.2.0** 릴리스 정보: + AWS IoT Greengrass v1.10에 대한 지원이 추가되었습니다. + [Greengrass Docker 애플리케이션 배포](docker-app-connector.md) 커넥터에 대한 지원이 추가되었습니다. + AWS IoT Greengrass [스트림 관리자](stream-manager.md)에 대한 지원이 추가되었습니다. + 중국(베이징) 리전 AWS IoT Greengrass 에서에 대한 지원이 추가되었습니다.   **v1.9.x, AWS IoT Greengrass v1.8.x 및 v1.7.x용 IDT v2.1.0** 릴리스 정보: + AWS IoT Greengrass v1.9.4에 대한 지원이 추가되었습니다. + Linux-ARMv6l 장치에 대한 지원을 추가했습니다.   ** AWS IoT Greengrass v1.9.3, v1.9.2, v.1.9.1, v1.9.0, v1.8.4, v1.8.3 및 v1.8.2용 IDT v2.0.0** 릴리스 정보: + 테스트 대상 장치에서 Python 종속성을 제거했습니다. + 테스트 제품군 실행 시간을 50% 이상 단축하여 검증 프로세스가 빨라졌습니다. + 실행 파일 크기를 50% 축소하여 다운로드 및 설치가 빨라졌습니다. + 모든 테스트 사례에서 [제한 시간 승수 지원](idt-troubleshooting.md#test-timeout)을 개선했습니다. + 오류를 보다 신속하게 해결할 수 있도록 진단 후 메시지를 개선했습니다. + IDT를 실행하는 데 필요한 권한 정책 템플릿을 업데이트했습니다. + AWS IoT Greengrass v1.9.3에 대한 지원이 추가되었습니다.   **v1. AWS IoT Greengrass 9.2, v1.9.1, v1.9.0, v1.8.3 및 v1.8.2용 IDT v1.3.3** 릴리스 정보: + Greengrass v1.9.2 및 v1.8.3에 대한 지원을 추가했습니다. + Greengrass OpenWrt에 대한 지원을 추가했습니다. + SSH 사용자 이름 및 암호 장치 로그인을 추가했습니다. + OpenWRT-ARMv7l 플랫폼에 대한 기본 테스트 버그 수정을 추가했습니다.   **v1.8.1용 IDT AWS IoT Greengrass v1.2** 릴리스 정보: + 제한 시간 문제를 처리하고 해결하기 위해 구성 가능한 제한 시간 승수를 추가했습니다(예: 낮은 대역폭 연결).   **v1.8.0용 IDT AWS IoT Greengrass v1.1** 릴리스 정보: + AWS IoT Greengrass 하드웨어 보안 통합(HSI)에 대한 지원이 추가되었습니다. + AWS IoT Greengrass 컨테이너 및 컨테이너 없음에 대한 지원이 추가되었습니다. + 자동 AWS IoT Greengrass 서비스 역할 생성을 추가했습니다. + 테스트 리소스 정리를 개선했습니다 + 텍스트 실행 요약 보고서를 추가했습니다.   **v1.7.1용 IDT AWS IoT Greengrass v1.1** 릴리스 정보: + AWS IoT Greengrass 하드웨어 보안 통합(HSI)에 대한 지원이 추가되었습니다. + AWS IoT Greengrass 컨테이너 및 컨테이너 없음에 대한 지원이 추가되었습니다. + 자동 AWS IoT Greengrass 서비스 역할 생성을 추가했습니다. + 테스트 리소스 정리를 개선했습니다 + 텍스트 실행 요약 보고서를 추가했습니다.   **v1.6.1용 IDT AWS IoT Greengrass v1.0** 릴리스 정보: + 향후 AWS IoT Greengrass 버전 호환성을 위해 OTA 테스트 버그 수정이 추가되었습니다. v1.6.1용 IDT AWS IoT Greengrass v1.0을 사용하는 경우 [Greengrass 서비스 역할을](service-role.md) 생성해야 합니다. 이후 버전에서는 IDT가 서비스 역할을 자동으로 생성합니다. # IDT를 사용하여 AWS IoT Greengrass 검증 제품군 실행 용 AWS IoT 디바이스 테스터(IDT) AWS IoT Greengrass 를 사용하여 AWS IoT Greengrass 코어 소프트웨어가 하드웨어에서 실행되고와 통신할 수 있는지 확인할 수 있습니다 AWS 클라우드. 또한 이 IDT는 AWS IoT Core와의 엔드 투 엔드 테스트를 수행합니다. 예를 들어 장치가 MQTT 메시지를 송수신하고 올바르게 처리할 수 있는지 확인합니다. AWS IoT Greengrass Version 1 가 [유지 관리 모드로](https://docs.aws.amazon.com/greengrass/v1/developerguide/maintenance-policy.html) 전환되었으므로 용 IDT는 더 이상 서명된 검증 보고서를 생성 AWS IoT Greengrass V1 하지 않습니다. AWS Partner Device Catalog에 하드웨어를 추가하려면 AWS IoT Greengrass V2 검증 제품군을 실행하여 제출할 수 있는 테스트 보고서를 생성합니다 AWS IoT. 자세한 내용은 [AWS 장치 검증 프로그램](https://aws.amazon.com/partners/dqp/) 및 [AWS IoT Greengrass V2지원 IDT 버전](https://docs.aws.amazon.com/greengrass/v2/developerguide/dev-test-versions.html)을 참조하십시오. 디바이스 테스트 외에도 용 IDT는 검증 프로세스를 용이하게 AWS 계정 하기 위해에 리소스(예: AWS IoT 사물, AWS IoT Greengrass 그룹, Lambda 함수 등)를 AWS IoT Greengrass 생성합니다. 이러한 리소스를 생성하기 위해 용 IDT AWS IoT Greengrass 는 `config.json` 파일에 구성된 AWS 자격 증명을 사용하여 사용자를 대신하여 API를 호출합니다. 이러한 리소스는 테스트 중 다양한 시점에서 프로비저닝됩니다. 용 IDT AWS IoT Greengrass 를 사용하여 AWS IoT Greengrass 검증 제품군을 실행하는 경우 IDT는 다음 단계를 수행합니다. 1. 장치 및 자격 증명 구성을 로드하고 검증합니다. 1. 필수 로컬 및 클라우드 리소스를 사용하여 선택한 테스트를 수행합니다. 1. 로컬 및 클라우드 리소스를 정리합니다. 1. 장치에서 검증에 필요한 테스트를 통과했는지를 나타내는 테스트 보고서를 생성합니다. ## 테스트 제품군 버전 용 IDT는 테스트를 테스트 제품군 및 테스트 그룹으로 AWS IoT Greengrass 구성합니다. + 테스트 제품군은 장치가 AWS IoT Greengrass의 특정 버전에서 작동하는지 확인하는 데 사용되는 테스트 그룹 집합입니다. + 테스트 그룹은 Greengrass 그룹 배포 및 MQTT 메시징 같은 특정 기능과 관련된 개별 테스트 집합입니다. IDT v3.0.0부터는 `major.minor.patch` 형식(예: `GGQ_1.0.0`)을 사용하여 테스트 제품군의 버전이 관리됩니다. IDT를 다운로드하면 패키지에 최신 테스트 제품군 버전이 포함됩니다. **중요** IDT는 장치 검증을 위해 세 가지 최신 테스트 제품군 버전을 지원합니다. 자세한 내용은 [용 AWS IoT 디바이스 테스터에 대한 지원 정책 AWS IoT Greengrass V1](idt-support-policy.md) 단원을 참조하십시오. 를 실행`list-supported-products`하여 현재 버전의 IDT에서 지원하는 AWS IoT Greengrass 및 테스트 제품군의 버전을 나열할 수 있습니다. 지원되지 않는 테스트 제품군 버전의 테스트는 장치 검증에 유효하지 않습니다. IDT는 지원되지 않는 버전에 대한 검증 보고서를 인쇄하지 않습니다. ### IDT 구성 설정에 대한 업데이트 새로운 테스트에서는 새로운 IDT 구성 설정을 도입할 수 있습니다. + 설정이 선택 사항인 경우 IDT는 테스트를 계속 실행합니다. + 설정이 필요한 경우 IDT는 사용자에게 이를 알리고 실행을 중지합니다. 설정을 구성한 후 테스트 실행을 다시 시작하십시오. 구성 설정은 `/configs` 폴더에 있습니다. 자세한 내용은 [AWS IoT Greengrass 검증 제품군을 실행하도록 IDT 설정 구성](set-config.md) 단원을 참조하십시오. 업데이트된 테스트 제품군 버전이 구성 설정을 추가하는 경우 IDT는 `/configs`에 원래 구성 파일의 복사본을 만듭니다. ## 테스트 그룹 설명 ------ #### [ IDT v2.0.0 and later ] **코어 검증을 위한 필수 테스트 그룹** 이러한 테스트 그룹은 AWS IoT Greengrass 디바이스가 AWS Partner Device Catalog에 적합한지 검증하는 데 필요합니다. AWS IoT Greengrass 핵심 종속성 디바이스가 AWS IoT Greengrass 코어 소프트웨어의 모든 소프트웨어 및 하드웨어 요구 사항을 충족하는지 확인합니다. 이 테스트 그룹의 `Software Packages Dependencies` 테스트 케이스는 [Docker 컨테이너](docker-config-setup.md)에서 테스트하는 경우 적용할 수 없습니다. 배포 장치에 Lambda 함수를 배포할 수 있는지 검증합니다. MQTT Greengrass 코어와 로컬 IoT 디바이스인 클라이언트 디바이스 간의 로컬 통신을 확인하여 AWS IoT Greengrass 메시지 라우터 기능을 확인합니다. 무선(OTA) 디바이스가 AWS IoT Greengrass 코어 소프트웨어의 OTA 업데이트를 성공적으로 수행할 수 있는지 확인합니다. 이 테스트 그룹은 [Docker 컨테이너](docker-config-setup.md)에서 테스트하는 경우 적용할 수 없습니다. 버전 AWS IoT Greengrass 제공된 버전이 사용 중인 AWS IoT 디바이스 테스터 버전과 호환되는지 확인합니다. **선택적 테스트 그룹** 이러한 테스트 그룹은 선택 사항입니다. 선택적 테스트에 적합한 것으로 선택하면 디바이스 카탈로그에 추가 기능이 포함된 AWS Partner 디바이스가 나열됩니다. 컨테이너 종속성 장치가 Greengrass 코어에서 컨테이너 모드로 Lambda 함수를 실행하기 위한 모든 소프트웨어 및 하드웨어 요구 사항을 충족하는지 여부를 검증합니다. 이 테스트 그룹은 [Docker 컨테이너](docker-config-setup.md)에서 테스트하는 경우 적용할 수 없습니다. 배포 컨테이너 장치에 Lambda 함수를 배포하고 Greengrass 코어에서 컨테이너 모드로 실행할 수 있는지 검증합니다. 이 테스트 그룹은 [Docker 컨테이너](docker-config-setup.md)에서 테스트하는 경우 적용할 수 없습니다. Docker 종속성(IDT v2.2.0 이상에서 지원됨) 장치가 Greengrass Docker 애플리케이션 배포 커넥터를 사용하여 컨테이너를 실행하는 데 필요한 모든 기술 종속성을 충족하는지 검증합니다. 이 테스트 그룹은 [Docker 컨테이너](docker-config-setup.md)에서 테스트하는 경우 적용할 수 없습니다. HSI(하드웨어 보안 통합) 제공된 HSI 공유 라이브러리가 하드웨어 보안 모듈(HSM)과 인터페이스할 수 있고 필요한 PKCS\$111 API를 올바로 구현하는지 확인합니다. HSM 및 공유 라이브러리가 CSR에 서명하고 TLS 작업을 수행하며 올바른 키 길이와 퍼블릭 키 알고리즘을 제공할 수 있어야 합니다. 스트림 관리자 종속성(IDT v2.2.0 이상에서 지원됨) 디바이스가 AWS IoT Greengrass 스트림 관리자를 실행하는 데 필요한 모든 기술적 종속성을 충족하는지 확인합니다. 기계 학습 종속성(IDT v3.1.0 이상에서 지원됨) 장치가 로컬로 ML 추론을 실행하는 데 필요한 모든 기술적 종속성을 충족하는지 검증합니다. 기계 학습 추론 테스트(IDT v3.1.0 이상에서 지원됨) ML 추론이 테스트 중인 지정된 장치에서 수행될 수 있는지 검증합니다. 자세한 내용은 [선택 사항: ML 검증을 위해 장치 구성](idt-ml-qualification.md) 단원을 참조하십시오. 기계 학습 추론 컨테이너 테스트(IDT v3.1.0 이상에서 지원됨) ML 추론이 테스트 중인 지정된 장치에서 수행될 수 있는지와 Greengrass 코어에서 컨테이너 모드로 실행될 수 있는지 검증합니다. 자세한 내용은 [선택 사항: ML 검증을 위해 장치 구성](idt-ml-qualification.md) 단원을 참조하십시오. ------ #### [ IDT v1.3.3 and earlier ] **코어 검증을 위한 필수 테스트 그룹** 이러한 테스트는 AWS IoT Greengrass 디바이스가 AWS Partner Device Catalog에 적합한지 검증하는 데 필요합니다. AWS IoT Greengrass 핵심 종속성 디바이스가 AWS IoT Greengrass 코어 소프트웨어의 모든 소프트웨어 및 하드웨어 요구 사항을 충족하는지 확인합니다. 조합(장치 보안 상호 작용) Greengrass 클라우드의 그룹에서 연결 정보를 변경하여 Greengrass 코어 장치에서 장치 인증서 관리자 및 IP 감지 기능을 확인합니다. 테스트 그룹은 AWS IoT Greengrass 서버 인증서를 교체하고가 연결을 AWS IoT Greengrass 허용하는지 확인합니다. 배포(IDT v1.2 및 이전 버전에 필요) 장치에 Lambda 함수를 배포할 수 있는지 검증합니다. Device Certificate Manager(DCM) AWS IoT Greengrass 디바이스 인증서 관리자가 시작 시 서버 인증서를 생성하고 인증서가 만료에 가까워지면 교체할 수 있는지 확인합니다. IPD(IP 감지) Greengrass 코어 장치에서 IP 주소가 변경될 때 코어 연결 정보가 업데이트되는지 확인합니다. 자세한 내용은 [자동 IP 감지 활성화](gg-core.md#ip-auto-detect) 단원을 참조하십시오. 로깅 AWS IoT Greengrass 로깅 서비스가 Python으로 작성된 사용자 Lambda 함수를 사용하여 로그 파일에 쓸 수 있는지 확인합니다. MQTT 두 Lambda 함수로 라우팅되는 주제에 대한 메시지를 전송하여 AWS IoT Greengrass 메시지 라우터 기능을 확인합니다. 기본 가 네이티브(컴파일된) Lambda 함수를 실행할 AWS IoT Greengrass 수 있는지 확인합니다. 무선(OTA) 디바이스가 AWS IoT Greengrass 코어 소프트웨어의 OTA 업데이트를 성공적으로 수행할 수 있는지 확인합니다. 침투 하드 링크/소프트 링크 보호 및 [seccomp](https://www.kernel.org/doc/Documentation/prctl/seccomp_filter.txt)가 활성화되지 않은 경우 AWS IoT Greengrass 코어 소프트웨어가 시작되지 않는지 확인합니다. 이 그룹은 기타 보안 관련 기능을 확인하는 데도 사용됩니다. 섀도우 로컬 섀도우와 섀도우 클라우드의 동기화 기능을 확인합니다. 스풀러 MQTT 메시지가 기본 스풀러 구성으로 대기되었는지 확인합니다. 토큰 교환 서비스(TES) 가 코어 인증서를 유효한 AWS 자격 증명으로 교환할 AWS IoT Greengrass 수 있는지 확인합니다. 버전 AWS IoT Greengrass 제공된 버전이 사용 중인 AWS IoT 디바이스 테스터 버전과 호환되는지 확인합니다. **선택적 테스트 그룹** 이러한 테스트는 선택 사항입니다. 선택적 테스트에 적합한 것으로 선택하면 디바이스 카탈로그에 추가 기능이 포함된 AWS Partner 디바이스가 나열됩니다. 컨테이너 종속성 장치가 Lambda 함수를 컨테이너 모드로 실행하는 데 필요한 모든 종속성을 충족하는지 확인합니다. HSI(하드웨어 보안 통합) 제공된 HSI 공유 라이브러리가 하드웨어 보안 모듈(HSM)과 인터페이스할 수 있고 필요한 PKCS\$111 API를 올바로 구현하는지 확인합니다. HSM 및 공유 라이브러리가 CSR에 서명하고 TLS 작업을 수행하며 올바른 키 길이와 퍼블릭 키 알고리즘을 제공할 수 있어야 합니다. 로컬 리소스 액세스 다양한 Linux 사용자 및 그룹이 소유한 로컬 파일 및 디렉터리에 대한 액세스를 LRA APIs를 통해 컨테이너화된 Lambda 함수에 AWS IoT Greengrass 제공하여 AWS IoT Greengrass 의 로컬 리소스 액세스(LRA) 기능을 확인합니다. Lambda 함수는 로컬 리소스 액세스 구성을 기반으로 로컬 리소스에 대한 액세스를 허용하거나 거부해야 합니다. Network Lambda 함수에서 소켓 연결을 설정할 수 있는지 확인합니다. 이러한 소켓 연결은 Greengrass 코어 구성에 기반하여 허용되거나 거부되어야 합니다. ------ # AWS IoT Greengrass 검증 제품군을 실행하기 위한 사전 조건 이 섹션에서는 용 AWS IoT 디바이스 테스터(IDT)를 사용하여 AWS IoT Greengrass 검증 제품군을 실행 AWS IoT Greengrass 하기 위한 사전 조건을 설명합니다. ## 용 AWS IoT 디바이스 테스터의 최신 버전 다운로드 AWS IoT Greengrass [최신 버전](dev-test-versions.md)의 IDT를 다운로드하여 읽기 및 쓰기 권한이 있는 파일 시스템의 위치에 소프트웨어의 압축을 풉니다. **참고** 여러 사용자가 NFS 디렉터리 또는 Windows 네트워크 공유 폴더와 같은 공유 위치에서 IDT를 실행하는 것은 지원되지 않습니다. 로컬 드라이브에 IDT 패키지의 압축을 풀고 로컬 워크스테이션에서 IDT 바이너리를 실행하는 것이 좋습니다. Windows의 경우 260자의 경로 길이 제한이 있습니다. Windows를 사용하는 경우 경로를 260자 제한 아래로 유지하도록 IDT 압축을 `C:\ ` 또는 `D:\` 같은 루트 디렉터리에 풉니다. ## 생성 및 구성 AWS 계정 에 IDT를 사용하려면 먼저 다음 단계를 수행해야 AWS IoT Greengrass합니다. 1. [를 생성합니다 AWS 계정.]() 가 이미 있는 경우 2단계로 AWS 계정건너뜁니다. 1. [IDT에 대한 권한을 구성합니다.]() 이러한 계정 권한을 통해 IDT는 사용자를 대신하여 AWS 서비스에 액세스하고 AWS IoT 사물, Greengrass 그룹 및 Lambda 함수와 같은 AWS 리소스를 생성할 수 있습니다. 이러한 리소스를 생성하기 위해 용 IDT AWS IoT Greengrass 는 `config.json` 파일에 구성된 AWS 자격 증명을 사용하여 사용자를 대신하여 API를 호출합니다. 이러한 리소스는 테스트 중 다양한 시점에서 프로비저닝됩니다. **참고** 대부분의 테스트에서 [Amazon Web Services 프리 티어](https://aws.amazon.com/free)를 사용할 수 있지만 AWS 계정에 가입할 때는 신용 카드를 등록해야 합니다. 자세한 내용은 [계정에 프리 티어가 적용되는데 결제 방법이 필요한 이유는 무엇입니까?](https://aws.amazon.com/premiumsupport/knowledge-center/free-tier-payment-method/)를 참조하세요. ### 1단계: 생성 AWS 계정 이 단계에는 AWS 계정을 생성하고 구성합니다. 가 이미 있는 경우 로 AWS 계정건너뜁니다[2단계: IDT에 대한 권한 구성](#configure-idt-permissions). #### 에 가입 AWS 계정 이 없는 경우 다음 단계를 AWS 계정완료하여 생성합니다. **에 가입하려면 AWS 계정** 1. [https://portal.aws.amazon.com/billing/signup](https://portal.aws.amazon.com/billing/signup)을 엽니다. 1. 온라인 지시 사항을 따르세요. 등록 절차 중 전화 또는 텍스트 메시지를 받고 전화 키패드로 확인 코드를 입력하는 과정이 있습니다. 에 가입하면 AWS 계정*AWS 계정 루트 사용자*이 생성됩니다. 루트 사용자에게는 계정의 모든 AWS 서비스 및 리소스에 액세스할 권한이 있습니다. 보안 모범 사례는 사용자에게 관리 액세스 권한을 할당하고, 루트 사용자만 사용하여 [루트 사용자 액세스 권한이 필요한 작업](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_root-user.html#root-user-tasks)을 수행하는 것입니다. AWS 는 가입 프로세스가 완료된 후 확인 이메일을 보냅니다. 언제든지 [https://aws.amazon.com/](https://aws.amazon.com/)으로 이동하고 **내 계정**을 선택하여 현재 계정 활동을 확인하고 계정을 관리할 수 있습니다. #### 관리자 액세스 권한이 있는 사용자 생성 에 가입한 후 일상적인 작업에 루트 사용자를 사용하지 않도록 관리 사용자를 AWS 계정보호 AWS IAM Identity Center, AWS 계정 루트 사용자활성화 및 생성합니다. **보안 AWS 계정 루트 사용자** 1. **루트 사용자를** 선택하고 AWS 계정 이메일 주소를 입력하여 계정 소유자[AWS Management Console](https://console.aws.amazon.com/)로에 로그인합니다. 다음 페이지에서 비밀번호를 입력합니다. 루트 사용자를 사용하여 로그인하는 데 도움이 필요하면 *AWS Sign-In 사용 설명서*의 [루트 사용자로 로그인](https://docs.aws.amazon.com/signin/latest/userguide/console-sign-in-tutorials.html#introduction-to-root-user-sign-in-tutorial)을 참조하세요. 1. 루트 사용자의 다중 인증(MFA)을 활성화합니다. 지침은 *IAM 사용 설명서*의 [AWS 계정 루트 사용자(콘솔)에 대한 가상 MFA 디바이스 활성화를 참조하세요](https://docs.aws.amazon.com/IAM/latest/UserGuide/enable-virt-mfa-for-root.html). **관리자 액세스 권한이 있는 사용자 생성** 1. IAM Identity Center를 활성화합니다. 지침은 *AWS IAM Identity Center 사용 설명서*의 [AWS IAM Identity Center설정](https://docs.aws.amazon.com//singlesignon/latest/userguide/get-set-up-for-idc.html)을 참조하세요. 1. IAM Identity Center에서 사용자에게 관리 액세스 권한을 부여합니다. 를 자격 증명 소스 IAM Identity Center 디렉터리 로 사용하는 방법에 대한 자습서는 사용 *AWS IAM Identity Center 설명서*[의 기본값으로 사용자 액세스 구성을 IAM Identity Center 디렉터리](https://docs.aws.amazon.com//singlesignon/latest/userguide/quick-start-default-idc.html) 참조하세요. **관리 액세스 권한이 있는 사용자로 로그인** + IAM IDentity Center 사용자로 로그인하려면 IAM Identity Center 사용자를 생성할 때 이메일 주소로 전송된 로그인 URL을 사용합니다. IAM Identity Center 사용자를 사용하여 로그인[하는 데 도움이 필요하면 사용 설명서의 AWS 액세스 포털에 로그인](https://docs.aws.amazon.com/signin/latest/userguide/iam-id-center-sign-in-tutorial.html)을 참조하세요. *AWS Sign-In * **추가 사용자에게 액세스 권한 할당** 1. IAM Identity Center에서 최소 권한 적용 모범 사례를 따르는 권한 세트를 생성합니다. 지침은 *AWS IAM Identity Center 사용 설명서*의 [Create a permission set](https://docs.aws.amazon.com//singlesignon/latest/userguide/get-started-create-a-permission-set.html)를 참조하세요. 1. 사용자를 그룹에 할당하고, 그룹에 Single Sign-On 액세스 권한을 할당합니다. 지침은 *AWS IAM Identity Center 사용 설명서*의 [그룹 추가](https://docs.aws.amazon.com//singlesignon/latest/userguide/addgroups.html)를 참조하세요. ### 2단계: IDT에 대한 권한 구성 이 단계에서는 용 IDT가 테스트를 실행하고 IDT 사용 데이터를 수집하는 데 AWS IoT Greengrass 사용하는 권한을 구성합니다. AWS Management Console 또는 AWS Command Line Interface (AWS CLI)를 사용하여 IDT에 대한 IAM 정책 및 테스트 사용자를 생성한 다음 사용자에게 정책을 연결할 수 있습니다. IDT에 대한 테스트 사용자를 이미 작성한 경우 [IDT 테스트를 실행하도록 장치 구성](device-config-setup.md) 또는 [선택 사항: 용 IDT용 Docker 컨테이너 구성 AWS IoT Greengrass](docker-config-setup.md) 단계로 건너뜁니다. + [IDT에 대한 권한 구성(콘솔)](#configure-idt-permissions-console) + [IDT에 대한 권한 구성(AWS CLI)](#configure-idt-permissions-cli) **IDT에 대한 권한을 구성하려면(콘솔)** 콘솔을 사용하여 AWS IoT Greengrass용 IDT에 대한 권한을 구성하려면 다음 단계를 수행하세요. 1. [IAM 콘솔](https://console.aws.amazon.com/iam)에 로그인합니다. 1. 특정 권한으로 역할을 생성하는 권한을 부여하는 고객 관리형 정책을 만듭니다. 1. 탐색 창에서 **정책**을 선택한 후 **정책 생성**을 선택합니다. 1. **JSON** 탭에서 자리 표시자 콘텐츠를 다음 정책으로 바꿉니다. ------ #### [ 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" ] } ] } ``` ------ **중요** 다음 정책은 AWS IoT Greengrass에서 IDT에 필요한 역할을 생성하고 관리하는 권한을 부여합니다. 여기에는 다음 AWS 관리형 정책을 연결할 수 있는 권한이 포함됩니다. [AWSGreengrassResourceAccessRolePolicy](https://console.aws.amazon.com/iam/home#/policies/arn:aws:iam::aws:policy/service-role/AWSGreengrassResourceAccessRolePolicy) [GreengrassOTAUpdateArtifactAccess](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. **다음: 태그**를 선택합니다. 1. **다음: 검토**를 선택합니다. 1. **이름**에 **IDTGreengrassIAMPermissions**를 입력합니다. **Summary(요약)** 아래에서 정책에 의해 부여된 권한을 검토합니다. 1. **정책 생성**을 선택합니다. 1. IAM 사용자를 만들고 AWS IoT Greengrass용 IDT에 필요한 권한을 연결합니다. 1. IAM 사용자를 생성합니다. *IAM 사용 설명서*에서 [IAM 사용자 생성(콘솔)](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_users_create.html#id_users_create_console)의 1\$15단계를 따르세요. 1. IAM 사용자에게 권한을 연결합니다. 1. **권한 설정** 페이지에서 **기존 정책 직접 연결**을 선택합니다. 1. 이전 단계에서 만든 **IDTGreengrassIAMPermissions** 정책을 검색합니다. 확인란을 선택합니다. 1. **AWSIoTDeviceTesterForGreengrassFullAccess** 정책을 검색합니다. 확인란을 선택합니다. **참고** [AWSIoTDeviceTesterForGreengrassFullAccess](https://console.aws.amazon.com/iam/home#/policies/arn:aws:iam::aws:policy/AWSIoTDeviceTesterForGreengrassFullAccess)는 IDT가 테스트에 사용되는 AWS 리소스를 생성하고 액세스하는 데 필요한 권한을 정의하는 AWS 관리형 정책입니다. 자세한 내용은 [AWS AWS IoT 디바이스 테스터에 대한 관리형 정책](#idt-managed-policy) 단원을 참조하십시오. 1. **다음: 태그**를 선택합니다. 1. **Next: Review(다음: 검토)**를 선택하여 선택 사항의 요약을 봅니다. 1. **사용자 생성**을 선택합니다. 1. 사용자의 액세스 키(액세스 키 ID와 비밀 액세스 키)를 보려면 암호와 액세스 키 옆에 있는 **Show(표시)**를 선택합니다. 액세스 키를 저장하려면 **Download .csv(csv 다운로드)**를 선택한 후 안전한 위치에 파일을 저장합니다. 나중에 이 정보를 사용하여 AWS 자격 증명 파일을 구성합니다. 1. 다음 단계: [물리적 장치](device-config-setup.md)를 구성합니다.   **IDT에 대한 권한을 구성하려면(AWS CLI)** 다음 단계에 따라 AWS CLI 를 사용하여 IDT에 대한 권한을 구성합니다 AWS IoT Greengrass. 콘솔에서 권한을 이미 구성한 경우 [IDT 테스트를 실행하도록 장치 구성](device-config-setup.md) 또는 [선택 사항: 용 IDT용 Docker 컨테이너 구성 AWS IoT Greengrass](docker-config-setup.md) 단계로 건너뜁니다. 1. 아직 설치되지 않은 AWS CLI 경우 컴퓨터에를 설치하고 구성합니다. *AWS Command Line Interface 사용 설명서* [AWS CLI설치](https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-install.html) 단계를 따르세요. **참고** AWS CLI 는 명령줄 셸의 서비스와 상호 작용하는 데 사용할 수 있는 AWS 오픈 소스 도구입니다. 1. IDT 및 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\"]}]}' ``` **참고** Linux, macOS 또는 Unix 터미널 명령과 다른 JSON 구문을 사용하기 때문에 이 단계에는 Windows 명령 프롬프트 예제가 포함되어 있습니다. ------ 1. IAM 사용자를 만들고 AWS IoT Greengrass용 IDT에 필요한 권한을 연결합니다. 1. IAM 사용자를 생성합니다. 이 예제 설정에서 사용자의 이름은 `IDTGreengrassUser`입니다. ``` aws iam create-user --user-name IDTGreengrassUser ``` 1. 2단계에서 생성한 `IDTGreengrassIAMPermissions` 정책을 IAM 사용자에게 연결합니다. 명령의 **를의 ID로 바꿉니다 AWS 계정. ``` aws iam attach-user-policy --user-name IDTGreengrassUser --policy-arn arn:aws:iam:::policy/IDTGreengrassIAMPermissions ``` 1. `AWSIoTDeviceTesterForGreengrassFullAccess` 정책을 IAM 사용자에게 연결합니다. ``` aws iam attach-user-policy --user-name IDTGreengrassUser --policy-arn arn:aws:iam::aws:policy/AWSIoTDeviceTesterForGreengrassFullAccess ``` **참고** [AWSIoTDeviceTesterForGreengrassFullAccess](https://console.aws.amazon.com/iam/home#/policies/arn:aws:iam::aws:policy/AWSIoTDeviceTesterForGreengrassFullAccess)는 IDT가 테스트에 사용되는 AWS 리소스를 생성하고 액세스하는 데 필요한 권한을 정의하는 AWS 관리형 정책입니다. 자세한 내용은 [AWS AWS IoT 디바이스 테스터에 대한 관리형 정책](#idt-managed-policy) 단원을 참조하십시오. 1. 사용자에 대한 비밀 액세스 키를 만듭니다. ``` aws iam create-access-key --user-name IDTGreengrassUser ``` 출력을 안전한 위치에 저장합니다. 나중에이 정보를 사용하여 AWS 자격 증명 파일을 구성합니다. 1. 다음 단계: [물리적 장치](device-config-setup.md)를 구성합니다. ## AWS AWS IoT 디바이스 테스터에 대한 관리형 정책 [AWSIoTDeviceTesterForGreengrassFullAccess](https://console.aws.amazon.com/iam/home#/policies/arn:aws:iam::aws:policy/AWSIoTDeviceTesterForGreengrassFullAccess) 관리형 정책을 통해 IDT는 작업을 실행하고 사용량 지표를 수집할 수 있습니다. 이 정책은 다음 IDT 권한을 부여합니다. + `iot-device-tester:CheckVersion`. 세트 AWS IoT Greengrass, 테스트 제품군 및 IDT 버전이 호환되는지 확인합니다. + `iot-device-tester:DownloadTestSuite`. 테스트 제품군을 다운로드합니다. + `iot-device-tester:LatestIdt`. 다운로드할 수 있는 최신 IDT 버전에 대한 정보를 가져옵니다. + `iot-device-tester:SendMetrics`. IDT가 테스트에 대해 수집하는 사용량 데이터를 게시합니다. + `iot-device-tester:SupportedVersion`. IDT에서 지원하는 AWS IoT Greengrass 및 테스트 제품군 버전의 목록을 가져옵니다. 이 정보는 명령줄 창에 표시됩니다. # IDT 테스트를 실행하도록 장치 구성 디바이스를 구성하려면 AWS IoT Greengrass 종속성을 설치하고, AWS IoT Greengrass 코어 소프트웨어를 구성하고, 디바이스에 액세스하도록 호스트 컴퓨터를 구성하고, 디바이스에 대한 사용자 권한을 구성해야 합니다. ## 테스트 중인 디바이스에 대한 AWS IoT Greengrass 종속성 확인 용 IDT AWS IoT Greengrass 가 디바이스를 테스트하려면 먼저 [시작하기 AWS IoT Greengrass](https://docs.aws.amazon.com/greengrass/latest/developerguide/gg-gs.html)에 설명된 대로 디바이스를 설정해야 합니다. 지원되는 플랫폼에 대한 자세한 내용은 [지원되는 플랫폼](https://docs.aws.amazon.com/greengrass/latest/developerguide/what-is-gg.html#gg-platforms)을 참조하십시오. ## AWS IoT Greengrass 소프트웨어 구성 용 IDT는 디바이스의 특정 버전과의 호환성을 AWS IoT Greengrass 테스트합니다 AWS IoT Greengrass. IDT는 디바이스 AWS IoT Greengrass 에서 테스트할 수 있는 두 가지 옵션을 제공합니다. + [AWS IoT Greengrass 코어 소프트웨어](what-is-gg.md#gg-core-download-tab)의 한 버전을 다운로드하여 사용합니다. IDT에서 자동으로 해당 소프트웨어를 설치합니다. + 디바이스에 이미 설치된 AWS IoT Greengrass 코어 소프트웨어 버전을 사용합니다. **참고** 의 각 버전 AWS IoT Greengrass 에는 해당 IDT 버전이 있습니다. 사용 중인 버전에 해당하는 IDT 버전을 다운로드 AWS IoT Greengrass 해야 합니다. 다음 단원에서는 이러한 옵션에 대해 설명합니다. 이러한 옵션 중 하나만 수행해야 합니다. ### 옵션 1: AWS IoT Greengrass 코어 소프트웨어 다운로드 및 이를 사용하도록 AWS IoT 디바이스 테스터 구성 AWS IoT Greengrass 코어 소프트웨어 다운로드 페이지에서 [AWS IoT Greengrass 코어 소프트웨어를](what-is-gg.md#gg-core-download-tab) 다운로드할 수 있습니다. 1. 올바른 아키텍처와 Linux 배포를 찾은 다음 **Download(다운로드)**를 선택합니다. 1. tar.gz 파일을 `/products/greengrass/ggc`에 복사합니다. **참고** AWS IoT Greengrass tar.gz 파일의 이름을 변경하지 마십시오. 동일한 운영 체제 및 아키텍처에 대해 이 디렉터리에 여러 파일을 배치하지 마세요. 예를 들어 해당 디렉터리에 `greengrass-linux-armv7l-1.7.1.tar.gz` 파일과 `greengrass-linux-armv7l-1.8.1.tar.gz` 파일이 모두 있으면 테스트가 실패합니다. ### 옵션 2: AWS IoT 디바이스 테스터와 AWS IoT Greengrass 함께의 기존 설치 사용 `/configs` 폴더에 있는 `device.json` 파일에 `greengrassLocation` 속성을 추가하여 디바이스에 설치된 AWS IoT Greengrass 코어 소프트웨어를 테스트하도록 IDT를 구성합니다. 예제: ``` "greengrassLocation" : "" ``` `device.json` 파일에 대한 자세한 내용은 [device.json 구성](set-config.md#device-config)를 참조하세요. Linux 디바이스에서 AWS IoT Greengrass 코어 소프트웨어의 기본 위치는 입니다`/greengrass`. **참고** 디바이스에 시작되지 않은 AWS IoT Greengrass 코어 소프트웨어가 설치되어 있어야 합니다. 장치에 `ggc_user` 사용자 및 `ggc_group`을 추가했는지 확인합니다. 자세한 내용은 [AWS IoT Greengrass에 대한 환경 설정](https://docs.aws.amazon.com/greengrass/latest/developerguide/module1.html)을 참조하십시오. ## 테스트 대상 장치에 액세스하도록 호스트 컴퓨터 구성 IDT는 호스트 컴퓨터에서 실행되며, SSH를 사용하여 장치에 연결할 수 있어야 합니다. IDT가 테스트 대상 장치에 대한 SSH 액세스를 획득하도록 허용하는 옵션은 두 가지가 있습니다. 1. 여기에서 설명하는 지침에 따라 SSH 키 페어를 생성하고 해당 키가 암호를 지정하지 않고 테스트 대상 장치에 로그인할 수 있도록 권한을 부여합니다. 1. `device.json` 파일의 각 장치에 사용자 이름 및 암호를 제공합니다. 자세한 내용은 [device.json 구성](set-config.md#device-config) 단원을 참조하십시오. 임의의 SSL 구현을 사용하여 SSH 키를 생성할 수 있습니다. 다음 지침은 [SSH-KEYGEN](https://www.ssh.com/ssh/keygen/) 또는 [ PuTTYgen](https://www.ssh.com/ssh/putty/windows/puttygen)(Windows)을 사용하는 방법을 보여줍니다. 다른 SSL 구현을 사용 중인 경우 해당 구현에 대한 설명서를 참조하십시오. IDT는 SSH 키를 사용하여 테스트 대상 장치에 인증합니다. **SSH-KEYGEN을 사용하여 SSH 키를 생성하려면** 1. SSH 키를 생성합니다, 공개 SSH **ssh-keygen** 명령을 사용하여 SSH 키 페어를 생성할 수 있습니다. 이미 호스트 컴퓨터에 SSH 키 페어가 있는 경우 IDT 전용 SSH 키 페어를 생성하는 것이 가장 좋습니다. 그러면 테스트를 완료한 후 호스트 컴퓨터가 더 이상 암호 없이 장치에 연결할 수 없습니다. 또한 원하는 사용자만 원격 장치에 액세스할 수 있도록 제한할 수 있습니다. **참고** Windows에는 SSH 클라이언트가 설치되어 있지 않습니다. Windows에 SSH 클라이언트 설치에 대한 내용은 [SSH 클라이언트 소프트웨어](https://www.ssh.com/ssh/#sec-Download-client-software) 다운로드를 참조하십시오. **ssh-keygen** 명령은 키 페어 저장 이름과 경로를 입력하라는 메시지를 표시합니다. 기본적으로 키 페어 파일은 `id_rsa`(프라이빗 키) 및 `id_rsa.pub`(퍼블릭 키)로 이름 지정됩니다. macOS와 Linux에서 이러한 파일의 기본 위치는 `~/.ssh/`입니다. Windows에서 기본 위치는 `C:\Users\\.ssh`입니다. 메시지가 표시되면 SSH 키를 보호하기 위한 키 구문을 입력합니다. 자세한 내용은 [새 SSH 키 생성](https://www.ssh.com/ssh/keygen/)을 참조하십시오. 1. 테스트 대상 장치에 권한 있는 SSH 키를 추가합니다, IDT는 SSH 프라이빗 키를 사용하여 테스트 대상 장치에 로그인해야 합니다. 테스트 대상 장치에 로그인하도록 SSH 프라이빗 키를 승인하려면 호스트 컴퓨터의 **ssh-copy-id** 명령을 사용합니다. 이 명령은 테스트 대상 장치에서 `~/.ssh/authorized_keys` 파일에 퍼블릭 키를 추가합니다. 예제: **\$1 ssh-copy-id **@**** 여기서 *remote-ssh-user*는 테스트 대상 장치에 로그인하는 데 사용하는 사용자 이름이고, *remote-device-ip*는 테스트를 실행할 테스트 대상 장치의 IP 주소입니다. 예제: **ssh-copy-id pi@192.168.1.5** 메시지가 표시되면 **ssh-copy-id** 명령에서 지정한 사용자 이름에 대한 암호를 입력합니다. **ssh-copy-id**는 퍼블릭 키가 `id_rsa.pub`로 이름 지정되고 기본 위치에 저장된다고 가정합니다(macOS와 Linux에서는 `~/.ssh/`, Windows에서는 `C:\Users\\.ssh`) 퍼블릭 키의 이름을 다르게 지정하거나 다른 위치에 저장한 경우, **ssh-copy-id**에 **-i** 옵션을 사용하여 SSH 퍼블릭 키의 정규화된 경로를 지정해야 합니다(예: **ssh-copy-id -i \$1/my/path/myKey.pub**). SSH 키 생성 및 퍼블릭 키 복사에 대한 자세한 내용은 [SSH-COPY-ID](https://www.ssh.com/ssh/copy-id)를 참조하십시오. **PuTTYgen을 사용하여 SSH 키를 생성하려면(Windows만 해당)** 1. 테스트 대상 장치에 OpenSSH 서버 및 클라이언트가 설치되어 있는지 확인합니다. 자세한 내용은 [OpenSSH](https://www.openssh.com/)를 참조하십시오. 1. 테스트 대상 장치에 [PuTTYgen](https://www.puttygen.com/)을 설치합니다. 1. PuTTYgen을 엽니다. 1. **생성**을 선택하고 마우스를 상자 안으로 이동하여 프라이빗 키를 생성합니다. 1. **Conversions(변환)** 메뉴에서 **Export OpenSSH key(OpenSSH 키 내보내기)**를 선택하고 프라이빗 키를 `.pem` 파일 확장명으로 저장합니다. 1. 테스트 대상 장치에서 `/home//.ssh/authorized_keys` 파일에 퍼블릭 키를 추가합니다. 1. PuTTYgen 창에서 퍼블릭 키 텍스트를 복사합니다. 1. PuTTY를 사용하여 테스트 대상 장치에서 세션을 생성합니다. 1. 명령 프롬프트 또는 Windows Powershell 창에서 다음 명령을 실행합니다. **C:/**/putty.exe -ssh **@**** 1. 메시지가 표시되면 장치의 암호를 입력합니다. 1. vi 또는 다른 텍스트 편집기를 사용하여 테스트 대상 장치의 `/home//.ssh/authorized_keys` 파일에 퍼블릭 키를 추가합니다. 1. 각 테스트 대상 장치에 대해 사용자 이름, IP 주소, 방금 호스트 컴퓨터에 저장한 프라이빗 키 파일의 경로로 `device.json` 파일을 업데이트합니다. 자세한 내용은 [device.json 구성](set-config.md#device-config) 단원을 참조하십시오. 프라이빗 키에 전체 경로 및 파일 이름을 제공하고 슬래시('/')를 사용해야 합니다. 예를 들어 Windows 경로 `C:\DT\privatekey.pem`의 경우 `device.json` 파일에 `C:/DT/privatekey.pem`을 사용합니다. ## 장치에서 사용자 권한 구성 IDT는 테스트 대상 장치에서 다양한 디렉터리와 파일에 대해 작업을 수행합니다. 이러한 작업 중 일부는 승격된 권한(**sudo** 사용)이 필요합니다. 이러한 작업을 자동화하려면 IDT for가 암호를 입력하라는 메시지 없이 sudo로 명령을 실행할 수 있어야 AWS IoT Greengrass 합니다. 암호 입력 메시지 없이 sudo 액세스를 허용하려면 테스트 대상 장치에서 다음 단계를 수행합니다. **참고** `username`은 IDT가 테스트 대상 장치에 액세스하는 데 사용하는 SSH 사용자를 나타냅니다. **sudo 그룹에 사용자를 추가하려면** 1. 테스트 대상 장치에서 `sudo usermod -aG sudo `을 실행합니다. 1. 변경 사항을 적용하려면 로그아웃했다가 다시 로그인하십시오. 1. 사용자 이름이 성공적으로 추가되었는지 확인하려면 **sudo echo test**를 실행합니다. 암호 입력 메시지가 표시되지 않으면 사용자가 제대로 구성된 것입니다. 1. `/etc/sudoers` 파일을 열고 파일 끝에 다음 줄을 추가합니다. ` ALL=(ALL) NOPASSWD: ALL` ## 선택적 기능을 테스트하도록 장치 구성 다음 주제에서는 선택적 기능에 대한 IDT 테스트를 실행하도록 장치를 구성하는 방법을 설명합니다. 이러한 기능을 테스트하려는 경우에만 다음 구성 단계를 수행하세요. 그렇지 않은 경우 [AWS IoT Greengrass 검증 제품군을 실행하도록 IDT 설정 구성](set-config.md)를 계속 진행합니다. **Topics** + [테스트 중인 디바이스에 대한 AWS IoT Greengrass 종속성 확인](#install-gg-dependencies) + [AWS IoT Greengrass 소프트웨어 구성](#config-gg) + [테스트 대상 장치에 액세스하도록 호스트 컴퓨터 구성](#configure-host) + [장치에서 사용자 권한 구성](#root-access) + [선택적 기능을 테스트하도록 장치 구성](#optional-feature-config) + [선택 사항: 용 IDT용 Docker 컨테이너 구성 AWS IoT Greengrass](docker-config-setup.md) + [선택 사항: ML 검증을 위해 장치 구성](idt-ml-qualification.md) # 선택 사항: 용 IDT용 Docker 컨테이너 구성 AWS IoT Greengrass AWS IoT Greengrass 는 Docker 컨테이너에서 AWS IoT Greengrass 코어 소프트웨어를 더 쉽게 실행할 수 있도록 Docker 이미지와 Dockerfile을 제공합니다. AWS IoT Greengrass 컨테이너를 설정한 후 IDT 테스트를 실행할 수 있습니다. 현재 AWS IoT Greengrass에서 IDT를 실행하는 데는 x86\$164 도커 아키텍처만 지원됩니다. 이 기능을 사용하려면 IDT v2.3.0 이상이 필요합니다. IDT 테스트를 실행하도록 Docker 컨테이너를 설정하는 프로세스는에서 제공하는 Docker 이미지 또는 Dockerfile을 사용하는지 여부에 따라 달라집니다 AWS IoT Greengrass. + [도커 이미지 사용](#docker-config-setup-docker-image). Docker 이미지에는 AWS IoT Greengrass 코어 소프트웨어 및 종속성이 설치되어 있습니다. + [도커 파일 사용](#docker-config-setup-dockerfile). Dockerfile에는 사용자 지정 AWS IoT Greengrass 컨테이너 이미지를 빌드하는 데 사용할 수 있는 소스 코드가 포함되어 있습니다. 다른 플랫폼 아키텍처에서 실행하거나 이미지 크기를 줄이기 위해 이미지를 수정할 수 있습니다. **참고** AWS IoT Greengrass 는 AWS IoT Greengrass 코어 소프트웨어 버전 1.11.1에 대한 Dockerfiles 또는 Docker 이미지를 제공하지 않습니다. 자체 사용자 지정 컨테이너 이미지에서 IDT 테스트를 실행하려면 이미지에에서 제공하는 Dockerfile에 정의된 종속성이 포함되어야 합니다 AWS IoT Greengrass. Docker 컨테이너 AWS IoT Greengrass 에서를 실행할 때는 다음 기능을 사용할 수 없습니다. + [Greengrass 컨테이너](connectors.md) 모드에서 실행되는 **커넥터** Docker 컨테이너에서 커넥터를 실행하려면 커넥터가 **컨테이너 없음** 모드로 실행되어야 합니다. **컨테이너 없음** 모드를 지원하는 커넥터를 찾으려면 [AWS에서 제공한 Greengrass 커넥터](connectors-list.md) 단원을 참조하십시오. 이러한 커넥터 중 일부에는 **컨테이너 없음**으로 설정해야 하는 격리 모드 파라미터가 있습니다. + [로컬 장치 및 볼륨 리소스](access-local-resources.md). Docker 컨테이너에서 실행되는 사용자 정의 Lambda 함수는 코어의 장치 및 볼륨에 직접 액세스해야 합니다. ## 에서 제공하는 Docker 이미지 구성 AWS IoT Greengrass 다음 단계에 따라 IDT 테스트를 실행하도록 AWS IoT Greengrass Docker 이미지를 구성합니다. **사전 조건** 이 자습서를 시작하기 전에 다음 작업을 수행해야 합니다. + 선택한 AWS Command Line Interface (AWS CLI) 버전에 따라 호스트 컴퓨터에 다음 소프트웨어 및 버전을 설치해야 합니다. ------ #### [ AWS CLI version 2 ] + [Docker](https://docs.docker.com/install/), 버전 18.09 이상. 이전 버전도 작동할 수 있지만 18.09 이상을 사용하는 것이 좋습니다. + AWS CLI 버전 2.0.0 이상. + AWS CLI 버전 2를 설치하려면 [AWS CLI 버전 2 설치를 참조하세요](https://docs.aws.amazon.com/cli/latest/userguide/install-cliv2.html). + 를 구성하려면 구성을 AWS CLI참조하세요. [AWS CLI](https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-configure.html) **참고** Windows 컴퓨터에서 이후 AWS CLI 버전 2로 업그레이드하려면 [MSI 설치](https://docs.aws.amazon.com/cli/latest/userguide/install-cliv2-windows.html) 프로세스를 반복해야 합니다. ------ #### [ AWS CLI version 1 ] + [Docker](https://docs.docker.com/install/), 버전 18.09 이상. 이전 버전도 작동할 수 있지만 18.09 이상을 사용하는 것이 좋습니다. + [Python](https://www.python.org/downloads/), 버전 3.6 이상. + [pip](https://pip.pypa.io/en/stable/installing) 버전 18.1 이상 + AWS CLI 버전 1.17.10 이상 + AWS CLI 버전 1을 설치하려면 [AWS CLI 버전 1 설치를 참조하세요](https://docs.aws.amazon.com/cli/latest/userguide/install-cliv1.html). + 를 구성하려면 구성을 AWS CLI참조하세요. [AWS CLI](https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-configure.html) + AWS CLI 버전 1의 최신 버전으로 업그레이드하려면 다음 명령을 실행합니다. ``` pip install awscli --upgrade --user ``` **참고** Windows에서 AWS CLI 버전 1의 [MSI 설치를](https://docs.aws.amazon.com/cli/latest/userguide/install-windows.html#msi-on-windows) 사용하는 경우 다음 사항에 유의하세요. AWS CLI 버전 1 설치가 botocore를 설치하지 못하면 [Python 및 pip 설치를](https://docs.aws.amazon.com/cli/latest/userguide/awscli-install-windows.html#awscli-install-windows-pip) 사용해 보세요. 이후 AWS CLI 버전 1로 업그레이드하려면 MSI 설치 프로세스를 반복해야 합니다. ------ + Amazon Elastic Container Registry(Amazon ECR) 리소스에 액세스하려면 다음 권한을 부여해야 합니다. + Amazon ECR을 사용하려면 사용자가 AWS Identity and Access Management (IAM) 정책을 통해 `ecr:GetAuthorizationToken` 권한을 부여해야 레지스트리에 인증하고 Amazon ECR 리포지토리에서 이미지를 푸시하거나 가져올 수 있습니다. 자세한 내용은 *Amazon Elastic Container Registry 사용 설명서*의 [Amazon ECR 리포지토리 정책 예시](https://docs.aws.amazon.com/AmazonECR/latest/userguide/repository-policy-examples.html) 및 [One 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)를 참조하십시오.   1. 도커 이미지를 다운로드하고 컨테이너를 구성합니다. [Docker Hub](https://hub.docker.com/r/amazon/aws-iot-greengrass) 또는 [Amazon Elastic Container Registry(Amazon ECR)](https://docs.aws.amazon.com/AmazonECR/latest/userguide/what-is-ecr.html)에서 사전 작성 이미지를 다운로드하고 Windows, macOS 및 Linux(x86\$164) 플랫폼에서 이 이미지를 실행할 수 있습니다. [1단계: Amazon ECR에서 AWS IoT Greengrass 컨테이너 이미지 가져오기](run-gg-in-docker-container.md#docker-pull-image)에서 Docker 이미지를 다운로드하려면 의 모든 단계를 완료합니다. 그런 다음 이 항목으로 돌아와 구성을 계속합니다. 1. Linux 사용자만 해당: IDT를 실행하는 사용자에게 도커 명령을 실행할 권한이 있는지 확인하십시오. 자세한 내용은 도커 설명서의 [도커를 루트가 아닌 사용자로 관리](https://docs.docker.com/install/linux/linux-postinstall/#manage-docker-as-a-non-root-user)를 참조하십시오. 1. AWS IoT Greengrass 컨테이너를 실행하려면 운영 체제에 대한 명령을 사용합니다. ------ #### [ Linux ] ``` docker run --rm --init -it -d --name aws-iot-greengrass \ -p 8883:8883 \ -v : \ : ``` + **을 호스트의 커널 구성 파일 경로로 대체하고 **를 볼륨이 컨테이너에 탑재된 경로로 대체합니다. 호스트의 커널 구성 파일은 일반적으로 `/proc/config.gz` 또는 `/boot/config-`에 있습니다. `uname -r`을 실행하여 ** 값을 확인할 수 있습니다. **예:** `/boot/config-`에서 구성 파일을 탑재하려면 다음 명령을 실행합니다. ``` -v /boot/config-4.15.0-74-generic:/boot/config-4.15.0-74-generic \ ``` **예:** `proc/config.gz`에서 구성 파일을 탑재하려면 다음 명령을 실행합니다. ``` -v /proc/config.gz:/proc/config.gz \ ``` + 명령에서 **:**를 대상 이미지의 리포지토리 및 태그 이름으로 대체합니다. **예:** AWS IoT Greengrass 코어 소프트웨어의 최신 버전을 가리키는 방법 ``` 216483018798.dkr.ecr.us-west-2.amazonaws.com/aws-iot-greengrass:latest ``` AWS IoT Greengrass Docker 이미지 목록을 가져오려면 다음 명령을 실행합니다. ``` 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 \ : ``` + 명령에서 **:**를 대상 이미지의 리포지토리 및 태그 이름으로 대체합니다. **예:** AWS IoT Greengrass 코어 소프트웨어의 최신 버전을 가리키는 방법 ``` 216483018798.dkr.ecr.us-west-2.amazonaws.com/aws-iot-greengrass:latest ``` AWS IoT Greengrass Docker 이미지 목록을 가져오려면 다음 명령을 실행합니다. ``` 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 \ : ``` + 명령에서 **:**를 대상 이미지의 리포지토리 및 태그 이름으로 대체합니다. **예:** AWS IoT Greengrass 코어 소프트웨어의 최신 버전을 가리키는 방법 ``` 216483018798.dkr.ecr.us-west-2.amazonaws.com/aws-iot-greengrass:latest ``` AWS IoT Greengrass Docker 이미지 목록을 가져오려면 다음 명령을 실행합니다. ``` aws ecr list-images --region us-west-2 --registry-id 216483018798 --repository-name aws-iot-greengrass ``` ------ **중요** IDT를 사용하여 테스트할 때는 일반적인 AWS IoT Greengrass 용도로 이미지를 실행하는 데 사용되는 `--entrypoint /greengrass-entrypoint.sh \` 인수를 포함하지 마십시오. 1. 다음 단계: [자격 AWS 증명과 `device.json` 파일을 구성합니다](set-config.md). ## 에서 제공하는 dockerfile 구성 AWS IoT Greengrass 다음 단계에 따라 IDT 테스트를 실행하도록 Dockerfile에서 빌드된 AWS IoT Greengrass Docker 이미지를 구성합니다. 1. [AWS IoT Greengrass Docker 소프트웨어](what-is-gg.md#gg-docker-download)에서 도커 파일 패키지를 호스트 컴퓨터에 다운로드하고 압축을 풉니다. 1. `README.md`를 엽니다. 다음 세 단계에서는 이 파일의 섹션을 참조합니다. 1. **Prerequisites(사전 조건)** 섹션의 요구 사항을 충족하는지 확인합니다. 1. Linux 사용자만 해당: **Enable Symlink and Hardlink Protection(symlink 및 hardlink 보호 활성화)** 및 **Enable IPv4 Network Forwarding(IPv4 네트워크 전달 활성화)** 단계를 완료합니다. 1. Docker 이미지를 작성하려면 **1단계. AWS IoT Greengrass Docker 이미지를 빌드합니다**. 그런 다음 이 항목으로 돌아와 구성을 계속합니다. 1. AWS IoT Greengrass 컨테이너를 실행하려면 운영 체제에 대한 명령을 사용합니다. ------ #### [ Linux ] ``` docker run --rm --init -it -d --name aws-iot-greengrass \ -p 8883:8883 \ -v : \ : ``` + **을 호스트의 커널 구성 파일 경로로 대체하고 **를 볼륨이 컨테이너에 탑재된 경로로 대체합니다. 호스트의 커널 구성 파일은 일반적으로 `/proc/config.gz` 또는 `/boot/config-`에 있습니다. `uname -r`을 실행하여 ** 값을 확인할 수 있습니다. **예:** `/boot/config-`에서 구성 파일을 탑재하려면 다음 명령을 실행합니다. ``` -v /boot/config-4.15.0-74-generic:/boot/config-4.15.0-74-generic \ ``` **예:** `proc/config.gz`에서 구성 파일을 탑재하려면 다음 명령을 실행합니다. ``` -v /proc/config.gz:/proc/config.gz \ ``` + 명령에서 **:**를 대상 이미지의 리포지토리 및 태그 이름으로 대체합니다. **예:** AWS IoT Greengrass 코어 소프트웨어의 최신 버전을 가리키는 방법 ``` 216483018798.dkr.ecr.us-west-2.amazonaws.com/aws-iot-greengrass:latest ``` AWS IoT Greengrass Docker 이미지 목록을 가져오려면 다음 명령을 실행합니다. ``` 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 \ : ``` + 명령에서 **:**를 대상 이미지의 리포지토리 및 태그 이름으로 대체합니다. **예:** AWS IoT Greengrass 코어 소프트웨어의 최신 버전을 가리키는 방법 ``` 216483018798.dkr.ecr.us-west-2.amazonaws.com/aws-iot-greengrass:latest ``` AWS IoT Greengrass Docker 이미지 목록을 가져오려면 다음 명령을 실행합니다. ``` 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 \ : ``` + 명령에서 **:**를 대상 이미지의 리포지토리 및 태그 이름으로 대체합니다. **예:** AWS IoT Greengrass 코어 소프트웨어의 최신 버전을 가리키는 방법 ``` 216483018798.dkr.ecr.us-west-2.amazonaws.com/aws-iot-greengrass:latest ``` AWS IoT Greengrass Docker 이미지 목록을 가져오려면 다음 명령을 실행합니다. ``` aws ecr list-images --region us-west-2 --registry-id 216483018798 --repository-name aws-iot-greengrass ``` ------ **중요** IDT를 사용하여 테스트할 때는 일반적인 AWS IoT Greengrass 용도로 이미지를 실행하는 데 사용되는 `--entrypoint /greengrass-entrypoint.sh \` 인수를 포함하지 마십시오. 1. 다음 단계: [자격 AWS 증명과 `device.json` 파일을 구성합니다](set-config.md). ## 용 IDT에 대한 Docker 컨테이너 설정 문제 해결 AWS IoT Greengrass 다음 정보를 사용하여 AWS IoT Greengrass 테스트용 IDT용 Docker 컨테이너 실행 관련 문제를 해결할 수 있습니다. ### WARNING: Error loading config file:/home/user/.docker/config.json - stat /home//.docker/config.json: permission denied Linux에서 `docker` 명령을 실행할 때 이 오류가 발생하면 다음 명령을 실행합니다. 다음 명령에서 **를 IDT를 실행하는 사용자로 대체합니다. ``` sudo chown : /home//.docker -R sudo chmod g+rwx /home//.docker -R ``` # 선택 사항: ML 검증을 위해 장치 구성 용 IDT AWS IoT Greengrass 는 기계 학습(ML) 검증 테스트를 제공하여 디바이스가 클라우드 훈련 모델을 사용하여 로컬에서 ML 추론을 수행할 수 있는지 검증합니다. ML 검증 테스트를 실행하려면 먼저 [IDT 테스트를 실행하도록 장치 구성](device-config-setup.md)에 설명된 대로 장치를 구성해야 합니다. 그런 다음 이 주제의 단계를 수행하여 실행할 ML 프레임워크에 대한 종속 항목을 설치합니다. ML 검증 테스트를 실행하려면 IDT v3.1.0 이상이 필요합니다. ## ML 프레임워크 종속 항목 설치 모든 ML 프레임워크 종속 항목은 `/usr/local/lib/python3.x/site-packages` 디렉터리 아래에 설치해야 합니다. 올바른 디렉터리에 설치되도록 하려면 종속 항목을 설치할 때 `sudo` 루트 권한을 사용하는 것이 좋습니다. 가상 환경은 검증 테스트에서 지원되지 않습니다. **참고** [컨테이너화](lambda-group-config.md#lambda-containerization-considerations)(**Greengrass 컨테이너** 모드)로 실행되는 Lambda 함수를 테스트하는 경우 `/usr/local/lib/python3.x` 아래에 Python 라이브러리에 대한 심볼릭 링크를 생성하는 것은 지원되지 않습니다. 오류를 방지하려면 올바른 디렉터리 아래에 종속 항목을 설치해야 합니다. 대상 프레임워크에 대한 종속 항목을 설치하는 단계를 따르세요. + [MXNet 종속성 설치](#ml-qualification-mxnet-dependencies) + [TensorFlow 종속 항목 설치](#ml-qualification-tensorflow-dependencies) + [DLR 종속 항목 설치](#ml-qualification-dlr-dependencies)   ## Apache MXNet 종속 항목 설치 이 프레임워크에 대한 IDT 검증 테스트에는 다음과 같은 종속 항목이 있습니다. + Python 3.6 또는 Python 3.7. **참고** Python 3.6을 사용하고 있다면 Python 3.7에서 Python 3.6 바이너리로의 심볼 링크를 생성해야 합니다. 이렇게 하면 AWS IoT Greengrass에 대한 Python 요구 사항을 충족하도록 장치가 구성됩니다. 예시: ``` sudo ln -s path-to-python-3.6/python3.6 path-to-python-3.7/python3.7 ``` + Apache MXNet v1.2.1 이상. + NumPy. 버전은 MXNet 버전과 호환되어야 합니다. ### MXnet 설치 MXNet 설명서의 지침에 따라 [MXNet을 설치](https://mxnet.apache.org/get_started/?platform=linux&language=python&processor=cpu&environ=pip&)합니다. **참고** Python 2.x와 Python 3.x가 모두 장치에 설치되어 있는 경우, 종속 항목을 설치하기 위해 실행하는 명령에서 Python 3.x를 사용합니다. ### MXNet 설치 검증 다음 옵션 중 하나를 선택하여 MXNet 설치를 검증합니다. #### 옵션 1: 장치에 SSH 및 스크립트 실행 1. 장치에 SSH합니다. 1. 종속 항목이 올바르게 설치되었는지 확인하려면 다음 스크립트를 실행합니다. ``` sudo python3.7 -c "import mxnet; print(mxnet.__version__)" ``` ``` sudo python3.7 -c "import numpy; print(numpy.__version__)" ``` 출력은 버전 번호를 인쇄하고 스크립트는 오류 없이 종료되어야 합니다. #### 옵션 2: IDT 종속 항목 테스트 실행 1. `device.json`이 ML 검증에 대해 구성되어 있는지 확인합니다. 자세한 내용은 [ML 검증을 위해 device.json 구성](set-config.md#device-json-ml-qualification) 단원을 참조하십시오. 1. 프레임워크에 대한 종속 항목 테스트를 실행합니다. ``` devicetester_[linux | mac | win_x86-64] run-suite --group-id mldependencies --test-id mxnet_dependency_check ``` 테스트 요약에 `mldependencies`에 대한 `PASSED` 결과가 표시됩니다.   ## TensorFlow 종속 항목 설치 이 프레임워크에 대한 IDT 검증 테스트에는 다음과 같은 종속 항목이 있습니다. + Python 3.6 또는 Python 3.7. **참고** Python 3.6을 사용하고 있다면 Python 3.7에서 Python 3.6 바이너리로의 심볼 링크를 생성해야 합니다. 이렇게 하면 AWS IoT Greengrass에 대한 Python 요구 사항을 충족하도록 장치가 구성됩니다. 예시: ``` sudo ln -s path-to-python-3.6/python3.6 path-to-python-3.7/python3.7 ``` + TensorFlow 1.x. ### TensorFlow 설치 TensorFlow 설명서의 지침에 따라 [pip](https://www.tensorflow.org/install/pip)를 통해 또는 [소스에서](https://www.tensorflow.org/install/source) TensorFlow 1.x를 설치합니다. **참고** Python 2.x와 Python 3.x가 모두 장치에 설치되어 있는 경우, 종속 항목을 설치하기 위해 실행하는 명령에서 Python 3.x를 사용합니다. ### TensorFlow 설치 검증 다음 옵션 중 하나를 선택하여 TensorFlow 설치를 검증합니다. #### 옵션 1: 장치에 SSH 및 스크립트 실행 1. 장치에 SSH합니다. 1. 종속 항목이 올바르게 설치되었는지 확인하려면 다음 스크립트를 실행합니다. ``` sudo python3.7 -c "import tensorflow; print(tensorflow.__version__)" ``` 출력은 버전 번호를 인쇄하고 스크립트는 오류 없이 종료되어야 합니다. #### 옵션 2: IDT 종속 항목 테스트 실행 1. `device.json`이 ML 검증에 대해 구성되어 있는지 확인합니다. 자세한 내용은 [ML 검증을 위해 device.json 구성](set-config.md#device-json-ml-qualification) 단원을 참조하십시오. 1. 프레임워크에 대한 종속 항목 테스트를 실행합니다. ``` devicetester_[linux | mac | win_x86-64] run-suite --group-id mldependencies --test-id tensorflow_dependency_check ``` 테스트 요약에 `mldependencies`에 대한 `PASSED` 결과가 표시됩니다.   ## Amazon SageMaker AI Neo DLR(Deep Learning Runtime) 종속성 설치 이 프레임워크에 대한 IDT 검증 테스트에는 다음과 같은 종속 항목이 있습니다. + Python 3.6 또는 Python 3.7. **참고** Python 3.6을 사용하고 있다면 Python 3.7에서 Python 3.6 바이너리로의 심볼 링크를 생성해야 합니다. 이렇게 하면 AWS IoT Greengrass에 대한 Python 요구 사항을 충족하도록 장치가 구성됩니다. 예시: ``` sudo ln -s path-to-python-3.6/python3.6 path-to-python-3.7/python3.7 ``` + SageMaker AI Neo DLR. + numpy. DLR 테스트 종속 항목을 설치한 후에는 [모델을 컴파일](#ml-qualification-dlr-compile-model)해야 합니다. ### DLR 설치 MXNet 설명서의 지침에 따라 [Neo DLR을 설치](https://neo-ai-dlr.readthedocs.io/en/latest/install.html#building-on-linux)합니다. **참고** Python 2.x와 Python 3.x가 모두 장치에 설치되어 있는 경우, 종속 항목을 설치하기 위해 실행하는 명령에서 Python 3.x를 사용합니다. ### DLR 설치 검증 다음 옵션 중 하나를 선택하여 DLR 설치를 검증합니다. #### 옵션 1: 장치에 SSH 및 스크립트 실행 1. 장치에 SSH합니다. 1. 종속 항목이 올바르게 설치되었는지 확인하려면 다음 스크립트를 실행합니다. ``` sudo python3.7 -c "import dlr; print(dlr.__version__)" ``` ``` sudo python3.7 -c "import numpy; print(numpy.__version__)" ``` 출력은 버전 번호를 인쇄하고 스크립트는 오류 없이 종료되어야 합니다. #### 옵션 2: IDT 종속 항목 테스트 실행 1. `device.json`이 ML 검증에 대해 구성되어 있는지 확인합니다. 자세한 내용은 [ML 검증을 위해 device.json 구성](set-config.md#device-json-ml-qualification) 단원을 참조하십시오. 1. 프레임워크에 대한 종속 항목 테스트를 실행합니다. ``` devicetester_[linux | mac | win_x86-64] run-suite --group-id mldependencies --test-id dlr_dependency_check ``` 테스트 요약에 `mldependencies`에 대한 `PASSED` 결과가 표시됩니다. ## DLR 모델 컴파일 ML 검증 테스트에 DLR 모델을 사용하려면 먼저 DLR 모델을 컴파일해야 합니다. 단계에서 다음 옵션 중 하나를 선택합니다. ### 옵션 1: Amazon SageMaker AI를 사용하여 모델 컴파일 다음 단계에 따라 SageMaker AI를 사용하여 IDT에서 제공하는 ML 모델을 컴파일합니다. 이 모델은 Apache MXNet을 사용하여 사전 교육되어 있습니다. 1. 디바이스 유형이 SageMaker AI에서 지원되는지 확인합니다. 자세한 내용은 Amazon SageMaker AI API 참조의 [대상 디바이스 옵션을](https://docs.aws.amazon.com/sagemaker/latest/APIReference/API_OutputConfig.html#sagemaker-Type-OutputConfig-TargetDevice) 참조하세요. *Amazon SageMaker * 현재 SageMaker AI에서 디바이스 유형을 지원하지 않는 경우의 단계를 따릅니다[옵션 2: TVM을 사용하여 DLR 모델 컴파일](#ml-qualification-compile-dlr-option-2). **참고** SageMaker AI에서 컴파일한 모델로 DLR 테스트를 실행하는 데 4\$15분이 걸릴 수 있습니다. 이 시간 동안 IDT를 중지하지 마시기 바랍니다. 1. DLR용 컴파일되지 않은 사전 교육된 MXNet 모델이 포함된 tarball 파일을 다운로드합니다. + [dlr-noncompiled-model-1.0.tar.gz](https://docs.aws.amazon.com/greengrass/latest/developerguide/download-dlr-noncompiled-model-1.0.html) 1. tarball의 압축을 풉니다. 이 명령은 다음과 같은 디렉터리 구조를 생성합니다. ![\[resnet18 디렉터리에는 3개의 파일이 있습니다.\]](http://docs.aws.amazon.com/ko_kr/greengrass/v1/developerguide/images/idt/idt-ml-qualification-dlr-uncompiled.png) 1. `resnet18` 디렉터리에서 `synset.txt`를 이동합니다. 새 위치를 기록해 둡니다. 나중에 컴파일된 모델 디렉터리에 이 파일을 복사합니다. 1. `resnet18` 디렉터리의 내용을 압축합니다. ``` tar cvfz model.tar.gz resnet18v1-symbol.json resnet18v1-0000.params ``` 1. 압축된 파일을의 Amazon S3 버킷에 업로드 AWS 계정한 다음 [모델 컴파일(콘솔)](https://docs.aws.amazon.com/sagemaker/latest/dg/neo-job-compilation-console.html)의 단계에 따라 컴파일 작업을 생성합니다. 1. **입력 구성**에 다음 값을 사용합니다. + **데이터 입력 구성**에 `{"data": [1, 3, 224, 224]}`를 입력합니다. + **기계 학습 프레임워크**에서 `MXNet`을 선택합니다. 1. **출력 구성**에 다음 값을 사용합니다. + **S3 출력 위치**에 컴파일된 모델을 저장할 Amazon S3 버킷 또는 폴더의 경로를 입력합니다. + **대상 장치**에서 장치 유형을 선택합니다. 1. 지정한 출력 위치에서 컴파일된 모델을 다운로드한 다음 파일의 압축을 풉니다. 1. `synset.txt`를 컴파일된 모델 디렉터리에 복사합니다. 1. 컴파일된 모델 디렉터리의 이름을 `resnet18`로 변경합니다. 컴파일된 모델 디렉터리는 디렉터리 구조가 다음과 같아야 합니다. ![\[resnet18 컴파일된 모델 디렉터리에 4개의 파일이 포함되어 있습니다.\]](http://docs.aws.amazon.com/ko_kr/greengrass/v1/developerguide/images/idt/idt-ml-qualification-dlr-compiled-sm.png) ### 옵션 2: TVM을 사용하여 DLR 모델 컴파일 다음 단계에 따라 TVM을 사용하여 IDT에서 제공하는 ML 모델을 컴파일합니다. 이 모델은 Apache MXNet을 사용하여 사전 교육되어 있으므로 모델을 컴파일하는 컴퓨터나 장치에 MXNet을 설치해야 합니다. MXNet을 설치하려면 [ MXNet 설명서](https://mxnet.apache.org/get_started/?platform=linux&language=python&processor=cpu&environ=pip&)의 지침을 따르세요. **참고** 대상 장치에서 모델을 컴파일하는 것이 좋습니다. 이 방법은 선택 사항이지만 호환성을 보장하고 잠재적인 문제를 완화하는 데 도움이 될 수 있습니다.   1. DLR용 컴파일되지 않은 사전 교육된 MXNet 모델이 포함된 tarball 파일을 다운로드합니다. + [dlr-noncompiled-model-1.0.tar.gz](https://docs.aws.amazon.com/greengrass/latest/developerguide/download-dlr-noncompiled-model-1.0.html) 1. tarball의 압축을 풉니다. 이 명령은 다음과 같은 디렉터리 구조를 생성합니다. ![\[resnet18 디렉터리에는 3개의 파일이 있습니다.\]](http://docs.aws.amazon.com/ko_kr/greengrass/v1/developerguide/images/idt/idt-ml-qualification-dlr-uncompiled.png) 1. TVM 설명서의 지침에 따라 [플랫폼에 대한 소스에서 TVM을 빌드하고 설치](https://docs.tvm.ai/install/from_source.html)합니다. 1. TVM이 빌드된 후 resnet18 모델에 대한 TVM 컴파일을 실행합니다. 다음 단계는 TVM 설명서의 [ 딥 러닝 모델 컴파일을 위한 빠른 시작 자습서](https://tvm.apache.org/docs/tutorial/relay_quick_start.html#sphx-glr-tutorials-get-started-relay-quick-start-py)를 기반으로 합니다. 1. 복제된 TVM 리포지토리에서 `relay_quick_start.py` 파일을 엽니다. 1. [릴레이의 신경망을 정의](https://tvm.apache.org/docs/tutorial/relay_quick_start.html#define-neural-network-in-relay)하는 코드를 업데이트합니다. 다음 옵션 중 하나를 사용할 수 있습니다. + 옵션 1: `mxnet.gluon.model_zoo.vision.get_model`을 사용하여 릴레이 모듈 및 파라미터를 가져옵니다. ``` 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}) ``` + 옵션 2: 1단계에서 다운로드한 컴파일되지 않은 모델에서 `relay_quick_start.py` 파일과 동일한 디렉터리에 다음 파일을 복사합니다. 이러한 파일에는 릴레이 모듈 및 파라미터가 포함되어 있습니다. + `resnet18v1-symbol.json` + `resnet18v1-0000.params` 1. 다음 코드를 사용하도록 [컴파일된 모듈을 저장하고 로드](https://tvm.apache.org/docs/tutorial/relay_quick_start.html#save-and-load-compiled-module)하는 코드를 업데이트합니다. ``` 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. 모델을 빌드합니다. ``` python3 tutorials/relay_quick_start.py --build-dir ./model ``` 이 명령은 다음과 같은 파일을 생성합니다. + `deploy_graph.json` + `deploy_lib.so` + `deploy_param.params` 1. 생성된 모델 파일을 `resnet18`이라는 디렉터리에 복사합니다. 이 디렉터리는 컴파일된 모델 디렉터리입니다. 1. 컴파일된 모델 디렉터리를 호스트 컴퓨터에 복사합니다. 그런 다음 1단계에서 다운로드한 컴파일되지 않은 모델에서 `synset.txt`를 컴파일된 모델 디렉터리에 복사합니다. 컴파일된 모델 디렉터리는 디렉터리 구조가 다음과 같아야 합니다. ![\[resnet18 컴파일된 모델 디렉터리에 4개의 파일이 포함되어 있습니다.\]](http://docs.aws.amazon.com/ko_kr/greengrass/v1/developerguide/images/idt/idt-ml-qualification-dlr-compiled-tvm.png) 그런 다음 자격 [AWS 증명과 `device.json` 파일을 구성합니다](set-config.md). # AWS IoT Greengrass 검증 제품군을 실행하도록 IDT 설정 구성 테스트를 실행하기 전에 호스트 컴퓨터에서 AWS 자격 증명 및 디바이스에 대한 설정을 구성해야 합니다. ## 자격 AWS 증명 구성 ` /configs/config.json` 파일에서 IAM 사용자 보안 인증을 구성해야 합니다. 에서 생성된 AWS IoT Greengrass 사용자의 IDT에 대한 자격 증명을 사용합니다[생성 및 구성 AWS 계정](dev-tst-prereqs.md#config-aws-account-for-idt). 두 가지 방법 중 하나로 자격 증명을 지정할 수 있습니다. + 보안 인증 파일 + 환경 변수 ### AWS 자격 증명 파일을 사용하여 자격 증명 구성 IDT는 AWS CLI와 동일한 자격 증명 파일을 사용합니다. 자세한 내용은 [구성 및 자격 증명 파일](https://docs.aws.amazon.com/cli/latest/userguide/cli-config-files.html)을 참조하십시오. 자격 증명 파일의 위치는 사용하는 운영 체제에 따라 달라집니다. + macOS, Linux의 경우: `~/.aws/credentials` + Windows: `C:\Users\UserName\.aws\credentials` 다음 형식으로 자격 AWS 증명을 `credentials` 파일에 추가합니다. ``` [default] aws_access_key_id = aws_secret_access_key = ``` `credentials` 파일의 AWS 자격 증명을 사용하도록 IDT AWS IoT Greengrass 를 구성하려면 다음과 같이 `config.json` 파일을 편집합니다. ``` { "awsRegion": "us-west-2", "auth": { "method": "file", "credentials": { "profile": "default" } } } ``` **참고** `default` AWS 프로필을 사용하지 않는 경우 `config.json` 파일에서 프로필 이름을 변경해야 합니다. 자세한 내용은 [명명된 프로필](https://docs.aws.amazon.com/cli/latest/userguide/cli-configure-profiles.html)을 참조하십시오. ### 환경 변수를 사용하여 AWS 자격 증명 구성 환경 변수는 운영 체제에서 유지 관리하고 시스템 명령에서 사용하는 변수입니다. 이들은 SSH 세션을 닫으면 저장되지 않습니다. 용 IDT AWS IoT Greengrass 는 `AWS_ACCESS_KEY_ID` 및 `AWS_SECRET_ACCESS_KEY` 환경 변수를 사용하여 AWS 자격 증명을 저장할 수 있습니다. Linux, macOS 또는 Unix에서 이러한 변수를 설정하려면 **export**를 사용합니다. ``` export AWS_ACCESS_KEY_ID= export AWS_SECRET_ACCESS_KEY= ``` Windows에서 이러한 변수를 설정하려면 **set**을 사용합니다. ``` set AWS_ACCESS_KEY_ID= set AWS_SECRET_ACCESS_KEY= ``` 환경 변수를 사용하도록 IDT를 구성하려면 `config.json` 파일에서 `auth` 섹션을 편집합니다. 다음 예를 참고하세요 ``` { "awsRegion": "us-west-2", "auth": { "method": "environment" } } ``` ## device.json 구성 IDT for 에는 AWS 자격 증명 외에도 테스트가 실행되는 디바이스에 대한 정보(예: IP 주소, 로그인 정보, 운영 체제 및 CPU 아키텍처)가 AWS IoT Greengrass 필요합니다. ` /configs/device.json`에 있는 `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": "" } } } } ] } ] ``` **참고** `method`가 `pki`로 설정된 경우에만 `privKeyPath`를 지정합니다. `method`가 `password`로 설정된 경우에만 `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": "" } } ] } ] ``` ------ 여기 설명된 것처럼 값이 포함된 모든 필드는 필수입니다. `id` *디바이스 풀*이라고 하는 디바이스 모음을 고유하게 식별하는 사용자 정의 영숫자 ID입니다. 풀에 속한 디바이스의 하드웨어는 서로 동일해야 합니다. 테스트 제품군을 실행할 때 풀에 있는 디바이스는 워크로드를 병렬화하는 데 사용됩니다. 다양한 테스트를 실행하기 위해 여러 디바이스가 사용됩니다. `sku` 테스트 대상 장치를 고유하게 식별하는 영숫자 값입니다. SKU는 적격 보드를 추적하는 데 사용됩니다. AWS Partner Device Catalog에 보드를 나열하려면 여기에서 지정하는 SKU가 나열 프로세스에서 사용하는 SKU와 일치해야 합니다. `features` 장치의 지원되는 기능이 포함된 배열입니다. 모든 기능이 필요합니다. `os` 및 `arch` 지원되는 운영 체제(OS) 및 아키텍처 조합: + `linux`, `x86_64` + `linux`, `armv6l` + `linux`, `armv7l` + `linux`, `aarch64` + `ubuntu`, `x86_64` + `openwrt`, `armv7l` + `openwrt`, `aarch64` IDT를 사용하여 Docker 컨테이너에서 AWS IoT Greengrass 실행을 테스트하는 경우 x86\$164 Docker 아키텍처만 지원됩니다. `container` 장치가 Greengrass 코어에서 컨테이너 모드로 Lambda 함수를 실행하기 위한 모든 소프트웨어 및 하드웨어 요구 사항을 충족하는지 여부를 검증합니다. 유효한 값은 `yes` 또는 `no`입니다. `docker` 장치가 Greengrass Docker 애플리케이션 배포 커넥터를 사용하여 컨테이너를 실행하는 데 필요한 모든 기술 종속성을 충족하는지 검증합니다. 유효한 값은 `yes` 또는 `no`입니다. `streamManagement` 디바이스가 AWS IoT Greengrass 스트림 관리자를 실행하는 데 필요한 모든 기술적 종속성을 충족하는지 확인합니다. 유효한 값은 `yes` 또는 `no`입니다. `hsi` 제공된 HSI 공유 라이브러리가 하드웨어 보안 모듈(HSM)과 인터페이스할 수 있고 필요한 PKCS\$111 API를 올바로 구현하는지 확인합니다. HSM 및 공유 라이브러리가 CSR에 서명하고 TLS 작업을 수행하며 올바른 키 길이와 퍼블릭 키 알고리즘을 제공할 수 있어야 합니다. 유효한 값은 `yes` 또는 `no`입니다. `ml` 장치가 로컬로 ML 추론을 실행하는 데 필요한 모든 기술적 종속성을 충족하는지 검증합니다. 유효한 값은 `mxnet`, `tensorflow`, `dlr`, `no`(예: `mxnet`, `mxnet,tensorflow`, `mxnet,tensorflow,dlr`, `no`)의 모든 조합일 수 있습니다. `mlLambdaContainerizationMode` Greengrass 장치가 로컬로 ML 추론을 실행하는 데 필요한 모든 기술적 종속성을 충족하는지 검증합니다. 유효한 값은 `container`, `process`, 또는 `both`의 값입니다. `processor` 장치가 지정된 프로세서 유형에 대한 모든 하드웨어 요구 사항을 충족하는지 확인합니다. 유효한 값은 `cpu` 또는 `gpu`입니다. `container`, `docker`, `streamManager`, `hsi`, `ml` 기능을 사용하지 않으려면 해당하는 `value`을(를) `no`(으)로 설정할 수 있습니다. Docker는 `streamManagement` 및 `ml`에 대한 기능 검증만 지원합니다. `machineLearning` 선택 사항. ML 검증 테스트를 위한 구성 정보입니다. 자세한 내용은 [ML 검증을 위해 device.json 구성](#device-json-ml-qualification) 단원을 참조하십시오. `hsm` 선택 사항. AWS IoT Greengrass 하드웨어 보안 모듈(HSM)을 사용하여 테스트하기 위한 구성 정보입니다. 그렇지 않으면 `hsm` 속성을 생략해야 합니다. 자세한 내용은 [하드웨어 보안 통합](hardware-security.md) 단원을 참조하십시오. 이 속성은 `connectivity.protocol`이 `ssh`로 설정된 경우에만 적용됩니다. `hsm.p11Provider` PKCS\$111 구현의 libdl 로드 가능 라이브러리에 대한 절대 경로입니다. `hsm.slotLabel` 하드웨어 모듈을 식별하는 데 사용되는 슬롯 레이블입니다. `hsm.slotUserPin` 모듈에 대한 AWS IoT Greengrass 코어를 인증하는 데 사용되는 사용자 PIN입니다. `hsm.privateKeyLabel` 하드웨어 모듈에서 키를 식별하는 데 사용되는 레이블입니다. `hsm.openSSLEngine` OpenSSL에서 PKCS\$111을 지원할 수 있게 해주는 OpenSSL 엔진 `.so` 파일의 절대 경로입니다. AWS IoT Greengrass OTA 업데이트 에이전트가 사용합니다. `devices.id` 테스트 대상 디바이스의 고유한 사용자 정의 식별자입니다. `connectivity.protocol` 이러한 장치와 통신하는 데 사용되는 통신 프로토콜입니다. 현재 지원되는 값은 `ssh`(물리적 장치의 경우) 및 `docker`(도커 컨테이너의 경우)입니다. `connectivity.ip` 테스트 대상 장치의 IP 입니다. 이 속성은 `connectivity.protocol`이 `ssh`로 설정된 경우에만 적용됩니다. `connectivity.containerId` 테스트 대상 Docker 컨테이너의 컨테이너 ID 또는 이름입니다. 이 속성은 `connectivity.protocol`이 `docker`로 설정된 경우에만 적용됩니다. `connectivity.auth` 연결에 대한 인증 정보입니다. 이 속성은 `connectivity.protocol`이 `ssh`로 설정된 경우에만 적용됩니다. `connectivity.auth.method` 지정된 연결 프로토콜을 통해 디바이스에 액세스하는 데 사용되는 인증 방법입니다. 지원되는 값은 다음과 같습니다. + `pki` + `password` `connectivity.auth.credentials` 인증에 사용되는 자격 증명입니다. `connectivity.auth.credentials.password` 테스트 대상 디바이스에 로그인하기 위해 사용하는 암호입니다. 이 값은 `connectivity.auth.method`가 `password`로 설정된 경우에만 적용됩니다. `connectivity.auth.credentials.privKeyPath` 테스트 대상 디바이스에 로그인하는 데 사용하는 프라이빗 키의 전체 경로입니다. 이 값은 `connectivity.auth.method`가 `pki`로 설정된 경우에만 적용됩니다. `connectivity.auth.credentials.user` 테스트 대상 장치에 로그인하기 위한 사용자 이름입니다. `connectivity.auth.credentials.privKeyPath` 테스트 대상 장치에 로그인하는 데 사용하는 프라이빗 키의 전체 경로입니다. `connectivity.port` 선택 사항. SSH 연결하는 데 사용하는 포트 번호입니다. 기본값은 22입니다. 이 속성은 `connectivity.protocol`이 `ssh`로 설정된 경우에만 적용됩니다. `greengrassLocation` 디바이스에서 AWS IoT Greengrass 코어 소프트웨어의 위치입니다. 물리적 디바이스의 경우이 값은의 기존 설치를 사용하는 경우에만 사용됩니다 AWS IoT Greengrass. 이 속성을 사용하여 장치에 설치된 AWS IoT Greengrass 코어 소프트웨어 버전을 사용하도록 IDT에 알립니다. 에서 제공하는 Docker 이미지 또는 Dockerfile의 Docker 컨테이너에서 테스트를 실행할 때이 값을 로 AWS IoT Greengrass설정합니다`/greengrass`. `kernelConfigLocation` 선택 사항. 커널 구성 파일의 경로입니다. AWS IoT 디바이스 테스터는이 파일을 사용하여 디바이스에 필요한 커널 기능이 활성화되어 있는지 확인합니다. 지정하지 않으면 IDT는 다음 경로를 사용하여 커널 구성 파일을 검색합니다. `/proc/config.gz` 및 `/boot/config-`. AWS IoT 장치 테스터는 검색된 첫 번째 경로를 사용합니다. ## ML 검증을 위해 device.json 구성 이 단원에서는 ML 검증에 적용되는 장치 구성 파일의 선택적 속성에 대해 설명합니다. ML 검증에 대한 테스트를 실행하려면 사용 사례에 적용되는 속성을 정의해야 합니다. `device-ml.json` 템플릿을 사용하여 장치의 구성 설정을 정의할 수 있습니다. 이 템플릿에는 선택적 ML 속성이 포함되어 있습니다. 또한 `device.json`을 사용하고 ML 검증 속성을 추가할 수 있습니다. 이러한 파일은 `/configs`에 있으며 ML 검증 속성을 포함합니다. `device-ml.json`을 사용하는 경우 IDT 테스트를 실행하기 전에 파일 이름을 `device.json`으로 변경해야 합니다. ML 검증에 적용되지 않는 장치 구성 속성에 대한 자세한 내용은 [device.json 구성](#device-config) 단원을 참조하십시오.   `features` 배열의 `ml` 보드에서 지원하는 ML 프레임워크입니다. 이 속성에는 IDT v3.1.0 이상이 필요합니다. + 보드에서 하나의 프레임워크만 지원하는 경우 프레임워크를 지정하세요. 예제: ``` { "name": "ml", "value": "mxnet" } ``` + 보드에서 여러 프레임워크를 지원하는 경우 프레임워크를 쉼표로 구분된 목록으로 지정하세요. 예제: ``` { "name": "ml", "value": "mxnet,tensorflow" } ``` `features` 배열의 `mlLambdaContainerizationMode` 테스트하는 데 사용할 [컨테이너화 모드](lambda-group-config.md#lambda-containerization-considerations)입니다. 이 속성에는 IDT v3.1.0 이상이 필요합니다. + 컨테이너화되지 않은 Lambda 함수로 ML 추론 코드를 실행하려면 `process`를 선택합니다. 이 옵션에는 AWS IoT Greengrass v1.10.x 이상이 필요합니다. + 컨테이너화된 Lambda 함수로 ML 추론 코드를 실행하려면 `container`를 선택합니다. + 두 모드로 ML 추론 코드를 실행하려면 `both`를 선택합니다. 이 옵션에는 AWS IoT Greengrass v1.10.x 이상이 필요합니다. `features` 배열의 `processor` 보드에서 지원하는 하드웨어 액셀러레이터를 나타냅니다. 이 속성에는 IDT v3.1.0 이상이 필요합니다. + 보드에서 CPU를 프로세서로 사용하는 경우 `cpu`를 선택합니다. + 보드에서 GPU를 프로세서로 사용하는 경우 `gpu`를 선택합니다. `machineLearning` 선택 사항. ML 검증 테스트를 위한 구성 정보입니다. 이 속성에는 IDT v3.1.0 이상이 필요합니다. `dlrModelPath` `dlr` 프레임워크를 사용하는 데 필요합니다. DLR 컴파일된 모델 디렉터리의 절대 경로로, 이름을 `resnet18`로 지정해야 합니다. 자세한 내용은 [DLR 모델 컴파일](idt-ml-qualification.md#ml-qualification-dlr-compile-model) 단원을 참조하십시오. `/Users//Downloads/resnet18`은 macOS의 경로 예입니다. `environmentVariables` 설정을 ML 추론 테스트에 동적으로 전달할 수 있는 키-값 페어입니다. CPU 장치의 경우 선택 사항입니다. 이 단원을 사용하여 장치 유형에 필요한 프레임워크별 환경 변수를 추가할 수 있습니다. 이러한 요구 사항에 대한 자세한 내용은 프레임워크 또는 장치의 공식 웹 사이트를 참조하십시오. 예를 들어, 일부 장치에서 MXNet 추론 테스트를 실행하려면 다음 환경 변수가 필요할 수 있습니다. ``` "environmentVariables": [ ... { "key": "PYTHONPATH", "value": "$MXNET_HOME/python:$PYTHONPATH" }, { "key": "MXNET_HOME", "value": "$HOME/mxnet/" }, ... ] ``` `value` 필드는 MXNet 설치에 따라 다를 수 있습니다. GPU 장치에서 [컨테이너화](lambda-group-config.md#lambda-containerization-considerations)와 함께 실행되는 Lambda 함수를 테스트하는 경우 GPU 라이브러리용 환경 변수를 추가하십시오. 이렇게 하면 GPU가 계산을 수행할 수 있습니다. 다른 GPU 라이브러리를 사용하려면 라이브러리 또는 장치의 공식 설명서를 참조하십시오. `mlLambdaContainerizationMode` 기능이 `container` 또는 `both`로 설정된 경우 다음 키를 구성하세요. ``` "environmentVariables": [ { "key": "PATH", "value": ":$PATH" }, { "key": "LD_LIBRARY_PATH", "value": "" }, ... ] ``` `deviceResources` GPU 장치에 필요합니다. Lambda 함수로 액세스할 수 있는 [로컬 리소스](access-local-resources.md#lra-resource-types)를 포함합니다. 이 섹션을 사용하여 로컬 장치 및 볼륨 리소스를 추가합니다. + 장치 리소스의 경우 `"type": "device"`를 지정합니다. GPU 장치의 경우 장치 리소스는 `/dev` 아래의 GPU 관련 장치 파일이어야 합니다. **참고** `/dev/shm` 디렉터리는 예외입니다. 볼륨 리소스로만 구성할 수 있습니다. + 볼륨 리소스의 경우 `"type": "volume"`을 지정합니다. # AWS IoT Greengrass 검증 제품군 실행 [필수 구성을 설정](set-config.md)한 후 테스트를 시작할 수 있습니다. 전체 테스트 제품군의 실행 시간은 하드웨어에 따라 다릅니다. 참조를 위해, Raspberry Pi 3B에서 전체 테스트 제품군을 완료하는 데 약 30분이 걸립니다. 다음 `run-suite` 명령 예제는 장치 풀에 대한 자격 테스트를 실행하는 방법을 보여 줍니다. 장치 풀은 동일한 장치의 집합입니다. ------ #### [ IDT v3.0.0 and later ] 지정된 테스트 제품군에 있는 모든 테스트 그룹을 실행합니다. ``` devicetester_[linux | mac | win_x86-64] run-suite --suite-id GGQ_1.0.0 --pool-id ``` `list-suites` 명령을 사용하여 `tests` 폴더에 있는 테스트 제품군을 나열합니다. 테스트 제품군에서 특정 테스트 그룹을 실행합니다. ``` devicetester_[linux | mac | win_x86-64] run-suite --suite-id GGQ_1.0.0 --group-id --pool-id ``` `list-groups` 명령을 사용하여 테스트 제품군의 테스트 그룹을 나열합니다. 테스트 그룹에서 특정 테스트 케이스를 실행합니다. ``` devicetester_[linux | mac | win_x86-64] run-suite --group-id --test-id ``` 테스트 그룹에서 여러 테스트 사례를 실행합니다. ``` devicetester_[linux | mac | win_x86-64] run-suite --group-id --test-id , ``` 테스트 그룹의 테스트 사례를 나열합니다. ``` devicetester_[linux | mac | win_x86-64] list-test-cases --group-id ``` `run-suite` 명령에 대한 옵션은 선택 사항입니다. 예를 들어 `device.json` 파일에 하나의 장치 풀만 정의되어 있는 경우에는 `pool-id`를 생략할 수 있습니다. 또는 `tests` 폴더에서 최신 테스트 제품군 버전을 실행하려면 `suite-id`를 생략할 수 있습니다. **참고** 상위 테스트 제품군 버전이 온라인으로 제공되는 경우 IDT가 메시지를 표시합니다. 자세한 내용은 [기본 업데이트 동작 설정](#idt-update-behavior) 단원을 참조하십시오. `run-suite` 및 기타 IDT 명령에 대한 자세한 내용은 [AWS IoT Greengrass 명령용 IDT](#bk-cli) 단원을 참조하십시오. ------ #### [ IDT v2.3.0 and earlier ] 지정된 제품군의 모든 테스트 그룹을 실행합니다. ``` devicetester_[linux | mac | win_x86-64] run-suite --suite-id GGQ_1 --pool-id ``` 특정 테스트 그룹을 실행합니다. ``` devicetester_[linux | mac | win_x86-64] run-suite --suite-id GGQ_1 --group-id --pool-id ``` 단일 장치 풀에서 단일 테스트 제품군을 실행 중인 경우 `suite-id` 및 `pool-id`는 선택 사항입니다. 즉, `device.json` 파일에 하나의 장치 풀만 정의되어 있습니다. ------ ## Greengrass 종속성 확인하기 관련 테스트 그룹을 실행하기 전에 종속성 확인 프로그램 테스트 그룹을 실행하여 모든 Greengrass 종속성이 설치되어 있는지 확인하는 것이 좋습니다. 예시: + 코어 자격 테스트 그룹을 실행하기 전에 `ggcdependencies`를 실행합니다. + 컨테이너별 테스트 그룹을 실행하기 전에 `containerdependencies`를 실행하십시오. + 도커별 테스트 그룹을 실행하기 전에 `dockerdependencies`를 실행하십시오. + 스트림 관리자별 테스트 그룹을 실행하기 전에 `ggcstreammanagementdependencies`를 실행합니다. ## 기본 업데이트 동작 설정 테스트 실행을 시작하면 IDT가 최신 테스트 제품군 버전을 온라인으로 확인합니다. 사용 가능한 버전이 있으면 IDT가 사용 가능한 최신 버전으로 업데이트하라는 메시지를 표시합니다. `upgrade-test-suite`(또는 `u`) 플래그를 설정하여 기본 업데이트 동작을 제어할 수 있습니다. 유효한 값은 다음과 같습니다. + `y`. IDT는 사용 가능한 최신 버전을 다운로드하고 사용합니다. + `n` (default). IDT는 `suite-id` 옵션에 지정된 버전을 사용합니다. `suite-id`를 지정하지 않으면 IDT가 `tests` 폴더의 최신 버전을 사용합니다. `upgrade-test-suite` 플래그를 포함하지 않으면 업데이트를 사용할 수 있을 때 IDT가 메시지를 표시하고 30초 동안 입력(`y` 또는 `n`)을 기다립니다. 입력이 되지 않으면 기본적으로 `n`으로 설정되고 테스트가 계속 실행됩니다. 다음 예는 이 기능의 일반적인 사용 사례를 보여줍니다. **테스트 그룹에 사용할 수 있는 최신 테스트를 자동으로 사용합니다.** ``` devicetester_linux run-suite -u y --group-id mqtt --pool-id DevicePool1 ``` **특정 테스트 제품군 버전에서 테스트를 실행합니다.** ``` devicetester_linux run-suite -u n --suite-id GGQ_1.0.0 --group-id mqtt --pool-id DevicePool1 ``` **런타임에 업데이트하라는 메시지를 표시합니다.** ``` devicetester_linux run-suite --pool-id DevicePool1 ``` ## AWS IoT Greengrass 명령용 IDT IDT 명령은 `/bin` 디렉터리에 있습니다. 다음 작업에 사용합니다. ------ #### [ IDT v3.0.0 and later ] `help` 지정된 명령에 대한 정보를 나열합니다. `list-groups` 지정된 테스트 제품군에 있는 그룹을 나열합니다. `list-suites` 사용 가능한 테스트 제품군을 나열합니다. `list-supported-products` 지원되는 제품,이 경우 AWS IoT Greengrass 버전 및 현재 IDT 버전에 대한 테스트 제품군 버전을 나열합니다. `list-test-cases` 주어진 테스트 그룹의 테스트 사례를 나열합니다. 다음 옵션이 지원됩니다. + `group-id`. 검색할 테스트 그룹입니다. 이 옵션은 필수이며 단일 그룹을 지정해야 합니다. `run-suite` 장치의 풀에 대해 테스트 제품군을 실행합니다. 지원되는 몇 가지 옵션은 다음과 같습니다. + `suite-id`. 실행할 테스트 제품군 버전입니다. 지정하지 않으면 IDT는 `tests` 폴더의 최신 버전을 사용합니다. + `group-id`. 실행할 테스트 그룹(쉼표로 구분된 목록). 지정하지 않으면 IDT는 테스트 제품군의 모든 테스트 그룹을 실행합니다. + `test-id`. 실행할 테스트 케이스(쉼표로 구분된 목록). 지정된 경우, `group-id`은(는) 단일 그룹을 지정해야 합니다. + `pool-id`. 테스트할 장치 풀. `device.json` 파일에 여러 장치 풀이 정의되어 있는 경우 하나의 풀을 지정해야 합니다. + `upgrade-test-suite`. 테스트 제품군 버전 업데이트가 처리되는 방식을 제어합니다. IDT v3.0.0부터는 IDT가 업데이트된 테스트 제품군 버전을 온라인으로 확인합니다. 자세한 내용은 [테스트 제품군 버전](idt-gg-qualification.md#idt-test-suite-versions) 단원을 참조하십시오. + `stop-on-first-failure`. 첫 번째 실패 시 실행을 중지하도록 IDT를 구성합니다. 이 옵션은 지정된 테스트 그룹을 디버깅하는 데 `group-id`와(과) 함께 사용해야 합니다. 전체 테스트 제품군을 실행하여 검증 보고서를 생성할 때는 이 옵션을 사용하지 마시기 바랍니다. + `update-idt`. IDT를 업데이트하라는 프롬프트에 대한 응답을 설정합니다. 입력이 `Y`일 경우 IDT가 최신 버전을 감지하면 테스트 실행이 중지됩니다. 입력이 `N`일 경우 테스트 실행이 계속됩니다. + 입력이 `update-managed-policy`. `Y`일 경우 IDT가 사용자의 관리형 정책이 업데이트되지 않았음을 감지하면 테스트 실행이 중지됩니다. 입력이 `N`일 경우 테스트 실행이 계속됩니다. `run-suite` 옵션에 대한 자세한 내용은 다음 `help` 옵션을 사용하십시오. ``` devicetester_[linux | mac | win_x86-64] run-suite -h ``` ------ #### [ IDT v2.3.0 and earlier ] `help` 지정된 명령에 대한 정보를 나열합니다. `list-groups` 지정된 테스트 제품군에 있는 그룹을 나열합니다. `list-suites` 사용 가능한 테스트 제품군을 나열합니다. `run-suite` 장치의 풀에 대해 테스트 제품군을 실행합니다. `run-suite` 옵션에 대한 자세한 내용은 다음 `help` 옵션을 사용하십시오. ``` devicetester_[linux | mac | win_x86-64] run-suite -h ``` ------ # 결과 및 로그 이해 이 단원에서는 IDT 결과 보고서 및 로그를 보고 해석하는 방법을 설명합니다. ## 결과 보기 실행하는 동안 IDT는 콘솔, 로그 파일 및 테스트 보고서에 오류를 작성합니다. IDT는 자격 테스트 제품군을 완료한 후 두 개의 테스트 보고서를 생성합니다. 이러한 보고서는 `/results//`에서 확인할 수 있습니다. 두 보고서 모두 검증 테스트 세트의 실행 결과를 캡처합니다. `awsiotdevicetester_report.xml`는 AWS Partner 디바이스 카탈로그에 디바이스를 나열 AWS 하기 위해 제출하는 검증 테스트 보고서입니다. 보고서에는 다음 요소가 포함됩니다. + IDT 버전 + 테스트된 AWS IoT Greengrass 버전입니다. + `device.json` 파일에 지정된 SKU 및 장치 풀 이름 + `device.json` 파일에 지정된 장치 풀의 기능 + 테스트 결과의 집계 요약 + 장치 기능(예: 로컬 리소스 액세스, 섀도우, MQTT 등)을 기반으로 테스트된 라이브러리별 테스트 결과의 분석 `GGQ_Result.xml` 보고서는 [JUnit XML 형식](https://llg.cubic.org/docs/junit/)입니다. [Jenkins](https://jenkins.io/), [Bamboo](https://www.atlassian.com/software/bamboo) 등과 같은 지속적 통합 및 배포 플랫폼에 이 보고서를 통합할 수 있습니다. 보고서에는 다음 요소가 포함됩니다. + 테스트 결과의 집계 요약 + 테스트된 AWS IoT Greengrass 기능별 테스트 결과 분석. ## IDT 보고서 해석 `awsiotdevicetester_report.xml` 또는 `awsiotdevicetester_report.xml`의 보고서 섹션에는 실행된 테스트 및 결과가 나열됩니다. 첫 번째 XML 태그 ``에는 테스트 실행의 요약이 포함됩니다. 예시: ``` ````` 태그에 사용되는 속성 `name` 테스트 제품군의 이름입니다. `time` 검증 세트를 실행하는 데 걸린 시간(초) `tests` 실행된 테스트의 수입니다. `failures` 실행되었지만 통과하지 못한 테스트의 수입니다. `errors` IDT에서 실행하지 못한 테스트의 수입니다. `disabled` 이 속성은 사용되지 않으므로 무시해도 좋습니다. `awsiotdevicetester_report.xml` 파일에는 테스트하는 제품에 대한 정보와 테스트 제품군을 실행한 후 확인된 제품 기능에 대한 정보를 포함하는 `` 태그가 포함되어 있습니다.`` 태그에 사용되는 속성 `name` 테스트하는 제품의 이름입니다. `version` 테스트하는 제품의 버전입니다. `features` 확인된 기능입니다. `required`로 표시된 기능은 자격에 대한 보드를 제출하는 데 필요합니다. 다음 코드 조각은 `awsiotdevicetester_report.xml` 파일에 이 정보가 나타나는 방식을 보여 줍니다. ``` ``` `optional`로 표시된 기능은 자격에 필수 기능이 아닙니다. 다음 코드 조각은 선택적 기능을 보여 줍니다. ``` 
 ``` 필요한 기능에 대한 테스트 실패 또는 오류가 없는 경우 디바이스는 실행을 위한 기술 요구 사항을 충족 AWS IoT Greengrass 하고 서비스와 상호 작용 AWS IoT 할 수 있습니다. 디바이스 카탈로그에 AWS Partner 디바이스를 나열하려면이 보고서를 검증 증거로 사용할 수 있습니다. 테스트 실패 또는 오류의 경우 `` XML 태그를 검토하여 실패한 테스트를 식별할 수 있습니다. `` 태그 내부의 `` XML 태그는 테스트 그룹에 대한 테스트 결과 요약을 보여 줍니다. 예시: ``` ``` 형식은 `` 태그와 비슷하지만, 사용되지 않고 무시할 수 있는 `skipped` 속성이 있습니다. 각 `` XML 태그 내부에는 테스트 그룹에 실행된 각 테스트에 대한 `` 태그가 있습니다. 예시: ``` > ````` 태그에 사용되는 속성 `name` 테스트의 이름입니다. `attempts` IDT에서 테스트 사례를 실행한 횟수입니다. 테스트가 실패하거나 오류가 발생하는 경우 문제 해결에 대한 정보와 함께 `` 또는 `` 태그가 `` 태그에 추가됩니다. 예시: ``` Reason for the test failure Reason for the test execution error ``` ## 로그 보기 IDT는 `/results//logs`에서 테스트 실행 로그를 생성합니다. 두 개의 로그 세트가 생성됩니다. `test_manager.log` AWS IoT Device Tester의 Test Manager 구성 요소에서 생성된 로그(예: 구성, 테스트 시퀀싱 및 보고서 생성과 관련된 로그). `.log (for example, ota.log)` 테스트 대상 장치의 로그를 포함한 테스트 그룹의 로그입니다. 테스트가 실패하면 테스트에 대한 테스트 대상 장치의 로그가 포함된 tar.gz 파일이 생성됩니다(예: `ota_prod_test_1_ggc_logs.tar.gz`). 자세한 내용은 [AWS IoT Greengrass 문제 해결을 위한 IDT](idt-troubleshooting.md) 단원을 참조하십시오. # IDT를 사용하여 자체 테스트 제품군 개발 및 실행 IDT v4.0.0부터 용 IDT는 표준화된 구성 설정 및 결과 형식을 디바이스 및 디바이스 소프트웨어에 대한 사용자 지정 테스트 제품군을 개발할 수 있는 테스트 제품군 환경과 AWS IoT Greengrass 결합합니다. 사용자 지정 테스트를 자체 내부 검증을 위해 추가하거나 디바이스 검증을 위해 고객에게 제공할 수 있습니다. IDT를 사용하여 다음과 같이 사용자 지정 테스트 도구 모음을 개발하고 실행하십시오. **사용자 지정 테스트 도구 모음을 개발하려면** + 테스트하려는 Greengrass 장치에 대해 사용자 지정 테스트 로직이 포함된 테스트 도구 모음을 만드세요. + 테스트 러너에게 사용자 지정 테스트 도구 모음과 IDT를 제공하세요. 테스트 도구 모음의 특정 설정 구성에 대한 정보를 포함해야 합니다. **사용자 지정 테스트 도구 모음을 실행하려면** + 테스트하려는 디바이스를 설정합니다. + 사용하려는 테스트 도구 모음의 필요에 따라 설정 구성을 구현하십시오. + IDT를 사용하여 사용자 지정 테스트 도구 모음을 실행하세요. + IDT에서 실행한 테스트의 테스트 결과 및 실행 로그를 확인합니다. ## 용 AWS IoT 디바이스 테스터의 최신 버전 다운로드 AWS IoT Greengrass [최신 버전](dev-test-versions.md)의 IDT를 다운로드하여 읽기 및 쓰기 권한이 있는 파일 시스템의 위치에 소프트웨어의 압축을 풉니다. **참고** 여러 사용자가 NFS 디렉터리 또는 Windows 네트워크 공유 폴더와 같은 공유 위치에서 IDT를 실행하는 것은 지원되지 않습니다. 로컬 드라이브에 IDT 패키지의 압축을 풀고 로컬 워크스테이션에서 IDT 바이너리를 실행하는 것이 좋습니다. Windows의 경우 260자의 경로 길이 제한이 있습니다. Windows를 사용하는 경우 경로를 260자 제한 아래로 유지하도록 IDT 압축을 `C:\ ` 또는 `D:\` 같은 루트 디렉터리에 풉니다. ## 테스트 도구 모음 생성 워크플로 테스트 도구 모음은 세 가지 유형의 파일로 구성됩니다. + 테스트 도구 모음 실행 방법에 대한 정보를 IDT에 제공하는 JSON 구성 파일. + IDT가 테스트 사례를 실행하는 데 사용하는 테스트 실행 파일. + 테스트를 실행하는 데 필요한 추가 파일. 다음 기본 단계를 완료하여 사용자 지정 IDT 테스트를 생성하세요. 1. 테스트 도구 모음의 [JSON 구성 파일을 만드세요](idt-json-config.md). 1. 테스트 도구 모음의 테스트 로직이 포함된 [테스트 사례 실행 파일을 만드세요](test-executables.md). 1. 테스트 도구 모음을 실행하는 데 [테스트 러너에게 필요한 구성 정보](set-config-custom.md)를 확인하고 문서화하세요. 1. IDT가 예상대로 테스트 도구 모음을 실행하고 [테스트 결과](run-tests-custom.md)를 생성할 수 있는지 확인하십시오. 샘플 사용자 지정 도구 모음을 빠르게 구축하고 실행하려면 [튜토리얼: 샘플 IDT 테스트 도구 모음 구축 및 실행](build-sample-suite.md)의 지침을 따르십시오. Python으로 사용자 지정 테스트 도구 모음 생성을 시작하려면 [튜토리얼: 간단한 IDT 테스트 도구 모음 개발](create-custom-tests.md)을(를) 참조하십시오. # 튜토리얼: 샘플 IDT 테스트 도구 모음 구축 및 실행 AWS IoT 디바이스 테스터 다운로드에는 샘플 테스트 제품군의 소스 코드가 포함됩니다. 이 자습서를 완료하여 샘플 테스트 제품군을 빌드하고 실행하여 용 AWS IoT 디바이스 테스터를 사용하여 사용자 지정 테스트 제품군 AWS IoT Greengrass 을 실행하는 방법을 이해할 수 있습니다. 이 자습서에서는 다음 단계를 완료합니다. 1. [샘플 테스트 도구 모음 구축](#build-sample) 1. [IDT를 사용하여 샘플 테스트 도구 모음을 실행하세요.](#run-sample) ## 사전 조건 이 자습서를 완료하려면 다음이 필요합니다. + **호스트 컴퓨터 요구 사항** + 최신 버전의 AWS IoT 디바이스 테스터 + [Python](https://www.python.org/downloads/) 3.7 이상 컴퓨터에 설치된 Python 버전 번호를 확인하려면 인스턴스에서 다음 명령을 실행합니다. ``` python3 --version ``` Windows에서 이 명령 사용시 오류가 반환되면 `python --version`을(를) 대신 사용하십시오. 반환된 버전 번호가 3.7 이상인 경우 Powershell 터미널에서 다음 명령을 실행하여 `python` 명령의 별칭으로 `python3`을(를) 설정합니다. ``` Set-Alias -Name "python3" -Value "python" ``` 버전 정보가 반환되지 않았거나 버전 번호가 3.7 미만이면 [Python 다운로드](https://wiki.python.org/moin/BeginnersGuide/Download)의 지침에 따라 Python 3.7 이상을 설치합니다. 자세한 내용은 [Python 설명서](https://docs.python.org)를 참조하세요. + [urllib3](https://urllib3.readthedocs.io/en/latest/) `urllib3`이 제대로 설치되었는지 확인하려면 다음 명령을 실행합니다. ``` python3 -c 'import urllib3' ``` `urllib3`가 설치되지 않은 경우에는 다음 명령을 실행하여 설치합니다. ``` python3 -m pip install urllib3 ``` + **디바이스 요구 사항** + Linux 운영 체제를 사용하고 호스트 컴퓨터와 동일한 네트워크에 네트워크로 연결된 디바이스입니다. Raspberry Pi OS와 함께 [Raspberry Pi](https://www.raspberrypi.org/)를 사용하는 것이 좋습니다. Raspberry Pi에 원격으로 연결하려면 Pi에서 [SSH](https://www.raspberrypi.org/documentation/remote-access/ssh/)를 설정해야 합니다. ## IDT용 디바이스 정보 구성 IDT가 테스트를 실행할 수 있도록 디바이스 정보를 구성하십시오. `/configs` 폴더에 있는 `device.json` 템플릿을 다음 정보로 업데이트해야 합니다. ``` [ { "id": "pool", "sku": "N/A", "devices": [ { "id": "", "connectivity": { "protocol": "ssh", "ip": "", "port": "", "auth": { "method": "pki | password", "credentials": { "user": "", "privKeyPath": "/path/to/private/key", "password": "" } } } } ] } ] ``` `devices` 개체에 다음 정보를 제공하시기 바랍니다. `id` 테스트 대상 디바이스의 고유한 사용자 정의 식별자입니다. `connectivity.ip` 디바이스의 IP 주소입니다. `connectivity.port` 선택 사항. 디바이스에 SSH 연결에 사용할 포트 번호입니다. `connectivity.auth` 연결에 대한 인증 정보입니다. 이 속성은 `connectivity.protocol`이 `ssh`로 설정된 경우에만 적용됩니다. `connectivity.auth.method` 지정된 연결 프로토콜을 통해 디바이스에 액세스하는 데 사용되는 인증 방법입니다. 지원되는 값은 다음과 같습니다. + `pki` + `password` `connectivity.auth.credentials` 인증에 사용되는 자격 증명입니다. `connectivity.auth.credentials.user` 디바이스에 로그인하는 데 사용되는 사용자 이름. `connectivity.auth.credentials.privKeyPath` 디바이스에 로그인하는 데 사용하는 프라이빗 키의 전체 경로입니다. 이 값은 `connectivity.auth.method`가 `pki`로 설정된 경우에만 적용됩니다. `devices.connectivity.auth.credentials.password` 디바이스에 로그인하기 위해 사용하는 암호입니다. 이 값은 `connectivity.auth.method`가 `password`로 설정된 경우에만 적용됩니다. **참고** `method`가 `pki`로 설정된 경우에만 `privKeyPath`를 지정합니다. `method`가 `password`로 설정된 경우에만 `password`를 지정합니다. ## 샘플 테스트 도구 모음 구축 `/samples/python` 폴더에는 제공된 구축 스크립트를 사용하여 테스트 도구 모음에 결합할 수 있는 샘플 구성 파일, 소스 코드 및 IDT Client SDK가 포함되어 있습니다. 다음 디렉터리 트리는 이러한 샘플 파일의 위치를 보여줍니다. ``` ├── ... ├── tests ├── samples │ ├── ... │ └── python │ ├── configuration │ ├── src │ └── build-scripts │ ├── build.sh │ └── build.ps1 └── sdks ├── ... └── python └── idt_client ``` 테스트 도구 모음을 구축하려면 호스트 컴퓨터에서 다음 명령을 실행합니다. ------ #### [ Windows ] ``` cd /samples/python/build-scripts ./build.ps1 ``` ------ #### [ Linux, macOS, or UNIX ] ``` cd /samples/python/build-scripts ./build.sh ``` ------ 그러면 `IDTSampleSuitePython_1.0.0` 폴더 내 `/tests` 폴더에 샘플 테스트 도구 모음이 만들어집니다. `IDTSampleSuitePython_1.0.0` 폴더의 파일을 검토하여 샘플 테스트 도구 모음이 어떻게 구성되어 있는지 이해하고 테스트 사례 실행 파일 및 테스트 구성 JSON 파일의 다양한 예제를 확인하세요. 다음 단계: IDT를 사용하여 생성한 [샘플 테스트 도구 모음을 실행](#run-sample)하십시오. ## IDT를 사용하여 샘플 테스트 도구 모음을 실행하세요. 샘플 테스트 도구 모음을 실행하려면 호스트 컴퓨터에서 다음 명령을 실행하세요. ``` cd /bin ./devicetester_[linux | mac | win_x86-64] run-suite --suite-id IDTSampleSuitePython ``` IDT는 샘플 테스트 도구 모음을 실행하고 결과를 콘솔로 스트리밍합니다. 테스트 실행이 완료되면 다음 정보가 표시됩니다. ``` ========== 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 ``` ## 문제 해결 다음 정보를 사용하면 튜토리얼 완료와 관련된 문제를 해결하는 데 도움이 됩니다. **테스트 케이스가 성공적으로 실행되지 않습니다** 테스트가 성공적으로 실행되지 않을 경우 IDT는 오류 로그를 콘솔로 스트리밍하여 테스트 실행 문제를 해결하는 데 도움을 줍니다. 이 튜토리얼의 모든 [사전 요구](#prereqs-tutorial-sample) 사항을 충족하는지 확인하세요. **테스트 중인 디바이스에 연결할 수 없습니다.** 다음을 확인합니다. + `device.json` 파일에는 올바른 IP 주소, 포트 및 인증 정보가 들어 있습니다. + 호스트 컴퓨터에서 SSH를 통해 장치에 연결할 수 있습니다. # 튜토리얼: 간단한 IDT 테스트 도구 모음 개발 테스트 제품군은 다음을 결합합니다. + 테스트 로직이 포함된 테스트 실행 파일 + 테스트 제품군을 설명하는 JSON 구성 파일 이 자습서에서는 AWS IoT Greengrass 용 IDT를 사용하여 단일 테스트 사례가 포함된 Python 테스트 제품군을 개발하는 방법을 보여줍니다. 이 자습서에서는 다음 단계를 완료합니다. 1. [테스트 도구 모음 디렉터리 생성](#test-suite-dir) 1. [JSON 구성 파일 생성](#test-suite-json) 1. [테스트 사례 실행 파일 생성](#test-suite-exe) 1. [테스트 도구 모음 실행](#run-test-suite) ## 사전 조건 이 자습서를 완료하려면 다음이 필요합니다. + **호스트 컴퓨터 요구 사항** + 최신 버전의 AWS IoT 디바이스 테스터 + [Python](https://www.python.org/downloads/) 3.7 이상 컴퓨터에 설치된 Python 버전 번호를 확인하려면 인스턴스에서 다음 명령을 실행합니다. ``` python3 --version ``` Windows에서 이 명령 사용시 오류가 반환되면 `python --version`을(를) 대신 사용하십시오. 반환된 버전 번호가 3.7 이상인 경우 Powershell 터미널에서 다음 명령을 실행하여 `python` 명령의 별칭으로 `python3`을(를) 설정합니다. ``` Set-Alias -Name "python3" -Value "python" ``` 버전 정보가 반환되지 않았거나 버전 번호가 3.7 미만이면 [Python 다운로드](https://wiki.python.org/moin/BeginnersGuide/Download)의 지침에 따라 Python 3.7 이상을 설치합니다. 자세한 내용은 [Python 설명서](https://docs.python.org)를 참조하세요. + [urllib3](https://urllib3.readthedocs.io/en/latest/) `urllib3`이 제대로 설치되었는지 확인하려면 다음 명령을 실행합니다. ``` python3 -c 'import urllib3' ``` `urllib3`가 설치되지 않은 경우에는 다음 명령을 실행하여 설치합니다. ``` python3 -m pip install urllib3 ``` + **디바이스 요구 사항** + Linux 운영 체제를 사용하고 호스트 컴퓨터와 동일한 네트워크에 네트워크로 연결된 디바이스입니다. Raspberry Pi OS와 함께 [Raspberry Pi](https://www.raspberrypi.org/)를 사용하는 것이 좋습니다. Raspberry Pi에 원격으로 연결하려면 Pi에서 [SSH](https://www.raspberrypi.org/documentation/remote-access/ssh/)를 설정해야 합니다. ## 테스트 도구 모음 디렉터리 생성 IDT는 각 테스트 도구 모음 내의 테스트 그룹에 테스트 사례를 논리적으로 분리합니다. 각 테스트 사례는 테스트 그룹 내에 있어야 합니다. 이 튜토리얼을 위해 `MyTestSuite_1.0.0`(이)라는 폴더를 만들고 이 폴더 내에 다음 디렉터리 트리를 생성하십시오. ``` MyTestSuite_1.0.0 └── suite └── myTestGroup └── myTestCase ``` ## JSON 구성 파일 생성 테스트 도구 모음에는 다음과 같은 필수 [JSON 구성 파일](idt-json-config.md)이 포함되어야 합니다.필수 JSON 파일 `suite.json` 테스트 제품군 정보가 포함되어 있습니다. [suite.json을 구성하십시오.](idt-json-config.md#suite-json)을(를) 참조하세요. `group.json` 테스트 그룹에 대한 정보를 포함합니다. 테스트 도구 모음의 각 테스트 그룹에 대한 `group.json` 파일을 만들어야 합니다. [group.json을 구성하십시오.](idt-json-config.md#group-json)을(를) 참조하세요. `test.json` 테스트 케이스에 대한 정보가 들어 있습니다. 테스트 도구 모음의 각 테스트 케이스에 대한 `test.json` 파일을 만들어야 합니다. [test.json을 구성하십시오.](idt-json-config.md#test-json)을(를) 참조하세요. 1. `MyTestSuite_1.0.0/suite` 폴더에서 다음 폴더 구조로 `suite.json` 파일을 안에 생성합니다. ``` { "id": "MyTestSuite_1.0.0", "title": "My Test Suite", "details": "This is my test suite.", "userDataRequired": false } ``` 1. `MyTestSuite_1.0.0/myTestGroup` 폴더에서 다음 폴더 구조로 `group.json` 파일을 안에 생성합니다. ``` { "id": "MyTestGroup", "title": "My Test Group", "details": "This is my test group.", "optional": false } ``` 1. `MyTestSuite_1.0.0/myTestGroup/myTestCase` 폴더에서 다음 폴더 구조로 `test.json` 파일을 안에 생성합니다. ``` { "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" ] } } } ``` 이제 `MyTestSuite_1.0.0` 폴더의 디렉터리 트리가 다음과 같이 표시되어야 합니다. ``` MyTestSuite_1.0.0 └── suite ├── suite.json └── myTestGroup ├── group.json └── myTestCase └── test.json ``` ## IDT 클라이언트 SDK 다운로드 [IDT 클라이언트 SDK](test-executables.md#idt-client-sdk)를 사용하여 IDT가 테스트 대상 디바이스와 상호 작용하고 테스트 결과를 보고할 수 있도록 합니다. 이 튜토리얼에서는 Python 버전의 SDK를 사용합니다. `/sdks/python/` 폴더에서 `idt_client` 폴더를 `MyTestSuite_1.0.0/suite/myTestGroup/myTestCase` 폴더로 복사합니다. SDK가 성공적으로 복사되었는지 확인하려면 다음 명령을 실행합니다. ``` cd MyTestSuite_1.0.0/suite/myTestGroup/myTestCase python3 -c 'import idt_client' ``` ## 테스트 사례 실행 파일 생성 테스트 사례 실행 파일에는 실행하려는 테스트 로직이 포함되어 있습니다. 테스트 도구 모음에는 여러 테스트 사례 실행 파일이 포함될 수 있습니다. 이 튜토리얼에서는 하나의 테스트 사례 실행 파일을 생성합니다. 1. 테스트 도구 모음 파일을 만드세요. `MyTestSuite_1.0.0/suite/myTestGroup/myTestCase` 폴더 안에 다음 내용으로 `myTestCase.py`라는 파일을 만듭니다. ``` from idt_client import * def main(): # Use the client SDK to communicate with IDT client = Client() if __name__ == "__main__": main() ``` 1. 클라이언트 SDK 함수를 사용하여 `myTestCase.py` 파일에 다음 테스트 로직을 추가합니다. 1. 테스트 중인 디바이스에서 SSH 명령어를 실행합니다. ``` 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. 테스트 결과를 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() ``` ## IDT용 디바이스 정보 구성 IDT가 테스트를 실행할 수 있도록 디바이스 정보를 구성하십시오. `/configs` 폴더에 있는 `device.json` 템플릿을 다음 정보로 업데이트해야 합니다. ``` [ { "id": "pool", "sku": "N/A", "devices": [ { "id": "", "connectivity": { "protocol": "ssh", "ip": "", "port": "", "auth": { "method": "pki | password", "credentials": { "user": "", "privKeyPath": "/path/to/private/key", "password": "" } } } } ] } ] ``` `devices` 개체에 다음 정보를 제공하시기 바랍니다. `id` 테스트 대상 디바이스의 고유한 사용자 정의 식별자입니다. `connectivity.ip` 디바이스의 IP 주소입니다. `connectivity.port` 선택 사항. 디바이스에 SSH 연결에 사용할 포트 번호입니다. `connectivity.auth` 연결에 대한 인증 정보입니다. 이 속성은 `connectivity.protocol`이 `ssh`로 설정된 경우에만 적용됩니다. `connectivity.auth.method` 지정된 연결 프로토콜을 통해 디바이스에 액세스하는 데 사용되는 인증 방법입니다. 지원되는 값은 다음과 같습니다. + `pki` + `password` `connectivity.auth.credentials` 인증에 사용되는 자격 증명입니다. `connectivity.auth.credentials.user` 디바이스에 로그인하는 데 사용되는 사용자 이름. `connectivity.auth.credentials.privKeyPath` 디바이스에 로그인하는 데 사용하는 프라이빗 키의 전체 경로입니다. 이 값은 `connectivity.auth.method`가 `pki`로 설정된 경우에만 적용됩니다. `devices.connectivity.auth.credentials.password` 디바이스에 로그인하기 위해 사용하는 암호입니다. 이 값은 `connectivity.auth.method`가 `password`로 설정된 경우에만 적용됩니다. **참고** `method`가 `pki`로 설정된 경우에만 `privKeyPath`를 지정합니다. `method`가 `password`로 설정된 경우에만 `password`를 지정합니다. ## 테스트 도구 모음 실행 테스트 도구 모음을 만든 후에는 예상대로 작동하는지 확인해야 합니다. 이를 위해 기존 디바이스 풀로 테스트 도구 모음을 실행하려면 다음 단계를 완료하세요. 1. `MyTestSuite_1.0.0` 폴더를 `/tests`에 복사하세요. 1. 다음 명령을 실행합니다. ``` cd /bin ./devicetester_[linux | mac | win_x86-64] run-suite --suite-id MyTestSuite ``` IDT는 테스트 도구 모음을 실행하고 결과를 콘솔로 스트리밍합니다. 테스트 실행이 완료되면 다음 정보가 표시됩니다. ``` 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 ``` ## 문제 해결 다음 정보를 사용하면 튜토리얼 완료와 관련된 문제를 해결하는 데 도움이 됩니다. **테스트 케이스가 성공적으로 실행되지 않습니다** 테스트가 성공적으로 실행되지 않을 경우 IDT는 오류 로그를 콘솔로 스트리밍하여 테스트 실행 문제를 해결하는 데 도움을 줍니다. 오류 로그를 확인하기 전에 다음 사항을 확인합니다. + IDT 클라이언트 SDK는 [이 단계](#add-idt-sdk)에서 설명한 대로 올바른 폴더에 있습니다. + 이 튜토리얼의 모든 [사전 요구 사항](#prereqs-tutorial-custom)을 충족합니다. **테스트 중인 디바이스에 연결할 수 없습니다.** 다음을 확인합니다. + `device.json` 파일에는 올바른 IP 주소, 포트 및 인증 정보가 들어 있습니다. + 호스트 컴퓨터에서 SSH를 통해 장치에 연결할 수 있습니다. # IDT 테스트 도구 모음 구성 파일 만들기 이 섹션에서는 사용자 지정 테스트 도구 모음을 작성할 때 포함하는 JSON 구성 파일을 만드는 형식을 설명합니다.필수 JSON 파일 `suite.json` 테스트 제품군 정보가 포함되어 있습니다. [suite.json을 구성하십시오.](#suite-json)을 참조하세요. `group.json` 테스트 그룹에 대한 정보를 포함합니다. 테스트 도구 모음의 각 테스트 그룹에 대한 `group.json` 파일을 만들어야 합니다. [group.json을 구성하십시오.](#group-json)을 참조하세요. `test.json` 테스트 케이스에 대한 정보가 들어 있습니다. 테스트 도구 모음의 각 테스트 케이스에 대한 `test.json` 파일을 만들어야 합니다. [test.json을 구성하십시오.](#test-json)을 참조하세요.JSON 파일(선택 사항) `state_machine.json` IDT가 테스트 도구 모음을 실행할 때 테스트가 실행되는 방법을 정의합니다. [state\$1machine.json을 구성합니다.](#state-machine-json)을 참조하세요. `userdata_schema.json` 테스트 실행기가 설정 구성에 포함할 수 있는 [`userdata.json` 파일](set-config-custom.md#userdata-config-custom)의 스키마를 정의합니다. 이 `userdata.json` 파일은 테스트를 실행하는 데 필요하지만 `device.json` 파일에는 없는 추가 구성 정보에 사용됩니다. [userdata\$1schema.json을 구성합니다.](#userdata-schema-json)을 참조하세요. JSON 구성 파일은 다음과 같이 `` 파일에 저장됩니다. ``` └── suite ├── suite.json ├── state_machine.json ├── userdata_schema.json ├── ├── group.json ├── └── test.json ``` ## suite.json을 구성하십시오. `suite.json` 파일은 환경 변수를 설정하고 테스트 도구 모음을 실행하는 데 사용자 데이터가 필요한지 여부를 결정합니다. 다음 템플릿을 사용하여 `/suite/suite.json` 파일을 구성하십시오. ``` { "id": "_", "title": "", "details": "", "userDataRequired": true | false, "environmentVariables": [ { "key": "", "value": "", }, ... { "key": "", "value": "", } ] } ``` 여기 설명된 것처럼 값이 포함된 모든 필드는 필수입니다. `id` 테스트 도구 모음의 고유한 사용자 정의 ID. `id`의 값은 `suite.json` 파일이 있는 테스트 도구 모음 폴더의 이름과 일치해야 합니다. 세트 이름과 세트 버전도 다음 요구 사항을 충족해야 합니다. + ``은(는) 언더바를 포함할 수 없습니다. + ``은(는) 다음과 같이 `x.x.x`(으)로 표시됩니다. 여기서 `x`은(는) 숫자입니다. ID는 IDT에서 생성한 테스트 보고서에 표시됩니다. `title` 이 테스트 도구 모음에서 테스트 중인 제품 또는 기능의 사용자 정의 이름입니다. 테스트 실행기의 IDT CLI에 이름이 표시됩니다. `details` 테스트 도구 모음의 용도에 대한 짧은 설명입니다. `userDataRequired` 테스트 실행기가 `userdata.json` 파일에 사용자 지정 정보를 포함해야 하는지 여부를 정의합니다. 이 값을 `true`으(로) 설정하는 경우, 테스트 도구 모음 폴더에도 [`userdata_schema.json` 파일](#userdata-schema-json)을 포함해야 합니다. `environmentVariables` 선택 사항. 이 테스트 도구 모음에 설정할 환경 변수 배열입니다. `environmentVariables.key` 환경 변수의 이름입니다. `environmentVariables.value` 환경 변수의 값입니다. ## group.json을 구성하십시오. `group.json` 파일은 테스트 그룹이 필수인지 옵션인지 여부를 정의합니다. 다음 템플릿을 사용하여 `/suite//group.json` 파일을 구성하십시오. ``` { "id": "", "title": "", "details": "", "optional": true | false, } ``` 여기 설명된 것처럼 값이 포함된 모든 필드는 필수입니다. `id` 테스트 그룹에 대한 고유한 사용자 정의 ID. `id`의 값은 `group.json` 파일이 있는 테스트 그룹 폴더의 이름과 일치해야 하며 언더바(`_`)를 포함할 수 없습니다. ID는 IDT에서 생성한 테스트 보고서에 사용됩니다. `title` 테스트 그룹을 나타내는 서술형 이름입니다. 테스트 실행기의 IDT CLI에 이름이 표시됩니다. `details` 테스트 그룹의 용도에 대한 짧은 설명입니다. `optional` 선택 사항. IDT에서 필수 테스트 실행을 완료한 후 이 테스트 그룹을 선택적 그룹으로 표시하도록 `true`(으)로 설정합니다. 기본값은 `false`입니다. ## test.json을 구성하십시오. `test.json` 파일은 테스트 케이스 실행 파일 및 테스트 케이스에서 사용되는 환경 변수를 결정합니다. 테스트 케이스 실행 파일 생성에 대한 자세한 내용은 [IDT 테스트 케이스 실행 파일 생성](test-executables.md) 단원을 참조하세요. 다음 템플릿을 사용하여 `/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": "", } ] } ``` 여기 설명된 것처럼 값이 포함된 모든 필드는 필수입니다. `id` 테스트 케이스의 고유한 사용자 정의 ID. `id`의 값은 `test.json` 파일이 있는 테스트 케이스 폴더의 이름과 일치해야 하며 언더바(`_`)를 포함할 수 없습니다. ID는 IDT에서 생성한 테스트 보고서에 사용됩니다. `title` 테스트 케이스를 나타내는 서술형 이름입니다. 테스트 실행기의 IDT CLI에 이름이 표시됩니다. `details` 테스트 케이스의 용도에 대한 짧은 설명입니다. `requireDUT` 선택 사항. 이 테스트를 실행하는 데 기기가 필요한 경우, `true`(으)로 설정하고, 그렇지 않으면 `false`(으)로 설정합니다. 기본값은 `true`입니다. 테스트 실행기는 `device.json` 파일에서 테스트를 실행하는 데 사용할 기기를 구성합니다. `requiredResources` 선택 사항. 이 테스트를 실행하는 데 필요한 리소스 기기에 대한 정보를 제공하는 배열입니다. `requiredResources.name` 이 테스트를 실행할 때 리소스 기기에 부여하는 고유한 이름입니다. `requiredResources.features` 사용자 정의 리소스 장치 기능의 배열. `requiredResources.features.name` 기능의 이름입니다. 이 장치를 사용하려는 장치 기능. 이 이름은 테스트 실행기가 `resource.json` 파일에 제공한 기능 이름과 일치합니다. `requiredResources.features.version` 선택 사항. 기능의 버전. 이 값은 테스트 실행기가 `resource.json` 파일에서 제공한 기능 버전과 일치합니다. 버전이 제공되지 않으면 기능이 확인되지 않습니다. 기능에 버전 번호가 필요하지 않은 경우, 이 필드를 비워 둡니다. `requiredResources.features.jobSlots` 선택 사항. 이 기능이 지원할 수 있는 동시 테스트 수입니다. 기본값은 `1`입니다. IDT에서 개별 기능에 대해 서로 다른 기기를 사용하도록 하려면 이 값을 `1`(으)로 설정하는 것이 좋습니다. `execution.timeout` IDT가 테스트 실행이 완료될 때까지 기다리는 시간(밀리초) 입니다. 이 값 설정에 대한 자세한 내용을 알아보려면 [IDT 테스트 케이스 실행 파일 생성](test-executables.md) 섹션을 참조하세요. `execution.os` IDT를 실행하는 호스트 컴퓨터의 운영 체제에 따라 실행할 테스트 케이스 실행 파일입니다. 지원되는 값은 `linux`, `mac` 및 `win`입니다. `execution.os.cmd` 지정된 운영 체제에서 실행하려는 테스트 케이스 실행 파일의 경로입니다. 이 위치는 시스템 경로에 있어야 합니다. `execution.os.args` 선택 사항. 테스트 케이스 실행 파일을 실행하기 위해 제공할 인수입니다. `environmentVariables` 선택 사항. 이 테스트 케이스에 설정된 환경 변수 배열입니다. `environmentVariables.key` 환경 변수의 이름입니다. `environmentVariables.value` 환경 변수의 값입니다. `test.json` 파일과 `suite.json` 파일에서 동일한 환경 변수를 지정하는 경우, `test.json` 파일의 값이 우선합니다. ## state\$1machine.json을 구성합니다. 상태 머신은 테스트 제품군 실행 흐름을 제어하는 구조입니다. 테스트 도구 모음의 시작 상태를 결정하고, 사용자 정의 규칙을 기반으로 상태 전환을 관리하며, 최종 상태에 도달할 때까지 해당 상태를 계속 전환합니다. 테스트 제품군에 사용자 정의 상태 머신이 포함되지 않은 경우 IDT가 상태 머신을 자동으로 생성합니다. 기본 상태 머신은 다음 기능을 수행합니다. + 테스트 실행기에 전체 테스트 제품군 대신 특정 테스트 그룹을 선택하고 실행할 수 있는 기능을 제공합니다. + 특정 테스트 그룹을 선택하지 않은 경우, 테스트 제품군의 모든 테스트 그룹을 무작위 순서로 실행합니다. + 보고서를 생성하고 각 테스트 그룹 및 테스트 사례의 테스트 결과를 보여주는 콘솔 요약을 인쇄합니다. IDT 상태 머신이 작동하는 자세한 방법은 [IDT 상태 머신 구성](idt-state-machine.md)을(를) 참조하십시오. ## userdata\$1schema.json을 구성합니다. `userdata_schema.json` 파일은 테스트 실행기가 사용자 데이터를 제공하는 스키마를 결정합니다. 테스트 도구 모음에 `device.json` 파일에 없는 정보가 필요한 경우, 사용자 데이터가 필요합니다. 예를 들어 테스트에는 Wi-Fi 네트워크 자격 증명, 특정 오픈 포트 또는 사용자가 제공해야 하는 인증서가 필요할 수 있습니다. 이 정보는 `userdata`(이)라는 입력 파라미터로 IDT에 제공될 수 있습니다. 이때 값은 `/config` 폴더에 생성한 `userdata.json` 파일입니다. `userdata.json` 파일 형식은 테스트 도구 모음에 포함된 `userdata_schema.json` 파일을 기반으로 합니다. 테스트 실행기가 `userdata.json` 파일을 제공해야 함을 나타내려면: 1. `suite.json` 파일에서 `userDataRequired`을(를) `true`(으)로 설정합니다. 1. ``에서 `userdata_schema.json` 파일을 생성하십시오. 1. `userdata_schema.json` 파일을 편집하여 유효한 [IETF 초안 v4 JSON 스키마](https://json-schema.org/specification-links.html#draft-4)를 생성하십시오. IDT는 테스트 도구 모음을 실행하면 자동으로 스키마를 읽고 이를 사용하여 테스트 실행기가 제공한 `userdata.json` 파일을 검증합니다. 유효한 경우, `userdata.json` 파일의 내용은 [IDT 컨텍스트](idt-context.md)와 [스테이트 머신 컨텍스트](idt-state-machine.md#state-machine-context) 모두에서 사용할 수 있습니다. # IDT 상태 머신 구성 상태 머신은 테스트 제품군 실행 흐름을 제어하는 구조입니다. 테스트 도구 모음의 시작 상태를 결정하고, 사용자 정의 규칙을 기반으로 상태 전환을 관리하며, 최종 상태에 도달할 때까지 해당 상태를 계속 전환합니다. 테스트 제품군에 사용자 정의 상태 머신이 포함되지 않은 경우 IDT가 상태 머신을 자동으로 생성합니다. 기본 상태 머신은 다음 기능을 수행합니다. + 테스트 실행기에 전체 테스트 제품군 대신 특정 테스트 그룹을 선택하고 실행할 수 있는 기능을 제공합니다. + 특정 테스트 그룹을 선택하지 않은 경우, 테스트 제품군의 모든 테스트 그룹을 무작위 순서로 실행합니다. + 보고서를 생성하고 각 테스트 그룹 및 테스트 사례의 테스트 결과를 보여주는 콘솔 요약을 인쇄합니다. IDT 테스트 제품군의 상태 머신은 다음 기준을 충족해야 합니다. + 각 상태는 테스트 그룹 실행 또는 보고서 파일 생성과 같이 IDT가 취할 수 있는 작업에 해당합니다. + 상태로 전환하면 상태와 관련된 작업이 실행됩니다. + 각 상태는 다음 상태의 전환 규칙을 정의합니다. + 종료 상태는 `Succeed` 또는 `Fail` 중 하나여야 합니다. ## 상태 머신 형식 다음 템플릿을 사용하여 `/suite/state_machine.json` 파일을 직접 구성할 수 있습니다. ``` { "Comment": "", "StartAt": "", "States": { "": { "Type": "", // Additional state configuration } // Required states "Succeed": { "Type": "Succeed" }, "Fail": { "Type": "Fail" } } } ``` 여기 설명된 것처럼 값이 포함된 모든 필드는 필수입니다. `Comment` 상태 머신의 설명입니다. `StartAt` IDT가 테스트 제품군을 실행하기 시작하는 상태의 이름. `StartAt`의 값은 `States` 객체에 나열된 상태 중 하나로 설정해야 합니다. `States` 사용자 정의 상태 이름을 유효한 IDT 상태에 매핑하는 객체입니다. 각 상태.*state-name* 객체에는 상태 *state-name*에 매핑된 유효한 상태의 정의가 포함됩니다. `States` 객체에는 `Succeed` 및 `Fail` 상태가 포함되어야 합니다. 유효한 상태에 대한 자세한 내용은 [유효한 상태 및 상태 정의](#valid-states) 섹션을 참조하세요. ## 유효한 상태 및 상태 정의 이 섹션에서는 IDT 상태 머신에서 사용할 수 있는 모든 유효한 상태의 상태 정의를 설명합니다. 다음 상태 중 일부는 테스트 케이스 수준의 구성을 지원합니다. 하지만 꼭 필요한 경우가 아니면 테스트 케이스 수준 대신 테스트 그룹 수준에서 상태 전환 규칙을 구성하는 것이 좋습니다. **Topics** + [RunTask](#state-runtask) + [Choice](#state-choice) + [Parallel](#state-parallel) + [AddProductFeatures](#state-addproductfeatures) + [Report](#state-report) + [LogMessage](#state-logmessage) + [SelectGroup](#state-selectgroup) + [Fail](#state-fail) + [Succeed](#state-succeed) ### RunTask `RunTask` 상태는 테스트 제품군에 정의된 테스트 그룹에서 테스트 케이스를 실행합니다. ``` { "Type": "RunTask", "Next": "", "TestGroup": "", "TestCases": [ "" ], "ResultVar": "" } ``` 여기 설명된 것처럼 값이 포함된 모든 필드는 필수입니다. `Next` 현재 상태에서 작업을 실행한 후 전환할 상태의 이름입니다. `TestGroup` 선택 사항. 실행할 테스트 그룹의 ID. 이 값을 지정하지 않으면 IDT는 테스트 실행기가 선택한 테스트 그룹을 실행합니다. `TestCases` 선택 사항. `TestGroup`에서 지정한 그룹의 테스트 케이스 ID 배열. IDT는 `TestGroup` 및 `TestCases` 값을 기반으로 다음과 같이 테스트 실행 동작을 결정합니다. + `TestGroup`과 `TestCases`가 모두 지정된 경우 IDT는 테스트 그룹에서 지정된 테스트 케이스를 실행합니다. + `TestCases`가 지정되었지만 `TestGroup`이 지정되지 않은 경우 IDT는 지정된 테스트 케이스를 실행합니다. + `TestGroup`이 지정되었지만 `TestCases`가 지정되지 않은 경우 IDT는 지정된 테스트 그룹 내의 모든 테스트 케이스를 실행합니다. + `TestGroup` 또는 `TestCases` 둘 다 지정되지 않은 경우 IDT는 테스트 실행기가 IDT CLI에서 선택한 테스트 그룹에서 모든 테스트 케이스를 실행합니다. 테스트 실행기에 대한 그룹 선택을 활성화하려면 `statemachine.json` 파일에 `RunTask` 및 `Choice` 상태를 모두 포함해야 합니다. 작동 방식에 대한 예제는 [상태 시스템 예시: 사용자가 선택한 테스트 그룹 실행](#allow-specific-groups)을 참조하십시오. 테스트 실행기의 IDT CLI 명령 활성화에 대한 자세한 내용은 [IDT CLI 명령을 활성화합니다.](test-executables.md#idt-cli-coop) 섹션을 참조하세요. `ResultVar` 테스트 실행 결과와 함께 설정할 컨텍스트 변수의 이름. `TestGroup`에 대한 값을 지정하지 않은 경우 이 값을 지정하지 마십시오. IDT는 다음에 따라 `ResultVar`에서 `true` 또는 `false`로 정의한 변수 값을 설정합니다. + 변수 이름의 `text_text_passed` 형식인 경우 값은 첫 번째 테스트 그룹의 모든 테스트를 통과했는지 아니면 건너뛰었는지로 설정됩니다. + 다른 모든 경우에는 값이 모든 테스트 그룹의 모든 테스트를 통과했는지 아니면 건너뛰었는지로 설정됩니다. 일반적으로 `RunTask` 상태를 사용하여 개별 테스트 케이스 ID를 지정하지 않고 테스트 그룹 ID를 지정하면 IDT가 지정된 테스트 그룹의 모든 테스트 케이스를 실행하게 됩니다. 이 상태에서 실행되는 모든 테스트 케이스는 무작위 순서로 병렬로 실행됩니다. 그러나 모든 테스트 케이스를 실행하는 데 디바이스가 필요하고 사용 가능한 디바이스가 하나뿐인 경우에는 테스트 케이스가 대신 순차적으로 실행됩니다. **오류 처리** 지정된 테스트 그룹 또는 테스트 케이스 ID가 유효하지 않은 경우 이 상태에서는 `RunTaskError` 실행 오류가 발생합니다. 상태에서 실행 오류가 발생하는 경우 상태 머신 컨텍스트의 `hasExecutionError` 변수도 `true`로 설정됩니다. ### Choice `Choice` 상태를 사용하면 사용자 정의 조건에 따라 전환할 다음 상태를 동적으로 설정할 수 있습니다. ``` { "Type": "Choice", "Default": "", "FallthroughOnError": true | false, "Choices": [ { "Expression": "", "Next": "" } ] } ``` 여기 설명된 것처럼 값이 포함된 모든 필드는 필수입니다. `Default` `Choices`에 정의된 표현식을 `true`로 평가할 수 없는 경우 전환할 기본 상태입니다. `FallthroughOnError` 선택 사항. 상태에서 표현식을 평가할 때 오류가 발생할 경우의 동작을 지정합니다. 평가 결과 오류가 발생할 경우 표현식을 건너뛰려면 `true`로 설정합니다. 일치하는 표현식이 없는 경우 상태 머신은 해당 `Default` 상태로 전환됩니다. `false` 값이 지정하지 않은 경우 기본값은 `FallthroughOnError`입니다. `Choices` 현재 상태에서 동작을 실행한 후 전환할 상태를 결정하는 표현식 및 상태의 배열입니다. `Choices.Expression` 부울 값으로 평가되어야 하는 표현식 문자열입니다. 표현식이 `true`로 평가되면 상태 머신은 `Choices.Next`에 정의된 상태로 전환됩니다. 표현식 문자열은 상태 시스템 컨텍스트에서 값을 검색한 다음 해당 값에 대한 연산을 수행하여 부울 값에 도달합니다. 상태 머신 컨텍스트 액세스에 대한 자세한 내용은 [상태 머신 컨텍스트](#state-machine-context) 섹션을 참조하세요. `Choices.Next` `Choices.Expression`에 정의된 표현식이 `true`로 평가되면 전환할 상태의 이름. **오류 처리** `Choice` 상태는 다음과 같은 경우에 오류 처리를 요구할 수 있습니다. + 선택 표현식의 일부 변수는 상태 머신 컨텍스트에 존재하지 않습니다. + 표현식의 결과는 부울 값이 아닙니다. + JSON 조회 결과는 문자열, 숫자 또는 부울이 아닙니다. 이 상태에서는 `Catch` 블록을 사용하여 오류를 처리할 수 없습니다. 오류가 발생했을 때 상태 머신 실행을 중지하려면 `FallthroughOnError`를 `false`로 설정해야 합니다. 하지만 사용 사례에 따라 다음 중 하나를 수행하도록 `FallthroughOnError`를 `true`로 설정하는 것이 좋습니다. + 액세스하는 변수가 존재하지 않을 것으로 예상되는 경우가 있다면, `Default`의 값과 추가 `Choices` 블록을 사용하여 다음 상태를 지정하십시오. + 액세스 중인 변수가 항상 존재해야 하는 경우 `Default` 상태를 `Fail`로 설정하십시오. ### Parallel `Parallel` 상태를 사용하면 새 상태 머신을 서로 병렬로 정의하고 실행할 수 있습니다. ``` { "Type": "Parallel", "Next": "", "Branches": [ ] } ``` 여기 설명된 것처럼 값이 포함된 모든 필드는 필수입니다. `Next` 현재 상태에서 작업을 실행한 후 전환할 상태의 이름입니다. `Branches` 실행할 상태 머신 정의의 배열입니다. 각 스테이트 머신 정의에는 고유한 `StartAt`, `Succeed`, `Fail` 상태가 포함되어야 합니다. 이 배열의 상태 머신 정의는 자체 정의 이외의 상태를 참조할 수 없습니다. 각 브랜치 상태 머신은 동일한 상태 머신 컨텍스트를 공유하므로 한 브랜치에서 변수를 설정한 다음 다른 브랜치에서 해당 변수를 읽으면 예상치 못한 동작이 발생할 수 있습니다. 브랜치 상태 머신을 모두 실행한 후에만 `Parallel` 상태가 다음 상태로 이동합니다. 디바이스가 필요한 각 상태는 디바이스를 사용할 수 있을 때까지 실행을 대기합니다. 여러 디바이스를 사용할 수 있는 경우 이 상태는 여러 그룹의 테스트 케이스를 병렬로 실행합니다. 사용할 수 있는 디바이스가 충분하지 않으면 테스트 케이스가 순차적으로 실행됩니다. 테스트 케이스는 병렬로 실행될 때 무작위 순서로 실행되므로 동일한 테스트 그룹에서 테스트를 실행하는 데 여러 디바이스가 사용될 수 있습니다. **오류 처리** 실행 오류를 처리하려면 브랜치 상태 머신과 부모 상태 머신이 모두 해당 `Fail` 상태로 전환되는지 확인하십시오. 브랜치 상태 머신은 부모 상태 머신에 실행 오류를 전송하지 않으므로 `Catch` 블록을 사용하여 브랜치 상태 머신의 실행 오류를 처리할 수 없습니다. 대신 공유 상태 머신 컨텍스트의 `hasExecutionErrors` 값을 사용하십시오. 이렇게 하는 방법의 예는 [상태 머신 예제: 두 테스트 그룹을 병렬로 실행](#run-in-parallel) 섹션을 참조하세요. ### AddProductFeatures `AddProductFeatures` 상태에서는 IDT에서 생성한 `awsiotdevicetester_report.xml` 파일에 제품 기능을 추가할 수 있습니다. 제품 기능은 디바이스가 충족할 수 있는 특정 기준에 대한 사용자 정의 정보입니다. 예를 들어, `MQTT` 제품 기능은 디바이스가 MQTT 메시지를 올바르게 게시하도록 지정할 수 있습니다. 보고서에서 제품 기능은 지정된 테스트의 통과 여부에 따라 `supported`, `not-supported` 또는 사용자 지정 값으로 설정됩니다. **참고** `AddProductFeatures` 상태는 자체적으로 보고서를 생성하지 않습니다. 보고서를 생성하려면 이 상태를 [`Report` 상태로](#state-report) 전환해야 합니다. ``` { "Type": "Parallel", "Next": "", "Features": [ { "Feature": "", "Groups": [ "" ], "OneOfGroups": [ "" ], "TestCases": [ "" ], "IsRequired": true | false, "ExecutionMethods": [ "" ] } ] } ``` 여기 설명된 것처럼 값이 포함된 모든 필드는 필수입니다. `Next` 현재 상태에서 작업을 실행한 후 전환할 상태의 이름입니다. `Features` `awsiotdevicetester_report.xml` 파일에 표시할 제품 기능의 배열. `Feature` 기능의 이름입니다. `FeatureValue` 선택 사항. 보고서에서 `supported` 대신 사용할 사용자 지정 값입니다. 이 값을 지정하지 않으면 테스트 결과에 따라 기능 값이 `supported` 또는 `not-supported`로 설정됩니다. `FeatureValue`에 사용자 지정 값을 사용하면 동일한 기능을 다른 조건으로 테스트할 수 있으며, IDT는 지원되는 조건에 대한 기능 값을 연결합니다. 예를 들어, 다음 발췌문은 두 개의 개별 기능 값이 있는 `MyFeature` 기능을 보여줍니다. ``` ... { "Feature": "MyFeature", "FeatureValue": "first-feature-supported", "Groups": ["first-feature-group"] }, { "Feature": "MyFeature", "FeatureValue": "second-feature-supported", "Groups": ["second-feature-group"] }, ... ``` 두 테스트 그룹이 모두 통과하면 기능 값이 `first-feature-supported, second-feature-supported`로 설정됩니다. `Groups` 선택 사항. 테스트 그룹 ID의 배열입니다. 기능을 지원하려면 지정된 각 테스트 그룹 내의 모든 테스트를 통과해야 합니다. `OneOfGroups` 선택 사항. 테스트 그룹 ID의 배열입니다. 기능이 지원되려면 지정된 테스트 그룹 중 하나 이상의 모든 테스트를 통과해야 합니다. `TestCases` 선택 사항. 테스트 케이스 ID의 배열입니다. 이 값을 지정하면 다음이 적용됩니다. + 기능이 지원되려면 지정된 모든 테스트 케이스를 통과해야 합니다. + `Groups`은 테스트 그룹 ID는 하나만 포함해야 합니다. + `OneOfGroups`은 지정하지 않아야 합니다. `IsRequired` 선택 사항. 보고서에서 이 기능을 선택적 기능으로 표시하려면 `false`로 설정합니다. 기본값은 `true`입니다. `ExecutionMethods` 선택 사항. `device.json` 파일에 지정된 `protocol` 값과 일치하는 실행 메서드의 배열. 이 값을 지정하는 경우 테스트 실행기는 이 배열의 값 중 하나와 일치하는 `protocol` 값을 지정하여 보고서에 기능을 포함해야 합니다. 이 값을 지정하지 않으면 기능이 항상 보고서에 포함됩니다. `AddProductFeatures` 상태를 사용하려면 `RunTask` 상태의 `ResultVar` 값을 다음 값 중 하나로 설정해야 합니다. + 개별 테스트 케이스 ID를 지정한 경우 `ResultVar`을(를) `group-id_test-id_passed`(으)로 설정합니다. + 개별 테스트 케이스 ID를 지정하지 않은 경우 `ResultVar`을(를) `group-id_passed`(으)로 설정합니다. `AddProductFeatures` 상태에서는 다음과 같은 방식으로 테스트 결과를 확인합니다. + 테스트 케이스 ID를 지정하지 않은 경우 각 테스트 그룹의 결과는 상태 머신 컨텍스트의 `group-id_passed` 변수 값에 따라 결정됩니다. + 테스트 케이스 ID를 지정한 경우 각 테스트의 결과는 상태 머신 컨텍스트의 `group-id_test-id_passed` 변수 값을 기반으로 결정됩니다. **오류 처리** 이 상태에서 제공된 그룹 ID가 유효한 그룹 ID가 아닌 경우 이 상태로 인해 `AddProductFeaturesError` 실행 오류가 발생합니다. 상태에서 실행 오류가 발생하는 경우 상태 머신 컨텍스트의 `hasExecutionErrors` 변수도 `true`로 설정됩니다. ### Report `Report` 상태는 `suite-name_Report.xml` 및 `awsiotdevicetester_report.xml` 파일을 생성합니다. 또한 이 상태는 보고서를 콘솔로 스트리밍합니다. ``` { "Type": "Report", "Next": "" } ``` 여기 설명된 것처럼 값이 포함된 모든 필드는 필수입니다. `Next` 현재 상태에서 작업을 실행한 후 전환할 상태의 이름입니다. 테스트 실행기가 테스트 결과를 볼 수 있도록 테스트 실행 흐름이 끝날 무렵에는 항상 `Report` 상태로 전환해야 합니다. 일반적으로 이 상태 이후의 다음 상태는 `Succeed`입니다. **오류 처리** 이 상태에서 보고서를 생성하는 데 문제가 발생하면 `ReportError` 실행 오류가 발생합니다. ### LogMessage `LogMessage` 상태는 `test_manager.log` 파일을 생성하고 로그 메시지를 콘솔로 스트리밍합니다. ``` { "Type": "LogMessage", "Next": "" "Level": "info | warn | error" "Message": "" } ``` 여기 설명된 것처럼 값이 포함된 모든 필드는 필수입니다. `Next` 현재 상태에서 작업을 실행한 후 전환할 상태의 이름입니다. `Level` 로그 메시지를 생성할 때의 오류 수준입니다. 유효하지 않은 수준을 지정하면 이 상태가 오류 메시지를 생성하고 삭제합니다. `Message` 로그할 메시지. ### SelectGroup `SelectGroup` 상태는 상태 머신 컨텍스트를 업데이트하여 선택된 그룹을 나타냅니다. 이 상태에서 설정된 값은 이후의 모든 `Choice` 상태에서 사용됩니다. ``` { "Type": "SelectGroup", "Next": "" "TestGroups": [ " ] } ``` 여기 설명된 것처럼 값이 포함된 모든 필드는 필수입니다. `Next` 현재 상태에서 작업을 실행한 후 전환할 상태의 이름입니다. `TestGroups` 선택된 것으로 표시될 테스트 그룹 배열입니다. 이 배열의 각 테스트 그룹 ID에 대해 `group-id_selected` 변수는 컨텍스트에서 `true`로 설정됩니다. IDT는 지정된 그룹이 존재하는지 여부를 확인하지 않으므로 유효한 테스트 그룹 ID를 제공해야 합니다. ### Fail `Fail` 상태는 상태 머신이 제대로 실행되지 않았음을 나타냅니다. 이는 상태 머신의 종료 상태이며 각 상태 머신 정의에는 이 상태가 포함되어야 합니다. ``` { "Type": "Fail" } ``` ### Succeed `Succeed` 상태는 상태 머신이 올바르게 실행되었음을 나타냅니다. 이는 상태 머신의 종료 상태이며 각 상태 머신 정의에는 이 상태가 포함되어야 합니다. ``` { "Type": "Succeed" } ``` ## 상태 머신 컨텍스트 상태 머신 컨텍스트는 실행 중에 상태 머신이 사용할 수 있는 데이터를 포함하는 읽기 전용 JSON 문서입니다. 상태 머신 컨텍스트는 상태 머신에서만 액세스할 수 있으며 테스트 흐름을 결정하는 정보를 포함합니다. 예를 들어 `userdata.json` 파일에서 테스트 실행기가 구성한 정보를 사용하여 특정 테스트 실행이 필요한지 여부를 결정할 수 있습니다. 상태 머신 컨텍스트는 다음 형식을 사용합니다. ``` { "pool": { }, "userData": { }, "config": { }, "suiteFailed": true | false, "specificTestGroups": [ "" ], "specificTestCases": [ "" ], "hasExecutionErrors": true } ``` `pool` 테스트 실행을 위해 선택한 디바이스 풀에 대한 정보. 선택한 디바이스 풀의 경우 이 정보는 `device.json` 파일에 정의된 해당 최상위 디바이스 풀 배열 요소에서 검색됩니다. `userData` `userdata.json` 파일의 정보. `config` 정보는 `config.json` 파일을 정의합니다. `suiteFailed` 값은 상태 머신이 시작될 때 `false`로 설정됩니다. 테스트 그룹이 `RunTask` 상태로 실패하는 경우 이 값은 상태 머신의 남은 실행 기간 동안으로 `true`로 설정됩니다. `specificTestGroups` 테스트 실행기가 전체 테스트 제품군 대신 실행할 특정 테스트 그룹을 선택하면 이 키가 생성되고 여기에는 특정 테스트 그룹 ID 목록이 포함됩니다. `specificTestCases` 테스트 실행기가 전체 테스트 제품군 대신 실행할 특정 테스트 케이스를 선택하면 이 키가 생성되고 여기에는 특정 테스트 케이스 ID 목록이 포함됩니다. `hasExecutionErrors` 상태 머신이 시작될 때 종료되지 않습니다. 어떤 상태에서든 실행 오류가 발생하는 경우 이 변수가 생성되고 남은 상태 머신 실행 기간 동안 `true`로 설정됩니다. JSONPath 표기법을 사용하여 컨텍스트를 쿼리할 수 있습니다. 상태 정의의 JSONPath 쿼리 구문은 `{{$.query}}`입니다. 일부 상태에서는 JSONPath 쿼리를 자리 표시자 문자열로 사용할 수 있습니다. IDT는 자리 표시자 문자열을 컨텍스트에서 평가된 JSONPath 쿼리의 값으로 대체합니다. 다음 값에 자리 표시자를 사용할 수 있습니다. + `RunTask` 상태의 `TestCases` 값. + `Expression` 값 `Choice` 상태. 상태 머신 컨텍스트에서 데이터에 액세스할 때 다음 조건이 충족되는지 확인하십시오. + JSON 경로는 `$.`로 시작해야 합니다. + 각 값은 문자열, 숫자 또는 부울로 평가되어야 합니다. JSONPath 표기법을 사용하여 컨텍스트에서 데이터에 액세스하는 방법에 대한 자세한 내용은 [IDT 컨텍스트 사용](idt-context.md) 섹션을 참조하십시오. ## 실행 오류 실행 오류는 상태 머신이 상태를 실행할 때 발생하는 상태 머신 정의의 오류입니다. IDT는 `test_manager.log` 파일의 각 오류에 대한 정보를 기록하고 로그 메시지를 콘솔로 스트리밍합니다. 다음 방법을 사용하여 실행 오류를 처리할 수 있습니다. + 상태 정의에 [`Catch` 블록](#catch)을 추가합니다. + 상태 머신 컨텍스트에서 [`hasExecutionErrors` 값](#context)의 값을 확인합니다. ### Catch `Catch`를 사용하려면 상태 정의에 다음을 추가하십시오. ``` "Catch": [ { "ErrorEquals": [ "" ] "Next": "" } ] ``` 여기 설명된 것처럼 값이 포함된 모든 필드는 필수입니다. `Catch.ErrorEquals` 캐치할 오류 유형의 배열입니다. 실행 오류가 지정된 값 중 하나와 일치하면 상태 머신이 `Catch.Next`에서 지정된 상태로 전환됩니다. 발생하는 오류 유형에 대한 자세한 내용은 각 상태 정의를 참조하십시오. `Catch.Next` 현재 상태에서 `Catch.ErrorEquals`에서 지정한 값 중 하나와 일치하는 실행 오류가 발생하는 경우 전환할 다음 상태입니다. Catch 블록은 둘 중 하나가 일치할 때까지 순차적으로 처리됩니다. Catch 블록에 나열된 오류와 일치하는 오류가 없으면 상태 머신이 계속 실행됩니다. 실행 오류는 잘못된 상태 정의로 인해 발생하므로 상태에 실행 오류가 발생하면 Fail 상태로 전환하는 것이 좋습니다. ### hasExecutionError 일부 상태에서는 실행 오류가 발생하는 경우 오류가 발생하는 것 외에도 상태 시스템 컨텍스트에서 `hasExecutionError` 값을 `true`로 설정합니다. 이 값을 사용하여 오류 발생 시기를 감지한 다음 `Choice` 상태를 사용하여 상태 머신을 해당 `Fail` 상태로 전환할 수 있습니다. 이 메서드는 다음과 특징이 있습니다. + 상태 머신은 `hasExecutionError`에 할당된 어떤 값으로도 시작되지 않으며 특정 상태가 값을 설정하기 전까지는 이 값을 사용할 수 없습니다. 즉, 실행 오류가 발생하지 않을 경우 상태 머신이 중지되지 않도록 이 값에 액세스하는 `Choice` 상태에 대해 명시적으로 `FallthroughOnError`를 `false`로 설정해야 합니다. + `true`로 설정한 후에는 `hasExecutionError`가 false로 설정되거나 컨텍스트에서 제거되지 않습니다. 즉, 이 값은 `true`로 처음 설정할 때만 유용하며 이후의 모든 상태에서는 의미 있는 값을 제공하지 않습니다. + `hasExecutionError` 값은 `Parallel` 상태의 모든 브랜치 상태 머신과 공유되므로 액세스 순서에 따라 예상치 못한 결과가 발생할 수 있습니다. 이러한 특성 때문에 Catch 블록을 대신 사용할 수 있는 경우에는 이 방법을 사용하지 않는 것이 좋습니다. ## 상태 머신 예제 이 섹션에서는 몇 가지 상태 시스템 구성의 예제를 제공합니다. **Topics** + [상태 머신 예제: 단일 테스트 그룹 실행](#single-test-group) + [상태 머신 예제: 사용자가 선택한 테스트 그룹 실행](#allow-specific-groups) + [상태 머신 예제: 제품 기능이 포함된 단일 테스트 그룹 실행](#run-with-product-features) + [상태 머신 예제: 두 테스트 그룹을 병렬로 실행](#run-in-parallel) ### 상태 머신 예제: 단일 테스트 그룹 실행 이 상태 머신: + ID `GroupA`를 사용하여 테스트 그룹을 실행하며 이 ID는 `group.json` 파일에 있어야 합니다. + 실행 오류가 있는지 확인하고 오류가 있는 경우, `Fail`로 전환합니다. + 보고서를 생성하고 오류가 없는 경우 `Succeed`로 전환하고 그렇지 않으면 `Fail`로 전환합니다. ``` { "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" } } } ``` ### 상태 머신 예제: 사용자가 선택한 테스트 그룹 실행 이 상태 머신: + 테스트 실행기가 특정 테스트 그룹을 선택했는지 확인합니다. 테스트 실행기가 테스트 그룹을 선택하지 않으면 테스트 케이스를 선택할 수 없기 때문에 상태 머신은 특정 테스트 케이스를 확인하지 않습니다. + 테스트 그룹을 선택한 경우: + 선택한 테스트 그룹 내에서 테스트 케이스를 실행합니다. 이를 위해 상태 머신은 `RunTask` 상태의 테스트 그룹이나 테스트 케이스를 명시적으로 지정하지 않습니다. + 모든 테스트를 실행한 후 보고서를 생성하고 종료합니다. + 테스트 그룹을 선택하지 않은 경우: + 테스트 그룹 `GroupA`에서 테스트를 실행합니다. + 보고서를 생성하고 종료합니다. ``` { "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" } } } ``` ### 상태 머신 예제: 제품 기능이 포함된 단일 테스트 그룹 실행 이 상태 머신: + 테스트 그룹 `GroupA`를 실행합니다. + 실행 오류가 있는지 확인하고 오류가 있는 경우, `Fail`로 전환합니다. + `awsiotdevicetester_report.xml` 파일에 `FeatureThatDependsOnGroupA` 기능을 추가합니다. + `GroupA`가 통과하면 기능이 `supported`로 설정됩니다. + 이 기능은 보고서에서 선택 사항으로 표시되어 있지 않습니다. + 보고서를 생성하고 오류가 없는 경우 `Succeed`로 전환하고 그렇지 않으면 `Fail`로 전환합니다. ``` { "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" } } } ``` ### 상태 머신 예제: 두 테스트 그룹을 병렬로 실행 이 상태 머신: + `GroupA`및 `GroupB` 테스트 그룹을 병렬로 실행합니다. 브랜치 상태 머신의 `RunTask` 상태에 의해 컨텍스트에 저장된 `ResultVar` 변수는 `AddProductFeatures` 상태에서 사용할 수 있습니다. + 실행 오류가 있는지 확인하고 오류가 있는 경우, `Fail`로 전환합니다. 이 상태 머신은 `Catch` 블록을 사용하지 않습니다. 해당 메서드는 브랜치 상태 머신의 실행 오류를 감지하지 못하기 때문입니다. + 통과한 그룹을 기반으로 `awsiotdevicetester_report.xml` 파일에 기능을 추가합니다. + `GroupA`가 통과하면 기능이 `supported`로 설정됩니다. + 이 기능은 보고서에서 선택 사항으로 표시되어 있지 않습니다. + 보고서를 생성하고 오류가 없는 경우 `Succeed`로 전환하고 그렇지 않으면 `Fail`로 전환합니다. 디바이스 풀에 두 개의 디바이스가 구성된 경우 `GroupA` 및 `GroupB` 둘 다 동시에 실행할 수 있습니다. 그러나 `GroupA` 또는 `GroupB` 둘 중 하나에 여러 테스트가 포함된 경우에는 두 디바이스 모두 해당 테스트에 할당될 수 있습니다. 장치가 하나만 구성된 경우 테스트 그룹은 순차적으로 실행됩니다. ``` { "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" } } } ``` # IDT 테스트 케이스 실행 파일 생성 다음과 같은 방법으로 테스트 세트 폴더에 테스트 케이스 실행 파일을 만들고 배치할 수 있습니다. + `test.json` 파일의 인수나 환경 변수를 사용하여 실행할 테스트를 결정하는 테스트 세트의 경우, 전체 테스트 세트에 대해 단일 테스트 사례 실행 파일을 만들거나 테스트 세트의 각 테스트 그룹에 대해 테스트 실행 파일을 만들 수 있습니다. + 지정된 명령을 기반으로 특정 테스트를 실행하려는 테스트 세트의 경우, 테스트 세트의 각 테스트 사례에 대해 테스트 사례 실행 파일을 하나씩 만듭니다. 테스트 작성자는 사용 사례에 적합한 접근 방식을 결정하고 그에 따라 테스트 사례 실행 파일을 구성할 수 있습니다. 각 `test.json` 파일에 올바른 테스트 케이스 실행 파일 경로를 제공하고 지정된 실행 파일이 올바르게 실행되는지 확인합니다. 모든 장치에서 테스트 케이스를 실행할 준비가 되면 IDT는 다음 파일을 읽습니다. + 선택한 테스트 사례에 대한 `test.json`에 따라 시작할 프로세스와 설정할 환경 변수가 결정됩니다. + 테스트 세트용 `suite.json`에 따라 설정할 환경 변수가 결정됩니다. IDT는 `test.json` 파일에 지정된 명령과 인수를 기반으로 필수 테스트 실행 파일 프로세스를 시작하고 필요한 환경 변수를 프로세스에 전달합니다. ## IDT 클라이언트 SDK 사용 IDT 클라이언트 SDK를 사용하면 IDT 및 테스트 대상 장치와 상호 작용하는 데 사용할 수 있는 API 명령을 사용하여 테스트 실행 파일에 테스트 로직을 작성하는 방법을 간소화할 수 있습니다. IDT는 현재 다음과 같은 SDK를 제공합니다. + Python용 IDT 클라이언트 SDK + Go용 IDT 클라이언트 SDK 이 SDK는 `/sdks` 폴더에 있습니다. 새 테스트 케이스 실행 파일을 만들 때는 사용할 SDK를 테스트 케이스 실행 파일이 들어 있는 폴더에 복사하고 코드에서 SDK를 참조해야 합니다. 이 섹션에서는 테스트 케이스 실행 파일에서 사용할 수 있는 사용 가능한 API 명령에 대한 간략한 설명을 제공합니다. **Topics** + [장치 상호작용](#api-device-interaction) + [IDT 상호 작용](#api-idt-interaction) + [호스트 상호작용](#api-host-interaction) ### 장치 상호작용 다음 명령을 사용하면 추가 장치 상호 작용 및 연결 관리 기능을 구현하지 않고도 테스트 중인 장치와 통신할 수 있습니다. `ExecuteOnDevice` 테스트 세트가 SSH 또는 Docker 셸 연결을 지원하는 장치에서 셸 명령을 실행할 수 있습니다. `CopyToDevice` 테스트 세트가 IDT를 실행하는 호스트 컴퓨터의 로컬 파일을 SSH 또는 Docker 셸 연결을 지원하는 장치의 지정된 위치로 복사할 수 있습니다. `ReadFromDevice` 테스트 세트가 UART 연결을 지원하는 장치의 직렬 포트에서 읽을 수 있도록 허용합니다. **참고** IDT는 컨텍스트의 장치 액세스 정보를 사용하여 만든 장치에 대한 직접 연결을 관리하지 않으므로 테스트 사례 실행 파일에서 이러한 장치 상호 작용 API 명령을 사용하는 것이 좋습니다. 하지만 이러한 명령이 테스트 사례 요구 사항을 충족하지 않는 경우, IDT 컨텍스트에서 장치 액세스 정보를 검색하고 이를 사용하여 테스트 세트에서 장치에 직접 연결할 수 있습니다. 직접 연결하려면 테스트 중인 장치와 리소스 장치에 대해 각각 `device.connectivity` 및 `resource.devices.connectivity` 필드에서 정보를 검색합니다. IDT 컨텍스트 사용에 관한 자세한 내용은 [IDT 컨텍스트 사용](idt-context.md) 섹션을 참조합니다. ### IDT 상호 작용 다음 명령을 사용하면 테스트 세트가 IDT와 통신할 수 있습니다. `PollForNotifications` 테스트 세트에서 IDT의 알림을 확인할 수 있습니다. `GetContextValue ` 및 `GetContextString` 테스트 세트가 IDT 컨텍스트에서 값을 검색할 수 있도록 합니다. 자세한 내용은 [IDT 컨텍스트 사용](idt-context.md) 단원을 참조하십시오. `SendResult` 테스트 세트에서 테스트 사례 결과를 IDT에 보고할 수 있습니다. 이 명령은 테스트 세트의 각 테스트 케이스 끝에서 직접적으로 호출해야 합니다. ### 호스트 상호작용 다음 명령을 사용하면 테스트 세트가 호스트 머신과 통신할 수 있습니다. `PollForNotifications` 테스트 세트에서 IDT의 알림을 확인할 수 있습니다. `GetContextValue ` 및 `GetContextString` 테스트 세트가 IDT 컨텍스트에서 값을 검색할 수 있도록 합니다. 자세한 내용은 [IDT 컨텍스트 사용](idt-context.md) 단원을 참조하십시오. `ExecuteOnHost` 테스트 세트가 로컬 머신에서 명령을 실행할 수 있도록 하고 IDT가 테스트 케이스 실행 수명 주기를 관리할 수 있도록 합니다. ## IDT CLI 명령을 활성화합니다. `run-suite` 명령 IDT CLI는 테스트 실행기가 테스트 실행을 사용자 지정할 수 있는 몇 가지 옵션을 제공합니다. 테스트 실행기가 이러한 옵션을 사용하여 사용자 지정 테스트 세트를 실행할 수 있도록 하려면 IDT CLI에 대한 지원을 구현해야 합니다. 지원을 구현하지 않는 경우, 테스트 실행기는 여전히 테스트를 실행할 수 있지만 일부 CLI 옵션은 제대로 작동하지 않습니다. 이상적인 고객 경험을 제공하려면 IDT CLI에서 `run-suite` 명령에 대한 다음 인수에 대한 지원을 구현하는 것이 좋습니다. `timeout-multiplier` 테스트를 실행하는 동안 모든 제한 시간에 적용할 1.0보다 큰 값을 지정합니다. 테스트 실행기는 이 인수를 사용하여 실행하려는 테스트 사례의 제한 시간을 늘릴 수 있습니다. 테스트 실행기가 `run-suite` 명령에서 이 인수를 지정하면 IDT는 이 인수를 사용하여 IDT\$1TEST\$1TIMEOUT 환경 변수의 값을 계산하고 IDT 컨텍스트에서 `config.timeoutMultiplier` 필드를 설정합니다. 이 인수를 뒷받침하려면 다음을 수행하여야 합니다. + `test.json` 파일의 제한 시간 값을 직접 사용하는 대신 IDT\$1TEST\$1TIMEOUT 환경 변수를 읽고 올바르게 계산된 제한 시간 값을 구합니다. + IDT 컨텍스트에서 `config.timeoutMultiplier` 값을 검색하여 장기 실행 제한 시간에 적용합니다. 제한 시간 이벤트로 인한 조기 종료에 대한 자세한 내용은 [종료 동작을 지정합니다.](#test-exec-exiting)을(를) 참조하세요. `stop-on-first-failure` 장애가 발생할 경우, IDT에서 모든 테스트 실행을 중지하도록 지정합니다. 테스트 실행기가 `run-suite` 명령에 이 인수를 지정하면 IDT는 장애가 발생하는 즉시 테스트 실행을 중단합니다. 그러나 테스트 케이스가 병렬로 실행되는 경우, 예상치 못한 결과가 발생할 수 있습니다. 지원을 구현하려면 IDT에서 이 이벤트가 발생할 경우, 테스트 로직에서 실행 중인 모든 테스트 사례를 중지하고, 임시 리소스를 정리하고, 테스트 결과를 IDT에 보고하도록 지시해야 합니다. 실패 시 조기 종료에 대한 자세한 내용은 [종료 동작을 지정합니다.](#test-exec-exiting) 섹션을 참조하세요. `group-id` 및 `test-id` IDT가 선택한 테스트 그룹 또는 테스트 케이스만 실행하도록 지정합니다. 테스트 실행기는 `run-suite` 명령과 함께 이러한 인수를 사용하여 다음과 같은 테스트 실행 동작을 지정할 수 있습니다. + 지정된 테스트 제품군에 있는 모든 테스트 그룹을 실행합니다. + 지정된 테스트 그룹 내에서 엄선된 테스트를 실행합니다. 이러한 인수를 지원하려면 테스트 세트의 상태 머신이 상태 머신의 특정 `RunTask` 및 `Choice` 상태 세트를 포함해야 합니다. 사용자 지정 상태 머신을 사용하지 않는 경우, 기본 IDT 상태 머신에 필요한 상태가 포함되므로 추가 조치를 취할 필요가 없습니다. 하지만 사용자 지정 상태 머신을 사용하는 경우에는 [상태 머신 예제: 사용자가 선택한 테스트 그룹 실행](idt-state-machine.md#allow-specific-groups)을(를) 샘플로 사용하여 상태 머신에 필요한 상태를 추가합니다. IDT CLI 명령에 대한 자세한 내용은 [사용자 지정 테스트 도구 모음 디버그 및 실행](run-tests-custom.md) 단원을 참조합니다. ## 이벤트 로그 작성 테스트가 실행되는 동안 `stdout` 및 `stderr`에 데이터를 보내 콘솔에 이벤트 로그와 오류 메시지를 기록합니다. 콘솔 메시지의 형식에 대한 자세한 정보는 [콘솔 메시지 형식](idt-review-results-logs.md#idt-console-format)에서 확인하세요. IDT가 테스트 세트 실행을 마치면 `/results//logs` 폴더에 있는 `test_manager.log` 파일에서도 이 정보를 확인할 수 있습니다. 테스트 대상 장치의 로그를 포함하여 테스트 실행의 로그를 `/results/execution-id/logs` 폴더에 있는 `_` 파일에 기록하도록 각 테스트 사례를 구성할 수 있습니다. 이렇게 하려면 `testData.logFilePath` 쿼리를 사용하여 IDT 컨텍스트에서 로그 파일의 경로를 검색하고 해당 경로에 파일을 만든 다음 원하는 콘텐츠를 작성해야 합니다. IDT는 실행 중인 테스트 케이스를 기반으로 경로를 자동으로 업데이트합니다. 테스트 사례에 대한 로그 파일을 만들지 않기로 선택하면 해당 테스트 사례에 대한 파일이 생성되지 않습니다. 필요에 따라 `/logs` 폴더에 추가 로그 파일을 생성하도록 텍스트 실행 파일을 설정할 수도 있습니다. 파일을 덮어쓰지 않도록 로그 파일 이름에 고유한 접두사를 지정하는 것이 좋습니다. ## 결과를 IDT에 보고합니다. IDT는 테스트 결과를 `awsiotdevicetester_report.xml` 및 `suite-name_report.xml` 파일에 기록합니다. 이 보고서 파일은 `/results//`에 위치합니다. 두 보고서 모두 테스트 세트의 실행 결과를 캡처합니다. IDT에서 이러한 보고서에 사용하는 스키마에 대한 자세한 내용은 [IDT 테스트 결과 및 로그 검토](idt-review-results-logs.md)을(를) 참조합니다. `suite-name_report.xml` 파일 내용을 채우려면 테스트 실행이 완료되기 전에 `SendResult` 명령을 사용하여 테스트 결과를 IDT에 보고해야 합니다. IDT에서 테스트 결과를 찾을 수 없는 경우, 테스트 사례에 오류가 발생합니다. 다음 Python 발췌문은 테스트 결과를 IDT로 보내는 명령을 보여줍니다. ``` request-variable = SendResultRequest(TestResult(result)) client.send_result(request-variable) ``` API를 통해 결과를 보고하지 않는 경우, IDT는 테스트 아티팩트 폴더에서 테스트 결과를 찾습니다. 이 폴더의 경로는 IDT 컨텍스트의 `testData.testArtifactsPath` 파일에 저장됩니다. 이 폴더에서 IDT는 찾은 첫 번째 알파벳순으로 정렬된 XML 파일을 테스트 결과로 사용합니다. 테스트 로직이 JUnit XML 결과를 생성하는 경우, 결과를 파싱한 다음 API를 사용하여 IDT에 제출하는 대신 아티팩트 폴더의 XML 파일에 테스트 결과를 기록하여 결과를 IDT에 직접 제공할 수 있습니다. 이 방법을 사용하는 경우, 테스트 로직이 테스트 결과를 정확하게 요약하고 결과 파일의 형식을 `suite-name_report.xml` 파일과 동일한 형식으로 지정해야 합니다. IDT는 제공된 데이터에 대한 검증을 수행하지 않습니다. 단, 다음과 같은 경우는 예외입니다. + IDT는 `testsuites` 태그의 모든 속성을 무시합니다. 대신 보고된 다른 테스트 그룹 결과에서 태그 속성을 계산합니다. + 하나 이상의 `testsuite` 태그가 `testsuites` 내에 있어야 합니다. IDT는 모든 테스트 사례에 동일한 아티팩트 폴더를 사용하고 테스트 실행 사이에 결과 파일을 삭제하지 않기 때문에 IDT에서 잘못된 파일을 읽을 경우, 이 방법을 사용하면 잘못된 보고가 발생할 수도 있습니다. 생성된 XML 결과 파일은 모든 테스트 사례에서 동일한 이름을 사용하여 각 테스트 사례의 결과를 덮어쓰고 IDT에서 사용할 수 있는 올바른 결과가 있는지 확인하는 것이 좋습니다. 테스트 세트의 보고에는 혼합된 접근 방식을 사용할 수 있습니다. 즉, 일부 테스트 사례에는 XML 결과 파일을 사용하고 다른 테스트 사례에는 API를 통해 결과를 제출하는 등 혼합된 접근 방식을 사용할 수 있지만 이 방법은 권장되지 않습니다. ## 종료 동작을 지정합니다. 테스트 케이스에서 실패 또는 오류 결과가 보고되더라도 텍스트 실행 파일이 항상 종료 코드 0으로 종료되도록 구성합니다. 0이 아닌 종료 코드는 테스트 케이스가 실행되지 않았음을 나타내거나 테스트 케이스 실행 파일이 IDT에 결과를 전달할 수 없는 경우에만 사용합니다. IDT가 0이 아닌 종료 코드를 받으면 테스트 케이스에 오류가 발생하여 테스트 케이스를 실행할 수 없게 된 것으로 표시합니다. IDT는 다음 이벤트에서 테스트 케이스가 완료되기 전에 테스트 케이스의 실행을 중단하도록 요청하거나 예상할 수 있습니다. 이 정보를 사용하여 테스트 케이스에서 이러한 각 이벤트를 감지하도록 테스트 케이스 실행 파일을 구성합니다. **제한 시간** 테스트 케이스가 `test.json` 파일에 지정된 제한 시간 값보다 오래 실행될 때 발생합니다. 테스트 실행기가 `timeout-multiplier` 인수를 사용하여 제한 시간 승수를 지정한 경우, IDT는 승수로 제한 시간 값을 계산합니다. 이 이벤트를 탐지하려면 IDT\$1TEST\$1TIMEOUT 환경 변수를 사용합니다. 테스트 실행기가 테스트를 시작하면 IDT는 IDT\$1TEST\$1TIMEOUT 환경 변수의 값을 계산된 제한 시간 값(초)으로 설정하고 변수를 테스트 케이스 실행 파일로 전달합니다. 변수 값을 읽어 적절한 타이머를 설정할 수 있습니다. **인터럽트** 테스트 러너가 IDT를 인터럽트할 때 발생합니다. 예를 들어, Ctrl\$1C 키를 누르면 됩니다. 터미널은 신호를 모든 하위 프로세스에 전파하므로 인터럽트 신호를 감지하도록 테스트 케이스에 신호 처리기를 구성하기만 하면 됩니다. 또는 정기적으로 API를 폴링하여 `PollForNotifications` API 응답의 `CancellationRequested` 부울 값을 확인할 수도 있습니다. IDT는 인터럽트 신호를 수신하면 `CancellationRequested` 부울 값을 `true`(으)로 설정합니다. **첫 번째 실패 시 중지** 현재 테스트 케이스와 병렬로 실행 중인 테스트 케이스가 실패하고 테스트 실행기가 `stop-on-first-failure` 인수를 사용하여 IDT에 오류가 발생할 경우, 중지하도록 지정하는 경우, 발생합니다. 이 이벤트를 탐지하기 위해 주기적으로 API를 폴링하여 `PollForNotifications` API 응답의 `CancellationRequested` 부울 값을 확인할 수 있습니다. IDT에서 장애가 발생하고 첫 번째 실패 시 중지되도록 구성된 경우, IDT는 `CancellationRequested` 부울 값을 `true`(으)로 설정합니다. 이러한 이벤트가 발생하면 IDT는 현재 실행 중인 테스트 케이스의 실행이 완료될 때까지 5분 동안 기다립니다. 실행 중인 모든 테스트 케이스가 5분 내에 종료되지 않으면 IDT는 각 프로세스를 강제로 중지합니다. 프로세스가 종료되기 전에 IDT에서 테스트 결과를 받지 못한 경우, 테스트 케이스가 제한 시간이 초과된 것으로 표시됩니다. 가장 좋은 방법은 테스트 케이스에서 이벤트 중 하나가 발생할 때 다음 작업을 수행하도록 하는 것입니다. 1. 일반 테스트 로직 실행을 중단합니다. 1. 테스트 대상 장치의 테스트 아티팩트와 같은 임시 리소스를 모두 정리합니다. 1. 테스트 실패 또는 오류와 같은 테스트 결과를 IDT에 보고합니다. 1. 종료 # IDT 컨텍스트 사용 IDT가 테스트 도구 모음을 실행할 때, 테스트 도구 모음은 각 테스트 실행 방식을 결정하는 데 사용할 수 있는 데이터 세트에 액세스할 수 있습니다. 이 데이터를 IDT 컨텍스트라고 합니다. 예를 들어 테스트 러너가 `userdata.json` 파일로 제공한 사용자 데이터 구성은 IDT 컨텍스트의 테스트 도구 모음에서 사용할 수 있도록 만들어졌습니다. IDT 컨텍스트는 읽기 전용 JSON 문서로 간주할 수 있습니다. 테스트 도구 모음은 객체, 배열, 숫자 등과 같은 표준 JSON 데이터 유형을 사용하여 컨텍스트에서 데이터를 검색하고, 컨텍스트에 데이터를 쓸 수 있습니다. ## 컨텍스트 스키마 IDT 컨텍스트는 다음 형식을 사용합니다. ``` { "config": { "timeoutMultiplier": timeout-multiplier }, "device": { }, "devicePool": { }, "resource": { "devices": [ { "name": "" } ] }, "testData": { "awsCredentials": { "awsAccessKeyId": "", "awsSecretAccessKey": "", "awsSessionToken": "" }, "logFilePath": "/path/to/log/file" }, "userData": { } } ``` `config` [`config.json` 파일](gg-core.md#config-json)의 정보. `config` 필드에는 다음과 같은 추가 필드도 포함됩니다. `config.timeoutMultiplier` 테스트 도구 모음에서 사용하는 모든 시간 제한 값의 승수입니다. 이 값은 IDT CLI에서 테스트 러너에 의해 지정됩니다. 기본값은 `1`입니다. `device` 테스트 실행을 위해 선택한 장치에 대한 정보. 이 정보는 선택한 장치의 [`device.json` 파일](set-config-custom.md#device-config-custom)에 있는 `devices` 배열 요소와 동일합니다. `devicePool` 테스트 실행을 위해 선택한 장치 풀에 대한 정보. 이 정보는 선택한 장치 풀에 대해 `device.json` 파일에 정의된 최상위 장치 풀 배열 요소와 동일합니다. `resource` `resource.json` 파일의 리소스 장치에 대한 정보. `resource.devices` 이 정보는 `resource.json` 파일에 정의된 `devices` 배열과 동일합니다. 각 `devices` 요소에는 다음과 같은 추가 필드가 포함됩니다. `resource.device.name` 리소스 장치의 이름입니다. 이 값은 `test.json` 파일의 `requiredResource.name` 값으로 설정됩니다. `testData.awsCredentials` 테스트에서 AWS 클라우드에 연결하는 데 사용되는 AWS 자격 증명입니다. 이 정보는 `config.json` 파일에서 가져옵니다. `testData.logFilePath` 테스트 사례가 로그 메시지를 기록하는 로그 파일의 경로입니다. 이 파일이 존재하지 않는 경우 테스트 도구 모음에서 해당 파일을 생성합니다. `userData` 테스트 러너가 [`userdata.json` 파일](set-config-custom.md#userdata-config-custom)에서 제공한 정보. ## 컨텍스트에서 데이터 액세스 JSON 파일 및 `GetContextValue` 및 `GetContextString` API로 실행 가능한 텍스트 파일에서 JSONPath 표기법을 사용하여 컨텍스트를 쿼리할 수 있습니다. IDT 컨텍스트에 액세스하기 위한 JSONPath 문자열의 구문은 다음과 같이 다양합니다. + `suite.json`와(과) `test.json`에서는 `{{query}}`을(를) 사용합니다. 즉, 루트 요소 `$.`을(를) 사용하여 표현식을 시작하지 마십시오. + `statemachine.json`에서는 `{{$.query}}`을(를) 사용합니다. + API 명령에서는 명령에 따라 `query` 또는 `{{$.query}}`을(를) 사용합니다. 자세한 내용을 알아보려면 SDK에서 인라인 설명서를 참조하세요. 다음 표에서는 일반적인 JSONPath 표현식의 연산자를 설명합니다. | Operator | Description | | --- |--- | | \$1 | The root element. Because the top-level context value for IDT is an object, you will typically use \$1. to start your queries. | | .childName | Accesses the child element with name childName from an object. If applied to an array, yields a new array with this operator applied to each element. The element name is case sensitive. For example, the query to access the awsRegion value in the config object is \$1.config.awsRegion. | | [start:end] | Filters elements from an array, retrieving items beginning from the 시작 index and going up to the end index, both inclusive. | | [index1, index2, ... , indexN] | Filters elements from an array, retrieving items from only the specified indices. | | [?(expr)] | Filters elements from an array using the expr expression. This expression must evaluate to a boolean value. | 필터 표현식을 만들려면 다음 구문을 사용하십시오. ``` | operator | ``` 이 구문에서: + `jsonpath`은(는) 표준 JSON 구문을 사용하는 JSONPath입니다. + `value`은(는) 표준 JSON 구문을 사용하는 모든 사용자 지정 값입니다. + `operator`는 다음 작업 중 하나를 호출합니다. + `<` (미만) + `<=` (이하) + `==` (같음) 표현식의 JSONPath 또는 값이 배열, 부울 또는 객체 값인 경우 이것이 사용할 수 있는 유일하게 지원되는 바이너리 연산자입니다. + `>=` (이상) + `>` (초과) + `=~`(정규 표현식 일치). 필터 표현식에서 이 연산자를 사용하려면 표현식 왼쪽의 JSONPath 또는 값이 문자열로 평가되어야 하고, 오른쪽은 [RE2 구문](https://github.com/google/re2/wiki/Syntax)을 따르는 패턴 값이어야 합니다. \$1\$1*query*\$1\$1 형식의 JSONPath 쿼리를 `test.json` 파일의 `args` 및 `environmentVariables` 필드, `suite.json` 파일의 `environmentVariables` 필드 내에서 자리 표시자 문자열로 사용할 수 있습니다. IDT는 컨텍스트 조회를 수행하고 쿼리의 평가된 값으로 필드를 채웁니다. 예를 들어 `suite.json` 파일에서 자리 표시자 문자열을 사용하여 각 테스트 사례에 따라 변경되는 환경 변수 값을 지정할 수 있으며, IDT는 환경 변수를 각 테스트 사례에 맞는 값으로 채웁니다. 하지만 `test.json` 및 `suite.json` 파일에서 자리 표시자 문자열을 사용하는 경우 쿼리에 다음 사항을 고려해야 합니다. + 쿼리에서 나타나는 `devicePool` 키는 모두 소문자로 입력해야 합니다. 즉, `devicepool`을(를) 대신 사용하십시오. + 배열의 경우 문자열 배열만 사용할 수 있습니다. 또한 배열은 비표준 `item1, item2,...,itemN` 형식을 사용합니다. 배열에 요소가 하나만 포함된 경우 이 배열은 `item`(으)로 직렬화되어 문자열 필드와 구분할 수 없게 됩니다. + 자리 표시자를 사용하여 컨텍스트에서 객체를 검색할 수 없습니다. 이러한 고려 사항 때문에 가능하면 `test.json` 및 `suite.json` 파일의 자리 표시자 문자열 대신 API를 사용하여 테스트 로직의 컨텍스트에 액세스하는 것이 좋습니다. 하지만 경우에 따라 JSONPath 자리 표시자를 사용하여 단일 문자열을 가져와서 환경 변수로 설정하는 것이 더 편리할 수 있습니다. # 테스트 러너를 위한 설정 구성 사용자 지정 테스트 도구 모음을 실행하려면 테스트 러너가 실행하려는 테스트 도구 모음을 기반으로 설정을 구성해야 합니다. 설정은 `/configs/` 폴더에 있는 JSON 구성 파일 템플릿을 기반으로 지정됩니다. 필요한 경우 테스트 실행기는 IDT가 AWS 클라우드에 연결하는 데 사용할 AWS 자격 증명도 설정해야 합니다. 테스트 작성자는 [테스트 도구 모음을 디버깅](run-tests-custom.md)하도록 이러한 파일을 구성해야 합니다. 테스트 러너가 테스트 도구 모음을 실행하는 데 필요한 대로 다음 설정을 구성할 수 있도록 지침을 제공해야 합니다. ## device.json 구성 `device.json` 파일은 테스트가 실행되는 장치에 대한 정보가 필요합니다(예: IP 주소, 로그인 정보, 운영 체제, CPU 아키텍처). 테스트 러너는 `/configs/` 폴더에 있는 다음 템플릿 `device.json` 파일을 사용하여 이 정보를 제공할 수 있습니다. ``` [ { "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": "", } } ] } ] ``` 여기 설명된 것처럼 값이 포함된 모든 필드는 필수입니다. `id` *장치 풀*이라고 하는 장치 모음을 고유하게 식별하는 사용자 정의 영숫자 ID입니다. 풀에 속한 장치의 하드웨어는 서로 동일해야 합니다. 테스트 제품군을 실행할 때 풀에 있는 장치는 워크로드를 병렬화하는 데 사용됩니다. 다양한 테스트를 실행하기 위해 여러 장치가 사용됩니다. `sku` 테스트 대상 장치를 고유하게 식별하는 영숫자 값입니다. SKU는 정규화된 장치를 추적하는 데 사용됩니다. AWS Partner Device Catalog에 보드를 나열하려면 여기에서 지정하는 SKU가 나열 프로세스에서 사용하는 SKU와 일치해야 합니다. `features` 선택 사항. 장치의 지원되는 기능이 포함된 배열입니다. 장치 기능은 테스트 도구 모음에서 구성한 사용자 정의 값입니다. `device.json` 파일에 포함할 기능 이름 및 값에 대한 정보를 테스트 러너에게 제공해야 합니다. 예를 들어, 다른 장치의 MQTT 서버 역할을 하는 장치를 테스트하려는 경우 이름이 `MQTT_QOS`로 지정된 기능에 대해 지원되는 특정 수준을 검증하도록 테스트 로직을 구성할 수 있습니다. 테스트 러너는 이 기능 이름을 제공하고 기능 값을 장치에서 지원하는 QOS 수준으로 설정합니다. 제공된 정보는 `devicePool.features` 쿼리를 사용하여 [IDT 컨텍스트](idt-context.md)에서 검색하거나 `pool.features` 쿼리를 사용하여 [상태 머신 컨텍스트](idt-state-machine.md#state-machine-context)에서 검색할 수 있습니다. `features.name` 기능의 이름입니다. `features.value` 지원되는 기능 값. `features.configs` 필요한 경우 기능에 대한 구성 설정. `features.config.name` 구성 설정의 이름입니다. `features.config.value` 지원되는 설정값. `devices` 테스트할 풀의 장치 배열입니다. 최소 1개 이상의 장치가 필요합니다. `devices.id` 테스트 대상 장치의 고유한 사용자 정의 식별자입니다. `connectivity.protocol` 이러한 장치와 통신하는 데 사용되는 통신 프로토콜입니다. 풀의 각 장치는 동일한 프로토콜을 사용해야 합니다. 현재 지원되는 값은 `uart` 물리적 장치의 경우 및, `docker` Docker 컨테이너의 경우 `ssh` 입니다. `connectivity.ip` 테스트 대상 장치의 IP 입니다. 이 속성은 `connectivity.protocol`이 `ssh`로 설정된 경우에만 적용됩니다. `connectivity.port` 선택 사항. SSH 연결하는 데 사용하는 포트 번호입니다. 기본값은 4입니다. 이 속성은 `connectivity.protocol`이 `ssh`로 설정된 경우에만 적용됩니다. `connectivity.auth` 연결에 대한 인증 정보입니다. 이 속성은 `connectivity.protocol`이 `ssh`로 설정된 경우에만 적용됩니다. `connectivity.auth.method` 지정된 연결 프로토콜을 통해 장치에 액세스하는 데 사용되는 인증 방법입니다. 지원되는 값은 다음과 같습니다. + `pki` + `password` `connectivity.auth.credentials` 인증에 사용되는 자격 증명입니다. `connectivity.auth.credentials.password` 테스트 대상 장치에 로그인하기 위해 사용하는 암호입니다. 이 값은 `connectivity.auth.method`가 `password`로 설정된 경우에만 적용됩니다. `connectivity.auth.credentials.privKeyPath` 테스트 대상 장치에 로그인하는 데 사용하는 프라이빗 키의 전체 경로입니다. 이 값은 `connectivity.auth.method`가 `pki`로 설정된 경우에만 적용됩니다. `connectivity.auth.credentials.user` 테스트 대상 장치에 로그인하기 위한 사용자 이름입니다. `connectivity.serialPort` 선택 사항. 장치가 연결된 직렬 포트입니다. 이 속성은 `connectivity.protocol`이 `uart`로 설정된 경우에만 적용됩니다. `connectivity.containerId` 테스트 대상 Docker 컨테이너의 컨테이너 ID 또는 이름입니다. 이 속성은 `connectivity.protocol`이 `docker`로 설정된 경우에만 적용됩니다. `connectivity.containerUser` 선택 사항. 컨테이너 내부 사용자의 사용자 이름입니다. 기본값은 Dockerfile에 제공된 사용자입니다. 기본값은 4입니다. 이 속성은 `connectivity.protocol`이 `docker`로 설정된 경우에만 적용됩니다. 테스트 러너가 테스트를 위해 잘못된 장치 연결을 구성했는지 확인하기 위해 상태 머신 컨텍스트에서 `pool.Devices[0].Connectivity.Protocol`을 검색하고 이를 `Choice` 상태에서 예상한 값과 비교할 수 있습니다. 잘못된 프로토콜이 사용된 경우 `LogMessage` 상태를 사용하여 메시지를 인쇄하고 `Fail` 상태로 전환하세요. 또는 오류 처리 코드를 사용하여 잘못된 장치 유형에 대한 테스트 실패를 보고할 수 있습니다. ## (선택 사항) userdata.json 구성 `userdata.json` 파일에는 테스트 도구 모음에 필요하지만 `device.json` 파일에 지정되지 않은 모든 추가 정보가 들어 있습니다. 이 파일의 형식은 테스트 도구 모음에 정의된 [`userdata_scheme.json` 파일](idt-json-config.md#userdata-schema-json)에 따라 달라집니다. 테스트 작성자인 경우, 이 정보를 작성한 테스트 도구 모음을 실행할 사용자에게 제공해야 합니다. ## (선택 사항) resource.json 구성 `resource.json` 파일에는 리소스 장치로 사용될 모든 장치에 대한 정보가 들어 있습니다. 리소스 장치는 테스트 대상 장치의 특정 기능을 테스트하는 데 필요한 장치입니다. 예를 들어 장치의 Bluetooth 기능을 테스트하려면 리소스 장치를 사용하여 장치가 제대로 연결될 수 있는지 테스트할 수 있습니다. 리소스 장치는 선택 사항이며 필요한 만큼 리소스 장치를 요청할 수 있습니다. 테스트 작성자는 [test.json 파일](idt-json-config.md#test-json)을 사용하여 테스트에 필요한 리소스 장치 기능을 정의합니다. 그런 다음 테스트 러너는 `resource.json` 파일을 사용하여 필수 기능을 갖춘 리소스 장치 풀을 제공합니다. 이 정보를 작성한 테스트 도구 모음을 실행할 사용자에게 제공해야 합니다. 테스트 러너는 `/configs/` 폴더에 있는 다음 템플릿 `resource.json` 파일을 사용하여 이 정보를 제공할 수 있습니다. ``` [ { "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": "", } } ] } ] ``` 여기 설명된 것처럼 값이 포함된 모든 필드는 필수입니다. `id` *장치 풀*이라고 하는 장치 모음을 고유하게 식별하는 사용자 정의 영숫자 ID입니다. 풀에 속한 장치의 하드웨어는 서로 동일해야 합니다. 테스트 제품군을 실행할 때 풀에 있는 장치는 워크로드를 병렬화하는 데 사용됩니다. 다양한 테스트를 실행하기 위해 여러 장치가 사용됩니다. `features` 선택 사항. 장치의 지원되는 기능이 포함된 배열입니다. 이 필드에 필요한 정보는 테스트 도구 모음의 [test.json 파일](idt-json-config.md#test-json)에 정의되어 있으며, 실행할 테스트와 이 테스트를 실행하는 방법을 결정합니다. 테스트 도구 모음에 기능이 필요하지 않은 경우에는 이 필드가 필요하지 않습니다. `features.name` 기능의 이름입니다. `features.version` 기능 버전. `features.jobSlots` 장치를 동시에 사용할 수 있는 테스트 수를 나타내는 설정입니다. 기본값은 `1`입니다. `devices` 테스트할 풀의 장치 배열입니다. 최소 1개 이상의 장치가 필요합니다. `devices.id` 테스트 대상 장치의 고유한 사용자 정의 식별자입니다. `connectivity.protocol` 이러한 장치와 통신하는 데 사용되는 통신 프로토콜입니다. 풀의 각 장치는 동일한 프로토콜을 사용해야 합니다. 현재 지원되는 값은 `uart` 물리적 장치의 경우 및, `docker` Docker 컨테이너의 경우 `ssh` 입니다. `connectivity.ip` 테스트 대상 장치의 IP 입니다. 이 속성은 `connectivity.protocol`이 `ssh`로 설정된 경우에만 적용됩니다. `connectivity.port` 선택 사항. SSH 연결하는 데 사용하는 포트 번호입니다. 기본값은 4입니다. 이 속성은 `connectivity.protocol`이 `ssh`로 설정된 경우에만 적용됩니다. `connectivity.auth` 연결에 대한 인증 정보입니다. 이 속성은 `connectivity.protocol`이 `ssh`로 설정된 경우에만 적용됩니다. `connectivity.auth.method` 지정된 연결 프로토콜을 통해 장치에 액세스하는 데 사용되는 인증 방법입니다. 지원되는 값은 다음과 같습니다. + `pki` + `password` `connectivity.auth.credentials` 인증에 사용되는 자격 증명입니다. `connectivity.auth.credentials.password` 테스트 대상 장치에 로그인하기 위해 사용하는 암호입니다. 이 값은 `connectivity.auth.method`가 `password`로 설정된 경우에만 적용됩니다. `connectivity.auth.credentials.privKeyPath` 테스트 대상 장치에 로그인하는 데 사용하는 프라이빗 키의 전체 경로입니다. 이 값은 `connectivity.auth.method`가 `pki`로 설정된 경우에만 적용됩니다. `connectivity.auth.credentials.user` 테스트 대상 장치에 로그인하기 위한 사용자 이름입니다. `connectivity.serialPort` 선택 사항. 장치가 연결된 직렬 포트입니다. 이 속성은 `connectivity.protocol`이 `uart`로 설정된 경우에만 적용됩니다. `connectivity.containerId` 테스트 대상 Docker 컨테이너의 컨테이너 ID 또는 이름입니다. 이 속성은 `connectivity.protocol`이 `docker`로 설정된 경우에만 적용됩니다. `connectivity.containerUser` 선택 사항. 컨테이너 내부 사용자의 사용자 이름입니다. 기본값은 Dockerfile에 제공된 사용자입니다. 기본값은 4입니다. 이 속성은 `connectivity.protocol`이 `docker`로 설정된 경우에만 적용됩니다. ## (선택 사항) config.json 구성 `config.json` 파일 형식의 IDT용 구성 정보가 들어 있습니다. 일반적으로 테스트 실행기는 IDT 및 선택적으로 AWS 리전에 대한 AWS 사용자 자격 증명을 제공하는 경우를 제외하고이 파일을 수정할 필요가 없습니다. 필요한 권한이 있는 자격 증명이 제공된 경우 AWS AWS IoT 디바이스 테스터는 사용량 지표를 수집하여 제출합니다 AWS. 이는 옵트인 기능이며 IDT 기능을 개선하는 데 사용됩니다. 자세한 내용은 [IDT 사용량 지표](idt-usage-metrics.md) 단원을 참조하십시오. 테스트 실행기는 다음 방법 중 하나로 AWS 자격 증명을 구성할 수 있습니다. + **보안 인증 파일** IDT는 AWS CLI와 동일한 자격 증명 파일을 사용합니다. 자세한 내용은 [구성 및 자격 증명 파일](https://docs.aws.amazon.com/cli/latest/userguide/cli-config-files.html)을 참조하십시오. 자격 증명 파일의 위치는 사용하는 운영 체제에 따라 달라집니다. + macOS, Linux의 경우: `~/.aws/credentials` + Windows: `C:\Users\UserName\.aws\credentials` + **환경 변수** 환경 변수는 운영 체제에서 유지 관리하고 시스템 명령에서 사용하는 변수입니다. SSH 세션 중에 정의된 변수는 해당 세션이 종료된 후에는 사용할 수 없습니다. IDT는 `AWS_ACCESS_KEY_ID` 및 `AWS_SECRET_ACCESS_KEY` 환경 변수를 사용하여 AWS 자격 증명을 저장할 수 있습니다. Linux, macOS 또는 Unix에서 이러한 변수를 설정하려면 **export**를 사용합니다. ``` export AWS_ACCESS_KEY_ID= export AWS_SECRET_ACCESS_KEY= ``` Windows에서 이러한 변수를 설정하려면 **set**을 사용합니다. ``` set AWS_ACCESS_KEY_ID= set AWS_SECRET_ACCESS_KEY= ``` IDT에 대한 AWS 자격 증명을 구성하려면 테스트 실행기가 `/configs/` 폴더에 있는 `config.json` 파일의 `auth` 섹션을 편집합니다. ``` { "log": { "location": "logs" }, "configFiles": { "root": "configs", "device": "configs/device.json" }, "testPath": "tests", "reportPath": "results", "awsRegion": "", "auth": { "method": "file | environment", "credentials": { "profile": "" } } } ] ``` 여기 설명된 것처럼 값이 포함된 모든 필드는 필수입니다. **참고** 이 파일의 모든 경로는 **을 기준으로 정의됩니다. `log.location` **에 있는 로그 폴더의 경로. `configFiles.root` 구성 파일이 포함된 폴더 경로입니다. `configFiles.device` `device.json` 파일 경로입니다. `testPath` 테스트 도구 모음이 들어 있는 폴더의 경로. `reportPath` IDT에서 테스트 도구 모음을 실행한 후 테스트 결과를 포함할 폴더의 경로입니다. `awsRegion` 선택 사항. 테스트 제품군에서 사용할 AWS 리전입니다. 설정하지 않으면 테스트 도구 모음은 각 테스트 도구 모음에 지정된 기본 리전을 사용합니다. `auth.method` IDT가 자격 AWS 증명을 검색하는 데 사용하는 메서드입니다. 지원되는 값은 보안 인증 파일에서 보안 인증을 검색하는 `file`와(과) 환경 변수를 사용하여 보안 인증을 검색하는 `environment`입니다. `auth.credentials.profile` 보안 인증 파일에서 사용할 보안 인증 프로필. 이 속성은 `auth.method`이 `file`로 설정된 경우에만 적용됩니다. # 사용자 지정 테스트 도구 모음 디버그 및 실행 [필요한 구성](set-config-custom.md)이 설정되면 IDT에서 테스트 도구 모음을 실행할 수 있습니다. 전체 테스트 제품군의 런타임은 하드웨어와 테스트 제품군의 구성에 따라 달라집니다. 참고로 Raspberry Pi 3B에서 전체 AWS IoT Greengrass 검증 테스트 제품군을 완료하는 데 약 30분이 걸립니다. 3B 테스트 제품군을 작성할 때 IDT를 사용하여 테스트 제품군을 디버그 모드에서 실행하여 코드를 실행하기 전에 검사하거나 테스트 실행기에 제공할 수 있습니다. ## IDT를 디버그 모드에서 실행합니다. 테스트 도구 모음은 장치와 상호 작용하고, 컨텍스트를 제공하고, 결과를 받기 위해 IDT를 사용하기 때문에 IDT 상호 작용 없이 IDE에서 테스트 도구 모음을 간단히 디버깅할 수는 없습니다. 이를 위해 IDT CLI는 IDT를 디버그 모드에서 실행할 수 있는 `debug-test-suite` 명령을 제공합니다. 다음 명령을 실행하여 `debug-test-suite`에 대해 사용 가능한 옵션을 봅니다. ``` devicetester_[linux | mac | win_x86-64] debug-test-suite -h ``` IDT를 디버그 모드에서 실행할 때 IDT는 실제로 테스트 도구 모음을 시작하거나 상태 머신을 실행하지 않습니다. 대신 IDE와 상호 작용하여 IDE에서 실행 중인 테스트 도구 모음의 요청에 응답하고 콘솔에 로그를 인쇄합니다. IDT는 타임아웃이 발생하지 않으며 수동으로 중단될 때까지 종료를 기다립니다. 디버그 모드에서도 IDT는 상태 머신을 실행하지 않으며 보고서 파일을 생성하지 않습니다. 테스트 도구 모음을 디버깅하려면 IDE를 사용하여 IDT가 일반적으로 구성 JSON 파일에서 얻는 일부 정보를 제공해야 합니다. 다음 정보를 제공하는지 확인합니다. + 각 테스트의 환경 변수 및 인수 IDT는 `test.json` 또는 `suite.json`에서 이 정보를 읽지 않습니다. + 리소스 장치를 선택하기 위한 인수. IDT는 `test.json`에서 이 정보를 읽지 않습니다. 테스트 도구 모음을 디버깅하려면 다음 단계를 완료하세요. 1. 테스트 도구 모음을 실행하는 데 필요한 설정 구성 파일을 생성합니다. 예를 들어, 테스트 도구 모음에 `device.json`, `resource.json`, 및 `user data.json`이(가) 필요한 경우, 필요에 따라 모두 구성해야 합니다. 1. 다음 명령을 실행하여 IDT를 디버그 모드로 설정하고 테스트를 실행하는 데 필요한 장치를 선택합니다. ``` devicetester_[linux | mac | win_x86-64] debug-test-suite [options] ``` 이 명령을 실행하면 IDT는 테스트 도구 모음의 요청을 기다린 다음 요청에 응답합니다. 또한 IDT는 IDT Client SDK의 케이스 프로세스에 필요한 환경 변수를 생성합니다. 1. IDE에서 `run` 또는 `debug` 구성을 사용하여 다음을 수행합니다. 1. IDT에서 생성한 환경 변수의 값을 설정합니다. 1. `test.json` 및 `suite.json` 파일에 지정한 모든 환경 변수 또는 인수의 값을 설정합니다. 1. 필요에 따라 중단점을 설정합니다. 1. IDE에서 테스트 도구 모음을 실행합니다. 필요한 횟수만큼 테스트 도구 모음을 디버깅하고 다시 실행할 수 있습니다. 디버그 모드에서는 IDT가 타임아웃되지 않습니다. 1. 디버깅을 완료한 후 IDT를 중단하여 디버그 모드를 종료하십시오. ## 테스트를 실행하기 위한 IDT CLI 명령 다음 단원에서는 IDT CLI 명령에 대해 설명합니다. ------ #### [ IDT v4.0.0 ] `help` 지정된 명령에 대한 정보를 나열합니다. `list-groups` 지정된 테스트 제품군에 있는 그룹을 나열합니다. `list-suites` 사용 가능한 테스트 제품군을 나열합니다. `list-supported-products` 현재 IDT 버전에 사용할 수 있는 IDT 버전,이 경우 AWS IoT Greengrass 버전 및 AWS IoT Greengrass 검증 테스트 제품군 버전에 지원되는 제품을 나열합니다. `list-test-cases` 주어진 테스트 그룹의 테스트 사례를 나열합니다. 다음 옵션이 지원됩니다. + `group-id`. 검색할 테스트 그룹입니다. 이 옵션은 필수이며 단일 그룹을 지정해야 합니다. `run-suite` 장치의 풀에 대해 테스트 제품군을 실행합니다. 다음은 몇 가지 일반적으로 사용되는 옵션입니다: + `suite-id`. 실행할 테스트 제품군 버전입니다. 지정하지 않으면 IDT는 `tests` 폴더의 최신 버전을 사용합니다. + `group-id`. 실행할 테스트 그룹(쉼표로 구분된 목록). 지정하지 않으면 IDT는 테스트 제품군의 모든 테스트 그룹을 실행합니다. + `test-id`. 실행할 테스트 케이스(쉼표로 구분된 목록). 지정된 경우, `group-id`은(는) 단일 그룹을 지정해야 합니다. + `pool-id`. 테스트할 장치 풀. `device.json` 파일에 여러 장치 풀이 정의되어 있는 경우, 테스트 실행기는 하나의 풀을 지정해야 합니다. + `timeout-multiplier`. 사용자 정의 승수를 사용하여 테스트에 대해 `test.json` 파일에 지정된 테스트 실행 제한 시간을 수정하도록 IDT를 구성합니다. + `stop-on-first-failure`. 첫 번째 실패 시 실행을 중지하도록 IDT를 구성합니다. 이 옵션은 지정된 테스트 그룹을 디버깅하는 데 `group-id`와(과) 함께 사용해야 합니다. + `userdata`. 테스트 도구 모음을 실행하는 데 필요한 사용자 데이터 정보가 포함된 파일을 설정합니다. 이는 테스트 도구 모음 `suite.json` 파일에서 `userdataRequired`이(가) true로 설정된 경우에만 필요합니다. `run-suite` 옵션에 대한 자세한 내용은 다음 `help` 옵션을 사용하십시오. ``` devicetester_[linux | mac | win_x86-64] run-suite -h ``` `debug-test-suite` 테스트 도구 모음을 디버그 모드에서 실행합니다. 자세한 내용은 [IDT를 디버그 모드에서 실행합니다.](#idt-debug-mode) 단원을 참조하십시오. ------ # IDT 테스트 결과 및 로그 검토 이 섹션에서는 IDT가 콘솔 로그와 테스트 보고서를 생성하는 형식을 설명합니다. ## 콘솔 메시지 형식 AWS IoT 디바이스 테스터는 테스트 제품군을 시작할 때 콘솔에 메시지를 인쇄하는 데 표준 형식을 사용합니다. 다음 발췌문은 IDT에서 생성한 콘솔 메시지의 한 가지 예를 보여줍니다. ``` time="2000-01-02T03:04:05-07:00" level=info msg=Using suite: MyTestSuite_1.0.0 executionId=9a52f362-1227-11eb-86c9-8c8590419f30 ``` 대부분의 콘솔 메시지는 다음 필드로 구성되어 있습니다. `time` 로깅된 이벤트의 전체 ISO 8601 타임스탬프. `level` 로깅된 이벤트의 메시지 수준. 일반적으로 로깅된 메시지 수준은 `info`, `warn` 또는 `error`중 하나입니다. IDT는 예상 이벤트가 발생하여 이벤트가 일찍 종료되는 경우 `fatal` 또는 `panic` 메시지를 표시합니다. `msg` 로깅된 메시지. `executionId` 현재 IDT 프로세스의 고유 ID 문자열입니다. 이 ID는 개별 IDT 실행을 구분하는 데 사용됩니다. 테스트 제품군에서 생성된 콘솔 메시지는 테스트 대상 장치와 테스트 제품군, 테스트 그룹 및 IDT가 실행하는 테스트 케이스에 대한 추가 정보를 제공합니다. 다음 발췌문은 테스트 제품군에서 생성한 콘솔 메시지의 한 가지 예를 보여줍니다: ``` 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 ``` 콘솔 메시지의 테스트 제품군 관련 부분에는 다음 필드가 포함됩니다. `suiteId` 현재 실행 중인 테스트 제품군의 이름. `groupId` 현재 실행 중인 테스트 그룹의 ID. `testCaseId` 현재 실행 중인 테스트 케이스의 ID. `deviceId` 현재 테스트 케이스에서 사용 중인 테스트 대상 장치의 ID. IDT에서 테스트 실행을 완료했을 때 콘솔에 테스트 요약을 인쇄하려면 상태 시스템에 [`Report` 상태](idt-state-machine.md#state-report)를 포함해야 합니다. 테스트 요약에는 테스트 제품군, 실행된 각 그룹의 테스트 결과, 생성된 로그 및 보고서 파일의 위치에 대한 정보가 포함됩니다. 다음 예제에서는 테스트 요약 메시지를 보여줍니다. ``` ========== 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 디바이스 테스터 보고서 스키마 `awsiotdevicetester_report.xml`은 다음 정보가 포함된 서명된 보고서입니다. + IDT 버전 + 테스트 제품군 버전입니다. + 보고서에 서명하는 데 사용된 보고서 서명 및 키. + `device.json` 파일에 지정된 SKU 및 장치 풀 이름. + 테스트된 제품 버전 및 장치 특성. + 테스트 결과의 집계 요약 이 정보는 `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 ``` `awsiotdevicetester_report.xml` 파일에는 테스트하는 제품에 대한 정보와 테스트 제품군을 실행한 후 확인된 제품 기능에 대한 정보를 포함하는 `` 태그가 포함되어 있습니다.`` 태그에 사용되는 속성 `name` 테스트하는 제품의 이름입니다. `version` 테스트하는 제품의 버전입니다. `features` 확인된 기능입니다. 필수로 `required` 표시된 특성은 테스트 제품군에서 장치를 검증하는 데 필요합니다. 다음 코드 조각은 `awsiotdevicetester_report.xml` 파일에 이 정보가 나타나는 방식을 보여 줍니다. ``` ``` `optional` 표시된 특성은 검증에 필요하지 않습니다. 다음 코드 조각은 선택적 기능을 보여 줍니다. ``` 
 ``` ## 테스트 제품군 보고서 스키마 `suite-name_Result.xml` 보고서는 [JUnit XML 형식](https://llg.cubic.org/docs/junit/)입니다. [Jenkins](https://jenkins.io/), [Bamboo](https://www.atlassian.com/software/bamboo) 등과 같은 지속적 통합 및 배포 플랫폼에 이 보고서를 통합할 수 있습니다. 보고서는 테스트 결과의 집계 요약을 포함합니다. ``` reason reason reason ``` `awsiotdevicetester_report.xml` 또는 `suite-name_report.xml`의 보고서 섹션에는 실행된 테스트 및 결과가 나열됩니다. 첫 번째 XML 태그 ``에는 테스트 실행의 요약이 포함됩니다. 예시: ``` ````` 태그에 사용되는 속성 `name` 테스트 제품군의 이름입니다. `time` 테스트 제품군를 실행하는 데 걸린 시간(초). `tests` 실행된 테스트의 수입니다. `failures` 실행되었지만 통과하지 못한 테스트의 수입니다. `errors` IDT에서 실행하지 못한 테스트의 수입니다. `disabled` 이 속성은 사용되지 않으므로 무시해도 좋습니다. 테스트 실패 또는 오류의 경우 `` XML 태그를 검토하여 실패한 테스트를 식별할 수 있습니다. `` 태그 내부의 `` XML 태그는 테스트 그룹에 대한 테스트 결과 요약을 보여 줍니다. 예시: ``` ``` 형식은 `` 태그와 비슷하지만, 사용되지 않고 무시할 수 있는 `skipped` 속성이 있습니다. 각 `` XML 태그 내부에는 테스트 그룹에 실행된 각 테스트에 대한 `` 태그가 있습니다. 예시: ``` > ````` 태그에 사용되는 속성 `name` 테스트의 이름입니다. `attempts` IDT에서 테스트 사례를 실행한 횟수입니다. 테스트가 실패하거나 오류가 발생하는 경우 문제 해결에 대한 정보와 함께 `` 또는 `` 태그가 `` 태그에 추가됩니다. 예시: ``` Reason for the test failure Reason for the test execution error ``` # IDT 사용량 지표 자격 AWS 증명에 필요한 권한을 제공하는 경우 AWS IoT 디바이스 테스터는 사용량 지표를 수집하여에 제출합니다 AWS. 이는 옵트인 기능이며 IDT 기능을 개선하는 데 사용됩니다. IDT는 다음과 같은 정보를 수집합니다. + AWS 계정 IDT를 실행하는 데 사용되는 ID + 테스트 실행에 사용된 IDT CLI 명령 + 실행되는 테스트 제품군 + ** 폴더의 테스트 제품군 + 디바이스 풀에 구성된 디바이스 수 + 테스트 케이스 이름 및 런타임 + 테스트 결과 정보(예: 테스트 통과, 실패, 오류 발생 또는 건너뛰었는지 여부) + 제품 기능 테스트 + IDT 종료 행동(예: 예상치 못한 종료 또는 조기 종료) IDT가 전송하는 모든 정보는 `/results//` 폴더의 `metrics.log` 파일에도 기록됩니다. 로그 파일을 보면 테스트 실행 중에 수집된 정보를 볼 수 있습니다. 이 파일은 사용량 지표를 수집하도록 선택한 경우에만 생성됩니다. 지표 수집을 비활성화하기 위해 추가 조치를 취할 필요가 없습니다. 자격 AWS 증명을 저장하지 말고 자격 증명이 저장되어 있는 경우 해당 AWS 자격 증명에 액세스하도록 `config.jso`n 파일을 구성하지 마십시오. ## 자격 AWS 증명 구성 가 아직 없는 경우 [생성](#idt-metrics-aws-account) AWS 계정해야 합니다. 이미가 있는 경우 IDT가 사용자를 대신하여에 사용량 지표를 [전송할 수 있도록 계정에 필요한 권한을 구성](#idt-metrics-permissions)하기만 AWS 계정하면 AWS 됩니다. ### 1단계: 생성 AWS 계정 이 단계에는 AWS 계정을 생성하고 구성합니다. 가 이미 있는 경우 로 AWS 계정건너뜁니다[2단계: IDT에 대한 권한 구성](#idt-metrics-permissions). #### 에 가입 AWS 계정 이 없는 경우 다음 단계를 AWS 계정완료하여 생성합니다. **에 가입하려면 AWS 계정** 1. [https://portal.aws.amazon.com/billing/signup](https://portal.aws.amazon.com/billing/signup)을 엽니다. 1. 온라인 지시 사항을 따르세요. 등록 절차 중 전화 또는 텍스트 메시지를 받고 전화 키패드로 확인 코드를 입력하는 과정이 있습니다. 에 가입하면 AWS 계정*AWS 계정 루트 사용자*이 생성됩니다. 루트 사용자에게는 계정의 모든 AWS 서비스 및 리소스에 액세스할 권한이 있습니다. 보안 모범 사례는 사용자에게 관리 액세스 권한을 할당하고, 루트 사용자만 사용하여 [루트 사용자 액세스 권한이 필요한 작업](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_root-user.html#root-user-tasks)을 수행하는 것입니다. AWS 는 가입 프로세스가 완료된 후 확인 이메일을 보냅니다. 언제든지 [https://aws.amazon.com/](https://aws.amazon.com/)으로 이동하고 **내 계정**을 선택하여 현재 계정 활동을 확인하고 계정을 관리할 수 있습니다. #### 관리자 액세스 권한이 있는 사용자 생성 에 가입한 후 일상적인 작업에 루트 사용자를 사용하지 않도록 관리 사용자를 AWS 계정보호 AWS IAM Identity Center, AWS 계정 루트 사용자활성화 및 생성합니다. **보안 AWS 계정 루트 사용자** 1. **루트 사용자를** 선택하고 AWS 계정 이메일 주소를 입력하여 계정 소유자[AWS Management Console](https://console.aws.amazon.com/)로에 로그인합니다. 다음 페이지에서 비밀번호를 입력합니다. 루트 사용자를 사용하여 로그인하는 데 도움이 필요하면 *AWS Sign-In 사용 설명서*의 [루트 사용자로 로그인](https://docs.aws.amazon.com/signin/latest/userguide/console-sign-in-tutorials.html#introduction-to-root-user-sign-in-tutorial)을 참조하세요. 1. 루트 사용자의 다중 인증(MFA)을 활성화합니다. 지침은 *IAM 사용 설명서*의 [AWS 계정 루트 사용자(콘솔)에 대한 가상 MFA 디바이스 활성화를 참조하세요](https://docs.aws.amazon.com/IAM/latest/UserGuide/enable-virt-mfa-for-root.html). **관리자 액세스 권한이 있는 사용자 생성** 1. IAM Identity Center를 활성화합니다. 지침은 *AWS IAM Identity Center 사용 설명서*의 [AWS IAM Identity Center설정](https://docs.aws.amazon.com//singlesignon/latest/userguide/get-set-up-for-idc.html)을 참조하세요. 1. IAM Identity Center에서 사용자에게 관리 액세스 권한을 부여합니다. 를 자격 증명 소스 IAM Identity Center 디렉터리 로 사용하는 방법에 대한 자습서는 사용 *AWS IAM Identity Center 설명서*[의 기본값으로 사용자 액세스 구성을 IAM Identity Center 디렉터리](https://docs.aws.amazon.com//singlesignon/latest/userguide/quick-start-default-idc.html) 참조하세요. **관리 액세스 권한이 있는 사용자로 로그인** + IAM IDentity Center 사용자로 로그인하려면 IAM Identity Center 사용자를 생성할 때 이메일 주소로 전송된 로그인 URL을 사용합니다. IAM Identity Center 사용자를 사용하여 로그인[하는 데 도움이 필요하면 사용 설명서의 AWS 액세스 포털에 로그인](https://docs.aws.amazon.com/signin/latest/userguide/iam-id-center-sign-in-tutorial.html)을 참조하세요. *AWS Sign-In * **추가 사용자에게 액세스 권한 할당** 1. IAM Identity Center에서 최소 권한 적용 모범 사례를 따르는 권한 세트를 생성합니다. 지침은 *AWS IAM Identity Center 사용 설명서*의 [Create a permission set](https://docs.aws.amazon.com//singlesignon/latest/userguide/get-started-create-a-permission-set.html)를 참조하세요. 1. 사용자를 그룹에 할당하고, 그룹에 Single Sign-On 액세스 권한을 할당합니다. 지침은 *AWS IAM Identity Center 사용 설명서*의 [그룹 추가](https://docs.aws.amazon.com//singlesignon/latest/userguide/addgroups.html)를 참조하세요. ### 2단계: IDT에 대한 권한 구성 이 단계에서는 IDT가 테스트를 실행하고 IDT 사용 데이터를 수집하는 데 사용하는 권한을 구성합니다. AWS Management Console 또는 AWS Command Line Interface (AWS CLI)를 사용하여 IDT에 대한 IAM 정책과 사용자를 생성한 다음 사용자에게 정책을 연결할 수 있습니다. + [IDT에 대한 권한 구성(콘솔)](#idt-metrics-permissions-console) + [IDT에 대한 권한 구성(AWS CLI)](#idt-metrics-permissions-cli) **IDT에 대한 권한을 구성하려면(콘솔)** 콘솔을 사용하여 AWS IoT Greengrass용 IDT에 대한 권한을 구성하려면 다음 단계를 수행하세요. 1. [IAM 콘솔](https://console.aws.amazon.com/iam)에 로그인합니다. 1. 특정 권한으로 역할을 생성하는 권한을 부여하는 고객 관리형 정책을 만듭니다. 1. 탐색 창에서 **정책**을 선택한 후 **정책 생성**을 선택합니다. 1. **JSON** 탭에서 자리 표시자 콘텐츠를 다음 정책으로 바꿉니다. ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "iot-device-tester:SendMetrics" ], "Resource": "*" } ] } ``` ------ 1. **다음: 태그**를 선택합니다. 1. **다음: 검토**를 선택합니다. 1. **이름**에 **IDTUsageMetricsIAMPermissions**를 입력합니다. **Summary(요약)** 아래에서 정책에 의해 부여된 권한을 검토합니다. 1. **정책 생성**을 선택합니다. 1. IAM 사용자를 생성하고 사용자에 권한을 연결합니다. 1. IAM 사용자를 생성합니다. [IAM 사용 설명서](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_users_create.html#id_users_create_console)에서 *IAM 사용자 생성(콘솔)*의 1\$15단계를 따르세요. 이미 IAM 사용자를 생성한 경우 다음 단계로 건너뛰세요. 1. IAM 사용자에게 권한을 연결합니다. 1. **권한 설정** 페이지에서 **기존 정책 직접 연결**을 선택합니다. 1. 이전 단계에서 만든 **IDTGreengrassIAMPermissions** 정책을 검색합니다. 확인란을 선택합니다. 1. **다음: 태그**를 선택합니다. 1. **Next: Review(다음: 검토)**를 선택하여 선택 사항의 요약을 봅니다. 1. **사용자 생성**을 선택합니다. 1. 사용자의 액세스 키(액세스 키 ID와 비밀 액세스 키)를 보려면 암호와 액세스 키 옆에 있는 **Show(표시)**를 선택합니다. 액세스 키를 저장하려면 **Download .csv(csv 다운로드)**를 선택한 후 안전한 위치에 파일을 저장합니다. 나중에이 정보를 사용하여 AWS 자격 증명 파일을 구성합니다.   **IDT에 대한 권한을 구성하려면(AWS CLI)** 다음 단계에 따라를 사용하여 AWS CLI 에 대한 IDT 권한을 구성합니다 AWS IoT Greengrass. 콘솔에서 권한을 이미 구성한 경우 [IDT 테스트를 실행하도록 장치 구성](device-config-setup.md) 또는 [선택 사항: 용 IDT용 Docker 컨테이너 구성 AWS IoT Greengrass](docker-config-setup.md) 단계로 건너뜁니다. 1. 아직 설치되지 않은 AWS CLI 경우 컴퓨터에를 설치하고 구성합니다. *AWS Command Line Interface 사용 설명서* [AWS CLI설치](https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-install.html) 단계를 따르세요. **참고** AWS CLI 는 명령줄 셸의 AWS 서비스와 상호 작용하는 데 사용할 수 있는 오픈 소스 도구입니다. 1. IDT 및 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": \"*\"}]}' ``` **참고** Linux, macOS 또는 Unix 터미널 명령과 다른 JSON 구문을 사용하기 때문에 이 단계에는 Windows 명령 프롬프트 예제가 포함되어 있습니다. ------ 1. IAM 사용자를 만들고 AWS IoT Greengrass용 IDT에 필요한 권한을 연결합니다. 1. IAM 사용자를 생성합니다. ``` aws iam create-user --user-name user-name ``` 1. 생성한 `IDTUsageMetricsIAMPermissions` 정책을 새 IAM 사용자에 연결합니다. *user-name*을 IAM 사용자 이름으로 바꾸고 명령에서 **를 자신이 사용하는 AWS 계정계정의 ID로 바꾸세요. ``` aws iam attach-user-policy --user-name user-name --policy-arn arn:aws:iam:::policy/IDTGreengrassIAMPermissions ``` 1. 사용자에 대한 비밀 액세스 키를 만듭니다. ``` aws iam create-access-key --user-name user-name ``` 출력을 안전한 위치에 저장합니다. 나중에이 정보를 사용하여 AWS 자격 증명 파일을 구성합니다. ## IDT에 AWS 자격 증명 제공 IDT가 자격 AWS 증명에 액세스하고 지표를 제출하도록 허용하려면 다음을 AWS수행합니다. 1. IAM 사용자의 AWS 자격 증명을 환경 변수로 저장하거나 자격 증명 파일에 저장합니다. 1. 다음 명령을 실행하여 환경 변수를 설정합니다. ``` AWS_ACCESS_KEY_ID=access-key AWS_SECRET_ACCESS_KEY=secret-access-key ``` 1. 자격 증명 파일을 사용하려면 다음 정보를 `.aws/credentials file:`에 추가합니다. ``` [profile-name] aws_access_key_id=access-key aws_secret_access_key=secret-access-key ``` 1. `config.json` 파일의 `auth` 섹션을 구성합니다. 자세한 내용은 [(선택 사항) config.json 구성](set-config-custom.md#config-json-custom) 단원을 참조하십시오. # AWS IoT Greengrass 문제 해결을 위한 IDT 용 IDT는 오류 유형에 따라 이러한 오류를 다양한 위치에 AWS IoT Greengrass 기록합니다. 오류는 콘솔, 로그 파일 및 테스트 보고서에 작성됩니다. ## 오류 코드 다음 표에는 AWS IoT Greengrass용 IDT에서 생성되는 오류 코드가 나와 있습니다. | 오류 코드 | 오류 코드 이름 | 가능한 근본 원인 | 문제 해결 | | --- | --- | --- | --- | | 101 | InternalError | 내부 오류가 발생했습니다. | `/results` 디렉터리에서 로그를 확인합니다. 이 문제를 디버깅할 수 없을 경우 [AWS 개발자 지원](https://aws.amazon.com/premiumsupport/plans/developers/)에 문의하십시오. | | 102 | TimeoutError | 제한된 시간 범위 내에 테스트를 완료할 수 없습니다. 이 문제는 다음 경우에 발생할 수 있습니다. [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/greengrass/v1/developerguide/idt-troubleshooting.html) | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/greengrass/v1/developerguide/idt-troubleshooting.html) | | 103 | PlatformNotSupportError | `device.json`에 지정된 OS/아키텍처 조합이 잘못되었습니다. | 지원되는 조합 중 하나로 구성을 변경합니다. [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/greengrass/v1/developerguide/idt-troubleshooting.html) 자세한 내용은 [device.json 구성](set-config.md#device-config) 단원을 참조하십시오. | | 104 | VersionNotSupportError | AWS IoT Greengrass 코어 소프트웨어 버전은 사용 중인 IDT 버전에서 지원되지 않습니다. | **device\$1tester\$1bin version** 명령을 사용하여 AWS IoT Greengrass 코어 소프트웨어의 지원되는 버전을 찾습니다. 예를 들어, macOS를 사용하는 경우 **./devicetester\$1mac\$1x86\$164 version**를 사용합니다. 사용 중인 AWS IoT Greengrass 코어 소프트웨어 버전을 찾으려면: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/greengrass/v1/developerguide/idt-troubleshooting.html) 다른 버전의 AWS IoT Greengrass 코어 소프트웨어를 테스트할 수 있습니다. 자세한 내용은 [시작하기 AWS IoT Greengrass](gg-gs.md) 단원을 참조하십시오. | | 105 | LanguageNotSupportError | IDT는 AWS IoT Greengrass 라이브러리 및 SDKs에 대해서만 Python을 지원합니다. | 다음을 확인하십시오. [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/greengrass/v1/developerguide/idt-troubleshooting.html) | | 106 | ValidationError | `device.json` 또는 `config.json`의 일부 필드가 잘못되었습니다. | 보고서에서 오류 코드 오른쪽에 표시되는 오류 메시지를 확인합니다. [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/greengrass/v1/developerguide/idt-troubleshooting.html) | | 107 | SSHConnectionFailed | 테스트 시스템이 구성된 장치에 연결할 수 없습니다. | `device.json` 파일에서 다음 필드가 올바른지 확인합니다. [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/greengrass/v1/developerguide/idt-troubleshooting.html) 자세한 내용은 [device.json 구성](set-config.md#device-config) 단원을 참조하십시오. | | 108 | RunCommandError | 테스트가 테스트 대상 장치에서 명령을 실행하지 못했습니다. | `device.json`에서 구성된 사용자의 루트 액세스가 허용되는지 확인합니다. 일부 장치에서는 루트 액세스로 명령을 실행할 때 암호가 필요합니다. 암호 없이 루트 액세스가 허용되는지 확인합니다. 자세한 내용은 해당 장치에 대한 설명서를 참조하십시오. 장치에서 실패하는 명령을 수동으로 실행하여 오류가 발생하는지 확인합니다. | | 109 | PermissionDeniedError | 루트 액세스가 없습니다. | 장치에서 구성된 사용자의 루트 액세스를 설정합니다. | | 110 | CreateFileError | 파일을 만들 수 없습니다. | 장치의 디스크 공간과 디렉터리 권한을 확인합니다. | | 111 | CreateDirError | 디렉터리를 만들 수 없습니다. | 장치의 디스크 공간과 디렉터리 권한을 확인합니다. | | 112 | InvalidPathError | AWS IoT Greengrass 코어 소프트웨어 경로가 잘못되었습니다. | 오류 메시지에 있는 경로가 유효한지 확인합니다. `devicetester_greengrass_` 디렉터리에 있는 파일을 편집하지 마십시오. | | 113 | InvalidFileError | 파일이 잘못되었습니다. | 오류 메시지에 있는 파일이 유효한지 확인합니다. | | 114 | ReadFileError | 지정된 로그 파일을 읽을 수 없습니다. | 다음을 확인합니다. [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/greengrass/v1/developerguide/idt-troubleshooting.html) macOS에서 테스트하는 경우 열린 파일 제한을 늘리십시오. 기본 제한은 256이며, 이 값은 테스트에 충분합니다. | | 115 | FileNotFoundError | 필요한 파일을 찾을 수 없습니다. | 다음을 확인합니다. [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/greengrass/v1/developerguide/idt-troubleshooting.html) | | 116 | OpenFileFailed | 지정된 파일을 열 수 없습니다. | 다음을 확인합니다. [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/greengrass/v1/developerguide/idt-troubleshooting.html) macOS에서 테스트하는 경우 열린 파일 제한을 늘리십시오. 기본 제한은 256이며, 이 값은 테스트에 충분합니다. | | 117 | WriteFileFailed | 파일에 쓰지 못했습니다(테스트 중인 장치 또는 테스트 시스템일 수 있음). | 오류 메시지에 지정된 디렉터리가 존재하며 쓰기 권한이 있는지 확인합니다. | | 118 | FileCleanUpError | 테스트가 지정된 파일 또는 디렉터리를 제거하지 못했거나 원격 장치에서 지정된 파일을 마운트 해제하지 못했습니다. | 이진 파일이 아직 실행 중이면 파일이 잠겨 있을 수 있습니다. 프로세스를 종료하고 지정된 파일을 삭제합니다. | | 119 | InvalidInputError | 구성이 잘못되었습니다. | `suite.json` 파일이 유효한지 확인합니다. | | 120 | InvalidCredentialError | 자격 AWS 증명이 잘못되었습니다. | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/greengrass/v1/developerguide/idt-troubleshooting.html) | | 121 | AWSSessionError | AWS 세션을 생성하지 못했습니다. | 자격 AWS 증명이 유효하지 않거나 인터넷 연결이 불안정한 경우이 오류가 발생할 수 있습니다. 를 사용하여 AWS API 작업을 호출 AWS CLI 해 보십시오. | | 122 | AWSApiCallError | AWS API 오류가 발생했습니다. | 이 오류는 네트워크 문제가 원인일 수 있습니다. 네트워크를 확인하고 테스트 그룹을 다시 시도합니다. | | 123 | IpNotExistError | 연결 정보에 IP 주소가 포함되지 않습니다. | 인터넷 연결을 확인하십시오. AWS IoT Greengrass 콘솔을 사용하여 테스트에서 사용 중인 AWS IoT Greengrass 코어 사물의 연결 정보를 확인할 수 있습니다. 연결 정보에 엔드포인트 10개가 포함되어 있으면 일부 또는 전부를 제거하고 테스트를 다시 실행할 수 있습니다. 자세한 내용은 [연결 정보](https://docs.aws.amazon.com/cli/latest/reference/greengrass/get-connectivity-info.html)를 참조하십시오. | | 124 | OTAJobNotCompleteError | OTA 작업이 완료되지 않았습니다. | 인터넷 연결을 확인하고 OTA 테스트 그룹을 다시 시도합니다. | | 125 | CreateGreengrassServiceRoleError | 다음 중 하나가 발생했습니다. [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/greengrass/v1/developerguide/idt-troubleshooting.html) | AWS IoT Greengrass 서비스 역할을 구성합니다. 자세한 내용은 [Greengrass 서비스 역할](service-role.md) 단원을 참조하십시오. | | 126 | DependenciesNotPresentError | 해당 테스트에 필요한 하나 이상의 종속성이 장치에 없습니다. | 테스트 로그(`/results//logs/`)를 확인하여 장치에서 누락된 종속성이 무엇인지 파악합니다. | | 127 | InvalidHSMConfiguration | 제공된 HSM/PKCS 구성 파일이 올바르지 않습니다. | `device.json` 파일에서 PKCS\$111을 사용하여 HSM과 상호 작용하는 데 필요한 구성을 제공합니다. | | 128 | OTAJobNotSuccededError | OTA 작업이 성공하지 못했습니다. | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/greengrass/v1/developerguide/idt-troubleshooting.html) | | 129 | NoConnectivityError | 호스트 에이전트가 인터넷에 연결하지 못합니다. | 네트워크 연결 및 방화벽 설정을 확인하십시오. 연결 문제가 해결되면 테스트 그룹을 다시 시도하십시오. | | 130 | NoPermissionError | 용 IDT를 실행하는 데 사용 중인 IAM 사용자에게 IDT를 실행하는 데 필요한 AWS 리소스를 생성할 수 있는 권한이 AWS IoT Greengrass 없습니다. | AWS IoT Greengrass용 IDT를 실행하는 데 필요한 권한을 부여하는 정책 템플릿은 [권한 정책 템플릿](https://docs.aws.amazon.com/greengrass/latest/developerguide/policy-template.html)을 참조하십시오. | | 131 | LeftoverAgentExistError | IDT를 시작하려고 할 때 디바이스가 AWS IoT Greengrass 프로세스를 실행 중입니다 AWS IoT Greengrass. | 장치에서 실행 중인 기존 Greengrass 대몬(daemon)이 없는지 확인합니다. [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/greengrass/v1/developerguide/idt-troubleshooting.html) 재부팅 후 자동으로 시작되도록 AWS IoT Greengrass 구성된의 기존 설치를 사용하는 경우 재부팅 후 테스트 제품군을 실행하기 전에 데몬을 중지해야 합니다. | | 132 | DeviceTimeOffsetError | 장치의 시간이 잘못되었습니다. | 장치를 올바른 시간으로 설정하세요. | | 133 | InvalidMLConfiguration | 제공된 ML 구성이 잘못되었습니다. | `device.json` 파일에서 ML 추론 테스트를 실행하는 데 필요한 올바른 구성을 제공하세요. 자세한 내용은 [선택 사항: ML 검증을 위해 장치 구성](idt-ml-qualification.md) 단원을 참조하십시오. | ## AWS IoT Greengrass 오류에 대한 IDT 해결 IDT를 사용하는 경우 IDT를 실행하기 전에 올바른 구성 파일을 준비해야 합니다 AWS IoT Greengrass. 구문 분석 및 구성 오류가 발생할 경우 첫 번째 단계는 환경에 적합한 구성 템플릿을 찾아서 사용하는 것입니다. 그래도 문제가 발생할 경우 다음 디버깅 프로세스를 참조하십시오. **Topics** + [오류는 어디서 찾을 수 있나요?](#where-to-look) + [구문 분석 오류](#parse-error) + [필수 파라미터 누락 오류](#param-missing) + [테스트를 시작할 수 없음 오류](#could-not-start-test) + [리소스 액세스 권한 없음 오류](#not-authorized-to-access-resource) + [권한 거부 오류](#pwd-sudo) + [SSH 연결 오류](#ssh-connect-errors) + [제한 시간 오류](#test-timeout) + [테스트 도중 명령을 찾을 수 없음 오류](#cmd-not-found) + [macOS에서의 보안 예외](#macos-notarization-exception) ### 오류는 어디서 찾을 수 있나요? 상위 수준의 오류는 실행하는 동안 콘솔에 표시되고, 오류와 함께 실패한 테스트 요약은 모든 테스트가 완료될 때 표시됩니다. `awsiotdevicetester_report.xml`에 테스트 실패의 원인이 되는 모든 오류에 대한 요약이 들어 있습니다. 각 테스트 실행에 대한 로그 파일은 테스트를 실행하는 동안 콘솔에 표시된 테스트 실행에 대한 이름이 UUID인 디렉터리에 저장됩니다. 테스트 로그 디렉터리는 `/results//logs/`에 있습니다. 이 디렉터리에는 디버깅에 유용한 다음 파일이 포함되어 있습니다. | 파일 | 설명 | | --- | --- | | test\$1manager.log | 테스트를 실행하는 동안 콘솔에 작성된 모든 로그입니다. 결과 요약은 실패한 테스트 목록을 포함하는 이 파일의 끝에 있습니다. 이 파일의 경고 및 오류 로그에서 실패에 대한 일부 정보를 확인할 수 있습니다. | | \$1\$1.log | 특정 테스트에 대한 상세 로그입니다. | | \$1ggc\$1logs.tar.gz | 테스트 중에 생성된 AWS IoT Greengrass 코어 데몬에 대한 모든 로그의 압축된 모음입니다. 자세한 설명은 [문제 해결 AWS IoT Greengrass](https://docs.aws.amazon.com/greengrass/latest/developerguide/gg-troubleshooting.html)을 참조하십시오. | | \$1ota\$1logs.tar.gz | 테스트 중에 AWS IoT Greengrass OTA 에이전트가 생성한 로그의 압축된 모음입니다. OTA 테스트만 해당됩니다. | | \$1basic\$1assertion\$1publisher\$1ggad\$1logs.tar.gz | 테스트 중 AWS IoT 게시자 장치에 의해 생성된 로그의 압축 모음입니다. | | \$1basic\$1assertion\$1subscriber\$1ggad\$1logs.tar.gz | 테스트 중 AWS IoT 구독자 장치에 의해 생성된 로그의 압축 모음입니다. | ### 구문 분석 오류 경우에 따라 JSON 구성의 오타로 인해 구문 분석 오류가 발생할 수 있습니다. 대부분의 경우 문제는 JSON 파일에서 대괄호, 쉼표 또는 따옴표를 생략한 결과입니다. IDT는 JSON 확인을 수행하고 디버깅 정보를 인쇄합니다. IDT는 오류가 발생한 줄, 줄 번호, 구문 오류의 열 번호를 인쇄합니다. 이 정보만 있으면 오류를 수정할 수 있지만, 여전히 오류를 찾을 수 없는 경우 IDE나 텍스트 편집기(예: Atom 또는 Sublime)에서 또는 온라인 도구(예: JSONLint)를 통해 수동으로 확인을 수행할 수 있습니다. ### 필수 파라미터 누락 오류 IDT에 새로운 기능이 추가되고 있으므로 구성 파일에 대한 변경 사항이 도입될 수 있습니다. 기존 구성 파일을 사용하면 구성이 손상될 수 있습니다. 이 문제가 발생할 경우 `/results//logs` 아래의 `.log` 파일에 누락된 모든 파라미터가 명시적으로 나열됩니다. 또한 IDT는 JSON 구성 파일 스키마를 검사하여 지원되는 최신 버전이 사용되었는지 확인합니다. ### 테스트를 시작할 수 없음 오류 테스트 시작 중에 실패를 가리키는 오류가 발생할 수 있습니다. 몇 가지 원인이 있을 수 있으므로 다음을 수행하십시오. + 실행 명령에 포함한 풀 이름이 실제로 존재하는지 확인합니다. 풀 이름은 `device.json` 파일에서 직접 참조됩니다. + 풀에 있는 장치에 올바른 구성 파라미터가 있는지 확인합니다. ### 리소스 액세스 권한 없음 오류 터미널 출력 또는 `/results//logs`아래 `test_manager.log` 파일에 ` is not authorized to access this resource` 오류 메시지가 나타날 수 있습니다. 이 문제를 해결하려면 `AWSIoTDeviceTesterForGreengrassFullAccess` 관리형 정책을 테스트 사용자에게 연결합니다. 자세한 내용은 [생성 및 구성 AWS 계정](dev-tst-prereqs.md#config-aws-account-for-idt) 단원을 참조하십시오. ### 권한 거부 오류 IDT는 테스트 대상 장치에서 다양한 디렉터리와 파일에 대해 작업을 수행합니다. 이러한 작업 일부에는 루트 액세스가 필요합니다. 이러한 작업을 자동화하기 위해서는 IDT가 암호 입력 없이 sudo를 사용하여 명령을 실행할 수 있어야 합니다. 암호 입력 없이 sudo 액세스를 허용하려면 다음 단계를 수행합니다. **참고** `user` 및 `username`은 IDT가 테스트 대상 장치에 액세스하는 데 사용하는 SSH 사용자를 나타냅니다. 1. sudo 그룹에 SSH 사용자를 추가하려면 **sudo usermod -aG sudo ****을 사용하십시오. 1. 변경 사항을 적용하려면 로그아웃했다가 로그인하십시오. 1. `/etc/sudoers` 파일을 열고 파일 끝에 다음 줄을 추가합니다. ` ALL=(ALL) NOPASSWD: ALL` **참고** 모범 사례로, `/etc/sudoers`를 편집할 때는 **sudo visudo**를 사용하는 것이 좋습니다. ### SSH 연결 오류 IDT가 테스트 대상 장치에 연결할 수 없으면 연결 실패가 `/results//logs/.log`에 기록됩니다. 테스트 대상 장치에 대한 연결은 IDT가 수행하는 첫 번째 작업 중 하나이므로 SSH 실패 메시지는 이 로그 파일의 맨 위에 표시됩니다. 대부분의 Windows 설정은 PuTTy 터미널 애플리케이션을 사용하여 Linux 호스트에 연결합니다. 이 애플리케이션에서는 표준 PEM 프라이빗 키 파일을 PPK라는 전용 Windows 형식으로 변환해야 합니다. `device.json` 파일에서 IDT가 구성되면 PEM 파일만 사용합니다. PPK 파일을 사용하는 경우 IDT는 AWS IoT Greengrass 디바이스와의 SSH 연결을 생성할 수 없으며 테스트를 실행할 수 없습니다. ### 제한 시간 오류 각 테스트의 제한 시간 기본값에 적용되는 제한 시간 승수를 지정하여 각 테스트에 대한 제한 시간을 늘릴 수 있습니다. 이 플래그에 대해 구성된 값은 1.0보다 크거나 같아야 합니다. 제한 시간 승수를 사용하려면 테스트를 실행할 때 `--timeout-multiplier` 플래그를 사용합니다. 예시: ``` ./devicetester_linux run-suite --suite-id GGQ_1.0.0 --pool-id DevicePool1 --timeout-multiplier 2.5 ``` 자세한 내용을 보려면 `run-suite --help`을(를) 실행하세요. ### 테스트 도중 명령을 찾을 수 없음 오류 AWS IoT Greengrass 디바이스에서 테스트를 실행하려면 이전 버전의 OpenSSL 라이브러리(libssl1.0.0)가 필요합니다. 대부분의 최신 Linux 배포는 libssl 버전 1.0.2 이상(v1.1.0)을 사용합니다. 예를 들어 Raspberry Pi에서 다음 명령을 실행하여 필요한 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 ``` ### macOS에서의 보안 예외 macOS 10.15를 사용하는 호스트 컴퓨터에서 IDT를 실행하면 IDT에 대한 공증 티켓이 제대로 감지되지 않고 IDT 실행이 차단됩니다. IDT를 실행하려면 `devicetester_mac_x86-64` 실행 파일에 보안 예외를 부여해야 합니다. **IDT 실행 파일에 보안 예외를 부여하려면** 1. Apple 메뉴에서 **시스템 기본 설정**을 실행합니다. 1. **보안 및 개인 정보 보호**를 선택한 다음 **일반** 탭에서 잠금 아이콘을 클릭하여 보안 설정을 변경합니다. 1. `"devicetester_mac_x86-64" was blocked from use because it is not from an identified developer.` 메시지를 찾아 **모두 허용**을 선택합니다. 1. 보안 경고를 수락합니다. IDT 지원 정책에 대해 궁금한 점이 있는 경우 [AWS 고객 지원 센터](https://aws.amazon.com/contact-us/)에 문의하십시오. # 용 AWS IoT 디바이스 테스터에 대한 지원 정책 AWS IoT Greengrass V1 AWS IoT 용 디바이스 테스터(IDT) AWS IoT Greengrass 는 [AWS Partner 디바이스 카탈로그](https://devices.amazonaws.com/)에 포함할 AWS IoT Greengrass 디바이스를 검증하고 [검증](https://aws.amazon.com/partners/dqp/)할 수 있는 다운로드 가능한 테스트 프레임워크입니다. 최신 버전의 AWS IoT Greengrass 및 IDT를 사용하여 디바이스를 테스트하거나 검증하는 것이 좋습니다. 자세한 내용은 *AWS IoT Greengrass Version 2 개발자 안내서*의 [지원되는 AWS IoT Greengrass V2 IDT 버전](https://docs.aws.amazon.com/greengrass/v2/developerguide/dev-test-versions.html)을 참조하세요. 지원되는 AWS IoT Greengrass 및 IDT 버전을 사용하여 디바이스를 테스트하거나 검증할 수도 있습니다. [IDT의 지원되지 않는 버전](dev-test-versions.md#idt-unsupported-versions)을 계속 사용할 수 있지만, 이러한 버전에는 버그 수정 또는 업데이트가 제공되지 않습니다. **중요** 2022년 4월 4일부터 용 AWS IoT 디바이스 테스터(IDT)는 더 이상 서명된 검증 보고서를 생성 AWS IoT Greengrass V1 하지 않습니다. AWS IoT Greengrass V1 디바이스 검증 프로그램을 통해 [AWS Partner 디바이스 카탈로그](https://devices.amazonaws.com/)에 나열할 새 디바이스를 더 이상 검증할 수 없습니다. [AWS](https://aws.amazon.com/partners/programs/dqp/) Greengrass V1 디바이스를 검증할 수는 없지만 용 IDT를 계속 사용하여 Greengrass V1 디바이스를 테스트 AWS IoT Greengrass V1 할 수 있습니다. [AWS Partner 장치 카탈로그](https://devices.amazonaws.com/)에서 Greengrass 장치를 검증하고 등재하려면 [AWS IoT Greengrass V2용 IDT](https://docs.aws.amazon.com/greengrass/v2/developerguide/device-tester-for-greengrass-ug.html)를 사용하는 것이 좋습니다. 지원 정책에 대해 궁금한 점이 있는 경우 [AWS 고객 지원 센터](https://aws.amazon.com/contact-us/)에 문의하십시오.