Terjemahan disediakan oleh mesin penerjemah. Jika konten terjemahan yang diberikan bertentangan dengan versi bahasa Inggris aslinya, utamakan versi bahasa Inggris.
# Kembangkan dan jalankan rangkaian pengujian IDT Anda sendiri
Mulai IDT v4.0.0, IDT untuk FreeRTOS menggabungkan pengaturan konfigurasi standar dan format hasil dengan lingkungan rangkaian pengujian yang memungkinkan Anda mengembangkan rangkaian pengujian khusus untuk perangkat dan perangkat lunak perangkat Anda. Anda dapat menambahkan tes khusus untuk validasi internal Anda sendiri atau memberikannya kepada pelanggan Anda untuk verifikasi perangkat.
Gunakan IDT untuk mengembangkan dan menjalankan rangkaian tes kustom, sebagai berikut:
****Untuk mengembangkan suite uji khusus****
+ Buat rangkaian pengujian dengan logika pengujian khusus untuk perangkat yang ingin Anda uji.
+ Sediakan IDT dengan rangkaian tes kustom Anda untuk menguji runner. Sertakan informasi tentang konfigurasi pengaturan khusus untuk rangkaian pengujian Anda.
****Untuk menjalankan suite pengujian khusus****
+ Atur perangkat yang ingin Anda uji.
+ Terapkan konfigurasi pengaturan yang diperlukan oleh rangkaian tes yang ingin Anda gunakan.
+ Gunakan IDT untuk menjalankan rangkaian tes kustom Anda.
+ Lihat hasil tes dan log eksekusi untuk tes yang dijalankan oleh IDT.
## Unduh versi terbaru AWS IoT Device Tester for FreeRTOS
Unduh [versi terbaru](dev-test-versions-afr.md#idt-latest-version-afr) IDT dan mengekstraksi perangkat lunak ke lokasi pada sistem file Anda di mana Anda telah membaca dan menulis izin.
**catatan**
IDT tidak mendukung yang sedang dijalankan oleh beberapa pengguna dari lokasi bersama, seperti direktori NFS atau folder bersama jaringan Windows. Kami sarankan Anda mengekstraksi paket IDT ke drive lokal dan menjalankan biner IDT pada workstation lokal Anda.
Windows memiliki batasan panjang jalur 260 karakter. Jika Anda menggunakan Windows, ekstraksi IDT ke direktori root seperti `C:\ ` atau `D:\` agar jalur Anda tetap di bawah batas 260 karakter.
## Alur kerja test suite
Rangkaian uji terdiri dari tiga jenis file:
+ File konfigurasi yang menyediakan IDT informasi tentang cara menjalankan rangkaian pengujian.
+ File yang dapat dieksekusi yang digunakan oleh IDT untuk menjalankan uji kasus.
+ File tambahan diperlukan untuk menjalankan tes.
Selesaikan langkah-langkah dasar berikut untuk membuat tes IDT kustom:
1. [Buat file konfigurasi](idt-json-config.md) untuk rangkaian pengujian Anda.
1. [Buat uji kasus yang dapat dieksekusi](test-executables.md) yang berisi logika ujian untuk rangkaian tes anda.
1. Verifikasi dan dokumentasi [informasi konfigurasi yang diperlukan untuk menguji runner](set-config-custom.md) untuk menjalankan rangkaian tes.
1. Verifikasi bahwa IDT dapat menjalankan rangkain tes Anda dan buat [hasil pengujian](run-tests-custom.md) seperti yang diharapkan.
Untuk cepat membangun rangkaian kustom sampel dan menjalankannya, ikuti petunjuk di [Tutorial: Bangun dan jalankan sampel rangkaian tes IDT](build-sample-suite.md).
Untuk memulai membuat rangkaian tes kustom di Python, lihat [Tutorial: Kembangkan rangkaian tes IDT sederhana](create-custom-tests.md).
# Tutorial: Bangun dan jalankan sampel rangkaian tes IDT
AWS IoT Device Tester Unduhan menyertakan kode sumber untuk rangkaian pengujian sampel. Anda dapat menyelesaikan tutorial ini untuk membangun dan menjalankan rangkaian pengujian sampel untuk memahami bagaimana Anda dapat menggunakan FreeRTOS AWS IoT Device Tester untuk menjalankan suite pengujian khusus. Meskipun tutorial ini menggunakan SSH, berguna untuk mempelajari cara menggunakan AWS IoT Device Tester dengan perangkat FreeRTOS.
Dalam tutorial ini, Anda akan melakukan langkah-langkah berikut:
1. [Bangun rangkaian uji sampel](build-sample.md)
1. [Gunakan IDT untuk menjalankan rangkaian uji sampel](run-sample.md)
**Topics**
+ [
# Siapkan prasyarat untuk rangkaian pengujian sampel
](prereqs-tutorial-sample.md)
+ [
# Konfigurasi informasi perangkat untuk IDT
](configure-idt-sample.md)
+ [
# Bangun rangkaian uji sampel
](build-sample.md)
+ [
# Gunakan IDT untuk menjalankan rangkaian uji sampel
](run-sample.md)
+ [
# Memecahkan masalah kesalahan
](tutorial-troubleshooting-custom.md)
# Siapkan prasyarat untuk rangkaian pengujian sampel
Untuk menyelesaikan tutorial ini, Anda memerlukan hal berikut ini:
+
**Persyaratan komputer host**
+ Versi terbaru dari AWS IoT Device Tester
+ [Python](https://docs.python.org/3/) 3.7 atau yang lebih baru
Untuk memeriksa versi Python yang diinstal pada komputer Anda, jalankan perintah berikut:
```
python3 --version
```
Pada Windows, jika penggunaan perintah ini menghasilkan kesalahan, gunakan `python --version` sebagai gantinya. Jika nomor versi yang dikembalikan adalah 3,7 atau lebih besar, jalankan perintah berikut di terminal Powershell untuk mengatur `python3` sebagai alias untuk perintah `python`.
```
Set-Alias -Name "python3" -Value "python"
```
Jika tidak ada informasi versi yang dikembalikan atau jika nomor versi kurang dari 3,7, ikuti petunjuk di [Mengunduh Py](https://wiki.python.org/moin/BeginnersGuide/Download) untuk menginstal Python 3.7\$1. Untuk informasi selengkapnya, lihat [dokumentasi Python](https://docs.python.org/3/).
+ [urllib3](https://urllib3.readthedocs.io/en/latest/)
Untuk memverifikasi bahwa `urllib3` diinstal dengan benar, jalankan perintah berikut:
```
python3 -c 'import urllib3'
```
Jika `urllib3` belum terinstal, gunakan perintah berikut untuk menginstalnya:
```
python3 -m pip install urllib3
```
+
**Persyaratan perangkat**
+ Perangkat dengan sistem operasi Linux dan koneksi jaringan ke jaringan yang sama dengan komputer host Anda.
Kami menyarankan agar Anda menggunakan [Raspberry Pi](https://www.raspberrypi.org/) dengan OS Raspberry Pi. Pastikan Anda mengatur [SSH](https://www.raspberrypi.com/documentation/computers/remote-access.html) pada Raspberry Pi Anda untuk terhubung secara jarak jauh ke sana.
# Konfigurasi informasi perangkat untuk IDT
Konfigurasi informasi perangkat Anda untuk IDT untuk menjalankan tes. Anda harus memperbarui templat `device.json` yang terletak di folder `/configs` dengan informasi berikut.
```
[
{
"id": "pool",
"sku": "N/A",
"devices": [
{
"id": "",
"connectivity": {
"protocol": "ssh",
"ip": "",
"port": "",
"auth": {
"method": "pki | password",
"credentials": {
"user": "",
"privKeyPath": "/path/to/private/key",
"password": ""
}
}
}
}
]
}
]
```
Di objek `devices`, berikan informasi berikut:
**`id`**
Pengenal unik yang ditetapkan pengguna untuk perangkat Anda.
**`connectivity.ip`**
Alamat IP perangkat Anda.
**`connectivity.port`**
Tidak wajib. Nomor port yang digunakan untuk koneksi SSH ke perangkat Anda.
**`connectivity.auth`**
Informasi autentikasi untuk koneksi tersebut.
Properti ini hanya berlaku jika `connectivity.protocol` diatur ke `ssh`.
**`connectivity.auth.method`**
Metode autentikasi yang digunakan untuk mengakses perangkat melalui protokol konektivitas yang diberikan.
Nilai yang didukung adalah:
+ `pki`
+ `password`
**`connectivity.auth.credentials`**
Kredensial yang digunakan untuk autentikasi.
**`connectivity.auth.credentials.user`**
Nama pengguna yang digunakan untuk masuk ke perangkat Anda.
**`connectivity.auth.credentials.privKeyPath`**
Jalur lengkap ke kunci pribadi yang digunakan untuk masuk ke perangkat Anda.
Nilai ini hanya berlaku jika `connectivity.auth.method` diatur ke `pki`.
**`devices.connectivity.auth.credentials.password`**
Kata sandi yang digunakan untuk masuk ke perangkat Anda.
Nilai ini hanya berlaku jika `connectivity.auth.method` diatur ke `password`.
**catatan**
Tentukan `privKeyPath` hanya jika `method` diatur ke `pki`.
Tentukan `password` hanya jika `method` diatur ke `password`.
# Bangun rangkaian uji sampel
Folder `/samples/python` berisi contoh file konfigurasi, kode sumber, dan SDK Klien IDT yang dapat Anda gabungkan ke dalam rangkaian tes dengan menggunakan skrip build yang disediakan. Pohon direktori berikut menunjukkan lokasi file contoh ini:
```
├── ...
├── tests
├── samples
│ ├── ...
│ └── python
│ ├── configuration
│ ├── src
│ └── build-scripts
│ ├── build.sh
│ └── build.ps1
└── sdks
├── ...
└── python
└── idt_client
```
Untuk membangun rangkaian tes, jalankan perintah berikut pada komputer host Anda:
------
#### [ Windows ]
```
cd /samples/python/build-scripts
./build.ps1
```
------
#### [ Linux, macOS, or UNIX ]
```
cd /samples/python/build-scripts
./build.sh
```
------
Hal ini akan menciptakan rangkaian uji sampel di folder `IDTSampleSuitePython_1.0.0` dalam folder `/tests`. Tinjau file dalam `IDTSampleSuitePython_1.0.0` folder untuk memahami bagaimana rangkaian pengujian sampel terstruktur dan untuk melihat berbagai contoh executable test case dan file konfigurasi pengujian.
**catatan**
Rangkaian pengujian sampel menyertakan kode sumber python. Jangan sertakan informasi sensitif dalam kode rangkaian pengujian Anda.
Langkah berikutnya: Gunakan IDT untuk [menjalankan rangkaian tes sampel](run-sample.md) yang Anda buat.
# Gunakan IDT untuk menjalankan rangkaian uji sampel
Untuk membangun rangkaian tes, jalankan perintah berikut pada komputer host Anda:
```
cd /bin
./devicetester_[linux | mac | win_x86-64] run-suite --suite-id IDTSampleSuitePython
```
IDT menjalankan sampel rangkaian tes dan mengalirkan hasil ke konsol. Ketika tes telah selesai berjalan, Anda akan melihat informasi berikut:
```
========== Test Summary ==========
Execution Time: 5s
Tests Completed: 4
Tests Passed: 4
Tests Failed: 0
Tests Skipped: 0
----------------------------------
Test Groups:
sample_group: PASSED
----------------------------------
Path to AWS 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
```
# Memecahkan masalah kesalahan
Gunakan informasi berikut untuk membantu menyelesaikan masalah dengan menyelesaikan tutorial.
**Kasus uji tidak berjalan dengan sukses**
+ Jika tes tidak berjalan sukses, IDT akan mengalirkan log kesalahan ke konsol yang dapat membantu Anda memecahkan masalah uji coba. Pastikan Anda memenuhi semua [prasyarat](prereqs-tutorial-sample.md) untuk tutorial ini.
**Tidak dapat terhubung ke perangkat yang sedang diuji**
Verifikasi hal berikut:
+ File `device.json` Anda berisi alamat IP, port, dan informasi autentikasi yang benar.
+ Anda dapat terhubung ke perangkat Anda melalui SSH dari komputer host Anda.
# Tutorial: Kembangkan rangkaian tes IDT sederhana
Rangkaian tes menggabungkan hal berikut:
+ Uji executable yang berisi logika uji
+ File konfigurasi yang menjelaskan rangkaian pengujian
Tutorial ini menunjukkan cara menggunakan IDT untuk FreeRTOS untuk mengembangkan rangkaian uji Python yang berisi satu kasus uji. Meskipun tutorial ini menggunakan SSH, berguna untuk mempelajari cara menggunakan AWS IoT Device Tester dengan perangkat FreeRTOS.
Dalam tutorial ini, Anda akan melakukan langkah-langkah berikut:
1. [Buat direktori rangkaian tes](test-suite-dir.md)
1. [Buat file konfigurasi](test-suite-json.md)
1. [Buat executable uji kasus](test-suite-exe.md)
1. [Jalankan rangkaian tes](run-test-suite.md)
Ikuti langkah-langkah di bawah ini untuk menyelesaikan tutorial untuk mengembangkan rangkaian tes IDT sederhana.
**Topics**
+ [
# Siapkan prasyarat untuk rangkaian pengujian IDT sederhana
](prereqs-tutorial-custom.md)
+ [
# Buat direktori rangkaian tes
](test-suite-dir.md)
+ [
# Buat file konfigurasi
](test-suite-json.md)
+ [
# Dapatkan SDK klien IDT
](add-idt-sdk.md)
+ [
# Buat executable uji kasus
](test-suite-exe.md)
+ [
# Konfigurasi informasi perangkat untuk IDT
](configure-idt-sample2.md)
+ [
# Jalankan rangkaian tes
](run-test-suite.md)
+ [
# Memecahkan masalah kesalahan
](tutorial-troubleshooting.md)
+ [
# Buat file konfigurasi rangkaian tes IDT
](idt-json-config.md)
+ [
# Konfigurasikan orkestrator uji IDT
](idt-test-orchestrator.md)
+ [
# Konfigurasikan state machine IDT
](idt-state-machine.md)
+ [
# Buat kasus uji IDT yang dapat dieksekusi
](test-executables.md)
+ [
# Gunakan konteks IDT
](idt-context.md)
+ [
# Mengonfigurasi pengaturan untuk test runner
](set-config-custom.md)
+ [
# Debug dan jalankan rangkaian tes kustom
](run-tests-custom.md)
+ [
# Tinjau hasil tes dan log IDT
](idt-review-results-logs.md)
+ [
# Kirim metrik penggunaan IDT
](idt-usage-metrics.md)
# Siapkan prasyarat untuk rangkaian pengujian IDT sederhana
Untuk menyelesaikan tutorial ini, Anda memerlukan hal berikut ini:
+
**Persyaratan komputer host**
+ Versi terbaru dari AWS IoT Device Tester
+ [Python](https://www.python.org/downloads/) 3.7 atau yang lebih baru
Untuk memeriksa versi Python yang diinstal pada komputer Anda, jalankan perintah berikut:
```
python3 --version
```
Pada Windows, jika penggunaan perintah ini menghasilkan kesalahan, gunakan `python --version` sebagai gantinya. Jika nomor versi yang dikembalikan adalah 3,7 atau lebih besar, jalankan perintah berikut di terminal Powershell untuk mengatur `python3` sebagai alias untuk perintah `python`.
```
Set-Alias -Name "python3" -Value "python"
```
Jika tidak ada informasi versi yang dikembalikan atau jika nomor versi kurang dari 3,7, ikuti petunjuk di [Mengunduh Py](https://wiki.python.org/moin/BeginnersGuide/Download) untuk menginstal Python 3.7\$1. Untuk informasi selengkapnya, lihat [dokumentasi Python](https://docs.python.org/3/).
+ [urllib3](https://urllib3.readthedocs.io/en/latest/)
Untuk memverifikasi bahwa `urllib3` diinstal dengan benar, jalankan perintah berikut:
```
python3 -c 'import urllib3'
```
Jika `urllib3` belum terinstal, gunakan perintah berikut untuk menginstalnya:
```
python3 -m pip install urllib3
```
+
**Persyaratan perangkat**
+ Perangkat dengan sistem operasi Linux dan koneksi jaringan ke jaringan yang sama dengan komputer host Anda.
Kami menyarankan agar Anda menggunakan [Raspberry Pi](https://www.raspberrypi.org/) dengan OS Raspberry Pi. Pastikan Anda mengatur [SSH](https://www.raspberrypi.com/documentation/computers/remote-access.html) pada Raspberry Pi Anda untuk terhubung secara jarak jauh ke sana.
# Buat direktori rangkaian tes
IDT secara logis memisahkan uji kasus ke dalam grup uji dalam setiap rangkaian tes. Setiap uji kasus harus berada di dalam grup uji. Untuk tutorial ini, buat folder bernama `MyTestSuite_1.0.0` dan buat pohon direktori berikut dalam folder ini:
```
MyTestSuite_1.0.0
└── suite
└── myTestGroup
└── myTestCase
```
# Buat file konfigurasi
Test suite Anda harus berisi [file konfigurasi](idt-json-config.md) wajib berikut:
**File yang diperlukan**
**`suite.json`**
Berisi informasi tentang rangkaian pengujian. Lihat [Konfigurasikan suite.json](idt-json-config.md#suite-json).
**`group.json`**
Berisi informasi tentang grup uji. Anda harus membuat file `group.json` untuk setiap grup uji di rangkaian tes Anda. Lihat [Konfigurasikan group.json](idt-json-config.md#group-json).
**`test.json`**
Berisi informasi tentang grup uji. Anda harus membuat file `test.json` untuk setiap grup uji di rangkaian tes Anda. Lihat [Konfigurasikan test.json](idt-json-config.md#test-json).
1. Di folder `MyTestSuite_1.0.0/suite`, buat file `suite.json` dengan struktur berikut:
```
{
"id": "MyTestSuite_1.0.0",
"title": "My Test Suite",
"details": "This is my test suite.",
"userDataRequired": false
}
```
1. Di folder `MyTestSuite_1.0.0/myTestGroup`, buat file `group.json` dengan struktur berikut:
```
{
"id": "MyTestGroup",
"title": "My Test Group",
"details": "This is my test group.",
"optional": false
}
```
1. Di folder `MyTestSuite_1.0.0/myTestGroup/myTestCase`, buat file `test.json` dengan struktur berikut:
```
{
"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"
]
}
}
}
```
Pohon direktori untuk folder `MyTestSuite_1.0.0` Anda sekarang akan terlihat seperti berikut ini:
```
MyTestSuite_1.0.0
└── suite
├── suite.json
└── myTestGroup
├── group.json
└── myTestCase
└── test.json
```
# Dapatkan SDK klien IDT
Anda menggunakan [SDK Klien IDT](test-executables.md#idt-client-sdk) untuk memungkinkan IDT berinteraksi dengan perangkat yang sedang diuji dan melaporkan hasil pengujian. Untuk tutorial ini, Anda akan menggunakan versi Python dari SDK.
Dari folder `/sdks/python/`, salin folder `idt_client` ke folder `MyTestSuite_1.0.0/suite/myTestGroup/myTestCase` Anda.
Untuk memverifikasi bahwa SDK berhasil disalin, jalankan perintah berikut.
```
cd MyTestSuite_1.0.0/suite/myTestGroup/myTestCase
python3 -c 'import idt_client'
```
# Buat executable uji kasus
Executable uji kasus berisi logika tes yang ingin Anda jalankan. Sebuah rangkaian tes dapat berisi beberapa executable uji kasus. Untuk tutorial ini, Anda hanya akan membuat satu executable uji kasus.
1. Buat file rangkaian test.
Di folder `MyTestSuite_1.0.0/suite/myTestGroup/myTestCase`, buat file `myTestCase.py` dengan konten berikut:
```
from idt_client import *
def main():
# Use the client SDK to communicate with IDT
client = Client()
if __name__ == "__main__":
main()
```
1. Gunakan fungsi SDK klien untuk menambahkan logika uji berikut ke file `myTestCase.py` Anda:
1. Jalankan perintah SSH pada perangkat yang diuji.
```
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. Kirim hasil tes ke 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()
```
# Konfigurasi informasi perangkat untuk IDT
Konfigurasi informasi perangkat Anda untuk IDT untuk menjalankan tes. Anda harus memperbarui templat `device.json` yang terletak di folder `/configs` dengan informasi berikut.
```
[
{
"id": "pool",
"sku": "N/A",
"devices": [
{
"id": "",
"connectivity": {
"protocol": "ssh",
"ip": "",
"port": "",
"auth": {
"method": "pki | password",
"credentials": {
"user": "",
"privKeyPath": "/path/to/private/key",
"password": ""
}
}
}
}
]
}
]
```
Di objek `devices`, berikan informasi berikut:
**`id`**
Pengenal unik yang ditetapkan pengguna untuk perangkat Anda.
**`connectivity.ip`**
Alamat IP perangkat Anda.
**`connectivity.port`**
Tidak wajib. Nomor port yang digunakan untuk koneksi SSH ke perangkat Anda.
**`connectivity.auth`**
Informasi autentikasi untuk koneksi tersebut.
Properti ini hanya berlaku jika `connectivity.protocol` diatur ke `ssh`.
**`connectivity.auth.method`**
Metode autentikasi yang digunakan untuk mengakses perangkat melalui protokol konektivitas yang diberikan.
Nilai yang didukung adalah:
+ `pki`
+ `password`
**`connectivity.auth.credentials`**
Kredensial yang digunakan untuk autentikasi.
**`connectivity.auth.credentials.user`**
Nama pengguna yang digunakan untuk masuk ke perangkat Anda.
**`connectivity.auth.credentials.privKeyPath`**
Jalur lengkap ke kunci pribadi yang digunakan untuk masuk ke perangkat Anda.
Nilai ini hanya berlaku jika `connectivity.auth.method` diatur ke `pki`.
**`devices.connectivity.auth.credentials.password`**
Kata sandi yang digunakan untuk masuk ke perangkat Anda.
Nilai ini hanya berlaku jika `connectivity.auth.method` diatur ke `password`.
**catatan**
Tentukan `privKeyPath` hanya jika `method` diatur ke `pki`.
Tentukan `password` hanya jika `method` diatur ke `password`.
# Jalankan rangkaian tes
Setelah Anda membuat rangkaian tes Anda, Anda ingin memastikan bahwa rangkaian tes itu berfungsi seperti yang diharapkan. Selesaikan langkah-langkah berikut untuk menjalankan rangkaian pengujian dengan kolam perangkat yang sudah ada untuk melakukannya.
1. Salin folder `MyTestSuite_1.0.0` Anda ke dalam `/tests`.
1. Jalankan perintah berikut:
```
cd /bin
./devicetester_[linux | mac | win_x86-64] run-suite --suite-id MyTestSuite
```
IDT menjalankan rangkaian tes Anda dan mengalirkan hasilnya ke konsol. Ketika tes telah selesai berjalan, Anda akan melihat informasi berikut:
```
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 AWS 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
```
# Memecahkan masalah kesalahan
Gunakan informasi berikut untuk membantu menyelesaikan masalah dengan menyelesaikan tutorial.
**Kasus uji tidak berjalan dengan sukses**
Jika tes tidak berjalan sukses, IDT akan mengalirkan log kesalahan ke konsol yang dapat membantu Anda memecahkan masalah uji coba. Sebelum Anda memeriksa log kesalahan, verifikasi hal berikut:
+ SDK klien IDT berada di folder yang benar seperti yang dijelaskan dalam. [Dapatkan SDK klien IDT](add-idt-sdk.md)
+ Pastikan Anda memenuhi semua prasyarat untuk tutorial ini. Untuk informasi selengkapnya, lihat [Siapkan prasyarat untuk rangkaian pengujian IDT sederhana](prereqs-tutorial-custom.md).
**Tidak dapat terhubung ke perangkat yang sedang diuji**
Verifikasi hal berikut:
+ File `device.json` Anda berisi alamat IP, port, dan informasi autentikasi yang benar.
+ Anda dapat terhubung ke perangkat Anda melalui SSH dari komputer host Anda.
# Buat file konfigurasi rangkaian tes IDT
Bagian ini menjelaskan format di mana Anda membuat file konfigurasi yang Anda sertakan saat Anda menulis rangkaian pengujian kustom.
**File konfigurasi yang diperlukan**
**`suite.json`**
Berisi informasi tentang rangkaian pengujian. Lihat [Konfigurasikan suite.json](#suite-json).
**`group.json`**
Berisi informasi tentang grup uji. Anda harus membuat file `group.json` untuk setiap grup uji di rangkaian tes Anda. Lihat [Konfigurasikan group.json](#group-json).
**`test.json`**
Berisi informasi tentang grup uji. Anda harus membuat file `test.json` untuk setiap grup uji di rangkaian tes Anda. Lihat [Konfigurasikan test.json](#test-json).
**File konfigurasi opsional**
**`test_orchestrator.yaml` atau `state_machine.json`**
Mendefinisikan bagaimana pengujian dijalankan saat IDT menjalankan rangkaian pengujian. SSe [Konfigurasikan test\$1orchestrator.yaml](#test-orchestrator-config).
Mulai IDT v4.5.2, Anda menggunakan `test_orchestrator.yaml` file untuk menentukan alur kerja pengujian. Di versi IDT sebelumnya, Anda menggunakan `state_machine.json` file tersebut. Untuk informasi tentang mesin negara, lihat[Konfigurasikan state machine IDT](idt-state-machine.md).
**`userdata_schema.json`**
Menentukan skema untuk [file `userdata.json`](set-config-custom.md#userdata-config-custom) yang dapat disertakan oleh test runner dalam konfigurasi pengaturannya. File `userdata.json` digunakan untuk konfigurasi informasi tambahan apa pun yang diperlukan untuk menjalankan tes tetapi tidak terdapat dalam file `device.json`. Lihat [Konfigurasikan userdata\$1schema.json](#userdata-schema-json).
File konfigurasi ditempatkan di Anda `` seperti yang ditunjukkan di sini.
```
└── suite
├── suite.json
├── test_orchestrator.yaml
├── userdata_schema.json
├──
├── group.json
├──
└── test.json
```
## Konfigurasikan suite.json
File `suite.json` menetapkan variabel lingkungan dan menentukan apakah data pengguna diperlukan untuk menjalankan rangkaian tes. Gunakan templat berikut untuk mengonfigurasi file `/suite/suite.json` Anda:
```
{
"id": "_",
"title": "",
"details": "",
"userDataRequired": true | false,
"environmentVariables": [
{
"key": "",
"value": "",
},
...
{
"key": "",
"value": "",
}
]
}
```
Semua kolom yang berisi nilai wajib diisi seperti yang dijelaskan di sini:
**`id`**
ID unik yang ditetapkan pengguna untuk rangkaian uji. Nilai dari `id` harus cocok dengan nama folder rangkaian uji tempat file `suite.json` berada. Nama rangkaian dan versi rangkaian juga harus memenuhi persyaratan berikut:
+ `` tidak dapat berisi garis bawah.
+ `` dilambangkan sebagai `x.x.x`, di mana `x` adalah angka.
ID ditampilkan dalam laporan uji yang dihasilkan IDT.
**`title`**
Nama yang ditetapkan pengguna untuk produk atau fitur yang diuji oleh rangkaian tes ini. Nama ditampilkan dalam IDT CLI untuk test runner.
**`details`**
Deskripsi singkat tentang tujuan dari rangkaian tes.
**`userDataRequired`**
Menentukan apakah test runner perlu menyertakan informasi kustom dalam file `userdata.json`. Jika Anda menetapkan nilai ini ke `true`, Anda juga harus menyertakan [file `userdata_schema.json`](#userdata-schema-json) dalam folder rangkaian uji Anda.
**`environmentVariables`**
Tidak wajib. Serangkaian variabel lingkungan yang akan ditetapkan untuk rangkaian tes ini.
**`environmentVariables.key`**
Nama variabel lingkungan.
**`environmentVariables.value`**
Nilai variabel lingkungan.
## Konfigurasikan group.json
File `group.json` menentukan apakah grup uji itu wajib atau opsional. Gunakan templat berikut untuk mengonfigurasi file `/suite//group.json` Anda:
```
{
"id": "",
"title": "",
"details": "",
"optional": true | false,
}
```
Semua kolom yang berisi nilai wajib diisi seperti yang dijelaskan di sini:
**`id`**
ID unik yang ditetapkan pengguna untuk grup uji. Nilai `id` harus sesuai dengan nama folder grup uji tempat `group.json` file berada dan tidak boleh memiliki garis bawah (`_`). ID digunakan dalam laporan uji yang dihasilkan IDT.
**`title`**
Nama deskriptif untuk grup uji. Nama tersebut ditampilkan dalam IDT CLI untuk test runner.
**`details`**
Deskripsi singkat tentang tujuan dari grup tes.
**`optional`**
Tidak wajib. Atur ke `true` untuk menampilkan grup tes ini sebagai grup opsional setelah IDT selesai menjalankan tes yang diperlukan. Nilai defaultnya adalah `false`.
## Konfigurasikan test.json
File `test.json` menentukan executable uji kasus dan variabel lingkungan yang digunakan oleh uji kasus. Untuk informasi selengkapnya tentang cara membuat executable uji kasus, lihat [Buat kasus uji IDT yang dapat dieksekusi](test-executables.md).
Gunakan templat berikut untuk mengonfigurasi file `/suite///test.json` Anda:
```
{
"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": "",
}
]
}
```
Semua kolom yang berisi nilai wajib diisi seperti yang dijelaskan di sini:
**`id`**
ID unik yang ditetapkan pengguna untuk grup uji. Nilai `id` harus sesuai dengan nama folder kasus uji tempat `test.json` file berada dan tidak boleh memiliki garis bawah (`_`). ID digunakan dalam laporan uji yang dihasilkan IDT.
**`title`**
Nama deskriptif untuk uji kasus. Nama tersebut ditampilkan dalam IDT CLI untuk test runner.
**`details`**
Deskripsi singkat tentang tujuan dari uji kasus.
**`requireDUT`**
Tidak wajib. Atur ke `true` jika perangkat diperlukan untuk menjalankan tes ini, jika tidak atur ke `false`. Nilai defaultnya adalah `true`. Test runner akan mengonfigurasi perangkat yang akan digunakannya untuk menjalankan pengujian di file `device.json`.
**`requiredResources`**
Tidak wajib. Serangkaian hal yang menyediakan informasi tentang perangkat sumber daya yang diperlukan untuk menjalankan tes ini.
**`requiredResources.name`**
Nama unik yang akan diberikan kepada sumber daya perangkat ketika tes ini berjalan.
**`requiredResources.features`**
Serangkaian fitur perangkat sumber daya yang ditetapkan pengguna.
**`requiredResources.features.name`**
Nama fitur. Fitur perangkat yang ingin Anda gunakan untuk perangkat ini. Nama ini dicocokkan dengan nama fitur yang disediakan oleh test runner di file `resource.json`.
**`requiredResources.features.version`**
Tidak wajib. Versi fitur. Nama ini dicocokkan dengan versi fitur yang disediakan oleh test runner di file `resource.json`. Jika versi tidak tersedia, maka fitur tersebut tidak dicentang. Jika nomor versi tidak diperlukan untuk fitur tersebut, biarkan kolom ini kosong.
**`requiredResources.features.jobSlots`**
Tidak wajib. Jumlah tes simultan yang dapat didukung fitur ini. Nilai default-nya adalah `1`. Jika Anda ingin IDT menggunakan perangkat yang berbeda untuk masing-masing fitur, kami sarankan Anda menetapkan nilai ini ke `1`.
**`execution.timeout`**
Jumlah waktu (dalam milidetik) yang ditunggu oleh IDT hingga tes tersebut selesai dijalankan. Untuk informasi selengkapnya tentang pengaturan parameter ini, lihat [Buat kasus uji IDT yang dapat dieksekusi](test-executables.md).
**`execution.os`**
Executable uji kasus yang akan dijalankan berdasarkan sistem operasi komputer host yang menjalankan IDT. Nilai yang didukung adalah `linux`, `mac`, dan `win`.
**`execution.os.cmd`**
Jalur ke executable uji kasus yang ingin Anda jalankan untuk sistem operasi tertentu. Lokasi ini harus berada di jalur sistem.
**`execution.os.args`**
Tidak wajib. Argumen yang akan disediakan untuk menjalankan executable uji kasus.
**`environmentVariables`**
Tidak wajib. Serangkaian variabel lingkungan yang akan ditetapkan untuk uji kasus ini.
**`environmentVariables.key`**
Nama variabel lingkungan.
**`environmentVariables.value`**
Nilai variabel lingkungan.
Jika Anda menentukan variabel lingkungan yang sama di file `test.json` dan di file `suite.json`, nilai dalam file `test.json` akan diutamakan.
## Konfigurasikan test\$1orchestrator.yaml
Orkestrator pengujian adalah konstruksi yang mengontrol alur eksekusi test suite. Ia menentukan keadaan awal dari rangkaian tes, mengelola transisi keadaan berdasarkan aturan yang ditetapkan pengguna, dan terus melakukan transisi melalui keadaan-keadaan tersebut sampai mencapai keadaan akhir.
Jika rangkaian pengujian Anda tidak menyertakan orkestrator pengujian yang ditentukan pengguna, IDT akan menghasilkan orkestrator pengujian untuk Anda.
Orkestrator uji default melakukan fungsi-fungsi berikut:
+ Menyediakan test runner dengan kemampuan untuk memilih dan menjalankan grup uji tertentu, dan bukan seluruh rangkaian uji.
+ Jika grup uji tertentu tidak dipilih, ia menjalankan setiap grup uji di rangkaian uji dengan urutan acak.
+ Membuat laporan dan mencetak ringkasan konsol yang menunjukkan hasil tes untuk setiap grup uji dan uji kasus.
Untuk informasi selengkapnya tentang bagaimana fungsi orkestrator pengujian IDT, lihat. [Konfigurasikan orkestrator uji IDT](idt-test-orchestrator.md)
## Konfigurasikan userdata\$1schema.json
File `userdata_schema.json` menentukan skema di mana test runner menyediakan data pengguna. Data pengguna diperlukan jika rangkaian uji Anda memerlukan informasi yang tidak ada di file `device.json`. Misalnya, pengujian Anda mungkin memerlukan kredensial jaringan Wi-Fi, port terbuka tertentu, atau sertifikat yang harus diberikan pengguna. Informasi ini dapat diberikan kepada IDT sebagai parameter input yang disebut `userdata`, nilai yang merupakan file `userdata.json`, yang dibuat oleh para pengguna dalam `/config` mereka. Format file `userdata.json` didasarkan pada `userdata_schema.json` yang Anda sertakan dalam rangkaian tes.
Untuk menunjukkan hal tersebut test runner harus menyediakan file `userdata.json`:
1. Di file `suite.json`, atur `userDataRequired` ke `true`.
1. Di `` Anda, buat file `userdata_schema.json`.
1. Edit file `userdata_schema.json` untuk membuat [Skema IETF Draft v4 JSON](https://json-schema.org/specification-links#draft-4) yang valid.
Ketika IDT menjalankan rangkaian uji Anda, secara otomatis ia membaca skema dan menggunakannya untuk memvalidasi file `userdata.json` yang disediakan oleh test runner. Jika valid, isi `userdata.json` file tersedia dalam konteks [IDT dan dalam konteks](idt-context.md) [orkestrator pengujian](idt-test-orchestrator.md#idt-test-orchestrator-context).
# Konfigurasikan orkestrator uji IDT
*Mulai IDT v4.5.2, IDT menyertakan komponen orkestrator pengujian baru.* Orkestrator pengujian adalah komponen IDT yang mengontrol alur eksekusi rangkaian pengujian, dan menghasilkan laporan pengujian setelah IDT selesai menjalankan semua pengujian. Orkestrator pengujian menentukan pemilihan pengujian dan urutan pengujian dijalankan berdasarkan aturan yang ditentukan pengguna.
Jika rangkaian pengujian Anda tidak menyertakan orkestrator pengujian yang ditentukan pengguna, IDT akan menghasilkan orkestrator pengujian untuk Anda.
Orkestrator uji default melakukan fungsi-fungsi berikut:
+ Menyediakan test runner dengan kemampuan untuk memilih dan menjalankan grup uji tertentu, dan bukan seluruh rangkaian uji.
+ Jika grup uji tertentu tidak dipilih, ia menjalankan setiap grup uji di rangkaian uji dengan urutan acak.
+ Membuat laporan dan mencetak ringkasan konsol yang menunjukkan hasil tes untuk setiap grup uji dan uji kasus.
Orkestrator uji menggantikan mesin status IDT. Kami sangat menyarankan Anda menggunakan orkestrator pengujian untuk mengembangkan rangkaian pengujian Anda alih-alih mesin status IDT. Orkestrator uji menyediakan fitur-fitur yang disempurnakan berikut:
+ Menggunakan format deklaratif dibandingkan dengan format imperatif yang digunakan mesin status IDT. Ini memungkinkan Anda menentukan tes mana yang ingin Anda jalankan dan kapan Anda ingin menjalankannya.
+ Mengelola penanganan grup tertentu, pembuatan laporan, penanganan kesalahan, dan pelacakan hasil sehingga Anda tidak diharuskan mengelola tindakan ini secara manual.
+ Menggunakan format YAMAL, yang mendukung komentar secara default.
+ Membutuhkan 80 persen lebih sedikit ruang disk daripada orkestrator pengujian untuk menentukan alur kerja yang sama.
+ Menambahkan validasi pra-pengujian untuk memverifikasi bahwa definisi alur kerja Anda tidak mengandung pengujian yang salah IDs atau dependensi melingkar.
## Format orkestrator uji
Anda dapat menggunakan templat berikut untuk mengonfigurasi file `custom-test-suite-folder/suite/test_orchestrator.yaml` Anda:
```
Aliases:
string: context-expression
ConditionalTests:
- Condition: context-expression
Tests:
- test-descriptor
Order:
- - group-descriptor
- group-descriptor
Features:
- Name: feature-name
Value: support-description
Condition: context-expression
Tests:
- test-descriptor
OneOfTests:
- test-descriptor
IsRequired: boolean
```
Semua kolom yang berisi nilai wajib diisi seperti yang dijelaskan di sini:
`Aliases`
Tidak wajib. String yang ditentukan pengguna yang memetakan ke ekspresi konteks. Alias memungkinkan Anda menghasilkan nama ramah untuk mengidentifikasi ekspresi konteks dalam konfigurasi orkestrator pengujian Anda. Ini sangat berguna jika Anda membuat ekspresi konteks kompleks atau ekspresi yang Anda gunakan di banyak tempat.
Anda dapat menggunakan ekspresi konteks untuk menyimpan kueri konteks yang memungkinkan Anda mengakses data dari konfigurasi IDT lainnya. Untuk informasi selengkapnya, lihat [Akses data dalam konteks](idt-context.md#accessing-context-data).
**Example**
**Contoh**
```
Aliases:
FizzChosen: "'{{$pool.features[?(@.name == 'Fizz')].value[0]}}' == 'yes'"
BuzzChosen: "'{{$pool.features[?(@.name == 'Buzz')].value[0]}}' == 'yes'"
FizzBuzzChosen: "'{{$aliases.FizzChosen}}' && '{{$aliases.BuzzChosen}}'"
```
`ConditionalTests`
Tidak wajib. Daftar kondisi, dan kasus uji terkait yang dijalankan ketika setiap kondisi terpenuhi. Setiap kondisi dapat memiliki beberapa kasus uji; Namun, Anda dapat menetapkan kasus uji yang diberikan hanya untuk satu kondisi.
Secara default, IDT menjalankan kasus uji apa pun yang tidak ditetapkan ke kondisi dalam daftar ini. Jika Anda tidak menentukan bagian ini, IDT menjalankan semua grup pengujian dalam rangkaian pengujian.
Setiap item dalam `ConditionalTests` daftar mencakup parameter berikut:
`Condition`
Ekspresi konteks yang mengevaluasi nilai Boolean. Jika nilai yang dievaluasi benar, IDT menjalankan kasus uji yang ditentukan dalam parameter. `Tests`
`Tests`
Daftar deskriptor tes.
Setiap deskriptor tes menggunakan ID kelompok uji dan satu atau lebih kasus uji IDs untuk mengidentifikasi pengujian individu untuk dijalankan dari kelompok uji tertentu. Deskriptor tes menggunakan format berikut:
```
GroupId: group-id
CaseIds: [test-id, test-id] # optional
```
**Example**
**Contoh**
Contoh berikut menggunakan ekspresi konteks generik yang dapat Anda definisikan sebagai`Aliases`.
```
ConditionalTests:
- Condition: "{{$aliases.Condition1}}"
Tests:
- GroupId: A
- GroupId: B
- Condition: "{{$aliases.Condition2}}"
Tests:
- GroupId: D
- Condition: "{{$aliases.Condition1}} || {{$aliases.Condition2}}"
Tests:
- GroupId: C
```
Berdasarkan kondisi yang ditentukan, IDT memilih kelompok uji sebagai berikut:
+ Jika `Condition1` benar, IDT menjalankan tes dalam kelompok uji A, B, dan C.
+ Jika `Condition2` benar, IDT menjalankan tes dalam kelompok uji C dan D.
`Order`
Tidak wajib. Urutan untuk menjalankan tes. Anda menentukan urutan pengujian di tingkat kelompok uji. Jika Anda tidak menentukan bagian ini, IDT menjalankan semua grup pengujian yang berlaku dalam urutan acak. Nilai `Order` adalah daftar daftar deskriptor grup. Setiap grup pengujian yang tidak Anda cantumkan`Order`, dapat dijalankan secara paralel dengan grup pengujian terdaftar lainnya.
Setiap daftar deskriptor grup berisi salah satu deskriptor grup lainnya, dan mengidentifikasi urutan untuk menjalankan grup yang ditentukan dalam setiap deskriptor. Anda dapat menggunakan format berikut untuk menentukan deskriptor grup individual:
+ `group-id`—ID grup dari grup uji yang ada.
+ `[group-id, group-id]`—Daftar kelompok uji yang dapat dijalankan dalam urutan apa pun relatif satu sama lain.
+ `"*"`—Wildcard. Ini setara dengan daftar semua kelompok uji yang belum ditentukan dalam daftar deskriptor grup saat ini.
Nilai untuk juga `Order` harus memenuhi persyaratan berikut:
+ Grup pengujian IDs yang Anda tentukan dalam deskriptor grup harus ada di rangkaian pengujian Anda.
+ Setiap daftar deskriptor kelompok harus menyertakan setidaknya satu kelompok uji.
+ Setiap daftar deskriptor grup harus berisi grup IDs unik. Anda tidak dapat mengulang ID grup uji dalam deskriptor grup individual.
+ Daftar deskriptor grup dapat memiliki paling banyak satu deskriptor grup wildcard. Deskriptor grup wildcard harus menjadi item pertama atau terakhir dalam daftar.
**Example**
**Contoh**
Untuk rangkaian pengujian yang berisi grup pengujian A, B, C, D, dan E, daftar contoh berikut menunjukkan cara berbeda untuk menentukan bahwa IDT pertama-tama harus menjalankan grup uji A, kemudian menjalankan grup uji B, dan kemudian menjalankan grup uji C, D, dan E dalam urutan apa pun.
+
```
Order:
- - A
- B
- [C, D, E]
```
+
```
Order:
- - A
- B
- "*"
```
+
```
Order:
- - A
- B
- - B
- C
- - B
- D
- - B
- E
```
`Features`
Tidak wajib. Daftar fitur produk yang Anda ingin IDT tambahkan ke `awsiotdevicetester_report.xml` file. Jika Anda tidak menentukan bagian ini, IDT tidak akan menambahkan fitur produk apa pun ke laporan.
Fitur produk adalah informasi yang ditetapkan pengguna tentang kriteria spesifik yang mungkin dipenuhi oleh perangkat. Misalnya, fitur produk MQTT dapat menunjukkan bahwa perangkat menerbitkan pesan MQTT dengan benar. Dalam`awsiotdevicetester_report.xml`, fitur produk ditetapkan sebagai`supported`,`not-supported`, atau nilai yang ditentukan pengguna khusus, berdasarkan apakah tes tertentu lulus.
Setiap item dalam `Features` daftar terdiri dari parameter berikut:
`Name`
Nama fitur.
`Value`
Tidak wajib. Nilai kustom yang ingin Anda gunakan dalam laporan, bukan`supported`. Jika nilai ini tidak ditentukan, maka IDT berbasis menetapkan nilai fitur ke `supported` atau `not-supported` berdasarkan hasil pengujian. Jika Anda menguji fitur yang sama dengan kondisi yang berbeda, Anda dapat menggunakan nilai kustom untuk setiap instance fitur tersebut dalam `Features` daftar, dan IDT menggabungkan nilai fitur untuk kondisi yang didukung. Untuk informasi selengkapnya, silakan lihat
`Condition`
Ekspresi konteks yang mengevaluasi nilai Boolean. Jika nilai yang dievaluasi benar, IDT menambahkan fitur ke laporan pengujian setelah selesai menjalankan rangkaian pengujian. Jika nilai yang dievaluasi salah, tes tidak termasuk dalam laporan.
`Tests`
Tidak wajib. Daftar deskriptor tes. Semua tes yang ditentukan dalam daftar ini harus lulus agar fitur didukung.
Setiap deskriptor pengujian dalam daftar ini menggunakan ID kelompok uji dan satu atau lebih kasus uji IDs untuk mengidentifikasi pengujian individual yang akan dijalankan dari kelompok uji tertentu. Deskriptor tes menggunakan format berikut:
```
GroupId: group-id
CaseIds: [test-id, test-id] # optional
```
Anda harus menentukan salah satu `Tests` atau `OneOfTests` untuk setiap fitur dalam `Features` daftar.
`OneOfTests`
Tidak wajib. Daftar deskriptor tes. Setidaknya salah satu tes yang ditentukan dalam daftar ini harus lulus agar fitur didukung.
Setiap deskriptor pengujian dalam daftar ini menggunakan ID kelompok uji dan satu atau lebih kasus uji IDs untuk mengidentifikasi pengujian individual yang akan dijalankan dari kelompok uji tertentu. Deskriptor tes menggunakan format berikut:
```
GroupId: group-id
CaseIds: [test-id, test-id] # optional
```
Anda harus menentukan salah satu `Tests` atau `OneOfTests` untuk setiap fitur dalam `Features` daftar.
`IsRequired`
Nilai boolean yang menentukan apakah fitur tersebut diperlukan dalam laporan pengujian. Nilai default-nya adalah `false`.
## Konteks orkestrator uji
Konteks orkestrator pengujian adalah dokumen JSON read-only yang berisi data yang tersedia untuk orkestrator pengujian selama eksekusi. Konteks orkestrator pengujian hanya dapat diakses dari orkestrator pengujian, dan berisi informasi yang menentukan alur pengujian. Misalnya, Anda dapat menggunakan informasi yang dikonfigurasi oleh test runner di file `userdata.json` untuk menentukan apakah pengujian tertentu wajib dijalankan.
Konteks orkestrator pengujian menggunakan format berikut:
```
{
"pool": {
},
"userData": {
},
"config": {
}
}
```
`pool`
Informasi tentang kolam perangkat yang dipilih untuk uji coba. Untuk kolam perangkat yang dipilih, informasi ini diambil dari elemen rangkaian perangkat tingkat atas yang sesuai yang ditentukan dalam file `device.json`.
`userData`
Informasi di file `userdata.json`.
`config`
Informasi di file `config.json`.
Anda dapat menanyakan konteks menggunakan JSONPath notasi. Sintaks untuk JSONPath kueri dalam definisi negara adalah. `{{query}}` Saat Anda mengakses data dari konteks orkestrator pengujian, pastikan setiap nilai mengevaluasi string, angka, atau Boolean.
Untuk informasi selengkapnya tentang penggunaan JSONPath notasi untuk mengakses data dari konteks, lihat[Gunakan konteks IDT](idt-context.md).
# Konfigurasikan state machine IDT
**penting**
Mulai IDT v4.5.2, mesin status ini tidak digunakan lagi. Kami sangat menyarankan Anda menggunakan orkestrator uji baru. Untuk informasi selengkapnya, lihat [Konfigurasikan orkestrator uji IDT](idt-test-orchestrator.md).
State machine adalah suatu konstruksi yang mengendalikan aliran eksekusi rangkaian uji. Ia menentukan keadaan awal dari rangkaian tes, mengelola transisi keadaan berdasarkan aturan yang ditetapkan pengguna, dan terus melakukan transisi melalui keadaan-keadaan tersebut sampai mencapai keadaan akhir.
Jika rangkaian tes Anda tidak menyertakan state machine yang ditetapkan pengguna, IDT akan membuat state machine untuk Anda. State machine default melakukan fungsi-fungsi berikut:
+ Menyediakan test runner dengan kemampuan untuk memilih dan menjalankan grup uji tertentu, dan bukan seluruh rangkaian uji.
+ Jika grup uji tertentu tidak dipilih, ia menjalankan setiap grup uji di rangkaian uji dengan urutan acak.
+ Membuat laporan dan mencetak ringkasan konsol yang menunjukkan hasil tes untuk setiap grup uji dan uji kasus.
State machine untuk rangkaian uji IDT harus memenuhi kriteria berikut:
+ Setiap keadaan sesuai dengan tindakan yang harus ddilakukan oleh IDT, seperti menjalankan grup uji atau produk file laporan.
+ Transisi ke suatu keadaan akan menghasilkan tindakan yang terkait dengan keadaan tersebut.
+ Setiap keadaan menentukan aturan transisi untuk keadaan berikutnya.
+ Keadaan akhir harus berupa `Succeed` atau `Fail`.
## Format state machine
Anda dapat menggunakan templat berikut untuk mengonfigurasi file `/suite/state_machine.json` Anda:
```
{
"Comment": "",
"StartAt": "",
"States": {
"": {
"Type": "",
// Additional state configuration
}
// Required states
"Succeed": {
"Type": "Succeed"
},
"Fail": {
"Type": "Fail"
}
}
}
```
Semua kolom yang berisi nilai wajib diisi seperti yang dijelaskan di sini:
**`Comment`**
Sebuah deskripsi tentang state machine.
**`StartAt`**
Nama keadaan di mana IDT mulai menjalankan rangkaian tes. Nilai dari `StartAt` harus diatur ke salah satu keadaan yang tercantum di objek `States`.
**`States`**
Sebuah objek yang memetakan nama keadaan yang ditetapkan pengguna ke keadaan IDT yang valid. Setiap Negara. *state-name*objek berisi definisi status valid yang dipetakan ke. *state-name*
Objek `States` harus mencakup keadaan `Succeed` dan `Fail`. Untuk informasi lebih lanjut tentang keadaan yang valid, lihat [Keadaan yang valid dan definisi keadaan](#valid-states).
## Keadaan yang valid dan definisi keadaan
Bagian ini menjelaskan definisi keadaan pada semua keadaan yang valid yang dapat digunakan dalam state machine IDT. Beberapa keadaan berikut mendukung konfigurasi pada tingkat uji kasus. Namun, kami sarankan Anda untuk mengonfigurasi aturan transisi keadaan pada tingkat grup uji dan bukan pada tingkat uji kasus kecuali jika benar-benar diperlukan.
**Topics**
+ [
### RunTask
](#state-runtask)
+ [
### Pilihan
](#state-choice)
+ [
### Paralel
](#state-parallel)
+ [
### AddProductFeatures
](#state-addproductfeatures)
+ [
### Laporan
](#state-report)
+ [
### LogMessage
](#state-logmessage)
+ [
### SelectGroup
](#state-selectgroup)
+ [
### Gagal
](#state-fail)
+ [
### Berhasil
](#state-succeed)
### RunTask
Keadaan `RunTask` menjalankan uji kasus dari grup uji yang ditentukan dalam rangkaian tes.
```
{
"Type": "RunTask",
"Next": "",
"TestGroup": "",
"TestCases": [
""
],
"ResultVar": ""
}
```
Semua kolom yang berisi nilai wajib diisi seperti yang dijelaskan di sini:
**`Next`**
Nama keadaan yang akan ditransisi setelah melaksanakan tindakan dalam keadaan saat ini.
**`TestGroup`**
Tidak wajib. ID grup uji yang akan dijalankan. Jika nilai ini tidak ditentukan, IDT akan menjalankan grup uji yang dipilih oleh test runner.
**`TestCases`**
Tidak wajib. Array kasus uji IDs dari grup yang ditentukan dalam`TestGroup`. Berdasarkan nilai-nilai `TestGroup` dan `TestCases`, IDT menentukan perilaku eksekusi tes sebagai berikut:
+ Ketika `TestGroup` dan `TestCases` ditentukan, IDT akan menjalankan uji kasus tertentu dari grup uji.
+ Ketika `TestCases` ditentukan tetapi `TestGroup` tidak ditentukan, IDT akan menjalankan uji kasus yang ditentukan.
+ Ketika `TestGroup` ditentukan tetapi `TestCases` tidak ditentukan, IDT akan menjalankan semua uji kasus di grup uji yang ditentukan.
+ Ketika `TestGroup` ataupun `TestCases` tidak ditentukan, IDT akan menjalankan semua uji kasus dari grup uji yang dipilih oleh test runner dari IDT CLI. Untuk mengaktifkan pilihan grup untuk test runner, Anda harus menyertakan keadaan `RunTask` dan `Choice` dalam file `statemachine.json` Anda. Untuk contoh cara kerjanya, lihat [Contoh state machine: Jalankan grup uji yang dipilih pengguna](#allow-specific-groups).
Untuk informasi selengkapnya tentang mengaktifkan perintah IDT CLI untuk test runner, lihat [Aktifkan perintah IDT CLI](test-executables.md#idt-cli-coop).
**`ResultVar`**
Nama variabel konteks yang akan diatur dengan hasil uji yang dijalankan. Jangan tentukan nilai ini jika Anda tidak menentukan nilai untuk `TestGroup`. IDT menetapkan nilai variabel yang Anda tentukan di `ResultVar` hingga `true` atau `false` berdasarkan berikut ini:
+ Jika nama variabel adalah dari bentuk `text_text_passed`, maka nilainya akan diatur ke apakah semua tes dalam grup uji pertama akan dilalui atau dilompati.
+ Dalam semua kasus lainnya, nilai akan diatur ke apakah semua tes di semua grup uji akan dilalui atau dilompati.
Biasanya, Anda akan menggunakan `RunTask` status untuk menentukan ID grup uji tanpa menentukan kasus uji individual IDs, sehingga IDT akan menjalankan semua kasus uji dalam kelompok uji yang ditentukan. Semua uji kasus yang dijalankan oleh keadaan ini berjalan secara paralel, dengan urutan acak. Namun, jika semua uji kasus memerlukan perangkat untuk dijalankan, dan hanya satu perangkat yang tersedia, maka uji kasus akan berjalan secara berurutan sebagai gantinya.
**Penanganan kesalahan**
Jika salah satu grup uji atau kasus uji IDs yang ditentukan tidak valid, maka status ini mengeluarkan kesalahan `RunTaskError` eksekusi. Jika keadaan ini menemukan kesalahan eksekusi, ia juga akan menetapkan variabel `hasExecutionError` dalam konteks state machine ke `true`.
### Pilihan
Keadaan `Choice` memungkinkan Anda secara dinamis mengatur keadaan berikutnya yang akan ditransisikan berdasarkan keadaan yang ditetapkan pengguna.
```
{
"Type": "Choice",
"Default": "",
"FallthroughOnError": true | false,
"Choices": [
{
"Expression": "",
"Next": ""
}
]
}
```
Semua kolom yang berisi nilai wajib diisi seperti yang dijelaskan di sini:
**`Default`**
Keadaan default yang akan ditransisikan jika tidak terdapat ekspresi yang ditentukan di `Choices` dapat dievaluasi pada `true`.
**`FallthroughOnError`**
Tidak wajib. Menentukan perilaku ketika keadaan tersebut bertemu kesalahan dalam mengevaluasi ekspresi. Atur ke `true` jika Anda ingin melompati ekspresi jika hasil evaluasi menghasilkan kesalahan. Jika tidak ada ekspresi yang cocok, state machine akan bertransisi ke keadaan `Default`. Jika nilai `FallthroughOnError` tidak ditentukan, default-nya adalah `false`.
**`Choices`**
Serangkaian ekspresi dan keadaan untuk menentukan keadaan mana yang akan ditransisikan setelah mengeksekusi tindakan dalam keadaan saat ini.
**`Choices.Expression`**
Ekspresi yang harus dievaluasi pada nilai boolean. Jika ekspresi mengevaluasi `true`, maka state machine akan bertransisi ke keadaan yang ditentukan dalam `Choices.Next`. String ekspresi mengambil nilai-nilai dari konteks state machine dan kemudian melakukan operasi padanya untuk sampai pada nilai boolean. Untuk informasi tentang mengakses konteks mesin status, lihat[Konteks mesin keadaan](#state-machine-context).
**`Choices.Next`**
Nama keadaan yang akan ditransisikan jika ekspresi yang ditentukan dalam `Choices.Expression` dievaluasi pada `true`.
**Penanganan kesalahan**
Keadaan `Choice` dapat memerlukan penanganan kesalahan dalam kasus berikut:
+ Beberapa variabel dalam ekspresi pilihan tidak ada dalam konteks state machine.
+ Hasil ekspresi bukan merupakan nilai boolean.
+ Hasil pencarian JSON bukanlah string, nomor, atau boolean.
Anda tidak dapat menggunakan blok `Catch` untuk menangani kesalahan dalam keadaan ini. Jika Anda ingin berhenti mengeksekusi state machine ketika menemukan kesalahan, Anda harus mengatur `FallthroughOnError` ke `false`. Namun, kami menyarankan agar Anda mengatur `FallthroughOnError` ke `true` Anda, dan tergantung pada kasus penggunaan Anda, lakukan salah satu langkah berikut:
+ Jika variabel yang Anda akses diharapkan untuk tidak ada dalam beberapa kasus, gunakan nilai `Default` dan blok `Choices` tambahan untuk menentukan keadaan berikutnya.
+ Jika variabel yang Anda akses harus selalu ada, atur keadaan `Default`ke `Fail`.
### Paralel
Keadaan `Parallel` memungkinkan Anda untuk menentukan dan menjalankan state machine baru secara paralel satu sama lain.
```
{
"Type": "Parallel",
"Next": "",
"Branches": [
]
}
```
Semua kolom yang berisi nilai wajib diisi seperti yang dijelaskan di sini:
**`Next`**
Nama keadaan yang akan ditransisi setelah melaksanakan tindakan dalam keadaan saat ini.
**`Branches`**
Serangkaian definisi state machine yang akan dijalankan. Setiap definisi state machine harus berisi keadaan `StartAt`, `Succeed`, dan `Fail` miliknya sendiri. Definisi state machine dalam rangkaian ini tidak dapat mengacu pada keadaan di luar definisinya sendiri.
Karena setiap cabang state machine memiliki konteks state machine yang sama, pengaturan variabel dalam satu cabang dan kemudian pembacaan variabel-variabel dari cabang lain dapat mengakibatkan perilaku yang tidak terduga.
Keadaan `Parallel` bergerak ke keadaan berikutnya hanya setelah keadaan tersebut menjalankan semua cabang state machine. Setiap keadaan yang memerlukan perangkat akan menunggu untuk berjalan hingga perangkat tersebut tersedia. Jika beberapa perangkat tersedia, keadaan ini akan menjalankan uji kasus dari beberapa grup secara paralel. Jika tidak tersedia perangkat yang memadai, uji kasus akan berjalan secara berurutan. Karena uji kasus dijalankan dalam urutan acak ketika berjalan secara paralel, perangkat yang berbeda mungkin digunakan untuk menjalankan tes dari grup tes yang sama.
**Penanganan kesalahan**
Pastikan bahwa baik state machine cabang dan state machine induk bertransisi ke keadaan `Fail` untuk menangani kesalahan eksekusi.
Karena state machine cabang tidak mengirimkan kesalahan eksekusi ke state machine induk, Anda tidak dapat menggunakan blok `Catch` untuk menangani kesalahan eksekusi di state machine cabang. Sebagai gantinya, gunakan nilai `hasExecutionErrors` dalam konteks state machine bersama. Untuk contoh cara bekerjanya, lihat [Contoh state machine: Jalankan dua grup uji secara paralel](#run-in-parallel).
### AddProductFeatures
Keadaan `AddProductFeatures` memungkinkan Anda menambahkan fitur produk ke file `awsiotdevicetester_report.xml` yang dihasilkan oleh IDT.
Fitur produk adalah informasi yang ditetapkan pengguna tentang kriteria spesifik yang mungkin dipenuhi oleh perangkat. Misalnya, fitur produk `MQTT` dapat menetapkan bahwa perangkat akan menerbitkan pesan MQTT dengan benar. Dalam laporan tersebut, fitur produk ditetapkan sebagai `supported`, `not-supported`, atau nilai kustom, berdasarkan apakah tes yang ditentukan berhasil dilalui.
**catatan**
Keadaan `AddProductFeatures` tidak menghasilkan laporan dengan sendirinya. Keadaan ini harus bertransisi ke [keadaan `Report`](#state-report) untuk menghasilkan laporan.
```
{
"Type": "Parallel",
"Next": "",
"Features": [
{
"Feature": "",
"Groups": [
""
],
"OneOfGroups": [
""
],
"TestCases": [
""
],
"IsRequired": true | false,
"ExecutionMethods": [
""
]
}
]
}
```
Semua kolom yang berisi nilai wajib diisi seperti yang dijelaskan di sini:
**`Next`**
Nama keadaan yang akan ditransisi setelah melaksanakan tindakan dalam keadaan saat ini.
**`Features`**
Serangkaian fitur produk yang akan ditampilkan di file `awsiotdevicetester_report.xml`.
**`Feature`**
Nama fitur
**`FeatureValue`**
Tidak wajib. Nilai kustom yang akan digunakan dalam laporan, dan bukan `supported`. Jika nilai ini tidak ditentukan, maka berdasarkan hasil tes, nilai fitur akan diatur ke `supported` atau `not-supported`.
Jika Anda menggunakan nilai kustom untuk `FeatureValue`, Anda dapat menguji fitur yang sama dengan kondisi yang berbeda, dan IDT akan menggabungkan nilai fitur untuk kondisi yang didukung. Misalnya, petikan berikut menunjukkan fitur `MyFeature` dengan dua nilai fitur yang terpisah:
```
...
{
"Feature": "MyFeature",
"FeatureValue": "first-feature-supported",
"Groups": ["first-feature-group"]
},
{
"Feature": "MyFeature",
"FeatureValue": "second-feature-supported",
"Groups": ["second-feature-group"]
},
...
```
Jika kedua grup uji itu lulus, nilai fitur akan diatur ke `first-feature-supported, second-feature-supported`.
**`Groups`**
Tidak wajib. Array kelompok uji IDs. Semua tes dalam setiap kelompok uji yang ditentukan harus lulus pada fitur yang akan didukung.
**`OneOfGroups`**
Tidak wajib. Array kelompok uji IDs. Semua tes dalam setidaknya satu kelompok uji yang ditentukan harus lulus pada fitur yang akan didukung.
**`TestCases`**
Tidak wajib. Sebuah array kasus uji IDs. Jika Anda menentukan nilai ini, maka hal berikut ini akan berlaku:
+ Semua uji kasus yang ditentukan harus lulus pada fitur yang akan didukung.
+ `Groups` harus berisi hanya satu ID grup uji.
+ `OneOfGroups` tidak boleh ditentukan.
**`IsRequired`**
Tidak wajib. Atur ke `false` untuk menandai fitur ini sebagai fitur opsional dalam laporan. Nilai default adalah `true`.
**`ExecutionMethods`**
Tidak wajib. Serangkaian metode eksekusi yang sesuai dengan nilai `protocol` yang ditentukan dalam file `device.json`. Jika nilai ini ditentukan, test runner harus menentukan nilai `protocol` yang cocok dengan salah satu nilai dalam rangkaian ini untuk menyertakan fitur tersebut dalam laporan. Jika nilai ini tidak ditentukan, maka fitur itu akan selalu disertakan dalam laporan.
Untuk menggunakan keadaan `AddProductFeatures`, Anda harus menetapkan nilai `ResultVar` di keadaan `RunTask` ke salah satu nilai berikut:
+ Jika Anda menentukan kasus uji individual IDs, maka atur `ResultVar` ke`group-id_test-id_passed`.
+ Jika Anda tidak menentukan kasus uji individual IDs, maka setel `ResultVar` ke`group-id_passed`.
Keadaan `AddProductFeatures` akan mengecek hasil tes dengan cara berikut:
+ Jika Anda tidak menentukan kasus uji apa pun IDs, maka hasil untuk setiap kelompok uji ditentukan dari nilai `group-id_passed` variabel dalam konteks mesin negara.
+ Jika Anda memang menentukan kasus uji IDs, maka hasil untuk masing-masing pengujian ditentukan dari nilai `group-id_test-id_passed` variabel dalam konteks mesin negara.
**Penanganan kesalahan**
Jika ID grup yang disediakan dalam keadaan ini bukan ID grup yang valid, maka keadaan ini akan menghasilkan kesalahan eksekusi `AddProductFeaturesError`. Jika keadaan ini menemukan kesalahan eksekusi, ia juga akan menetapkan variabel `hasExecutionErrors` dalam konteks state machine ke `true`.
### Laporan
Keadaan `Report` menghasilkan file `suite-name_Report.xml` dan `awsiotdevicetester_report.xml`. Keadaan ini juga mengalirkan laporan ke konsol.
```
{
"Type": "Report",
"Next": ""
}
```
Semua kolom yang berisi nilai wajib diisi seperti yang dijelaskan di sini:
**`Next`**
Nama keadaan yang akan ditransisi setelah melaksanakan tindakan dalam keadaan saat ini.
Anda harus selalu beralih ke keadaan `Report` menjelang akhir aliran eksekusi tes agar test runner dapat melihat hasil tes. Biasanya, keadaan berikutnya setelah keadaan ini adalah `Succeed`.
**Penanganan kesalahan**
Jika keadaan ini mengalami masalah dalam menghasilkan laporan, keadaan tersebut akan mengeluarkan kesalahan eksekusi `ReportError`.
### LogMessage
Keadaan `LogMessage` akan menghasilkan file `test_manager.log` dan mengalirkan pesan log ke konsol.
```
{
"Type": "LogMessage",
"Next": ""
"Level": "info | warn | error"
"Message": ""
}
```
Semua kolom yang berisi nilai wajib diisi seperti yang dijelaskan di sini:
**`Next`**
Nama keadaan yang akan ditransisi setelah melaksanakan tindakan dalam keadaan saat ini.
**`Level`**
Tingkat kesalahan tempat membuat pesan log. Jika Anda menentukan tingkat yang tidak valid, keadaan ini akan menghasilkan pesan kesalahan dan membuangnya.
**`Message`**
Pesan yang akan dicatat.
### SelectGroup
Keadaan `SelectGroup` memperbarui konteks state machine untuk menunjukkan grup mana yang dipilih. Nilai-nilai yang ditetapkan oleh keadaan ini digunakan oleh setiap kondisi `Choice` berikutnya.
```
{
"Type": "SelectGroup",
"Next": ""
"TestGroups": [
"
]
}
```
Semua kolom yang berisi nilai wajib diisi seperti yang dijelaskan di sini:
**`Next`**
Nama keadaan yang akan ditransisi setelah melaksanakan tindakan dalam keadaan saat ini.
**`TestGroups`**
Serangkaian grup uji yang akan ditandai sudah dipilih. Untuk setiap ID grup uji dalam rangkaian ini, variabel `group-id_selected` akan diatur ke `true` dalam konteks. Pastikan Anda menyediakan grup pengujian yang valid IDs karena IDT tidak memvalidasi apakah grup yang ditentukan ada.
### Gagal
Keadaan `Fail` menunjukkan bahwa state machine tidak mengeksekusi dengan benar. Ini adalah keadaan akhir untuk state machine, dan setiap definisi state machine harus mencakup keadaan ini.
```
{
"Type": "Fail"
}
```
### Berhasil
Keadaan `Succeed` menunjukkan bahwa state machine mengeksekusi dengan benar. Ini adalah keadaan akhir untuk state machine, dan setiap definisi state machine harus mencakup keadaan ini.
```
{
"Type": "Succeed"
}
```
## Konteks mesin keadaan
Konteks state machine adalah dokumen JSON baca-saja yang berisi data yang tersedia untuk state machine selama eksekusi. Konteks state machine hanya dapat diakses dari state machine, dan berisi informasi yang menentukan aliran uji. Misalnya, Anda dapat menggunakan informasi yang dikonfigurasi oleh test runner di file `userdata.json` untuk menentukan apakah pengujian tertentu wajib dijalankan.
Konteks state machine menggunakan format berikut:
```
{
"pool": {
},
"userData": {
},
"config": {
},
"suiteFailed": true | false,
"specificTestGroups": [
""
],
"specificTestCases": [
""
],
"hasExecutionErrors": true
}
```
**`pool`**
Informasi tentang kolam perangkat yang dipilih untuk uji coba. Untuk kolam perangkat yang dipilih, informasi ini diambil dari elemen rangkaian perangkat tingkat atas yang sesuai yang ditentukan dalam file `device.json`.
**`userData`**
Informasi di file `userdata.json`.
**`config`**
Informasi menyematkan file `config.json`.
**`suiteFailed`**
Nilai diatur ke `false` ketika state machine dimulai. Jika grup uji gagal dalam keadaan `RunTask`, maka nilai ini akan ditetapkan ke `true` untuk durasi sisa eksekusi state machine.
**`specificTestGroups`**
Jika test runner memilih grup pengujian tertentu untuk dijalankan, bukan seluruh rangkaian pengujian, kunci ini dibuat dan berisi daftar grup pengujian tertentu. IDs
**`specificTestCases`**
Jika test runner memilih kasus pengujian tertentu untuk dijalankan, bukan seluruh rangkaian pengujian, kunci ini dibuat dan berisi daftar kasus uji tertentu. IDs
**`hasExecutionErrors`**
Tidak keluar saat state machine dimulai. Jika keadaan apa pun menemukan kesalahan eksekusi, variabel ini akan dibuat dan diatur ke `true` selama durasi sisa eksekusi state machine.
Anda dapat menanyakan konteks menggunakan JSONPath notasi. Sintaks untuk JSONPath kueri dalam definisi negara adalah. `{{$.query}}` Anda dapat menggunakan JSONPath kueri sebagai string placeholder di beberapa negara bagian. IDT menggantikan string placeholder dengan nilai kueri yang dievaluasi JSONPath dari konteks. Anda dapat menggunakan placeholder untuk nilai-nilai berikut:
+ Nilai `TestCases` dalam keadaan `RunTask`.
+ Nilai `Expression` keadaan `Choice`.
Ketika Anda mengakses data dari konteks state machine, pastikan keadaan berikut dipenuhi:
+ Jalur JSON Anda harus dimulai dengan `$.`
+ Setiap nilai harus dievaluasi pada string, angka, atau boolean.
Untuk informasi selengkapnya tentang penggunaan JSONPath notasi untuk mengakses data dari konteks, lihat[Gunakan konteks IDT](idt-context.md).
## Kesalahan eksekusi
Kesalahan eksekusi adalah kesalahan dalam definisi state machine yang ditemui oleh state machine mesin ketika mengeksekusi keadaan. IDT mencatat informasi tentang setiap kesalahan dalam file `test_manager.log` dan mengalirkan pesan log ke konsol.
Anda dapat menggunakan metode berikut untuk menangani kesalahan eksekusi:
+ Tambahkan [blok `Catch`](#catch) dalam definisi keadaan.
+ Periksa nilai dari [nilai `hasExecutionErrors`](#context) dalam konteks state machine.
### Tangkap
Untuk menggunakan `Catch`, tambahkan hal berikut ini ke definisi keadaan Anda:
```
"Catch": [
{
"ErrorEquals": [
""
]
"Next": ""
}
]
```
Semua kolom yang berisi nilai wajib diisi seperti yang dijelaskan di sini:
**`Catch.ErrorEquals`**
Serangkaian jenis kesalahan yang akan ditangkap. Jika kesalahan eksekusi cocok dengan salah satu nilai yang ditentukan, maka state machine akan bertransisi ke keadaan yang ditentukan dalam `Catch.Next`. Lihat setiap definisi keadaan untuk informasi tentang jenis kesalahan yang dihasilkannya.
**`Catch.Next`**
Keadaan berikutnya yang akan ditransisikan jika keadaan saat ini menemukan kesalahan eksekusi yang cocok dengan salah satu nilai yang ditentukan dalam `Catch.ErrorEquals`.
Blok tangkapan ditangani secara berurutan hingga salah satunya cocok. Jika tidak ada kesalahan yang cocok dengan yang tercantum dalam blok Tangkapan, maka state machine akan terus mengeksekusi. Karena kesalahan eksekusi adalah akibat dari definisi keadaan yang salah, kami sarankan Anda beralih ke keadaan gagal ketika suatu keadaan mengalami kesalahan eksekusi.
### hasExecutionError
Ketika beberapa keadaan mengalami kesalahan eksekusi, selain mengeluarkan kesalahan, keaadaan itu juga mengatur nilai `hasExecutionError` ke `true` dalam konteks state machine. Anda dapat menggunakan nilai ini untuk mendeteksi ketika terjadi kesalahan, dan kemudian menggunakan keadaan `Choice` untuk mengalihkan state machine ke keadaan `Fail`.
Metode ini memiliki karakteristik sebagai berikut.
+ State machine tidak dimulai dengan nilai yang ditugaskan pada `hasExecutionError`, dan nilai ini tidak tersedia sampai keadaan tertentu menetapkannya. Ini berarti bahwa Anda harus secara tegas mengatur `FallthroughOnError` ke `false` untuk keadaan `Choice` yang mengakses nilai ini untuk mencegah state machine berhenti jika tidak ada kesalahan eksekusi yang terjadi.
+ Setelah ditetapkan ke `true`, `hasExecutionError` tidak pernah ditetapkan menjadi salah atau dihapus dari konteks. Ini berarti bahwa nilai ini berguna hanya pertama kalinya ketika nilai tersebut ditetapkan ke `true`, dan untuk semua keadaan berikutnya, nilai itu tidak memberikan nilai yang berarti.
+ Nilai `hasExecutionError` dibagi dengan semua cabang state machine pada keadaan `Parallel`, yang dapat mengakibatkan hasil yang tidak diharapkan tergantung pada urutan yang diakses.
Karena karakteristik ini, kami tidak menyarankan Anda menggunakan metode ini jika Anda dapat menggunakan blok Catch sebagai gantinya.
## Contoh mesin keadaan
Bagian ini menyediakan beberapa contoh konfigurasi state machine.
**Topics**
+ [
### Contoh state machine: Jalankan grup uji tunggal
](#single-test-group)
+ [
### State machine contoh: Jalankan grup uji yang dipilih pengguna
](#allow-specific-groups)
+ [
### Contoh state machine: Jalankan grup uji tunggal dengan fitur produk
](#run-with-product-features)
+ [
### Contoh state machine: Jalankan dua grup uji secara paralel
](#run-in-parallel)
### Contoh state machine: Jalankan grup uji tunggal
State machine ini:
+ Menjalankan grup uji dengan id `GroupA`, yang harus ada dalam rangkaian pada file `group.json`.
+ Memeriksa kesalahan eksekusi dan bertransisi ke `Fail` jika ada yang ditemukan.
+ Menghasilkan laporan dan bertransisi ke `Succeed` jika tidak ada kesalahan, dan `Fail` bila sebaliknya.
```
{
"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"
}
}
}
```
### State machine contoh: Jalankan grup uji yang dipilih pengguna
State machine ini:
+ Memeriksa apakah test runner telah memilih grup uji tertentu. State machine tidak memeriksa uji kasus tertentu karena test runner tidak dapat memilih uji kasus tanpa sekaligus memilih grup uji.
+ Jika grup uji sudah dipilih:
+ Jalankan uji kasus dalam grup uji yang dipilih. Untuk melakukannya, state machine tidak secara tegas menentukan grup uji atau uji kasus di keadaan `RunTask`
+ Buat laporan setelah menjalankan semua tes dan keluar.
+ Jika grup uji tidak dipilih:
+ Jalankan tes dalam grup uji `GroupA`.
+ Buat laporan dan keluar.
```
{
"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"
}
}
}
```
### Contoh state machine: Jalankan grup uji tunggal dengan fitur produk
State machine ini:
+ Menjalankan grup uji `GroupA`.
+ Memeriksa kesalahan eksekusi dan bertransisi ke `Fail` jika ada yang ditemukan.
+ Menambahkan fitur `FeatureThatDependsOnGroupA` pada file `awsiotdevicetester_report.xml`:
+ Jika `GroupA` lulus, fitur tersebut diatur ke `supported`.
+ Fitur ini tidak ditandai opsional dalam laporan.
+ Menghasilkan laporan dan bertransisi ke `Succeed` jika tidak ada kesalahan, dan `Fail` bila sebaliknya.
```
{
"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"
}
}
}
```
### Contoh state machine: Jalankan dua grup uji secara paralel
State machine ini:
+ Menjalankan grup tes `GroupA` dan `GroupB` secara paralel. Variabel `ResultVar` yang disimpan dalam konteks tersebut oleh keadaan `RunTask` dalam state machine cabang yang tersedia pada keadaan `AddProductFeatures`
+ Memeriksa kesalahan eksekusi dan bertransisi ke `Fail` jika ada yang ditemukan. State machine ini tidak menggunakan blok `Catch` karena metode itu tidak mendeteksi kesalahan eksekusi di state machine cabang.
+ Menambahkan fitur ke file `awsiotdevicetester_report.xml` berdasarkan grup-grup yang lulus
+ Jika `GroupA` lulus, fitur tersebut diatur ke `supported`.
+ Fitur ini tidak ditandai opsional dalam laporan.
+ Menghasilkan laporan dan bertransisi ke `Succeed` jika tidak ada kesalahan, dan `Fail` bila sebaliknya.
Jika dua perangkat dikonfigurasi di kolam perangkat, baik `GroupA` maupun `GroupB` dapat berjalan pada saat yang sama. Namun, jika `GroupA` atau `GroupB` memiliki beberapa tes di dalamnya, maka kedua perangkat dapat dialokasikan pada tes tersebut. Jika hanya satu perangkat yang dikonfigurasi, grup uji akan berjalan secara berurutan.
```
{
"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"
}
}
}
```
# Buat kasus uji IDT yang dapat dieksekusi
Anda dapat membuat dan menempatkan test case yang dapat dieksekusi di folder test suite dengan cara berikut:
+ Untuk rangkaian tes yang menggunakan argumen atau variabel lingkungan dari file `test.json` untuk menentukan tes mana yang akan dijalankan, Anda dapat membuat uji kasus tunggal yang dapat dieksekusi untuk seluruh rangkaian tes, atau tes yang dapat dijalankan untuk setiap grup uji di rangkaian tes.
+ Untuk rangkaian tes di mana Anda ingin menjalankan tes tertentu berdasarkan perintah tertentu, Anda membuat satu executable uji kasus untuk setiap uji kasus di rangkaian tes.
Sebagai penyusun tes, Anda dapat menentukan pendekatan yang sesuai untuk kasus penggunaan Anda dan menyusun executable uji kasus yang sesuai. Pastikan bahwa Anda menyediakan jalur eksekusi uji kasus yang benar di setiap file `test.json`, dan bahwa executable yang ditentukan berjalan dengan benar.
Ketika semua perangkat siap untuk dijalankan oleh uji kasus, IDT akan membaca file-file berikut:
+ `test.json` untuk uji kasus yang dipilih menentukan proses yang akan dimulai dan variabel lingkungan yang akan diatur.
+ `suite.json` untuk rangkaian uji tersebut menentukan variabel lingkungan yang akan diatur.
IDT memulai proses eksekusi pengujian yang diperlukan berdasarkan perintah dan argumen yang ditentukan dalam `test.json` file, dan meneruskan variabel lingkungan yang diperlukan ke proses.
## Gunakan IDT Client SDK
Klien IDT SDKs memungkinkan Anda menyederhanakan cara Anda menulis logika pengujian dalam pengujian yang dapat dieksekusi dengan perintah API yang dapat Anda gunakan berinteraksi dengan IDT dan perangkat yang sedang diuji. IDT saat ini menyediakan yang berikut: SDKs
+ IDT Client SDK for Python
+ IDT Client SDK for Go
+ SDK Klien IDT untuk Java
Ini SDKs terletak di `/sdks` folder. Ketika Anda membuat executable uji kasus yang baru, Anda harus menyalin SDK yang ingin Anda gunakan ke folder yang berisi executable uji kasus dan mengacu pada SDK dalam kode Anda. Bagian ini memberikan penjelasan singkat tentang perintah API yang tersedia yang dapat Anda gunakan dalam executable uji kasus Anda.
**Topics**
+ [
### Interaksi perangkat
](#api-device-interaction)
+ [
### Interaksi IDT
](#api-idt-interaction)
+ [
### Interaksi host
](#api-host-interaction)
### Interaksi perangkat
Perintah berikut memungkinkan Anda untuk berkomunikasi dengan perangkat yang diuji tanpa harus menerapkan interaksi perangkat tambahan dan fungsi manajemen konektivitas apa pun.
**`ExecuteOnDevice`**
Memungkinkan rangkaian tes untuk menjalankan perintah shell pada perangkat yang mendukung SSH atau koneksi Docker shell.
**`CopyToDevice`**
Memungkinkan rangkaian tes untuk menyalin file lokal dari mesin host yang menjalankan IDT ke lokasi yang ditentukan pada perangkat yang mendukung SSH atau koneksi Docker shell.
**`ReadFromDevice`**
Memungkinkan rangkaian tes untuk membaca dari port serial perangkat yang mendukung koneksi UART.
**catatan**
Karena IDT tidak mengelola koneksi langsung ke perangkat yang dibuat menggunakan informasi akses perangkat dari konteks, sebaiknya gunakan perintah API interaksi perangkat ini di executable uji kasus. Namun, jika perintah ini tidak memenuhi persyaratan uji kasus Anda, maka Anda dapat mengambil informasi akses perangkat dari konteks IDT dan menggunakannya untuk membuat koneksi langsung ke perangkat dari rangkaian tes.
Untuk membuat sambungan langsung, ambil informasi di `device.connectivity` dan `resource.devices.connectivity` masing-masing untuk perangkat Anda yang sedang diuji dan untuk perangkat sumber daya. Untuk informasi lebih lanjut mengenai penggunaan konteks IDT, lihat [Gunakan konteks IDT](idt-context.md).
### Interaksi IDT
Perintah berikut memungkinkan rangkaian tes Anda untuk berkomunikasi dengan IDT.
**`PollForNotifications`**
Memungkinkan rangkaian tes untuk memeriksa notifikasi dari IDT.
**`GetContextValue ` dan `GetContextString`**
Memungkinkan rangkaian tes untuk mengambil nilai-nilai dari konteks IDT. Untuk informasi selengkapnya, lihat [Gunakan konteks IDT](idt-context.md).
**`SendResult`**
Memungkinkan rangkaian tes untuk melaporkan hasil uji kasus ke IDT. Perintah ini harus dipanggil pada akhir setiap uji kasus di rangkaian tes.
### Interaksi host
Perintah berikut memungkinkan rangkaian tes Anda untuk berkomunikasi dengan mesin host.
**`PollForNotifications`**
Memungkinkan rangkaian tes untuk memeriksa notifikasi dari IDT.
**`GetContextValue` dan `GetContextString`**
Memungkinkan rangkaian tes untuk mengambil nilai-nilai dari konteks IDT. Untuk informasi selengkapnya, lihat [Gunakan konteks IDT](idt-context.md).
**`ExecuteOnHost`**
Memungkinkan rangkaian tes untuk menjalankan perintah pada mesin lokal dan memungkinkan IDT untuk mengelola siklus hidup executable uji kasus.
## Aktifkan perintah IDT CLI
Perintah `run-suite` IDT CLI menyediakan beberapa pilihan yang membiarkan test runner untuk mengkustomisasi pelaksanaan tes. Untuk memungkinkan test runner menggunakan opsi ini untuk menjalankan rangkaian tes kustom Anda, Anda menerapkan dukungan untuk IDT CLI. Jika Anda tidak menerapkan dukungan, test runner masih akan dapat menjalankan tes, tetapi beberapa opsi CLI tidak akan berfungsi dengan benar. Untuk memberikan pengalaman pelanggan yang ideal, kami merekomendasikan agar Anda menerapkan dukungan untuk argumen berikut untuk perintah `run-suite` dalam IDT CLI:
**`timeout-multiplier`**
Menentukan nilai yang lebih besar dari 1,0 yang akan diterapkan pada semua batas waktu saat menjalankan tes.
Test runner dapat menggunakan argumen ini untuk meningkatkan batas waktu untuk uji kasus yang ingin dijalankannya. Ketika test runner menentukan argumen ini pada perintah `run-suite`, IDT akan menggunakannya untuk menghitung nilai variabel lingkungan IDT\$1TEST\$1TIMEOUT dan menetapkan kolom `config.timeoutMultiplier` dalam konteks IDT. Untuk mendukung argumen ini, Anda harus melakukan hal berikut:
+ Alih-alih langsung menggunakan nilai batas waktu dari file `test.json`, baca variabel lingkungan IDT\$1TEST\$1TIMEOUT untuk mendapatkan nilai batas waktu yang dihitung dengan benar.
+ Ambil nilai `config.timeoutMultiplier` dari konteks IDT dan terapkan ia pada batas waktu yang panjang.
Untuk informasi selengkapnya tentang keluar lebih awal karena peristiwa habis waktu, lihat [Tentukan perilaku keluar](#test-exec-exiting).
**`stop-on-first-failure`**
Tentukan bahwa IDT harus berhenti menjalankan semua tes jika menemui kegagalan.
Ketika test runner menentukan argumen ini pada perintah `run-suite`, IDT akan berhenti menjalankan pengujian tersebut segera setelah menemui kegagalan. Namun, jika uji kasus berjalan secara paralel, hal ini dapat menyebabkan hasil yang tidak terduga. Untuk menerapkan dukungan, pastikan bahwa jika IDT menemui peristiwa ini, logika pengujian Anda akan menginstruksikan semua uji kasus yang sedang berjalan untuk berhenti, membersihkan sumber daya sementara, dan melaporkan hasil tes ke IDT. Untuk informasi selengkapnya tentang keluar lebih awal karena menemui kegagalan, lihat [Tentukan perilaku keluar](#test-exec-exiting).
**`group-id` dan `test-id`**
Menentukan bahwa IDT harus menjalankan hanya grup uji atau uji kasus yang dipilih.
Test runner dapat menggunakan argumen ini dengan perintah `run-suite` untuk menentukan perilaku eksekusi tes berikut:
+ Jalankan semua tes di dalam grup uji yang ditentukan.
+ Jalankan pilihan tes dari dalam grup uji tertentu.
Untuk mendukung argumen ini, state machine untuk rangkaian tes Anda harus menyertakan serangkaian keadaan `RunTask` dan `Choice` tertentu pada state machine Anda. Jika Anda tidak menggunakan state machine kustom, maka state machine IDT default akan meliputi keadaan yang diperlukan untuk Anda dan Anda tidak perlu melakukan tindakan tambahan. Namun, jika Anda menggunakan state machine kustom, gunakan [State machine contoh: Jalankan grup uji yang dipilih pengguna](idt-state-machine.md#allow-specific-groups) sebagai contoh untuk menambahkan keadaan yang diperlukan dalam state machine Anda.
Untuk informasi selengkapnya tentang perintah IDT CLI, lihat [Debug dan jalankan rangkaian tes kustom](run-tests-custom.md).
## Menulis log peristiwa
Saat tes berjalan, Anda mengirim data ke `stdout` dan `stderr` untuk menuliskan log peristiwa dan pesan kesalahan pada konsol. Untuk informasi lebih lanjut tentang format pesan konsol, lihat [Format pesan konsol](idt-review-results-logs.md#idt-console-format).
Ketika IDT selesai menjalankan rangkaian tes tersebut, informasi ini juga tersedia di file `test_manager.log` yang terletak di `/results//logs`.
Anda dapat mengonfigurasi setiap uji kasus untuk menuliskan log dari pengujiannya yang dijalankan, termasuk log dari perangkat yang diuji, ke file `_` yang terletak di `/results/execution-id/logs`. Untuk melakukan ini, ambil path ke berkas log dari konteks IDT dengan kueri `testData.logFilePath`, buat file di path itu, dan tuliskan konten yang Anda inginkan padanya. IDT secara otomatis memperbarui jalur berdasarkan uji kasus yang berjalan. Jika Anda memilih untuk tidak membuat file log untuk uji kasus, maka tidak ada file yang akan dibuat untuk uji kasus itu.
Anda juga dapat mengatur executable teks Anda untuk membuat berkas log tambahan yang diperlukan dalam folder `/logs`. Kami menyarankan Anda untuk menentukan prefiks yang unik untuk nama file log sehingga file Anda tidak akan ditimpa.
## Laporkan hasil ke IDT
IDT menuliskan hasil tes ke file `awsiotdevicetester_report.xml` dan `suite-name_report.xml`. File laporan ini terletak di `/results//`. Kedua laporan tersebut menangkap hasil dari eksekusi rangkaian tes. Untuk informasi selengkapnya tentang skema yang menggunakan IDT untuk laporan ini, lihat [Tinjau hasil tes dan log IDT](idt-review-results-logs.md)
Untuk mengisi konten file `suite-name_report.xml`, Anda harus menggunakan perintah `SendResult` untuk melaporkan hasil tes ke IDT sebelum eksekusi tes itu selesai. Jika IDT tidak dapat menemukan hasil tes, ia akan mengeluarkan kesalahan untuk uji kasus tersebut. Kutipan Python berikut menunjukkan perintah yang akan mengirimkan hasil tes ke IDT:
```
request-variable = SendResultRequest(TestResult(result))
client.send_result(request-variable)
```
Jika Anda tidak melaporkan hasil melalui API, IDT akan mencari hasil tes di folder artefak tes. Path ke folder ini disimpan dalam `testData.testArtifactsPath` yang disimpan dalam konteks IDT. Dalam folder ini, IDT menggunakan file XML yang diurutkan menurut abjad pertama yang ditempatkannya sebagai hasil tes.
Jika logika pengujian Anda menghasilkan hasil JUnit XHTML, Anda dapat menulis hasil pengujian ke file XHTML di folder artefak untuk langsung memberikan hasil ke IDT alih-alih mengurai hasil dan kemudian menggunakan API untuk mengirimkannya ke IDT.
Jika Anda menggunakan metode ini, pastikan bahwa logika pengujian Anda secara akurat merangkum hasil pengujian dan memformat file hasil Anda dalam format yang sama seperti file `suite-name_report.xml`. IDT tidak melakukan validasi data yang Anda berikan, dengan pengecualian berikut:
+ IDT mengabaikan semua properti dari tanda `testsuites`. Sebaliknya, IDT menghitung properti tag dari hasil grup pengujian lainnya yang dilaporkan.
+ Setidaknya satu `testsuite` tag harus ada dalam `testsuites`.
Karena IDT menggunakan folder artefak yang sama untuk semua uji kasus dan tidak menghapus file hasil antara pengujian yang berjalan, metode ini mungkin juga akan menyebabkan pelaporan yang salah jika IDT membaca file yang salah. Kami menyarankan Anda menggunakan nama yang sama untuk file hasil XML yang dihasilkan di semua uji kasus untuk menimpa hasil untuk setiap uji kasus dan pastikan bahwa hasil yang benar tersedia untuk digunakan oleh IDT. Meskipun Anda dapat menggunakan pendekatan campuran untuk pelaporan di rangkaian pengujian Anda, yaitu menggunakan file hasil XML untuk beberapa uji kasus dan mengirimkan hasil melalui API untuk uji kasus lainnya, kami tidak merekomendasikan pendekatan ini.
## Tentukan perilaku keluar
Konfigurasikan executable teks Anda agar selalu keluar dengan kode keluar 0, meskipun uji kasus melaporkan kegagalan atau hasil kesalahan. Gunakan kode keluar bukan nol hanya untuk menunjukkan bahwa suatu uji kasus tidak berjalan atau jika executable uji kasus tidak dapat menyampaikan hasil apapun ke IDT. Ketika IDT menerima kode keluar bukan nol, IDT akan menandai uji kasus tersebut telah mengalami kesalahan yang mencegahnya berjalan.
IDT mungkin meminta atau mengharapkan uji kasus untuk berhenti berjalan sebelum selesai dalam peristiwa berikut. Gunakan informasi ini untuk mengonfigurasi executable uji kasus untuk mendeteksi setiap peristiwa ini dari uji kasus:
****Batas waktu****
Terjadi ketika uji kasus berjalan lebih lama daripada nilai batas waktu yang ditentukan dalam file `test.json`. Jika test runner menggunakan argumen `timeout-multiplier` untuk menentukan pengali batas waktu, IDT akan menghitung nilai batas waktu dengan pengali tersebut.
Untuk mendeteksi peristiwa ini, gunakan variabel lingkungan IDT\$1TEST\$1TIMEOUT. Ketika test runner meluncurkan tes, IDT akan menetapkan nilai variabel lingkungan IDT\$1TEST\$1TIMEOUT pada nilai batas waktu yang dihitung (dalam detik) dan melewati variabel pada executable uji kasus. Anda dapat membaca nilai variabel untuk menetapkan penghitung waktu yang sesuai.
****Mengganggu****
Terjadi ketika test runner menginterupsi IDT. Misalnya, dengan menekan Ctrl\$1C.
Karena terminal menyebarkan sinyal ke semua proses anak, Anda cukup mengonfigurasi bagian yang menangani sinyal dalam uji kasus Anda untuk mendeteksi sinyal yang terinterupsi.
Atau, Anda dapat secara berkala mengumpulkan API untuk memeriksa nilai boolean `CancellationRequested` di respons API `PollForNotifications`. Ketika IDT menerima sinyal terinterupsi, ia akan menetapkan nilai boolean `CancellationRequested` untuk `true`.
****Berhenti pada kegagalan pertama****
Terjadi ketika uji kasus yang berjalan secara paralel dengan uji kasus gagal dan test runner menggunakan argumen `stop-on-first-failure` untuk menentukan bahwa IDT harus berhenti ketika menemui kegagalan apa pun.
Untuk mendeteksi peristiwa ini, Anda dapat secara berkala mengumpulkan API untuk memeriksa nilai boolean `CancellationRequested` di respons API `PollForNotifications`. Ketika IDT menemui kegagalan dan dikonfigurasi untuk berhenti pada kegagalan pertama, tetapkan nilai boolean `CancellationRequested` untuk `true`.
Ketika salah satu peristiwa ini terjadi, IDT akan menunggu selama 5 menit untuk setiap uji kasus yang sedang berjalan saat ini untuk menyelesaikan prosesnya. Jika semua uji kasus yang berjalan tidak keluar dalam waktu 5 menit, IDT akan memaksa masing-masing proses untuk berhenti. Jika IDT belum menerima hasil tes sebelum proses berakhir, ia akan menandai uji kasus telah habis waktu. Sebagai praktik terbaik, Anda harus memastikan bahwa uji kasus Anda melakukan tindakan berikut ketika menghadapi salah satu peristiwa berikut:
1. Berhenti menjalankan logika uji normal.
1. Bersihkan sumber daya sementara apa pun, seperti uji artefak pada perangkat yang sedang diuji.
1. Laporkan hasil tes ke IDT, seperti kegagalan uji atau kesalahan.
1. Keluar
# Gunakan konteks IDT
Ketika IDT menjalankan rangkaian tes, rangkaian tes tersebut dapat mengakses serangkaian data yang dapat digunakan untuk menentukan bagaimana setiap tes akan berjalan. Data ini disebut konteks IDT. Sebagai contoh, konfigurasi data pengguna yang disediakan oleh test runner di file `userdata.json` tersedia pada rangkaian tes dalam konteks IDT.
Konteks IDT dapat dianggap sebagai dokumen JSON hanya-baca. Rangkaian uji dapat mengambil data dari dan menuliskan data ke konteks tersebut dengan menggunakan jenis data JSON standar seperti objek, rangkaian, angka, dan sebagainya.
## Skema konteks
Konteks state machine menggunakan format berikut:
```
{
"config": {
"timeoutMultiplier": timeout-multiplier,
"idtRootPath":
},
"device": {
},
"devicePool": {
},
"resource": {
"devices": [
{
"name": ""
}
]
},
"testData": {
"awsCredentials": {
"awsAccessKeyId": "",
"awsSecretAccessKey": "",
"awsSessionToken": ""
},
"logFilePath": "/path/to/log/file"
},
"userData": {
}
}
```
**`config`**
Informasi dari [`config.json` file](set-config-custom.md#config-json-custom). `config`Bidang ini juga berisi bidang tambahan berikut:
**`config.timeoutMultiplier`**
Pengganda untuk setiap nilai batas waktu yang digunakan oleh rangkaian tes. Nilai ini ditentukan oleh test runner dari IDT CLI. Nilai default-nya adalah `1`.
**`config.idRootPath`**
Nilai ini adalah placeholder untuk nilai jalur absolut IDT saat mengonfigurasi file. `userdata.json` Ini digunakan oleh perintah build dan flash.
**`device`**
Informasi tentang kolam perangkat yang dipilih untuk uji coba. Informasi ini setara dengan elemen rangkaian `devices` dalam [file `device.json`](set-config-custom.md#device-config-custom) untuk perangkat yang dipilih.
**`devicePool`**
Informasi tentang kolam perangkat yang dipilih untuk uji coba. Informasi ini setara dengan elemen rangkaian kolam perangkat tingkat ata yang ditentukan di file `device.json` untuk kolam perangkat yang dipilih.
**`resource`**
Informasi tentang perangkat sumber daya dari file `resource.json`.
**`resource.devices`**
Informasi ini setara dengan rangkaian `devices` yang ditentukan dalam file `resource.json`. Setiap elemen `devices` mencakup kolom tambahan berikut:
**`resource.device.name`**
Nama sumber daya. Nilai ini diatur ke nilai `requiredResource.name` pada file `test.json`.
**`testData.awsCredentials`**
AWS Kredensi yang digunakan oleh tes untuk terhubung ke cloud. AWS Informasi ini diperoleh dari file `config.json`.
**`testData.logFilePath`**
Path ke file log di mana uji kasus menuliskan pesan log. Rangkaian tes membuat file ini jika tidak ada.
**`userData`**
Informasi yang diberikan oleh test runner di [file `userdata.json`](set-config-custom.md#userdata-config-custom).
## Akses data dalam konteks
Anda dapat menanyakan konteks menggunakan JSONPath notasi dari file konfigurasi Anda dan dari teks Anda yang dapat dieksekusi dengan dan. `GetContextValue` `GetContextString` APIs Sintaks untuk JSONPath string untuk mengakses konteks IDT bervariasi sebagai berikut:
+ Pada `suite.json` dan `test.json`, Anda menggunakan `{{query}}`. Artinya, jangan gunakan elemen root `$.` untuk memulai ekspresi Anda.
+ Pada `statemachine.json`, Anda menggunakan `{{$.query}}`.
+ Dalam perintah API, Anda menggunakan `query` atau `{{$.query}}`, tergantung pada perintahnya. Untuk informasi selengkapnya, lihat dokumentasi sebaris di. SDKs
Tabel berikut menjelaskan operator dalam JSONPath ekspresi foobar khas:
| Operator | Deskripsi |
| --- | --- |
| \$1 | Elemen root. Karena nilai konteks tingkat atas untuk IDT adalah objek, Anda biasanya akan menggunakannya \$1. untuk memulai kueri Anda. |
| .childName | Mengakses elemen anak dengan nama childName dari objek. Jika diterapkan ke array, menghasilkan array baru dengan operator ini diterapkan ke setiap elemen. Nama elemen peka huruf besar/kecil. Misalnya, kueri untuk mengakses awsRegion nilai dalam config objek adalah\$1.config.awsRegion. |
| [start:end] | Memfilter elemen dari array, mengambil item yang dimulai dari start indeks dan naik ke end indeks, keduanya inklusif. |
| [index1, index2, ... , indexN] | Memfilter elemen dari array, mengambil item dari hanya indeks yang ditentukan. |
| [?(expr)] | Menyaring elemen dari array menggunakan expr ekspresi. Ekspresi ini harus mengevaluasi nilai boolean. |
Untuk membuat ekspresi filter, gunakan sintaks berikut:
```
| operator |
```
Dalam sintaks ini:
+ `jsonpath`adalah JSONPath yang menggunakan sintaks JSON standar.
+ `value` adalah setiap nilai kustom yang menggunakan sintaks JSON standar.
+ `operator` adalah salah satu dari operator berikut ini:
+ `<` (Kurang dari)
+ `<=` (Kurang dari atau sama dengan)
+ `==` (Sama dengan)
Jika nilai JSONPath atau dalam ekspresi Anda adalah nilai array, boolean, atau objek, maka ini adalah satu-satunya operator biner yang didukung yang dapat Anda gunakan.
+ `>=` (Lebih besar dari atau sama dengan)
+ `>` (Lebih besar dari)
+ `=~` (Kecocokan ekspresi reguler). Untuk menggunakan operator ini dalam ekspresi filter, nilai JSONPath or di sisi kiri ekspresi Anda harus mengevaluasi ke string dan sisi kanan harus berupa nilai pola yang mengikuti [RE2sintaks](https://github.com/google/re2/wiki/Syntax).
Anda dapat menggunakan JSONPath kueri dalam formulir \$1\$1*query*\$1\$1 sebagai string placeholder di dalam dan bidang dalam file `args` dan dalam `environmentVariables` bidang dalam `test.json` file. `environmentVariables` `suite.json` IDT melakukan pencarian konteks dan mengisi kolom dengan nilai kueri yang dievaluasi. Misalnya, di file `suite.json`, Anda dapat menggunakan string placeholder untuk menentukan nilai variabel lingkungan yang berubah dengan setiap uji kasus dan IDT akan mengisi variabel lingkungan dengan nilai yang benar untuk setiap uji kasus. Namun, ketika Anda menggunakan string placeholder di file `test.json` dan `suite.json`, pertimbangan berikut berlaku untuk kueri Anda:
+ Anda harus menuliskan setiap kejadian kunci `devicePool` dalam kueri Anda semua dengan huruf kecil. Artinya, gunakan `devicepool` sebagai gantinya
+ Untuk rangkaian, Anda hanya dapat menggunakan rangkaian string. Selain itu, rangkaian menggunakan format `item1, item2,...,itemN` non-standar. Jika rangkaian tersebut hanya berisi satu elemen, maka rangkaian itu akan diserialkan sebagai `item`, sehingga menjadikannya tidak dapat dibedakan dari kolom string.
+ Anda tidak dapat menggunakan placeholder untuk mengambil objek dari konteks.
Karena pertimbangan ini, kami merekomendasikan bahwa bila memungkinkan, Anda menggunakan API untuk mengakses konteks dalam logika pengujian Anda dan bukan string placeholder di file `test.json` dan `suite.json`. Namun, dalam beberapa kasus mungkin lebih mudah menggunakan JSONPath placeholder untuk mengambil string tunggal untuk ditetapkan sebagai variabel lingkungan.
# Mengonfigurasi pengaturan untuk test runner
Untuk menjalankan rangkaian tes kustom, test runner harus mengonfigurasi pengaturannya berdasarkan rangkaia tes yang ingin dijalankannya. Pengaturan ditentukan berdasarkan templat file konfigurasi yang terletak di `/configs/` folder. Jika diperlukan, pelari uji juga harus menyiapkan AWS kredensil yang akan digunakan IDT untuk terhubung ke cloud. AWS
Sebagai penyusun tes, Anda perlu mengonfigurasi file-file ini untuk [men-debug rangkaian tes](run-tests-custom.md). Anda harus memberikan petunjuk kepada test runner agar dapat mengonfigurasi pengaturan berikut yang diperlukan untuk menjalankan rangkaian tes Anda.
## Konfigurasikan device.json
File `device.json` berisi informasi tentang perangkat tempat uji dijalankan (misalnya, alamat IP, informasi login, sistem operasi, dan arsitektur CPU).
Test runner dapat memberikan informasi ini dengan menggunakan file `device.json` templat berikut yang terletak di folder `/configs/`.
```
[
{
"id": "",
"sku": "",
"features": [
{
"name": "",
"value": "",
"configs": [
{
"name": "",
"value": ""
}
],
}
],
"devices": [
{
"id": "",
"pairedResource": "", //used for no-op protocol
"connectivity": {
"protocol": "ssh | uart | docker | no-op",
// ssh
"ip": "",
"port": ,
"publicKeyPath": "",
"auth": {
"method": "pki | password",
"credentials": {
"user": "",
// pki
"privKeyPath": "/path/to/private/key",
// password
"password": "",
}
},
// uart
"serialPort": "",
// docker
"containerId": "",
"containerUser": "",
}
}
]
}
]
```
Semua kolom yang berisi nilai wajib diisi seperti yang dijelaskan di sini:
**`id`**
ID alfanumerik yang ditetapkan pengguna secara unik mengidentifikasi kumpulan perangkat yang disebut *kolam perangkat*. Perangkat yang termasuk dalam suatu kolam harus memiliki perangkat keras yang identik. Ketika Anda menjalankan serangkaian tes, perangkat di kolam tersebut digunakan untuk memparalelkan beban kerja. Beberapa perangkat digunakan untuk menjalankan tes yang berbeda.
**`sku`**
Nilai alfanumerik secara unik mengidentifikasi perangkat yang sedang diuji. SKU digunakan untuk melacak perangkat yang berkualitas.
Jika Anda ingin mencantumkan papan Anda di Katalog Perangkat AWS Mitra, SKU yang Anda tentukan di sini harus cocok dengan SKU yang Anda gunakan dalam proses pencatatan.
**`features`**
Tidak wajib. Rangkaian yang berisi fitur perangkat yang didukung. Fitur perangkat adalah nilai-nilai yang ditetapkan pengguna yang Anda konfigurasikan di rangkaian tes Anda. Anda harus memberikan informasi kepada test runner tentang nama fitur dan nilai-nilai yang akan disertakan dalam file `device.json`. Misalnya, jika Anda ingin menguji perangkat yang berfungsi sebagai server MQTT untuk perangkat lain, maka Anda dapat mengonfigurasi logika uji Anda untuk memvalidasi tingkat tertentu yang didukung untuk fitur bernama `MQTT_QoS`. Pelari uji memberikan nama fitur ini dan menetapkan nilai fitur ke level QoS yang didukung oleh perangkat mereka. Anda dapat mengambil informasi yang diberikan dari [konteks IDT](idt-context.md) dengan kueri `devicePool.features`, atau dari [konteks state machine](idt-state-machine.md#state-machine-context) dengan kueri `pool.features`.
**`features.name`**
Nama fitur.
**`features.value`**
Nilai fitur yang didukung.
**`features.configs`**
Pengaturan konfigurasi, jika diperlukan, untuk fitur.
**`features.config.name`**
Nama pengaturan konfigurasi.
**`features.config.value`**
Nilai pengaturan yang didukung.
**`devices`**
Rangkaian perangkat di kolam yang akan diuji. Setidaknya diperlukan satu perangkat.
**`devices.id`**
Pengenal unik yang ditetapkan pengguna untuk perangkat yang sedang diuji.
**`devices.pairedResource`**
Pengidentifikasi unik yang ditentukan pengguna untuk perangkat sumber daya. Nilai ini diperlukan saat Anda menguji perangkat menggunakan protokol `no-op` konektivitas.
**`connectivity.protocol`**
Protokol komunikasi yang digunakan untuk berkomunikasi dengan perangkat ini. Setiap perangkat di kolam harus menggunakan protokol yang sama.
Saat ini, satu-satunya nilai yang didukung adalah `ssh` dan `uart` untuk perangkat fisik, `docker` untuk wadah Docker, dan `no-op` untuk perangkat yang tidak memiliki koneksi langsung dengan mesin host IDT tetapi memerlukan perangkat sumber daya sebagai middleware fisik untuk berkomunikasi dengan mesin host.
Untuk perangkat tanpa operasi, Anda mengonfigurasi ID perangkat sumber daya di`devices.pairedResource`. Anda juga harus menentukan ID ini dalam `resource.json` file. Perangkat yang dipasangkan harus berupa perangkat yang dipasangkan secara fisik dengan perangkat yang sedang diuji. Setelah IDT mengidentifikasi dan menghubungkan ke perangkat sumber daya yang dipasangkan, IDT tidak akan terhubung ke perangkat sumber daya lain sesuai dengan fitur yang dijelaskan dalam file. `test.json`
**`connectivity.ip`**
Alamat IP perangkat yang sedang diuji.
Properti ini hanya berlaku jika `connectivity.protocol` diatur ke `ssh`.
**`connectivity.port`**
Tidak wajib. Jumlah port yang akan digunakan untuk koneksi SSH.
Nilai default-nya adalah 22.
Properti ini hanya berlaku jika `connectivity.protocol` diatur ke `ssh`.
**`connectivity.publicKeyPath`**
Tidak wajib. Jalur lengkap ke kunci publik digunakan untuk mengautentikasi koneksi ke perangkat yang sedang diuji. Saat Anda menentukan`publicKeyPath`, IDT memvalidasi kunci publik perangkat saat membuat koneksi SSH ke perangkat yang sedang diuji. Jika nilai ini tidak ditentukan, IDT membuat koneksi SSH, tetapi tidak memvalidasi kunci publik perangkat.
Kami sangat menyarankan Anda menentukan jalur ke kunci publik, dan Anda menggunakan metode aman untuk mengambil kunci publik ini. Untuk klien SSH berbasis baris perintah standar, kunci publik disediakan dalam file. `known_hosts` Jika Anda menentukan file kunci publik terpisah, file ini harus menggunakan format yang sama dengan `known_hosts` file, yaitu,`ip-address key-type public-key`.
**`connectivity.auth`**
Informasi autentikasi untuk koneksi tersebut.
Properti ini hanya berlaku jika `connectivity.protocol` diatur ke `ssh`.
**`connectivity.auth.method`**
Metode autentikasi yang digunakan untuk mengakses perangkat melalui protokol konektivitas yang diberikan.
Nilai yang didukung adalah:
+ `pki`
+ `password`
**`connectivity.auth.credentials`**
Kredensial yang digunakan untuk autentikasi.
**`connectivity.auth.credentials.password`**
Kata sandi yang digunakan untuk masuk ke perangkat yang sedang diuji.
Nilai ini hanya berlaku jika `connectivity.auth.method` diatur ke `password`.
**`connectivity.auth.credentials.privKeyPath`**
Jalur lengkap ke kunci privat yang digunakan untuk masuk ke perangkat yang sedang diuji.
Nilai ini hanya berlaku jika `connectivity.auth.method` diatur ke `pki`.
**`connectivity.auth.credentials.user`**
Nama pengguna untuk masuk ke perangkat yang sedang diuji.
**`connectivity.serialPort`**
Tidak wajib. Port serial tempat perangkat itu terhubung.
Properti ini hanya berlaku jika `connectivity.protocol` diatur ke `uart`.
**`connectivity.containerId`**
ID kontainer atau nama kontainer Docker yang sedang diuji.
Properti ini hanya berlaku jika `connectivity.protocol` diatur ke `docker`.
**`connectivity.containerUser`**
Tidak wajib. Nama pengguna untuk pengguna di dalam kontainer. Nilai default adalah pengguna yang disediakan di Dockerfile.
Nilai default-nya adalah 22.
Properti ini hanya berlaku jika `connectivity.protocol` diatur ke `docker`.
Untuk memeriksa apakah test runner mengonfigurasi koneksi perangkat yang salah untuk suatu pengujian, Anda dapat mengambil `pool.Devices[0].Connectivity.Protocol` dari konteks state machine dan membandingkannya dengan nilai yang diharapkan pada keadaan `Choice`. Jika protokol yang salah digunakan, cetak pesan dengan menggunakan keadaan `LogMessage` dan beralihlah ke keadaan `Fail`.
Atau, Anda dapat menggunakan kode penanganan kesalahan untuk melaporkan kegagalan pengujian untuk jenis perangkat yang salah.
## (Opsional) Konfigurasikan userdata.json
File `userdata.json` berisi informasi tambahan yang diperlukan oleh rangkaian tes tetapi tidak ditentukan dalam file `device.json`. Format file ini tergantung pada [file `userdata_scheme.json`](idt-json-config.md#userdata-schema-json) yang ditentukan dalam rangkaian uji tersebut. Jika Anda seorang penyusun tes, pastikan Anda memberikan informasi ini kepada pengguna yang akan menjalankan rangkaian tes yang Anda susun.
## (Opsional) Konfigurasikan resource.json
File `resource.json` berisi informasi tentang perangkat apa pun yang akan digunakan sebagai perangkat sumber daya. Perangkat sumber daya adalah perangkat yang diperlukan untuk menguji kemampuan tertentu dari perangkat yang diuji. Misalnya, untuk menguji kemampuan Bluetooth perangkat, Anda mungkin menggunakan perangkat sumber daya untuk menguji apakah perangkat Anda dapat berhasil tersambung. Perangkat sumber daya bersifat opsional, dan Anda dapat memerlukan perangkat sumber daya sebanyak yang Anda butuhkan. Sebagai penyusun tes, Anda menggunakan [file test.json](idt-json-config.md#test-json) untuk menentukan fitur perangkat sumber daya yang diperlukan untuk tes. Test runner kemudian akan menggunakan file `resource.json` untuk menyediakan kolam perangkat sumber daya yang memiliki fitur yang diperlukan. Pastikan Anda memberikan informasi ini kepada pengguna yang akan menjalankan rangkaian tes yang Anda tulis.
Test runner dapat memberikan informasi ini dengan menggunakan file `resource.json` templat berikut yang terletak di folder `/configs/`.
```
[
{
"id": "",
"features": [
{
"name": "",
"version": "",
"jobSlots":
}
],
"devices": [
{
"id": "",
"connectivity": {
"protocol": "ssh | uart | docker",
// ssh
"ip": "",
"port": ,
"publicKeyPath": "",
"auth": {
"method": "pki | password",
"credentials": {
"user": "",
// pki
"privKeyPath": "/path/to/private/key",
// password
"password": "",
}
},
// uart
"serialPort": "",
// docker
"containerId": "",
"containerUser": "",
}
}
]
}
]
```
Semua kolom yang berisi nilai wajib diisi seperti yang dijelaskan di sini:
**`id`**
ID alfanumerik yang ditetapkan pengguna secara unik mengidentifikasi kumpulan perangkat yang disebut *kolam perangkat*. Perangkat yang termasuk dalam suatu kolam harus memiliki perangkat keras yang identik. Ketika Anda menjalankan serangkaian tes, perangkat di kolam tersebut digunakan untuk memparalelkan beban kerja. Beberapa perangkat digunakan untuk menjalankan tes yang berbeda.
**`features`**
Tidak wajib. Rangkaian yang berisi fitur perangkat yang didukung. Informasi yang diperlukan dalam kolom ini ditentukan dalam [file test.json](idt-json-config.md#test-json) di rangkaian tes dan menentukan tes mana yang akan dijalankan dan bagaimana menjalankan tes tersebut. Jika rangkaian tes tidak memerlukan fitur apa pun, kolom ini tidak wajib diisi.
**`features.name`**
Nama fitur.
**`features.version`**
Versi fitur.
**`features.jobSlots`**
Pengaturan untuk menunjukkan berapa banyak tes yang dapat secara bersamaan menggunakan perangkat. Nilai default-nya adalah `1`.
**`devices`**
Rangkaian perangkat di kolam yang akan diuji. Setidaknya diperlukan satu perangkat.
**`devices.id`**
Pengenal unik yang ditetapkan pengguna untuk perangkat yang sedang diuji.
**`connectivity.protocol`**
Protokol komunikasi yang digunakan untuk berkomunikasi dengan perangkat ini. Setiap perangkat di kolam harus menggunakan protokol yang sama.
Saat ini, satu-satunya nilai yang didukung adalah `ssh` dan `uart` untuk perangkat fisik, dan `docker` untuk kontainer Docker.
**`connectivity.ip`**
Alamat IP perangkat yang sedang diuji.
Properti ini hanya berlaku jika `connectivity.protocol` diatur ke `ssh`.
**`connectivity.port`**
Tidak wajib. Jumlah port yang akan digunakan untuk koneksi SSH.
Nilai default-nya adalah 22.
Properti ini hanya berlaku jika `connectivity.protocol` diatur ke `ssh`.
**`connectivity.publicKeyPath`**
Tidak wajib. Jalur lengkap ke kunci publik digunakan untuk mengautentikasi koneksi ke perangkat yang sedang diuji. Saat Anda menentukan`publicKeyPath`, IDT memvalidasi kunci publik perangkat saat membuat koneksi SSH ke perangkat yang sedang diuji. Jika nilai ini tidak ditentukan, IDT membuat koneksi SSH, tetapi tidak memvalidasi kunci publik perangkat.
Kami sangat menyarankan Anda menentukan jalur ke kunci publik, dan Anda menggunakan metode aman untuk mengambil kunci publik ini. Untuk klien SSH berbasis baris perintah standar, kunci publik disediakan dalam file. `known_hosts` Jika Anda menentukan file kunci publik terpisah, file ini harus menggunakan format yang sama dengan `known_hosts` file, yaitu,`ip-address key-type public-key`.
**`connectivity.auth`**
Informasi autentikasi untuk koneksi tersebut.
Properti ini hanya berlaku jika `connectivity.protocol` diatur ke `ssh`.
**`connectivity.auth.method`**
Metode autentikasi yang digunakan untuk mengakses perangkat melalui protokol konektivitas yang diberikan.
Nilai yang didukung adalah:
+ `pki`
+ `password`
**`connectivity.auth.credentials`**
Kredensial yang digunakan untuk autentikasi.
**`connectivity.auth.credentials.password`**
Kata sandi yang digunakan untuk masuk ke perangkat yang sedang diuji.
Nilai ini hanya berlaku jika `connectivity.auth.method` diatur ke `password`.
**`connectivity.auth.credentials.privKeyPath`**
Jalur lengkap ke kunci privat yang digunakan untuk masuk ke perangkat yang sedang diuji.
Nilai ini hanya berlaku jika `connectivity.auth.method` diatur ke `pki`.
**`connectivity.auth.credentials.user`**
Nama pengguna untuk masuk ke perangkat yang sedang diuji.
**`connectivity.serialPort`**
Tidak wajib. Port serial tempat perangkat itu terhubung.
Properti ini hanya berlaku jika `connectivity.protocol` diatur ke `uart`.
**`connectivity.containerId`**
ID kontainer atau nama kontainer Docker yang sedang diuji.
Properti ini hanya berlaku jika `connectivity.protocol` diatur ke `docker`.
**`connectivity.containerUser`**
Tidak wajib. Nama pengguna untuk pengguna di dalam kontainer. Nilai default adalah pengguna yang disediakan di Dockerfile.
Nilai default-nya adalah 22.
Properti ini hanya berlaku jika `connectivity.protocol` diatur ke `docker`.
## (Opsional) Konfigurasikan config.json
File `config.json` berisi informasi konfigurasi untuk IDT. Biasanya, pelari uji tidak perlu memodifikasi file ini kecuali untuk memberikan kredensi AWS pengguna mereka untuk IDT, dan secara opsional, suatu wilayah. AWS Jika AWS kredensil dengan izin yang diperlukan disediakan, AWS IoT Device Tester kumpulkan dan kirimkan metrik penggunaan ke. AWS Ini adalah fitur opt-in dan digunakan untuk meningkatkan fungsi IDT. Untuk informasi selengkapnya, lihat [Kirim metrik penggunaan IDT](idt-usage-metrics.md).
Pelari uji dapat mengonfigurasi AWS kredensialnya dengan salah satu cara berikut:
+ **File kredensil**
IDT menggunakan file kredensial yang sama sebagai AWS CLI. Untuk informasi selengkapnya, lihat [File konfigurasi dan kredensial](https://docs.aws.amazon.com/cli/latest/userguide/cli-config-files.html).
Lokasi file kredensial itu bervariasi, tergantung pada sistem operasi yang Anda gunakan:
+ macOS, Linux: `~/.aws/credentials`
+ Windows: `C:\Users\UserName\.aws\credentials`
+ **Variabel lingkungan**
Variabel lingkungan adalah variabel yang dikelola oleh sistem operasi dan digunakan oleh perintah sistem. Variabel yang ditentukan selama sesi SSH tidak akan tersedia setelah sesi itu ditutup. IDT dapat menggunakan variabel lingkungan `AWS_ACCESS_KEY_ID` dan `AWS_SECRET_ACCESS_KEY` untuk menyimpan kredensial AWS
Untuk mengatur variabel ini di Linux, macOS, atau Unix, gunakan **export**:
```
export AWS_ACCESS_KEY_ID=
export AWS_SECRET_ACCESS_KEY=
```
Untuk menetapkan variabel ini di Windows, gunakan **set**:
```
set AWS_ACCESS_KEY_ID=
set AWS_SECRET_ACCESS_KEY=
```
Untuk mengonfigurasi AWS kredensi IDT, pelari uji mengedit `auth` bagian dalam `config.json` file yang terletak di folder. `/configs/`
```
{
"log": {
"location": "logs"
},
"configFiles": {
"root": "configs",
"device": "configs/device.json"
},
"testPath": "tests",
"reportPath": "results",
"awsRegion": "",
"auth": {
"method": "file | environment",
"credentials": {
"profile": ""
}
}
}
]
```
Semua kolom yang berisi nilai wajib diisi seperti yang dijelaskan di sini:
**catatan**
Semua jalur dalam file ini didefinisikan relatif terhadap file**.
**`log.location`**
Jalur ke folder log di file**.
**`configFiles.root`**
Path ke folder yang berisi file konfigurasi.
**`configFiles.device`**
Jalur ke file `device.json`.
**`testPath`**
Path ke folder yang berisi rangkaian tes.
**`reportPath`**
Path ke folder yang akan berisi hasil tes setelah IDT menjalankan rangkaian tes.
**`awsRegion`**
Tidak wajib. AWS Wilayah yang akan digunakan test suite. Jika tidak ditetapkan, rangkaian tes akan menggunakan wilayah default yang ditentukan dalam setiap rangkaian tes.
**`auth.method`**
Metode yang digunakan IDT untuk mengambil kredensil AWS . Nilai yang didukung adalah `file` untuk mengambil kredensial dari file kredensial, dan `environment` untuk mengambil klredensial dengan menggunakan variabel lingkungan.
**`auth.credentials.profile`**
Profil kredensial yang akan digunakan dari file kredensial. Properti ini hanya berlaku jika `auth.method` diatur ke `file`.
# Debug dan jalankan rangkaian tes kustom
Setelah [konfigurasi yang diperlukan](set-config-custom.md) diatur, IDT dapat menjalankan rangkaian tes Anda. Waktu aktif dari rangkaian tes penuh akan tergantung pada perangkat keras dan komposisi rangkaian tes. Untuk referensi, dibutuhkan sekitar 30 menit untuk menyelesaikan rangkaian tes kualifikasi FreeRTOS lengkap pada Raspberry Pi 3B.
Ketika Anda menyusun rangkaian tes Anda, Anda dapat menggunakan IDT untuk menjalankan rangkaian tes dalam mode debug untuk memeriksa kode Anda sebelum Anda menjalankannya atau memberikannya kepada test runner.
## Jalankan IDT dalam mode debug
Karena rangkaian tes tergantung pada IDT untuk berinteraksi dengan perangkat, menyediakan konteks, dan menerima hasil, Anda tidak bisa hanya men-debug rangkaian tes Anda di IDE tanpa berinteraksi dengan IDT. Untuk melakukannya, IDT CLI menyediakan perintah `debug-test-suite` yang memungkinkan Anda menjalankan IDT dalam mode debug. Jalankan perintah berikut untuk menampilkan opsi yang tersedia untuk `debug-test-suite`:
```
devicetester_[linux | mac | win_x86-64] debug-test-suite -h
```
Saat Anda menjalankan IDT dalam mode debug, IDT sebenarnya tidak meluncurkan rangkaian pengujian atau menjalankan orkestrator pengujian; sebaliknya, IDT berinteraksi dengan IDE Anda untuk merespons permintaan yang dibuat dari rangkaian pengujian yang berjalan di IDE dan mencetak log ke konsol. IDT tidak melakukan timeout dan menunggu untuk keluar hingga secara manual terinterupsi. Dalam mode debug, IDT juga tidak menjalankan orkestrator pengujian dan tidak akan menghasilkan file laporan apa pun. Untuk men-debug rangkaian pengujian Anda, Anda harus menggunakan IDE Anda untuk memberikan beberapa informasi yang biasanya diperoleh IDT dari file konfigurasi. Pastikan Anda memberikan informasi berikut:
+ Variabel lingkungan dan argumen untuk setiap tes. IDT tidak akan membaca informasi ini dari `test.json` atau `suite.json`.
+ Argumen untuk memilih perangkat sumber daya. IDT tidak akan membaca informasi ini dari `test.json`.
Untuk men-debug rangkaian tes Anda, selesaikan langkah berikut:
1. Buat file konfigurasi pengaturan yang diperlukan untuk menjalankan rangkaian tes. Misalnya, jika rangkaian tes Anda memerlukan `device.json`, `resource.json`, dan `user data.json`, pastikan Anda mengonfigurasi semuanya sesuai kebutuhan.
1. Jalankan perintah berikut untuk menempatkan IDT dalam mode debug dan pilih perangkat yang diperlukan untuk menjalankan tes.
```
devicetester_[linux | mac | win_x86-64] debug-test-suite [options]
```
Setelah Anda menjalankan perintah ini, IDT akan menunggu permintaan dari rangkaian tes dan kemudian menanggapinya. IDT juga akan menghasilkan variabel lingkungan yang diperlukan untuk proses kasus untuk IDT Client SDK.
1. Dalam IDE Anda, gunakan konfigurasi `run` atau `debug` untuk melakukan hal berikut:
1. Menetapkan nilai-nilai variabel lingkungan yang dihasilkan IDT.
1. Tetapkan nilai dari setiap variabel lingkungan atau argumen yang Anda tentukan dalam file `test.json` dan `suite.json` Anda.
1. Menetapkan breakpoint sesuai kebutuhan.
1. Menjalankan rangkaian tes di IDE Anda.
Anda dapat men-debug dan kembali menjalankan rangkaain tes sebanyak mungkin yang diperlukan. IDT tidak melakukan timeout dalam mode debug.
1. Setelah Anda menyelesaikan debugging, interupsi IDT untuk keluar dari mode debug.
## Perintah IDT CLI untuk menjalankan percobaan
Bagian berikut menjelaskan perintah IDT CLI:
------
#### [ IDT v4.0.0 ]
**`help`**
Mendaftar informasi tentang perintah yang ditentukan.
**`list-groups`**
Mendaftar grup dalam rangkaian tes yang diberikan.
**`list-suites`**
Mencantumkan rangkaian tes yang tersedia.
**`list-supported-products`**
Daftar produk yang didukung untuk versi IDT Anda, dalam hal ini versi FreeRTOS, dan versi rangkaian pengujian kualifikasi FreeRTOS yang tersedia untuk versi IDT saat ini.
**`list-test-cases`**
Mencantumkan uji kasus dalam grup uji yang diberikan. Opsi berikut didukung:
+ `group-id`. Grup uji yang harus dicari. Opsi ini diperlukan dan harus menentukan satu grup.
**`run-suite`**
Menjalankan serangkaian tes pada kolam perangkat. Berikut ini adalah beberapa opsi yang umum digunakan:
+ `suite-id`. Versi rangkaian tes yang akan dijalankan. Jika tidak ditentukan, IDT akan menggunakan versi terbaru dalam folder `tests`.
+ `group-id`. Grup uji yang akan jalankan, sebagai daftar yang dipisahkan koma. Jika tidak ditentukan, IDT akan menjalankan semua grup uji di rangkaian tes.
+ `test-id`. Uji kasus yang akan dijalankan, sebagai daftar yang dipisahkan koma. Ketika ditentukan, `group-id` harus menentukan satu grup.
+ `pool-id`. Kolam perangkat yang akan diuji. Test runner harus menentukan kolam jika memiliki beberapa perangkat kolam yang ditentukan dalam file `device.json`.
+ `timeout-multiplier`. Mengkonfigurasi IDT untuk mengubah batas waktu eksekusi tes yang ditentukan dalam file `test.json` untuk tes dengan pengganda yang ditetapkan pengguna.
+ `stop-on-first-failure`. Mengkonfigurasi IDT untuk menghentikan eksekusi pada kegagalan pertama. Pilihan ini harus digunakan dengan `group-id` untuk men-debug grup uji yang ditentukan.
+ `userdata`. Menetapkan file yang berisi informasi data pengguna yang diperlukan untuk menjalankan rangkaian tes. Hal ini hanya diperlukan jika `userdataRequired` diatur ke BETUL di file `suite.json`untuk rangkaian uji itu.
Untuk informasi lebih lanjut tentang opsi `run-suite`, gunakan opsi `help`:
```
devicetester_[linux | mac | win_x86-64] run-suite -h
```
**`debug-test-suite`**
Jalankan rangkaian tes dalam mode debug. Untuk informasi selengkapnya, lihat [Jalankan IDT dalam mode debug](#idt-debug-mode).
------
# Tinjau hasil tes dan log IDT
Bagian ini menjelaskan format di mana IDT menghasilkan log konsol dan laporan uji.
## Format pesan konsol
AWS IoT Device Tester menggunakan format standar untuk mencetak pesan ke konsol saat memulai rangkaian pengujian. Kutipan berikut menunjukkan contoh pesan konsol yang dihasilkan oleh IDT.
```
[INFO] [2000-01-02 03:04:05]: Using suite: MyTestSuite_1.0.0 executionId=9a52f362-1227-11eb-86c9-8c8590419f30
```
Sebagian besar pesan konsol terdiri dari kolom berikut:
**`time`**
Sebuah cap waktu ISO 8601 penuh untuk peristiwa yang tercatat.
**`level`**
Tingkat pesan untuk peristiwa yang tercatat. Biasanya, tingkat pesan yang tercatat adalah salah satu dari `info`, `warn`, atau `error`. IDT mengeluarkan pesan `fatal` atau `panic` jika bertemu dengan peristiwa yang diharapkan yang menyebabkannya keluar lebih awal.
**`msg`**
Pesan yang dicatat.
**`executionId`**
Sebuah string ID yang unik untuk proses IDT saat ini. ID ini digunakan untuk membedakan antara IDT individual yang berjalan.
Pesan konsol yang dihasilkan dari rangkaian tes memberikan informasi tambahan tentang perangkat yang diuji berikut rangkaian uji, grup uji, dan uji kasus yang dijalankan oleh IDT. Kutipan berikut menunjukkan contoh pesan konsol yang dihasilkan dari rangkaian tes.
```
[INFO] [2000-01-02 03:04:05]: Hello world! suiteId=MyTestSuitegroupId=myTestGroup testCaseId=myTestCase deviceId=my-deviceexecutionId=9a52f362-1227-11eb-86c9-8c8590419f30
```
Bagian tertentu dari rangkaian tes pada pesan konsol berisi kolom-kolom berikut:
**`suiteId`**
Nama rangkaian tes yang sedang berjalan saat ini.
**`groupId`**
ID grup uji yang sedang berjalan saat ini.
**`testCaseId`**
ID uji kasus yang berjalan saat ini.
**`deviceId`**
ID dari perangkat yang diuji yang sedang digunakan oleh uji kasus saat ini.
Ringkasan uji berisi informasi tentang rangkaian uji, hasil uji untuk setiap grup yang dijalankan, dan lokasi log dan file laporan yang dihasilkan. Contoh berikut menunjukkan pesan ringkasan tes.
```
========== 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 AWS 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 Device Tester skema laporan
`awsiotdevicetester_report.xml` adalah laporan bertanda tangan yang berisi informasi berikut:
+ Versi IDT.
+ Versi rangkaian tes.
+ Tanda tangan laporan dan kunci yang digunakan untuk menandatangani laporan.
+ SKU Perangkat dan nama kolam perangkat yang ditentukan dalam file `device.json`.
+ Versi produk dan fitur perangkat yang diuji.
+ Ringkasan agregat hasil tes. Informasi ini sama dengan yang terkandung dalam file `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
```
File `awsiotdevicetester_report.xml` berisi tanda `` yang berisi informasi tentang produk yang sedang diuji dan fitur produk yang divalidasi setelah menjalankan serangkaian pengujian.
**Atribut yang digunakan dalam `` tag**
**`name`**
Nama produk yang sedang diuji.
**`version`**
Versi produk yang sedang diuji.
**`features`**
Fitur divalidasi. Fitur yang ditandai sebagai `required` diperlukan bagi rangkaian tes untuk memvalidasi perangkat. Potongan berikut menunjukkan bagaimana informasi ini muncul di file `awsiotdevicetester_report.xml`.
```
```
Fitur yang ditandai sebagai `optional` tidak diperlukan untuk validasi. Potongan berikut menunjukkan fitur opsional.
```
```
## Skema laporan rangkaian uji
`suite-name_Result.xml`Laporan ini dalam [format JUnit XHTML](https://llg.cubic.org/docs/junit/). Anda dapat mengintegrasikannya ke dalam platform integrasi dan deployment berkelanjutan seperti [Jenkins](https://jenkins.io/), [Bamboo](https://www.atlassian.com/software/bamboo), dan sebagainya. Laporan ini berisi ringkasan agregat hasil tes.
```
reason
reason
reason
```
Bagian laporan baik di `awsiotdevicetester_report.xml` maupun `suite-name_report.xml` mendaftar tes yang dijalankan dan hasilnya.
Tag XML pertama `` berisi ringkasan pelaksanaan tes. Contoh:
```
```
**Atribut yang digunakan dalam `` tag**
**`name`**
Nama rangkaian tes.
**`time`**
Waktu, dalam hitungan detik, yang dibutuhkannya untuk menjalankan rangkaian tes.
**`tests`**
Jumlah tes yang dilaksanakan.
**`failures`**
Jumlah tes yang dijalankan, tetapi tidak lulus.
**`errors`**
Jumlah tes yang tidak dapat dilaksanakan oelh IDT.
**`disabled`**
Atribut ini tidak digunakan dan bisa diabaikan.
Jika pengujian gagal atau salah, Anda dapat mengidentifikasi pengujian yang gagal dengan meninjau tanda XML ``. Tag XML `` di dalam tag `` menunjukkan ringkasan hasil tes untuk grup uji. Contoh:
```
```
Format ini serupa dengan tanda ``, tetapi dengan atribut `skipped` yang tidak digunakan dan dapat diabaikan. Di dalam masing-masing tanda XML ``, terdapat tanda `` untuk setiap tes yang dieksekusi untuk suatu grup uji. Contoh:
```
```
**Atribut yang digunakan dalam `` tag**
**`name`**
Nama tes.
**`attempts`**
Berapa kali IDT mengeksekusi uji kasus.
Ketika tes gagal atau kesalahan terjadi, tag `` atau `` akan ditambahkan ke tag `` dengan informasi untuk pemecahan masalah. Contoh:
```
Reason for the test failure
Reason for the test execution error
```
# Kirim metrik penggunaan IDT
Jika Anda memberikan AWS kredensil dengan izin yang diperlukan, AWS IoT Device Tester kumpulkan dan kirimkan metrik penggunaan ke. AWS Ini adalah fitur opt-in dan digunakan untuk meningkatkan fungsi IDT. IDT mengumpulkan informasi seperti berikut:
+ ID AWS akun yang digunakan untuk menjalankan IDT
+ Perintah IDT CLI yang digunakan untuk menjalankan tes
+ Rangkaian tes yang dijalankan
+ Suite pengujian di ** folder
+ Jumlah perangkat yang dikonfigurasi dalam kolam perangkat
+ Nama uji kasus dan waktu aktif
+ Informasi hasil tes, seperti apakah tes berhasil dilalui, gagal, mengalami kesalahan, atau dilewati
+ Fitur produk yang diuji
+ Perilaku keluar IDT, seperti keluar tak terduga atau lebih awal
Semua informasi yang dikirimkan IDT juga dicatat pada file `metrics.log` di folder `/results//`. Anda dapat melihat file log untuk melihat informasi yang dikumpulkan ketika tes dijalankan. File ini dibuat hanya jika Anda memilih untuk mengumpulkan metrik penggunaan.
Untuk menonaktifkan pengumpulam metrik, Anda tidak perlu melakukan tindakan tambahan. Cukup jangan menyimpan AWS kredensil Anda, dan jika Anda memiliki AWS kredensil yang disimpan, jangan konfigurasikan `config.json` file untuk mengaksesnya.
## Mendaftar untuk Akun AWS
Jika Anda tidak memiliki Akun AWS, selesaikan langkah-langkah berikut untuk membuatnya.
**Untuk mendaftar untuk Akun AWS**
1. Buka [https://portal.aws.amazon.com/billing/pendaftaran.](https://portal.aws.amazon.com/billing/signup)
1. Ikuti petunjuk online.
Bagian dari prosedur pendaftaran melibatkan menerima panggilan telepon atau pesan teks dan memasukkan kode verifikasi pada keypad telepon.
Saat Anda mendaftar untuk sebuah Akun AWS, sebuah *Pengguna root akun AWS*dibuat. Pengguna root memiliki akses ke semua Layanan AWS dan sumber daya di akun. Sebagai praktik keamanan terbaik, tetapkan akses administratif ke pengguna, dan gunakan hanya pengguna root untuk melakukan [tugas yang memerlukan akses pengguna root](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_root-user.html#root-user-tasks).
AWS mengirimi Anda email konfirmasi setelah proses pendaftaran selesai. Kapan saja, Anda dapat melihat aktivitas akun Anda saat ini dan mengelola akun Anda dengan masuk [https://aws.amazon.com.rproxy.govskope.uske/](https://aws.amazon.com/) dan memilih **Akun Saya**.
## Buat pengguna dengan akses administratif
Setelah Anda mendaftar Akun AWS, amankan Pengguna root akun AWS, aktifkan AWS IAM Identity Center, dan buat pengguna administratif sehingga Anda tidak menggunakan pengguna root untuk tugas sehari-hari.
**Amankan Anda Pengguna root akun AWS**
1. Masuk ke [Konsol Manajemen AWS](https://console.aws.amazon.com/)sebagai pemilik akun dengan memilih **pengguna Root** dan memasukkan alamat Akun AWS email Anda. Di laman berikutnya, masukkan kata sandi.
Untuk bantuan masuk dengan menggunakan pengguna root, lihat [Masuk sebagai pengguna root](https://docs.aws.amazon.com/signin/latest/userguide/console-sign-in-tutorials.html#introduction-to-root-user-sign-in-tutorial) di *AWS Sign-In Panduan Pengguna*.
1. Mengaktifkan autentikasi multi-faktor (MFA) untuk pengguna root Anda.
Untuk petunjuk, lihat [Mengaktifkan perangkat MFA virtual untuk pengguna Akun AWS root (konsol) Anda](https://docs.aws.amazon.com/IAM/latest/UserGuide/enable-virt-mfa-for-root.html) di Panduan Pengguna *IAM*.
**Buat pengguna dengan akses administratif**
1. Aktifkan Pusat Identitas IAM.
Untuk mendapatkan petunjuk, silakan lihat [Mengaktifkan AWS IAM Identity Center](https://docs.aws.amazon.com//singlesignon/latest/userguide/get-set-up-for-idc.html) di *Panduan Pengguna AWS IAM Identity Center *.
1. Di Pusat Identitas IAM, berikan akses administratif ke pengguna.
Untuk tutorial tentang menggunakan Direktori Pusat Identitas IAM sebagai sumber identitas Anda, lihat [Mengkonfigurasi akses pengguna dengan default Direktori Pusat Identitas IAM](https://docs.aws.amazon.com//singlesignon/latest/userguide/quick-start-default-idc.html) di *Panduan AWS IAM Identity Center Pengguna*.
**Masuk sebagai pengguna dengan akses administratif**
+ Untuk masuk dengan pengguna Pusat Identitas IAM, gunakan URL masuk yang dikirim ke alamat email saat Anda membuat pengguna Pusat Identitas IAM.
Untuk bantuan masuk menggunakan pengguna Pusat Identitas IAM, lihat [Masuk ke portal AWS akses](https://docs.aws.amazon.com/signin/latest/userguide/iam-id-center-sign-in-tutorial.html) di *Panduan AWS Sign-In Pengguna*.
**Tetapkan akses ke pengguna tambahan**
1. Di Pusat Identitas IAM, buat set izin yang mengikuti praktik terbaik menerapkan izin hak istimewa paling sedikit.
Untuk petunjuknya, lihat [Membuat set izin](https://docs.aws.amazon.com//singlesignon/latest/userguide/get-started-create-a-permission-set.html) di *Panduan AWS IAM Identity Center Pengguna*.
1. Tetapkan pengguna ke grup, lalu tetapkan akses masuk tunggal ke grup.
Untuk petunjuk, lihat [Menambahkan grup](https://docs.aws.amazon.com//singlesignon/latest/userguide/addgroups.html) di *Panduan AWS IAM Identity Center Pengguna*.
Untuk memberikan akses dan menambahkan izin bagi pengguna, grup, atau peran Anda:
+ Pengguna dan grup di AWS IAM Identity Center:
Buat rangkaian izin. Ikuti instruksi di [Buat rangkaian izin](https://docs.aws.amazon.com//singlesignon/latest/userguide/howtocreatepermissionset.html) dalam *Panduan Pengguna AWS IAM Identity Center *.
+ Pengguna yang dikelola di IAM melalui penyedia identitas:
Buat peran untuk federasi identitas. Ikuti instruksi dalam [Buat peran untuk penyedia identitas pihak ketiga (federasi)](https://docs.aws.amazon.com//IAM/latest/UserGuide/id_roles_create_for-idp.html) dalam *Panduan Pengguna IAM*.
+ Pengguna IAM:
+ Buat peran yang dapat diambil pengguna Anda. Ikuti instruksi dalam [Buat peran untuk pengguna IAM](https://docs.aws.amazon.com//IAM/latest/UserGuide/id_roles_create_for-user.html) dalam *Panduan Pengguna IAM*.
+ (Tidak disarankan) Lampirkan kebijakan langsung ke pengguna atau tambahkan pengguna ke grup pengguna. Ikuti petunjuk dalam [Menambahkan izin ke pengguna (konsol)](https://docs.aws.amazon.com//IAM/latest/UserGuide/id_users_change-permissions.html#users_change_permissions-add-console) dalam *Panduan Pengguna IAM*.
## Memberikan AWS kredensi ke IDT
Untuk mengizinkan IDT mengakses AWS kredensi Anda dan mengirimkan metrik AWS, lakukan hal berikut:
1. Menyimpan AWS kredensi untuk pengguna IAM Anda sebagai variabel lingkungan atau dalam file kredensial:
1. Untuk menggunakan variabel lingkungan, jalankan perintah berikut:
```
AWS_ACCESS_KEY_ID=access-key
AWS_SECRET_ACCESS_KEY=secret-access-key
```
1. Untuk menggunakan file kredensial, tambahkan informasi berikut ke `.aws/credentials file:`
```
[profile-name]
aws_access_key_id=access-key
aws_secret_access_key=secret-access-key
```
1. Konfigurasikan bagian `auth` dari file `config.json`. Lihat informasi yang lebih lengkap di [(Opsional) Konfigurasikan config.json](set-config-custom.md#config-json-custom).