기계 번역으로 제공되는 번역입니다. 제공된 번역과 원본 영어의 내용이 상충하는 경우에는 영어 버전이 우선합니다.

# Device Advisor 테스트 케이스
<a name="device-advisor-tests"></a>

Device Advisor는 6가지 범주로 미리 빌드된 테스트를 제공합니다.
+ [TLS](device-advisor-tests-tls.md)
+ [MQTT](device-advisor-tests-mqtt.md)
+ [섀도우](device-advisor-tests-shadow.md)
+ [작업 실행](device-advisor-tests-job-execution.md)
+ [권한 및 정책](device-advisor-tests-permissions-policies.md)
+ [장기간 테스트](device-advisor-tests-long-duration.md)

## Device Advisor 테스트 사례는 AWS Device Qualification Program에 적합합니다.
<a name="qualifiying-test-cases"></a>

[AWS 디바이스 자격 프로그램](https://aws.amazon.com/partners/programs/dqp/)에 따라 자격을 얻으려면 디바이스가 다음 테스트를 통과해야 합니다.

**참고**  
다음은 자격 테스트의 수정된 목록입니다.
+ [TLS 연결](device-advisor-tests-tls.md#TLS_Connect)(“TLS 연결”)
+ [TLS 잘못된 주체 이름 서버 인증서](device-advisor-tests-tls.md#TLS_Incorrect_Subject_Name)(“잘못된 주체 일반 이름(CN)/주체 대체 이름(SAN)”)
+ [TLS 비보안 서버 인증서](device-advisor-tests-tls.md#TLS_Unsecure_Server_Cert)(“공인 CA가 서명하지 않음”)
+ [AWS IoT 암호화 제품군에 대한 TLS 디바이스 지원](device-advisor-tests-tls.md#TLS_DeviceSupport_For_IOT)(" AWS IoT 권장 암호화 제품군에 대한 TLS 디바이스 지원")
+ [TLS 최대 크기 조각 수신](device-advisor-tests-tls.md#TLS_MaximumSize)('TLS 수신 최대 크기 조각')
+ [TLS 만료된 서버 인증서](device-advisor-tests-tls.md#TLS_Expired_Server_Cert)('만료된 서버 인증서')
+ [TLS 대형 서버 인증서](device-advisor-tests-tls.md#TLS_LargeServerCert)('TLS 대형 서버 인증서')
+ [MQTT Connect](device-advisor-tests-mqtt.md#MQTT_Connect)("Device send CONNECT to AWS IoT Core (Happy case)")
+ [MQTT 구독](device-advisor-tests-mqtt.md#MQTT_Subscribe)(“구독 가능(해피 케이스)”)
+ [MQTT 게시](device-advisor-tests-mqtt.md#MQTT_Publish)(“QoS0(해피 케이스)”)
+ [MQTT 연결 지터 재시도](device-advisor-tests-mqtt.md#MQTT_ConnectJitterBackoff)('지터 백오프를 사용하는 디바이스 연결 재시도 - CONNACK 응답 없음')

# TLS
<a name="device-advisor-tests-tls"></a>

이러한 테스트를 사용하여 디바이스와 간의 전송 계층 보안 프로토콜(TLS) AWS IoT 이 안전한지 확인합니다.

**참고**  
이제 Device Advisor에서 TLS 1.3을 지원합니다.

## 해피 패스
<a name="happy-path"></a>

**TLS 연결**  <a name="TLS_Connect"></a>
테스트 중인 디바이스가 TLS 핸드셰이크를 완료할 수 있는지 확인합니다 AWS IoT. 이 테스트는 클라이언트 디바이스의 MQTT 구현의 유효성을 검사하지 않습니다.  

**Example API 테스트 케이스 정의:**  
`EXECUTION_TIMEOUT`의 기본값은 5분입니다. 최상의 결과를 얻으려면 시간 제한 값을 2분으로 설정하는 것이 좋습니다.

```
"tests":[
   {
      "name":"my_tls_connect_test",
      "configuration": {
         // optional:
         "EXECUTION_TIMEOUT":"300",  //in seconds
      },
      "test":{
         "id":"TLS_Connect",
         "version":"0.0.0"
      }
   }
]
```

**Example 테스트 케이스 출력:**  
+ **통과** - 테스트 중인 디바이스가 TLS 핸드셰이크를 완료했습니다 AWS IoT.
+ **경고와 함께 전달 **- 테스트 중인 디바이스가 TLS 핸드셰이크를 완료 AWS IoT했지만 디바이스 또는의 TLS 경고 메시지가 있었습니다 AWS IoT.
+ **실패** - 핸드셰이크 오류 AWS IoT 로 인해 테스트 중인 디바이스가에서 TLS 핸드셰이크를 완료하지 못했습니다.

**TLS 최대 크기 조각 수신**  <a name="TLS_MaximumSize"></a>
이 테스트 케이스는 디바이스가 TLS 최대 크기 조각을 수신하고 처리할 수 있다는 것을 검증하는 데 도움이 됩니다. 대규모 페이로드를 수신하려면 테스트 디바이스가 QoS 1로 미리 구성된 주제를 구독해야 합니다. `${payload}` 구성을 사용하여 페이로드를 사용자 정의할 수 있습니다.  

**Example API 테스트 케이스 정의:**  
`EXECUTION_TIMEOUT`의 기본값은 5분입니다. 최상의 결과를 얻으려면 시간 제한 값을 2분으로 설정하는 것이 좋습니다.

```
"tests":[
   {
      "name":"TLS Receive Maximum Size Fragments",
      "configuration": {
         // optional:
         "EXECUTION_TIMEOUT":"300",  //in seconds
         "PAYLOAD_FORMAT":"{"message":"${payload}"}", // A string with a placeholder ${payload}, or leave it empty to receive a plain string.
         "TRIGGER_TOPIC": "test_1" // A topic to which a device will subscribe, and to which a test case will publish a large payload.
      },
      "test":{
         "id":"TLS_Receive_Maximum_Size_Fragments",
         "version":"0.0.0"
      }
   }
]
```

## 암호 그룹
<a name="cipher-suites"></a>

** AWS IoT 권장 암호 제품군에 대한 TLS 디바이스 지원**  <a name="TLS_DeviceSupport_For_IOT"></a>
테스트 중인 디바이스의 TLS 클라이언트 Hello 메시지에 있는 암호 제품군에 권장 [AWS IoT 암호 제품군](transport-security.md)이 포함되어 있다는 것을 검증합니다. 디바이스에서 지원하는 암호 제품군에 대한 다른 인사이트를 제공합니다.  

**Example API 테스트 케이스 정의:**  
`EXECUTION_TIMEOUT`의 기본값은 5분입니다. 제한 시간 값을 2분으로 설정하는 것을 권장합니다.

```
"tests":[
   {
      "name":"my_tls_support_aws_iot_cipher_suites_test",
      "configuration": {
         // optional:
         "EXECUTION_TIMEOUT":"300",  // in seconds
      },
      "test":{
         "id":"TLS_Support_AWS_IoT_Cipher_Suites",
         "version":"0.0.0"
      }
   }
]
```

**Example 테스트 케이스 출력:**  
+ **통과** - 테스트 중인 디바이스 암호 제품군에는 권장 AWS IoT 암호 제품군 중 하나 이상이 포함되어 있으며 지원되지 않는 암호 제품군은 포함되어 있지 않습니다.
+ **경고가 있는 통과** - 디바이스 암호 제품군에 하나 이상의 AWS IoT 암호 제품군이 포함되지만 다음과 같은 문제가 있습니다.

  1. 권장 암호 제품군이 포함되어 있지 않습니다.

  1. 여기에는에서 지원하지 않는 암호 제품군이 포함되어 있습니다 AWS IoT.

  지원되지 않는 암호 제품군이 안전한지 확인하는 것이 좋습니다.
+ **실패** - 테스트 중인 디바이스에 AWS IoT 지원되는 암호 제품군이 포함되어 있지 않습니다.

## 더 큰 크기의 서버 인증서
<a name="larger-size"></a>

**TLS 대형 서버 인증서**  <a name="TLS_LargeServerCert"></a>
디바이스에서 더 큰 크기의 서버 인증서를 수신하고 처리할 때 AWS IoT 로 TLS 핸드셰이크를 완료할 수 있다는 것을 검증합니다. 이 테스트에서 사용하는 서버 인증서의 크기(바이트)는 **TLS Connect** 테스트 사례 및 IoT Core에서 현재 사용되는 크기보다 20만큼 큽니다.이 테스트 사례에서는가 TLS에 대한 디바이스의 버퍼 공간을 AWS IoT 테스트합니다. 버퍼 공간이 충분히 크면 TLS 핸드셰이크가 오류 없이 모두 적용됩니다. 이 테스트는 디바이스의 MQTT 구현을 검증하지 않습니다. TLS 핸드셰이크 프로세스가 완료된 후 테스트 케이스가 종료됩니다.  

**Example API 테스트 케이스 정의:**  
`EXECUTION_TIMEOUT`의 기본값은 5분입니다. 최상의 결과를 얻으려면 시간 제한 값을 2분으로 설정하는 것이 좋습니다. 이 테스트 케이스는 실패하지만 **TLS 연결** 테스트 케이스는 통과하는 경우 TLS에 대한 디바이스의 버퍼 공간 제한을 늘리는 것이 좋습니다. 버퍼 공간 제한을 늘리면 크기가 늘어나는 경우 디바이스가 더 큰 크기의 서버 인증서를 처리할 수 있습니다.

```
"tests":[
   {
      "name":"my_tls_large_size_server_cert_test",
      "configuration": {
         // optional:
         "EXECUTION_TIMEOUT":"300",  // in seconds
      },
      "test":{
         "id":"TLS_Large_Size_Server_Cert",
         "version":"0.0.0"
      }
   }
]
```

**Example 테스트 케이스 출력:**  
+ **통과** - 테스트 중인 디바이스가 AWS IoT와 TLS 핸드셰이크를 완료했습니다.
+ **경고와 함께 전달 **- 테스트 중인 디바이스가 TLS 핸드셰이크를 완료 AWS IoT했지만 디바이스 또는의 TLS 경고 메시지가 있습니다 AWS IoT.
+ **실패** - 핸드셰이크 프로세스 중 오류로 AWS IoT 인해 테스트 중인 디바이스가 로 TLS 핸드셰이크를 완료하지 못했습니다.

## TLS 비보안 서버 인증서
<a name="unsecure-server"></a>

**공인 CA에서 서명하지 않음**  <a name="TLS_Unsecure_Server_Cert"></a>
테스트 중인 디바이스가 ATS CA의 유효한 서명이 없는 서버 인증서를 받는 경우 연결을 종료한다는 것을 검증합니다. 디바이스는 유효한 인증서를 제공하는 엔드포인트에만 연결해야 합니다.  

**Example API 테스트 케이스 정의:**  
`EXECUTION_TIMEOUT`의 기본값은 5분입니다. 제한 시간 값을 2분으로 설정하는 것을 권장합니다.

```
"tests":[
   {
      "name":"my_tls_unsecure_server_cert_test",
      "configuration": {
         // optional:
         "EXECUTION_TIMEOUT":"300",  //in seconds
      },
      "test":{
         "id":"TLS_Unsecure_Server_Cert",
         "version":"0.0.0"
      }
   }
]
```

**Example 테스트 케이스 출력:**  
+ **통과** - 테스트 중인 디바이스가 연결을 종료했습니다.
+ **실패** - 테스트 중인 디바이스가 TLS 핸드셰이크를 완료했습니다 AWS IoT.

**TLS 잘못된 주체 이름 서버 인증서/잘못된 주체 일반 이름(CN)/주체 대체 이름(SAN)**  <a name="TLS_Incorrect_Subject_Name"></a>
테스트 중인 디바이스가 요청한 도메인 이름과 다른 도메인 이름에 대한 서버 인증서를 제공하는 경우 연결을 종료하는지 확인합니다.  

**Example API 테스트 케이스 정의:**  
`EXECUTION_TIMEOUT`의 기본값은 5분입니다. 제한 시간 값을 2분으로 설정하는 것을 권장합니다.

```
"tests":[
   {
      "name":"my_tls_incorrect_subject_name_cert_test",
      "configuration": {
         // optional:
         "EXECUTION_TIMEOUT":"300",   // in seconds
      },
      "test":{
         "id":"TLS_Incorrect_Subject_Name_Server_Cert",
         "version":"0.0.0"
      }
   }
]
```

**Example 테스트 케이스 출력:**  
+ **통과** - 테스트 중인 디바이스가 연결을 종료했습니다.
+ **실패** - 테스트 중인 디바이스가 TLS 핸드셰이크를 완료했습니다 AWS IoT.

## TLS 만료된 서버 인증서
<a name="expired-server"></a>

**만료된 서버 인증서**  <a name="TLS_Expired_Server_Cert"></a>
만료된 서버 인증서가 제공되는 경우 테스트 중인 디바이스가 연결을 종료하는지 확인합니다.  

**Example API 테스트 케이스 정의:**  
`EXECUTION_TIMEOUT`의 기본값은 5분입니다. 제한 시간 값을 2분으로 설정하는 것을 권장합니다.

```
"tests":[
   {
      "name":"my_tls_expired_cert_test",
      "configuration": {
         // optional:
         "EXECUTION_TIMEOUT":"300",  //in seconds
      },
      "test":{
         "id":"TLS_Expired_Server_Cert",
         "version":"0.0.0"
      }
   }
]
```

**Example 테스트 케이스 출력:**  
+ **통과** - 테스트 중인 디바이스가 TLS 핸드셰이크 완료를 거부합니다 AWS IoT. 디바이스는 연결을 끊기 전에 TLS 알림 메시지를 보냅니다.
+ **경고가 있는 통과** - 테스트 중인 디바이스가 AWS IoT와 TLS 핸드셰이크를 완료하기를 거부합니다. 하지만 연결을 끊기 전에 TLS 알림 메시지를 보내지 않습니다.
+ **실패** - 테스트 중인 디바이스가 TLS 핸드셰이크를 완료합니다 AWS IoT.

# MQTT
<a name="device-advisor-tests-mqtt"></a>

## 연결, 연결 끊기, 다시 연결
<a name="connect"></a>

**"디바이스 전송 CONNECT 대상 AWS IoT Core (해피 케이스)"**  <a name="MQTT_Connect"></a>
테스트 중인 디바이스가 CONNECT 요청을 전송하는지 확인합니다.  
*API 테스트 케이스 정의:*  
`EXECUTION_TIMEOUT`의 기본값은 5분입니다. 제한 시간 값을 2분으로 설정하는 것을 권장합니다.

```
"tests":[
   {
      "name":"my_mqtt_connect_test",
      "configuration": {
         // optional:
         "EXECUTION_TIMEOUT":"300",   // in seconds
      },
      "test":{
         "id":"MQTT_Connect",
         "version":"0.0.0"
      }
   }
]
```

**“디바이스는 QoS1을 위한 임의의 주제로 PUBACK를 반환 할 수 있습니다.”**  
이 테스트 케이스는 디바이스(클라이언트)가 QoS1을 사용하여 주제를 구독한 후 브로커로부터 게시 메시지를 받은 경우 PUBACK 메시지를 반환할 수 있는지 확인합니다.  
페이로드 콘텐츠 및 페이로드 크기는 이 테스트 케이스에 대해 구성할 수 있습니다. 페이로드 크기가 구성된 경우 Device Advisor는 페이로드 콘텐츠 값을 덮어쓰고 미리 정의된 페이로드를 원하는 크기로 디바이스에 보냅니다. 페이로드 크기는 0에서 128 사이의 값이며 128KB를 초과할 수 없습니다. AWS IoT Core 는 [AWS IoT Core 메시지 브로커 및 프로토콜 제한 및 할당량](https://docs.aws.amazon.com/general/latest/gr/iot-core.html#message-broker-limits) 페이지에 표시된 대로 128KB보다 큰 게시 및 연결 요청을 거부합니다.  
*API 테스트 케이스 정의:*  
`EXECUTION_TIMEOUT`의 기본값은 5분입니다. 제한 시간 값은 2분을 권장합니다. `PAYLOAD_SIZE`는 0에서 128KB 사이의 값으로 구성할 수 있습니다. Device Advisor는 지정된 크기의 사전 정의된 페이로드를 디바이스에 다시 전송하므로 페이로드 크기를 정의하면 페이로드 콘텐츠가 무시됩니다.

```
"tests":[                            
{
        "name":"my_mqtt_client_puback_qos1",
        "configuration": {
            // optional:"TRIGGER_TOPIC": "myTopic",
            "EXECUTION_TIMEOUT":"300", // in seconds
            "PAYLOAD_FOR_PUBLISH_VALIDATION":"custom payload",
            "PAYLOAD_SIZE":"100" // in kilobytes
        },
        "test": {
            "id": "MQTT_Client_Puback_QoS1",
            "version": "0.0.0"
        }
    }
]
```

**“지터 백오프로 디바이스 연결 재시도 - CONNACK 응답 없음”**  <a name="MQTT_ConnectJitterBackoff"></a>
테스트 중인 디바이스가 브로커와 5회 이상 다시 연결할 때 적절한 지터 백오프를 사용하는지 확인합니다. 브로커는 테스트의 CONNNECT 요청에 따라 디바이스의 타임스탬프를 기록하고, 패킷 유효성 검사를 수행하고, 테스트 중인 디바이스에 CONNACK를 보내지 않고 일시 중지하고, 테스트 중인 디바이스가 요청을 다시 보낼 때까지 기다립니다. 여섯 번째 연결 시도는 통과할 수 있으며 CONNACK는 테스트 중인 디바이스로 다시 흐를 수 있습니다.  
위의 프로세스가 다시 수행됩니다. 전체적으로 이 테스트 케이스는 디바이스가 총 12번 이상 연결되어야 합니다. 수집된 타임스탬프는 테스트 중인 디바이스에서 지터 백오프가 사용되는지 확인하는 데 사용됩니다. 테스트 중인 디바이스에 엄격하게 지수 백오프 지연이 있는 경우 이 테스트 케이스가 경고와 함께 통과됩니다.  
이 테스트 케이스를 통과하려면 테스트 중인 디바이스에서 [지수 백오프 및 지터](https://aws.amazon.com/blogs//architecture/exponential-backoff-and-jitter/) 메커니즘을 구현하는 것이 좋습니다.  
*API 테스트 케이스 정의:*  
`EXECUTION_TIMEOUT`의 기본값은 5분입니다. 시간 초과 값을 4분으로 설정하는 것이 좋습니다.

```
"tests":[
   {
      "name":"my_mqtt_jitter_backoff_retries_test",
      "configuration": {
         // optional:
         "EXECUTION_TIMEOUT":"300",    // in seconds
      },
      "test":{
         "id":"MQTT_Connect_Jitter_Backoff_Retries",
         "version":"0.0.0"
      }
   }
]
```

**“지수 백오프로 디바이스 연결 재시도 - CONNACK 응답 없음”**  
테스트 중인 디바이스가 브로커와 5회 이상 다시 연결할 때 적절한 지수 백오프를 사용하는지 확인합니다. 브로커는 테스트의 CONNNECT 요청에 따라 디바이스의 타임스탬프를 기록하고, 패킷 유효성 검사를 수행하고, 클라이언트 디바이스에 CONNACK를 보내지 않고 일시 중지하고, 테스트 중인 디바이스가 요청을 다시 보낼 때까지 기다립니다. 수집된 타임스탬프는 테스트 중인 디바이스에서 지수 백오프가 사용되는지 확인하는 데 사용됩니다.  
이 테스트 케이스를 통과하려면 테스트 중인 디바이스에서 [지수 백오프 및 지터](https://aws.amazon.com/blogs//architecture/exponential-backoff-and-jitter/) 메커니즘을 구현하는 것이 좋습니다.  
*API 테스트 케이스 정의:*  
`EXECUTION_TIMEOUT`의 기본값은 5분입니다. 시간 초과 값을 4분으로 설정하는 것이 좋습니다.

```
"tests":[
   {
      "name":"my_mqtt_exponential_backoff_retries_test",
      "configuration": {
         // optional:
         "EXECUTION_TIMEOUT":"600",  // in seconds
      },
      "test":{
         "id":"MQTT_Connect_Exponential_Backoff_Retries",
         "version":"0.0.0"
      }
   }
]
```

**“지터 백오프로 디바이스 재연결 - 서버 연결 해제 후”**  
테스트 중인 디바이스가 서버에서 연결 해제된 후 다시 연결하는 동안 필요한 지터 및 백오프를 사용하는지 검증합니다. Device Advisor는 최소 5회 동안 서버에서 디바이스 연결을 해제하고 MQTT 재연결을 위한 디바이스 동작을 관찰합니다. Device Advisor는 테스트 중인 디바이스에 대한 CONNECT 요청의 타임스탬프를 기록하고, 패킷 유효성 검사를 수행하고, 클라이언트 디바이스에 CONNACK를 보내지 않고 일시 중지하고, 테스트 중인 디바이스가 요청을 다시 보낼 때까지 기다립니다. 수집된 타임스탬프는 테스트 중인 디바이스가 다시 연결하는 동안 지터와 백오프가 사용되는지 확인하는 데 사용됩니다. 테스트 중인 디바이스에 엄격한 지수 백오프가 있거나 적절한 지터 백오프 메커니즘을 구현하지 않는 경우 이 테스트 케이스는 경고와 함께 통과합니다. 테스트 중인 디바이스가 선형 백오프 또는 상수 백오프 메커니즘을 구현한 경우 테스트가 실패합니다.  
이 테스트 케이스를 통과하려면 테스트 중인 장치에서 [지수 백오프 및 지터](https://aws.amazon.com/blogs//architecture/exponential-backoff-and-jitter/) 메커니즘을 구현하는 것이 좋습니다.  
*API 테스트 케이스 정의:*  
`EXECUTION_TIMEOUT`의 기본값은 5분입니다. 시간 초과 값을 4분으로 설정하는 것이 좋습니다.  
백오프에 대한 검증을 위한 재연결 시도 횟수는 `RECONNECTION_ATTEMPTS`를 지정하여 변경할 수 있습니다. 번호는 5\$110 사이여야 합니다. 기본값은 5입니다.

```
"tests":[
   {
      "name":"my_mqtt_reconnect_backoff_retries_on_server_disconnect",
      "configuration":{
         // optional:
         "EXECUTION_TIMEOUT":"300",  // in seconds
         "RECONNECTION_ATTEMPTS": 5
      },
      "test":{
         "id":"MQTT_Reconnect_Backoff_Retries_On_Server_Disconnect",
         "version":"0.0.0"
      }
   }
]
```

**"지터 백오프로 디바이스 재연결 - 연결 상태가 불안정한 경우"**  
테스트 중인 디바이스가 불안정한 연결에서 다시 연결하는 동안 필요한 지터 및 백오프를 사용하는지 확인합니다. Device Advisor는 5번의 성공적인 연결 후 서버에서 디바이스의 연결을 끊고 MQTT 재연결에 대한 디바이스의 동작을 관찰합니다. Device Advisor는 테스트 중인 디바이스에 대한 CONNECT 요청의 타임스탬프를 기록하고, 패킷 유효성 검사를 수행하고, CONNACK를 다시 보내고, 연결을 끊고, 연결 해제의 타임스탬프를 기록하고, 테스트 중인 디바이스가 요청을 다시 보낼 때까지 기다립니다. 수집된 타임스탬프는 성공적이지만 불안정한 연결 후 다시 연결하는 동안 테스트 중인 디바이스가 지터와 백오프를 사용하는지 확인하는 데 사용됩니다. 테스트 중인 디바이스에 엄격한 지수 백오프가 있거나 적절한 지터 백오프 메커니즘을 구현하지 않는 경우 이 테스트 케이스는 경고와 함께 통과합니다. 테스트 중인 디바이스가 선형 백오프 또는 상수 백오프 메커니즘을 구현한 경우 테스트가 실패합니다.  
이 테스트 케이스를 통과하려면 테스트 중인 장치에서 [지수 백오프 및 지터](https://aws.amazon.com/blogs//architecture/exponential-backoff-and-jitter/) 메커니즘을 구현하는 것이 좋습니다.  
*API 테스트 케이스 정의:*  
`EXECUTION_TIMEOUT`의 기본값은 5분입니다. 시간 초과 값을 4분으로 설정하는 것이 좋습니다.  
백오프에 대한 검증을 위한 재연결 시도 횟수는 `RECONNECTION_ATTEMPTS`를 지정하여 변경할 수 있습니다. 번호는 5\$110 사이여야 합니다. 기본값은 5입니다.

```
"tests":[
   {
      "name":"my_mqtt_reconnect_backoff_retries_on_unstable_connection",
      "configuration":{
         // optional:
         "EXECUTION_TIMEOUT":"300",  // in seconds
         "RECONNECTION_ATTEMPTS": 5
      },
      "test":{
         "id":"MQTT_Reconnect_Backoff_Retries_On_Unstable_Connection",
         "version":"0.0.0"
      }
   }
]
```

## 게시
<a name="publish"></a>

**“QoS0(해피 케이스)”**  <a name="MQTT_Publish"></a>
테스트 중인 디바이스가 QoS0 또는 QoS1이 포함된 메시지를 게시하는지 확인합니다. 테스트 설정에서 이 주제 값 및 페이로드를 지정하여 메시지 주제 및 페이로드의 유효성을 검사할 수도 있습니다.  
`EXECUTION_TIMEOUT`의 기본값은 5분입니다. 제한 시간 값을 2분으로 설정하는 것을 권장합니다.

```
"tests":[
   {
      "name":"my_mqtt_publish_test",
      "configuration":{
         // optional:
         "EXECUTION_TIMEOUT":"300",  // in seconds
         "TOPIC_FOR_PUBLISH_VALIDATION": "my_TOPIC_FOR_PUBLISH_VALIDATION",
         "PAYLOAD_FOR_PUBLISH_VALIDATION": "my_PAYLOAD_FOR_PUBLISH_VALIDATION",
      },
      "test":{
         "id":"MQTT_Publish",
         "version":"0.0.0"
      }
   }
]
```

**“QoS1 게시 재시도 - PUBACK 없음”**  
브로커가 PUBACK을 보내지 않는 경우 테스트 중인 디바이스가 QoS1과 함께 전송된 메시지를 다시 게시하는지 확인합니다. 테스트 설정에서 이 주제를 지정하여 메시지 주제의 유효성을 검사할 수도 있습니다. 메시지를 다시 게시하기 전에 클라이언트 디바이스의 연결을 끊으면 안 됩니다. 또한 이 테스트는 다시 게시된 메시지의 패킷 식별자가 원본과 같은지 확인합니다. 테스트 실행 중에 디바이스의 연결이 끊겼다가 다시 연결되면 테스트 케이스가 오류 없이 재설정되며 디바이스에서 테스트 케이스 단계를 다시 수행해야 합니다.  
*API 테스트 케이스 정의:*  
`EXECUTION_TIMEOUT`의 기본값은 5분입니다. 적어도 4분이 권장됩니다.

```
"tests":[
   {
      "name":"my_mqtt_publish_retry_test",
      "configuration":{
         // optional:
         "EXECUTION_TIMEOUT":"300",  // in seconds
         "TOPIC_FOR_PUBLISH_VALIDATION": "my_TOPIC_FOR_PUBLISH_VALIDATION",
         "PAYLOAD_FOR_PUBLISH_VALIDATION": "my_PAYLOAD_FOR_PUBLISH_VALIDATION",
      },
      "test":{
         "id":"MQTT_Publish_Retry_No_Puback",
         "version":"0.0.0"
      }
   }
]
```

**'보관된 메시지 게시'**  
테스트 중인 디바이스가 `retainFlag`가 true로 설정된 메시지를 게시하는지 확인합니다. 테스트 설정에서 이 주제 값 및 페이로드를 지정하여 메시지 주제 및 페이로드의 유효성을 검사할 수 있습니다. PUBLISH 패킷 내에서 전송된 `retainFlag`가 true로 설정되지 않은 경우 테스트 케이스가 실패합니다.  
*API 테스트 케이스 정의:*  
`EXECUTION_TIMEOUT`의 기본값은 5분입니다. 제한 시간 값을 2분으로 설정하는 것을 권장합니다. 이 테스트 케이스를 실행하려면 [디바이스 역할](https://docs.aws.amazon.com/iot/latest/developerguide/device-advisor-setting-up.html#da-iam-role)에 `iot:RetainPublish` 작업을 추가합니다.

```
"tests":[
   {
      "name":"my_mqtt_publish_retained_messages_test",
      "configuration":{
         // optional:
         "EXECUTION_TIMEOUT":"300",  // in seconds
         "TOPIC_FOR_PUBLISH_RETAINED_VALIDATION": "my_TOPIC_FOR_PUBLISH_RETAINED_VALIDATION",
         "PAYLOAD_FOR_PUBLISH_RETAINED_VALIDATION": "my_PAYLOAD_FOR_PUBLISH_RETAINED_VALIDATION",
      },
      "test":{
         "id":"MQTT_Publish_Retained_Messages",
         "version":"0.0.0"
      }
   }
]
```

**'사용자 속성을 포함한 게시'**  
테스트 중인 디바이스가 올바른 사용자 속성이 포함된 메시지를 게시하는지 확인합니다. 테스트 설정에서 이름-값 페어를 설정하여 사용자 속성의 유효성을 검사할 수 있습니다. 사용자 속성이 제공되지 않거나 일치하지 않는 경우 테스트 케이스가 실패합니다.  
*API 테스트 케이스 정의:*  
MQTT5 전용 테스트 케이스입니다.  
`EXECUTION_TIMEOUT`의 기본값은 5분입니다. 제한 시간 값을 2분으로 설정하는 것을 권장합니다.

```
"tests":[
   {
      "name":"my_mqtt_user_property_test",
      "test":{
        "USER_PROPERTIES": [
            {"name": "name1", "value":"value1"},
            {"name": "name2", "value":"value2"}
        ],
        "EXECUTION_TIMEOUT":"300",  // in seconds
      },
      "test":{
         "id":"MQTT_Publish_User_Property",
         "version":"0.0.0"
      }
   }
]
```

## Subscribe
<a name="subscribe"></a>

**“구독 가능(해피 케이스)”**  <a name="MQTT_Subscribe"></a>
테스트 중인 디바이스가 MQTT 주제를 구독하는지 확인합니다. 테스트 설정에서 이 주제를 지정하여 테스트 중인 디바이스가 구독하는 주제의 유효성을 검사할 수도 있습니다.  
*API 테스트 케이스 정의:*  
`EXECUTION_TIMEOUT`의 기본값은 5분입니다. 제한 시간 값을 2분으로 설정하는 것을 권장합니다.

```
"tests":[
   {
      "name":"my_mqtt_subscribe_test",
      "configuration":{
         // optional:
         "EXECUTION_TIMEOUT":"300",  // in seconds
         "TOPIC_LIST_FOR_SUBSCRIPTION_VALIDATION":["my_TOPIC_FOR_PUBLISH_VALIDATION_a","my_TOPIC_FOR_PUBLISH_VALIDATION_b"]
      },
      "test":{
         "id":"MQTT_Subscribe",
         "version":"0.0.0"
      }
   }
]
```

**“구독 재시도 - SUBACK 없음”**  
테스트 중인 디바이스가 실패한 MQTT 주제를 구독을 재시도하는지 확인합니다. 그런 다음 서버는 대기하고 SUBACK를 보내지 않습니다. 클라이언트 디바이스가 구독을 다시 시도하지 않으면 테스트가 실패합니다. 클라이언트 디바이스는 동일한 패킷 ID로 실패한 구독을 다시 시도해야 합니다. 테스트 설정에서 이 주제를 지정하여 테스트 중인 디바이스가 구독하는 주제의 유효성을 검사할 수도 있습니다. 테스트 실행 중에 디바이스의 연결이 끊겼다가 다시 연결되면 테스트 케이스가 오류 없이 재설정되며 디바이스에서 테스트 케이스 단계를 다시 수행해야 합니다.  
*API 테스트 케이스 정의:*  
`EXECUTION_TIMEOUT`의 기본값은 5분입니다. 시간 초과 값을 4분으로 설정하는 것이 좋습니다.

```
"tests":[
   {
      "name":"my_mqtt_subscribe_retry_test",
      "configuration":{
         "EXECUTION_TIMEOUT":"300",  // in seconds
         // optional:
         "TOPIC_LIST_FOR_SUBSCRIPTION_VALIDATION":["myTOPIC_FOR_PUBLISH_VALIDATION_a","my_TOPIC_FOR_PUBLISH_VALIDATION_b"]
      },
      "test":{
         "id":"MQTT_Subscribe_Retry_No_Suback",
         "version":"0.0.0"
      }
   }
]
```

## Keep-Alive
<a name="keep-alive"></a>

**"Mqtt No Ack PingResp"**  
이 테스트 케이스는 테스트 중인 디바이스가 ping 응답을 받지 못했을 때 연결이 해제되었는지 확인합니다. 이 테스트 사례의 일환으로 Device Advisor는 게시, 구독 및 ping 요청을 AWS IoT Core 위해에서 전송된 응답을 차단합니다. 또한 테스트 중인 디바이스가 MQTT 연결을 해제하는지 검증합니다.  
*API 테스트 케이스 정의:*  
`EXECUTION_TIMEOUT`의 기본값은 5분입니다. 시간 제한을 `keepAliveTime` 값의 1.5배보다 크게 설정하는 것이 좋습니다.  
 이 테스트의 최대 `keepAliveTime` 시간은 230초를 초과하지 않아야 합니다.

```
"tests":[
    {
       "name":"Mqtt No Ack PingResp",
       "configuration": 
          //optional:
          "EXECUTION_TIMEOUT":"306",   // in seconds
       },
       "test":{
          "id":"MQTT_No_Ack_PingResp",
          "version":"0.0.0"
       }
    }
]
```

## 영구 세션
<a name="persistent-session"></a>

**‘영구 세션(해피 케이스)’**  
이 테스트 케이스는 영구 세션에서 연결이 끊어질 때 디바이스 동작을 검증합니다. 테스트 케이스는 디바이스가 다시 연결되고, 명시적으로 재구독하지 않은 채로 트리거 주제에 대한 구독을 다시 시작하고, 주제에 저장된 메시지를 수신하고, 영구 세션에서 예상대로 작동할 수 있는지 확인합니다. 이 테스트 사례가 통과하면 클라이언트 디바이스가 예상대로 AWS IoT Core 브로커와의 영구 세션을 유지할 수 있음을 나타냅니다. AWS IoT 영구 세션에 대한 자세한 내용은 [ MQTT 영구 세션 사용을 ](https://docs.aws.amazon.com/iot/latest/developerguide/mqtt.html#mqtt-persistent-sessions)참조하세요.  
이 테스트 케이스에서는 클라이언트 디바이스가 클린 세션 플래그가 거짓으로 설정된 AWS IoT Core 와 CONNECT된 후 트리거 주제를 구독할 것으로 예상됩니다. 구독에 성공하면 AWS IoT Core Device Advisor에서 디바이스의 연결을 해제합니다. 디바이스가 연결이 끊긴 상태인 동안 QoS 1 메시지 페이로드가 해당 주제에 저장됩니다. 그런 다음 Device Advisor는 클라이언트 디바이스가 테스트 엔드포인트에 다시 연결할 수 있도록 허용합니다. 이 시점에서 영구 세션이 있기 때문에 클라이언트 디바이스는 추가 SUBSCRIBE 패킷을 보내지 않고 주제 구독을 재개하고 브로커로부터 QoS 1 메시지를 수신할 것으로 기대됩니다. 다시 연결한 후 클라이언트 디바이스가 추가 SUBSCRIBE 패킷을 전송하여 트리거 주제를 다시 구독하거나 클라이언트가 트리거 주제에서 저장된 메시지를 수신하지 못하면 테스트 케이스가 실패합니다.  
*API 테스트 케이스 정의:*  
`EXECUTION_TIMEOUT`의 기본값은 5분입니다. 시간 초과 값을 최소한 4분으로 설정하는 것이 좋습니다. 첫 번째 연결에서 클라이언트 디바이스는 이전에 구독한 적이 없는 `TRIGGER_TOPIC`을 명시적으로 구독해야 합니다. 테스트 케이스를 통과하려면 클라이언트 디바이스가 QoS 1을 사용하여 `TRIGGER_TOPIC`을 성공적으로 구독해야 합니다. 다시 연결한 후 클라이언트 디바이스는 활성 영구 세션이 있다는 것을 이해하도록 기대됩니다. 따라서 트리거 주제가 보낸 저장된 메시지를 수락하고 해당 특정 메시지에 대해 PUBACK을 반환해야 합니다.

```
"tests":[
   {
      "name":"my_mqtt_persistent_session_happy_case",
      "configuration":{
         //required:
         "TRIGGER_TOPIC": "myTrigger/topic",
         // optional:
         // if Payload not provided, a string will be stored in the trigger topic to be sent back to the client device
         "PAYLOAD": "The message which should be received from AWS IoT Broker after re-connecting to a persistent session from the specified trigger topic.",            
         "EXECUTION_TIMEOUT":"300" // in seconds
      },
      "test":{
         "id":"MQTT_Persistent_Session_Happy_Case",
         "version":"0.0.0"
      }
   }
]
```

**“영구 세션 - 세션 만료”**  
이 테스트 케이스는 연결이 해제된 디바이스가 만료된 영구 세션에 다시 연결할 때 디바이스 동작을 검증하는 데 도움을 줍니다. 세션이 만료되면 새 SUBSCRIBE 패킷을 명시적으로 전송하여 디바이스가 이전에 구독한 주제를 다시 구독할 것으로 기대됩니다.  
첫 번째 연결 중에 영구 세션을 시작하기 위해 `CleanSession` 플래그가 false로 설정되므로 테스트 디바이스가 AWS IoT 브로커와 연결될 것으로 예상됩니다. 그러면 디바이스가 트리거 주제를 구독할 것입니다. 그런 다음 구독이 성공하고 영구 세션을 시작한 후 AWS IoT Core Device Advisor에서 디바이스의 연결을 해제합니다. 연결 해제 후 AWS IoT Core Device Advisor를 사용하면 테스트 디바이스가 테스트 엔드포인트와 다시 연결할 수 있습니다. 이 시점에서 테스트 디바이스가 다른 CONNECT 패킷을 전송할 때 AWS IoT Core Device Advisor는 영구 세션이 만료되었음을 나타내는 CONNACK 패킷을 다시 보냅니다. 테스트 디바이스는 이 패킷을 올바르게 해석해야 하며 영구 세션이 종료될 때 동일한 트리거 주제를 다시 구독할 것으로 기대됩니다. 테스트 디바이스가 주제 트리거를 다시 구독하지 않으면 테스트 케이스가 실패합니다. 테스트를 통과하려면 디바이스가 영구 세션이 끝났음을 이해하고 두 번째 연결에서 동일한 트리거 주제에 대해 새 SUBSCRIBE 패킷을 다시 보내야 합니다.  
테스트 디바이스가 이 테스트 케이스를 통과하면 디바이스가 영구 세션 만료 시 기대되는 방식으로 재연결을 처리할 수 있다는 뜻입니다.  
*API 테스트 케이스 정의:*  
`EXECUTION_TIMEOUT`의 기본값은 5분입니다. 시간 초과 값을 최소한 4분으로 설정하는 것이 좋습니다. 테스트 디바이스는 이전에 구독한 적이 없는 `TRIGGER_TOPIC`을 명시적으로 구독해야 합니다. 테스트 케이스를 통과하려면 테스트 디바이스가 `CleanSession` 플래그가 거짓으로 설정된 CONNECT 패킷을 보내야 하며 QoS 1을 사용하여 트리거 주제에 성공적으로 구독해야 합니다. 연결에 성공하면 AWS IoT Core Device Advisor가 디바이스의 연결을 해제합니다. 연결이 끊긴 후 AWS IoT Core Device Advisor는 디바이스가 다시 연결되도록 허용하고 Device Advisor가 영구 세션을 종료했을 `TRIGGER_TOPIC` 것이므로 AWS IoT Core 디바이스는 동일한를 다시 구독해야 합니다.

```
"tests":[
   {
      "name":"my_expired_persistent_session_test",
      "configuration":{
         //required:
         "TRIGGER_TOPIC": "myTrigger/topic",
         // optional:       
         "EXECUTION_TIMEOUT":"300" // in seconds
      },
      "test":{
         "id":"MQTT_Expired_Persistent_Session",
         "version":"0.0.0"
      }
   }
]
```

# 섀도우
<a name="device-advisor-tests-shadow"></a>

이러한 테스트를 사용하여 테스트 중인 디바이스가 AWS IoT 디바이스 섀도우 서비스를 올바르게 사용하는지 확인합니다. 자세한 내용은 [AWS IoT 디바이스 섀도우 서비스](iot-device-shadows.md)를 참조하세요. 이러한 테스트 케이스가 테스트 스위트에 구성된 경우 스위트 실행을 시작할 때 사물을 제공하는 것이 필요합니다.

**MQTT over WebSocket**은 현재 지원되지 않습니다.

## 게시
<a name="publish"></a>

***'디바이스가 연결 후 상태를 게시합니다(해피 케이스)'***  
디바이스가에 연결한 후 상태를 게시할 수 있는지 확인 AWS IoT Core  
*API 테스트 케이스 정의:*  
`EXECUTION_TIMEOUT`의 기본값은 5분입니다. 제한 시간 값을 2분으로 설정하는 것을 권장합니다.

```
"tests":[
   {
      "name":"my_shadow_publish_reported_state",
      "configuration": {
         // optional:
         "EXECUTION_TIMEOUT":"300", // in seconds
         "SHADOW_NAME": "SHADOW_NAME",
         "REPORTED_STATE": {
            "STATE_ATTRIBUTE": "STATE_VALUE"
         }
      },
      "test":{
         "id":"Shadow_Publish_Reported_State",
         "version":"0.0.0"
      }
   }
]
```
`REPORTED_STATE`는 연결 후 디바이스의 정확한 섀도우 상태에 대한 추가 검증을 위해 제공될 수 있습니다. 기본적으로 이 테스트 케이스는 디바이스 게시 상태의 유효성을 검사합니다.  
`SHADOW_NAME`이 제공되지 않으면 테스트 케이스는 기본적으로 명명되지 않은(클래식) 섀도우 유형의 주제 접두사에 게시된 메시지를 찾습니다. 디바이스에서 명명된 섀도우 유형을 사용하는 경우 섀도우 이름을 제공합니다. 자세한 내용은 [디바이스에서 섀도우 사용](https://docs.aws.amazon.com/iot/latest/developerguide/device-shadow-comms-device.html) 섹션을 참조하세요.

## 업데이트
<a name="update"></a>

***'디바이스가 보고된 상태를 원하는 상태로 업데이트합니다(해피 케이스)'***  
디바이스가 수신된 모든 업데이트 메시지를 읽고 디바이스의 상태를 원하는 상태 속성과 일치하도록 동기화하는지 확인합니다. 동기화 후 디바이스에서 최신 보고된 상태를 게시해야 합니다. 테스트를 실행하기 전에 디바이스에 이미 기존 섀도우가 있는 경우 테스트 케이스에 대해 구성된 원하는 상태와 기존 보고된 상태가 아직 일치하지 않는지 확인합니다. 섀도우 문서에서 **ClientToken** 필드가 `DeviceAdvisorShadowTestCaseSetup`일 것이므로 이 필드를 확인하여 Device Advisor가 보낸 섀도우 업데이트 메시지를 식별할 수 있습니다.  
*API 테스트 케이스 정의:*  
`EXECUTION_TIMEOUT`의 기본값은 5분입니다. 제한 시간 값을 2분으로 설정하는 것을 권장합니다.

```
"tests":[
   {
      "name":"my_shadow_update_reported_state",
      "configuration": {
         "DESIRED_STATE": {
            "STATE_ATTRIBUTE": "STATE_VALUE"
         },
         // optional:
         "EXECUTION_TIMEOUT":"300", // in seconds
         "SHADOW_NAME": "SHADOW_NAME"
      },
      "test":{
         "id":"Shadow_Update_Reported_State",
         "version":"0.0.0"
      }
   }
]
```
`DESIRED_STATE`에는 적어도 속성 하나와 관련 값이 있어야 합니다.  
`SHADOW_NAME`이 제공되지 않으면 테스트 케이스는 기본적으로 명명되지 않은(클래식) 섀도우 유형의 주제 접두사에 게시된 메시지를 찾습니다. 디바이스에서 명명된 섀도우 유형을 사용하는 경우 섀도우 이름을 제공합니다. 자세한 내용은 [디바이스에서 섀도우 사용](https://docs.aws.amazon.com/iot/latest/developerguide/device-shadow-comms-device.html) 섹션을 참조하세요.

# 작업 실행
<a name="device-advisor-tests-job-execution"></a>

**“디바이스가 작업 실행을 완료할 수 있습니다.”**  
 이 테스트 사례는 디바이스가 AWS IoT 작업을 사용하여 업데이트를 수신할 수 있는지 확인하고 성공적인 업데이트 상태를 게시하는 데 도움이 됩니다. AWS IoT 작업에 대한 자세한 내용은 [ 작업을 참조하세요](https://docs.aws.amazon.com//iot/latest/developerguide/iot-jobs.html).  
 이 테스트 케이스를 성공적으로 실행하려면 [디바이스 역할](https://docs.aws.amazon.com/iot/latest/developerguide/device-advisor-setting-up.html#da-iam-role)을 부여해야 하는 예약된 AWS 주제 두 개가 있습니다. 작업 활동 관련 메시지를 구독하려면 **notify** 및 **notify-next** 주제를 사용합니다. 디바이스 역할은 다음 주제에 대해 PUBLISH 작업을 허용해야 합니다.  
+ \$1aws/things/**thingName**/jobs/**jobId**/get
+ \$1aws/things/**thingName**/jobs/**jobId**/update
다음 주제에 대해 SUBSCRIBE 및 RECEIVE 작업을 허용하는 것이 좋습니다.  
+ \$1aws/things/**thingName**/jobs/get/accepted
+ \$1aws/things/**thingName**/jobs/**jobId**/get/rejected
+ \$1aws/things/**thingName**/jobs/**jobId**/update/accepted
+ \$1aws/things/**thingName**/jobs/**jobId**/update/rejected
다음 주제에 대해 SUBSCRIBE 작업을 허용하는 것이 좋습니다.  
+ \$1aws/things/**thingName**/jobs/notify-next
이러한 예약된 주제에 대한 자세한 내용은 [AWS IoT 작업](https://docs.aws.amazon.com/iot/latest/developerguide/reserved-topics.html#reserved-topics-job)의 예약된 주제를 참조하세요.  
**MQTT over WebSocket**은 현재 지원되지 않습니다.  
*API 테스트 케이스 정의:*  
`EXECUTION_TIMEOUT`의 기본값은 5분입니다. 제한 시간 값을 3분으로 설정하는 것을 권장합니다. 제공된 AWS IoT 작업 문서 또는 소스에 따라 제한 시간 값을 조정합니다(예: 작업을 실행하는 데 시간이 오래 걸리는 경우 테스트 사례에 더 긴 제한 시간 값을 정의). 테스트를 실행하려면 유효한 AWS IoT 작업 문서 또는 이미 존재하는 작업 ID가 필요합니다. AWS IoT 작업 문서는 JSON 문서 또는 S3 링크로 제공될 수 있습니다. 작업 문서가 제공된 경우 작업 ID를 제공하는 것은 선택 사항입니다. 작업 ID가 제공되면 Device Advisor는 사용자를 대신하여 AWS IoT 작업을 생성하는 동안 해당 ID를 사용합니다. 작업 문서가 제공되지 않은 경우 테스트 케이스를 실행하는 리전과 동일한 리전에 있는 기존 ID를 제공할 수 있습니다. 이 경우 Device Advisor는 테스트 사례를 실행하는 동안 해당 AWS IoT 작업을 사용합니다.

```
"tests": [
   {
      "name":"my_job_execution",
      "configuration": {
         // optional:
         // Test case will create a job task by using either JOB_DOCUMENT or JOB_DOCUMENT_SOURCE.
         // If you manage the job task on your own, leave it empty and provide the JOB_JOBID (self-managed job task).
         // JOB_DOCUMENT is a JSON formatted string
         "JOB_DOCUMENT": "{
            \"operation\":\"reboot\",
            \"files\" : {
               \"fileName\" : \"install.py\",
               \"url\" : \"${aws:iot:s3-presigned-url:https://s3.amazonaws.com/bucket-name/key}\"
            }
         }",
         // JOB_DOCUMENT_SOURCE is an S3 link to the job document. It will be used only if JOB_DOCUMENT is not provided.
         "JOB_DOCUMENT_SOURCE": "https://s3.amazonaws.com/bucket-name/key",
         // JOB_JOBID is mandatory, only if neither document nor document source is provided. (Test case needs to know the self-managed job task id).
         "JOB_JOBID": "String",
         // JOB_PRESIGN_ROLE_ARN is used for the presign Url, which will replace the placeholder in the JOB_DOCUMENT field
         "JOB_PRESIGN_ROLE_ARN": "String",
         // Presigned Url expiration time. It must be between 60 and 3600 seconds, with the default value being 3600.
         "JOB_PRESIGN_EXPIRES_IN_SEC": "Long"   
         "EXECUTION_TIMEOUT": "300", // in seconds         
      },
      "test": {
         "id": "Job_Execution",
         "version": "0.0.0"
      }
   }
]
```
작업 문서 생성 및 사용에 관한 자세한 내용은 [작업 문서](https://docs.aws.amazon.com//iot/latest/developerguide/iot-jobs.html)를 참조하세요.

# 권한 및 정책
<a name="device-advisor-tests-permissions-policies"></a>

다음 테스트를 사용하여 디바이스 인증서에 연결된 정책이 표준 모범 사례를 따르는지 확인할 수 있습니다.

**MQTT over WebSocket**은 현재 지원되지 않습니다.

**“디바이스 인증서 연결 정책에 와일드카드가 포함되어 있지 않습니다.”**  
 디바이스와 연결된 권한 정책이 모범 사례를 따르고 디바이스에 필요한 것보다 더 많은 권한을 부여하지 않는지 확인합니다.  
*API 테스트 케이스 정의:*  
`EXECUTION_TIMEOUT`의 기본값은 1분입니다. 시간 제한을 30초 이상으로 설정하는 것이 좋습니다.

```
"tests":[
   {
        "name":"my_security_device_policies",
        "configuration": {
            // optional:
            "EXECUTION_TIMEOUT":"60"    // in seconds
        },
        "test": {
            "id": "Security_Device_Policies",
            "version": "0.0.0"
        }
    }
]
```

# 장기간 테스트
<a name="device-advisor-tests-long-duration"></a>

장기간 테스트는 디바이스가 장기간 작동할 때 디바이스의 동작을 모니터링하는 새로운 테스트 제품군입니다. 디바이스의 특정 동작에 초점을 맞춘 개별 테스트를 실행하는 것과 달리, 장기간 테스트는 디바이스 수명 동안 다양한 실제 시나리오에서 디바이스의 동작을 검사합니다. Device Advisor는 최대한 효율적인 순서로 테스트를 오케스트레이션합니다. 이 테스트에서는 테스트 중인 디바이스의 성능에 대한 유용한 지표가 포함된 요약 로그를 비롯한 결과 및 로그가 생성됩니다.

## MQTT 장기간 테스트 케이스
<a name="long-duration-test-case"></a>

MQTT 장기 테스트 케이스에서 디바이스의 동작은 MQTT 연결, 구독, 게시 및 재연결과 같은 해피 케이스 시나리오에서 처음에 관찰됩니다. 그런 다음 MQTT 재연결 백오프, 긴 서버 연결 해제 및 간헐적 연결과 같은 여러 복잡한 실패 시나리오에서 디바이스가 관찰됩니다.

## MQTT 장기간 테스트 케이스 실행 흐름
<a name="long-duration-test-case-execution-flow"></a>

MQTT 장기긴 테스트 케이스 실행에는 세 단계가 있습니다.

![\[기본 테스트 실행, 고급 테스트 실행 및 추가 실행 시간을 보여주는 ‘MQTT 장기 테스트 실행’입니다.\]](http://docs.aws.amazon.com/ko_kr/iot/latest/developerguide/images/mqtt-execution-flow.png)


### 기본 테스트 실행
<a name="basic-tests-execution"></a>

이 단계에서 테스트 케이스는 간단한 테스트를 병렬로 실행합니다. 테스트에서는 디바이스에 구성에서 선택된 작업이 있는지 확인합니다.

기본 테스트 세트에는 선택한 작업에 따라 다음이 포함될 수 있습니다.

#### CONNECT
<a name="basic-tests-execution-connect"></a>

이 시나리오는 디바이스가 브로커와 성공적으로 연결할 수 있는지 확인합니다.

![\[CONNECT 메시지를 보내는 디바이스와 브로커가 성공적인 반환 코드를 사용하여 CONNACK 메시지로 응답하는 기본 연결 흐름입니다.\]](http://docs.aws.amazon.com/ko_kr/iot/latest/developerguide/images/basic-connect.png)


#### PUBLISH
<a name="basic-tests-execution-publish"></a>

이 시나리오는 디바이스가 브로커에 대해 성공적으로 게시하는지 확인합니다.

##### QoS 0
<a name="publish-qos0"></a>

이 테스트 케이스는 QoS 0으로 게시하는 동안 디바이스가 브로커에 `PUBLISH` 메시지를 성공적으로 전송하는지 확인합니다. 이 테스트는 디바이스에서 `PUBACK` 메시지를 수신할 때까지 기다리지 않습니다.

![\[QoS 0 수준의 PUBLISH 메시지를 보내는 디바이스가 포함된 PUBLISH QoS 0 흐름입니다.\]](http://docs.aws.amazon.com/ko_kr/iot/latest/developerguide/images/Qos0.png)


##### QoS 1
<a name="publish-qos1"></a>

이 테스트 케이스에서는 디바이스가 QoS 1을 사용하여 브로커에 두 개의`PUBLISH` 메시지를 보낼 것으로 예상합니다. 첫 번째 `PUBLISH` 메시지 이후 브로커는 응답하기 전에 최대 15초 동안 기다립니다. 디바이스는 15초 이내에 동일한 패킷 식별자로 원본 `PUBLISH` 메시지를 재시도해야 합니다. 이렇게 하면 브로커가 `PUBACK` 메시지로 응답하고 테스트에서 검증합니다. 디바이스가 `PUBLISH`를 재시도하지 않으면 원본 `PUBACK`이 디바이스로 전송되고 테스트는 시스템 메시지와 더불어 **경고와 함께 통과**로 표시됩니다 테스트 실행 중에 디바이스의 연결이 끊겼다가 다시 연결되면 테스트 시나리오가 오류 없이 재설정되며 디바이스에서 테스트 시나리오 단계를 다시 수행해야 합니다.

![\[QoS 1 수준과 브로커와의 여러 상호 작용으로 PUBLISH 메시지를 보내는 디바이스가 포함된 PUBLISH QoS 1 흐름입니다.\]](http://docs.aws.amazon.com/ko_kr/iot/latest/developerguide/images/Qos1.png)


#### SUBSCRIBE
<a name="basic-tests-execution-subscribe"></a>

이 시나리오는 디바이스가 브로커에 대해 성공적으로 구독하는지 확인합니다.

##### QoS 0
<a name="subscribe-qos0"></a>

이 테스트 케이스는 QoS 0으로 구독하는 동안 디바이스가 브로커에 `SUBSCRIBE` 메시지를 성공적으로 전송하는지 확인합니다. 테스트에서 디바이스가 SUBACK 메시지를 수신할 때까지 기다리지 않습니다.

![\[QoS 0 수준의 SUBSCRIBE 메시지를 보내는 디바이스와 SUBACK 메시지 및 성공 최대 QoS 0 코드로 응답하는 브로커를 포함하는 SUBSCRIBE QoS 0 흐름입니다.\]](http://docs.aws.amazon.com/ko_kr/iot/latest/developerguide/images/subscribe-Qos0.png)


##### QoS 1
<a name="subscribe-qos1"></a>

이 테스트 케이스에서는 디바이스가 QoS 1을 사용하여 브로커에 두 개의`SUBSCRIBE` 메시지를 보낼 것으로 예상합니다. 첫 번째 `SUBSCRIBE` 메시지 이후 브로커는 응답하기 전에 최대 15초 동안 기다립니다. 디바이스는 15초 이내에 동일한 패킷 식별자로 원본 `SUBSCRIBE` 메시지를 재시도해야 합니다. 이렇게 하면 브로커가 `SUBACK` 메시지로 응답하고 테스트에서 검증합니다. 디바이스가 `SUBSCRIBE`를 재시도하지 않으면 원본 `SUBACK`이 디바이스로 전송되고 테스트는 시스템 메시지와 더불어 **경고와 함께 통과**로 표시됩니다 테스트 실행 중에 디바이스의 연결이 끊겼다가 다시 연결되면 테스트 시나리오가 오류 없이 재설정되며 디바이스에서 테스트 시나리오 단계를 다시 수행해야 합니다.

![\[QoS 1 수준 및 브로커와의 여러 상호 작용으로 SUBSCRIBE 메시지를 보내는 디바이스가 포함된 SUBSCRIBE QoS 1 흐름입니다.\]](http://docs.aws.amazon.com/ko_kr/iot/latest/developerguide/images/subscribe-Qos1.png)


#### RECONNECT
<a name="basic-tests-execution-reconnect"></a>

이 시나리오는 성공적인 연결에서 디바이스의 연결이 끊어진 후 디바이스가 브로커와 성공적으로 다시 연결되는지 확인합니다. Device Advisor는 테스트 제품군을 실행하는 동안 이전에 디바이스를 두 번 이상 연결한 경우 디바이스의 연결을 끊지 않습니다. 대신 테스트가 **통과**로 표시됩니다.

![\[DUT와 브로커 간의 RECONNECT 흐름입니다.\]](http://docs.aws.amazon.com/ko_kr/iot/latest/developerguide/images/reconnect.png)


### 고급 테스트 실행
<a name="advanced-tests-execution"></a>

이 단계에서 테스트 케이스는 디바이스가 모범 사례를 준수하는지 확인하기 위해 더 복잡한 테스트를 순차적으로 실행합니다. 이러한 고급 테스트는 선택할 수 있으며 필요하지 않은 경우 선택 취소할 수 있습니다. 각 고급 테스트에는 시나리오에서 요구하는 내용에 따라 고유한 제한 시간 값이 있습니다.

#### RETURN PUBACK ON QoS 1 SUBSCRIPTION
<a name="advanced-tests-execution-return-puback"></a>

**참고**  
디바이스가 QoS 1 구독을 수행할 수 있는 경우에만 이 시나리오를 선택합니다.

이 시나리오는 디바이스가 주제를 구독하고 브로커에서 `PUBLISH` 메시지를 수신한 후 `PUBACK` 메시지를 반환하는지 확인합니다.

![\[DUT와 브로커 간의 QoS 1 구독에 대한 반환 PUBACK 흐름입니다.\]](http://docs.aws.amazon.com/ko_kr/iot/latest/developerguide/images/return-puback.png)


#### RECEIVE LARGE PAYLOAD
<a name="advanced-tests-execution-receive-large-payload"></a>

**참고**  
디바이스가 QoS 1 구독을 수행할 수 있는 경우에만 이 시나리오를 선택합니다.

이 시나리오는 페이로드가 큰 QoS 1 주제에 대해 브로커에서 `PUBLISH` 메시지를 수신한 후 디바이스가 `PUBACK` 메시지로 응답하는지 확인합니다. 예상 페이로드의 형식은 `LONG_PAYLOAD_FORMAT` 옵션을 사용하여 구성할 수 있습니다.

![\[DUT와 브로커 간의 RECEIVE LARGE PAYLOAD 흐름입니다.\]](http://docs.aws.amazon.com/ko_kr/iot/latest/developerguide/images/large-payload.png)


#### PERSISTENT SESSION
<a name="advanced-tests-execution-persistent-session"></a>

**참고**  
디바이스가 QoS 1 구독을 수행할 수 있고 영구 세션을 유지할 수 있는 경우에만 이 시나리오를 선택합니다.

이 시나리오에서는 영구 세션을 유지하는 디바이스 동작을 확인합니다. 테스트는 다음 조건이 충족될 때 유효성을 검증합니다.
+ 디바이스가 활성 QoS 1 구독 및 영구 세션이 활성화된 상태로 브로커에 연결됩니다.
+ 세션 중에 디바이스에서 브로커의 연결이 성공적으로 해제됩니다.
+ 디바이스가 브로커에 다시 연결되고 해당 주제를 명시적으로 다시 구독하지 않고도 트리거 주제에 대한 구독을 재개합니다.
+ 디바이스가 구독한 주제에 대해 브로커가 저장한 메시지를 성공적으로 수신하고 예상대로 실행됩니다.

 AWS IoT 영구 세션에 대한 자세한 내용은 [MQTT 영구 세션 사용을](https://docs.aws.amazon.com//iot/latest/developerguide/mqtt.html#mqtt-persistent-sessions) 참조하세요.

![\[DUT와 브로커 간의 PERSISTENT SESSION 흐름입니다.\]](http://docs.aws.amazon.com/ko_kr/iot/latest/developerguide/images/persistent-session.png)


#### KEEP ALIVE
<a name="advanced-tests-execution-keep-alive"></a>

이 시나리오는 디바이스가 브로커로부터 ping 응답을 받지 못한 후 연결이 성공적으로 해제되는지 확인합니다. 연결에는 유효한 연결 유지 타이머가 구성되어 있어야 합니다. 이 테스트의 일환으로 브로커는 `PUBLISH`, `SUBSCRIBE` 및 `PINGREQ` 메시지에 대해 전송된 모든 응답을 차단합니다. 또한 테스트 중인 디바이스가 MQTT 연결을 해제하는지 검증합니다.

![\[DUT와 브로커 간의 KEEP ALIVE 흐름입니다.\]](http://docs.aws.amazon.com/ko_kr/iot/latest/developerguide/images/keep-alive.png)


#### INTERMITTENT CONNECTIVITY
<a name="advanced-tests-execution-intermittent-connectivity"></a>

이 시나리오는 브로커가 임의의 시간 동안 임의의 간격으로 디바이스 연결을 해제한 후 디바이스가 브로커에 다시 연결될 수 있는지 확인합니다.

![\[DUT와 브로커 간의 INTERMITTENT CONNECTIVITY 흐름입니다.\]](http://docs.aws.amazon.com/ko_kr/iot/latest/developerguide/images/intermittent.png)


#### RECONNECT BACKOFF
<a name="advanced-tests-execution-reconnect-backoff"></a>

이 시나리오는 브로커가 여러 번 연결을 해제할 때 디바이스에 백오프 메커니즘이 구현되어 있는지 확인합니다. Device Advisor는 백오프 유형을 지수, 지터, 선형 또는 상수로 보고합니다. 백오프 시도 횟수는 `BACKOFF_CONNECTION_ATTEMPTS` 옵션을 사용하여 구성할 수 있습니다. 기본값은 5입니다. 값은 5\$110으로 구성 가능합니다.

이 테스트를 통과하려면 테스트 중인 디바이스에서 [지수 백오프 및 지터](https://aws.amazon.com/blogs/architecture/exponential-backoff-and-jitter/) 메커니즘을 구현하는 것이 좋습니다.

![\[DUT와 브로커 간의 RECONNECT BACKOFF 흐름입니다.\]](http://docs.aws.amazon.com/ko_kr/iot/latest/developerguide/images/reconnect-backoff.png)


#### LONG SERVER DISCONNECT
<a name="advanced-tests-execution-longserver-disconnect"></a>

이 시나리오는 브로커가 오랜 시간(최대 120분) 동안 디바이스 연결을 해제한 후 디바이스가 성공적으로 다시 연결될 수 있는지 확인합니다. 서버 연결 해제 시간은 `LONG_SERVER_DISCONNECT_TIME` 옵션을 사용하여 구성할 수 있습니다. 기본값은 120분입니다. 이 값은 30분\$1120분으로 구성할 수 있습니다.

![\[DUT와 브로커 간의 LONG SERVER DISCONNECT 흐름입니다.\]](http://docs.aws.amazon.com/ko_kr/iot/latest/developerguide/images/longserver-disconnect.png)


### 추가 실행 시간
<a name="additional-execution-time"></a>

추가 실행 시간은 위의 모든 테스트를 완료한 후 테스트 케이스를 종료하기 전에 테스트가 대기하는 시간입니다. 고객은 이 추가 기간을 사용하여 디바이스와 브로커 간의 모든 통신을 모니터링하고 기록합니다. `ADDITIONAL_EXECUTION_TIME` 옵션을 사용하여 추가 실행 시간을 구성할 수 있습니다. 기본적으로 이 옵션은 0분으로 설정되며 0분\$1120분이 될 수 있습니다.

## MQTT 장기간 테스트 구성 옵션
<a name="long-duration-test-case-config-options"></a>

MQTT 장기간 테스트를 위해 제공되는 모든 구성 옵션은 선택 사항입니다. 다음 옵션을 사용할 수 있습니다.

**OPERATIONS**  
디바이스에서 수행하는 작업 목록(예: `CONNECT`, `PUBLISH`, `SUBSCRIBE`)입니다. 테스트 케이스는 지정된 작업을 기반으로 시나리오를 실행합니다. 지정되지 않은 작업은 유효한 것으로 간주됩니다.  

```
{                                
"OPERATIONS": ["PUBLISH", "SUBSCRIBE"]
//by default the test assumes device can CONNECT   
}
```

**SCENARIOS**  
선택한 작업에 따라 테스트 케이스는 시나리오를 실행하여 디바이스의 동작을 검증합니다. 다음 두 가지 유형의 시나리오가 있습니다.  
+ **기본 시나리오**는 디바이스가 구성의 일부로 위에서 선택한 작업을 수행할 수 있는지 확인하는 간단한 테스트입니다. 이는 구성에 지정된 작업을 기반으로 미리 선택됩니다. 구성에 다른 입력이 필요하지 않습니다.
+ **고급 시나리오**는 실제 조건이 충족되었을 때 디바이스가 모범 사례를 따르는지 확인하기 위해 디바이스에 대해 수행되는 보다 복잡한 시나리오입니다. 이는 선택 사항이며 테스트 제품군의 구성 입력에 시나리오 배열로 전달할 수 있습니다.

```
{                                
    "SCENARIOS": [      // list of advanced scenarios
                "PUBACK_QOS_1",
                "RECEIVE_LARGE_PAYLOAD",
                "PERSISTENT_SESSION",
                "KEEP_ALIVE",
                "INTERMITTENT_CONNECTIVITY",
                "RECONNECT_BACK_OFF",
                "LONG_SERVER_DISCONNECT"
    ]  
}
```

**BASIC\$1TESTS\$1EXECUTION\$1TIME\$1OUT:**  
테스트 케이스에서 모든 기본 테스트가 완료될 때까지 기다리는 최대 시간입니다. 기본값은 60분입니다. 이 값은 30분\$1120분으로 구성할 수 있습니다.

**LONG\$1SERVER\$1DISCONNECT\$1TIME:**  
Long Server Disconnect 테스트 중에 테스트 케이스가 디바이스의 연결을 해제했다가 다시 연결하는 데 걸리는 시간입니다. 기본값은 60분입니다. 이 값은 30분\$1120분으로 구성할 수 있습니다.

**ADDITIONAL\$1EXECUTION\$1TIME:**  
이 옵션을 구성하면 모든 테스트가 완료된 후 디바이스와 브로커 간의 이벤트를 모니터링할 수 있는 시간이 제공됩니다. 기본값은 0분입니다. 이 값은 0분\$1120분으로 구성할 수 있습니다.

**BACKOFF\$1CONNECTION\$1ATTEMPTS:**  
이 옵션은 테스트 케이스에서 디바이스의 연결을 해제하는 횟수를 구성합니다. 이는 Reconnect Backoff 테스트에서 사용됩니다. 기본값은 5회입니다. 이 값은 5\$110으로 구성할 수 있습니다.

**LONG\$1PAYLOAD\$1FORMAT:**  
테스트 케이스가 디바이스에서 구독하는 QoS 1 주제에 게시할 때 디바이스에서 예상하는 메시지 페이로드의 형식입니다.

**API 테스트 케이스 정의:**

```
{                                
"tests":[
   {
      "name":"my_mqtt_long_duration_test",
      "configuration": {
         // optional
         "OPERATIONS": ["PUBLISH", "SUBSCRIBE"], 
         "SCENARIOS": [      
            "LONG_SERVER_DISCONNECT", 
            "RECONNECT_BACK_OFF",
            "KEEP_ALIVE",
            "RECEIVE_LARGE_PAYLOAD",
            "INTERMITTENT_CONNECTIVITY",
            "PERSISTENT_SESSION",   
         ],
         "BASIC_TESTS_EXECUTION_TIMEOUT": 60, // in minutes (60 minutes by default)
         "LONG_SERVER_DISCONNECT_TIME": 60,   // in minutes (120 minutes by default)
         "ADDITIONAL_EXECUTION_TIME": 60,     // in minutes (0 minutes by default)
         "BACKOFF_CONNECTION_ATTEMPTS": "5",
         "LONG_PAYLOAD_FORMAT":"{"message":"${payload}"}"
      },
      "test":{
         "id":"MQTT_Long_Duration",
         "version":"0.0.0"
      }
   }
 ]      
}
```

## MQTT 장기간 테스트 케이스 요약 로그
<a name="long-duration-test-case-summary-log"></a>

MQTT 장기간 테스트 케이스는 일반 테스트 케이스보다 더 오래 실행됩니다. 실행 중 디바이스 연결, 게시 및 구독과 같은 중요한 이벤트를 나열하는 별도의 요약 로그가 제공됩니다. 세부 정보에는 테스트된 항목, 테스트되지 않은 항목 및 실패한 항목이 포함됩니다. 로그 끝부분에는 테스트 케이스 실행 중에 발생한 모든 이벤트의 요약이 포함됩니다. 여기에는 다음이 포함됩니다.
+ *디바이스에 구성된 연결 유지 타이머*
+ *디바이스에 구성된 영구 세션 플래그*
+ *테스트 실행 중 디바이스 연결 수*
+ *디바이스 재연결 백오프 유형(재연결 백오프 테스트에 대해 검증된 경우)*
+ *테스트 케이스 실행 중에 디바이스가 게시한 주제*
+ *테스트 케이스 실행 중에 디바이스가 구독한 주제*