Seperti yang sudah saya katakan di bagian terakhir , ketika mengembangkan proyek IoT, protokol untuk berinteraksi dengan perangkat agak tidak stabil, dan kemungkinan kehilangan kontak dengan perangkat uji setelah memperbarui firmware cukup besar. Beberapa tim terlibat dalam pengembangan, dan ada persyaratan yang ketat - jangan sampai kehilangan kemampuan untuk menguji lapisan bisnis aplikasi, bahkan jika mem-flash perangkat merusak seluruh aliran kerja dengan sensor.
Agar analis bisnis menguji hipotesis mereka pada data yang kurang lebih mirip dengan kenyataan, kami membuat model simulasi perangkat. Jadi, jika perangkat rusak karena firmware baru, dan data perlu segera diterima, kami meluncurkan model simulasi alih-alih perangkat nyata di jaringan, yang, menurut format lama, menggerakkan data dan menghasilkan hasilnya.Juga, keuntungan dari model ini adalah bahwa bisnis tidak akan pernah membeli sejumlah besar perangkat hanya untuk menguji hipotesis. Misalnya, tim analisis bisnis memutuskan bahwa memperkirakan waktu pengisian kontainer harus bekerja secara berbeda. Dan untuk menguji hipotesis mereka, tidak ada yang akan lari untuk membeli 10.000 sensor.Pengembangan model simulasi
Model simulasi itu sendiri adalah sebagai berikut:
Keadaan dan perilaku tempat sampah dijelaskan oleh mesin keadaan biasa. Pertama, kita menginisialisasi mesin negara dengan keadaan `KOSONG (level = 0)` dan kita dapat melakukan beberapa tindakan di atasnya, yaitu, membuang sampah ke dalam wadah. Sekarang Anda perlu memutuskan apakah wadah tersebut masih kosong `(level? MAX_LEVEL)` atau apakah sudah penuh` (level> = MAX_LEVEL) `. Jika yang kedua, maka statusnya berubah menjadi `FULL`.Seseorang dapat membongkar sampah dari wadah penuh, atau petugas kebersihan datang untuk membersihkan kekacauannya, dan kita perlu memutuskan negara mana yang akan dituju. Status `PILIHAN` bertanggung jawab untuk memilih tindakan - dalam terminologi mesin keadaan, sesuatu yang mirip dengan blok if.Wadah lain mungkin terbakar, dan kemudian status mesin-negara berubah menjadi `FIRE`. Juga, wadah mungkin jatuh, dan kondisinya menjadi `JATUH` (dalam laporan saya berbicara tentang apa yang menyebabkan penurunan kontainer yang tidak terduga). Tetapi ada keadaan `HILANG` lain, yang valid dari negara lain - diatur ketika koneksi terputus.Mesin seperti itu menggambarkan hampir semua perilaku wadah dan sensor di dalamnya. Tetapi ini tidak cukup untuk membuat model simulasi, karena kita tahu tentang kemungkinan keadaan dan transisi dari mereka, tetapi kita tidak tahu apa probabilitas dari kejadian ini dan kapan mereka akan terjadi.Bahkan, ternyata probabilitas kejadian tergantung pada waktu hari, karena:- operator tidak bekerja di malam hari;
- orang membuang lebih banyak sampah pada jam-jam tertentu (di pagi hari sebelum bekerja dan di malam hari).
Oleh karena itu, kami memungkinkan tim analisis bisnis untuk menyesuaikan perilaku simulasi. Dimungkinkan untuk menetapkan probabilitas suatu peristiwa pada waktu tertentu dalam sehari.Tes stres yang sederhana dan intuitif
Imitasi itu sendiri memiliki banyak keunggulan, dan salah satunya adalah pengujian beban murah. Itu murah karena peniruan, pada kenyataannya, utas terpisah yang memulai mesin keadaan, menerapkan peristiwa padanya, dan peristiwa itu sendiri dikirim ke server nyata.Oleh karena itu, simulasi untuk backend tidak berbeda dengan sensor sebenarnya. Dan jika kita perlu menjalankan 1000 sensor, jalankan 1000 utas dan bekerja. Selain itu, simulasi berskala sempurna.
Di satu sisi, agak kasar untuk menguji beban, tetapi di sisi lain, simulasi memungkinkan untuk mendorong banyak data mendekati kenyataan untuk seluruh proyek. Dan jangan lupa tentang pengembang Cina berbakat yang mengabaikan protokol standar seperti MQTT dan memotong protokol mereka di atas soket. Oleh karena itu, kami harus melakukan implementasi server kami sendiri yang menerima data pada soket di bawah protokol eksklusif ini.Server seperti itu harus multi-threaded, karena ada banyak sensor input. dan bagian ini juga perlu diuji secara terpisah menggunakan tes kinerja. Anda dapat mengambil JMeter (menulis skrip uji khas), JMH / JCStress (menguji bagian yang terisolasi dan membuat tolok ukur yang lebih tipis), atau yang lain dari milik Anda. Ketika Anda membuat keputusan dalam situasi yang sama, saya menyarankan Anda untuk mendengarkan para profesional, misalnya, Alexei Shipilev. Di JPoint 2017, ia dengan sangat dingin berbicara tentang cara membandingkan berbagai hal dan apa yang perlu Anda pikirkan ketika melakukan pengujian kinerja.Kami memilih opsi untuk melakukan sesuatu sendiri, karena proyek memiliki pendekatan atipikal untuk QA - kami tidak memiliki tim penguji yang terpisah, dan tim backend sendiri menguji fungsionalitasnya. Artinya, orang yang menulis server soket harus menutupi kode dengan unit biasa, tes integrasi dan kinerja.Kami memiliki alat kecil yang memungkinkan kami untuk dengan cepat menggambarkan skenario pemuatan dan menjalankannya dalam jumlah paralel yang tepat:StressTestRunner.test()
.mode(ExecutionMode.EXECUTOR_MODE)
.threads(THREADS_COUNT)
.iterations(MESSAGES_COUNT)
.timeout(5, TimeUnit.SECONDS)
.run(() -> sensor.send(MESSAGE));
Awaitility.await()
.atMost(5, TimeUnit.SECONDS)
.untilAsserted(() ->
verifyReceived(MESSAGES_COUNT)
);
Kami mengatakan berapa banyak utas yang perlu Anda jalankan, berapa banyak pesan untuk dikirim, berapa lama waktu yang diperlukan, dan mengirim data ke soket di setiap utas. Tinggal menunggu server kami untuk memproses semua data ini dengan benar. Hanya beberapa baris kode yang telah dirilis yang dapat ditulis oleh pengembang backend.Persaingan masalah jaringan
Dengan bantuan imitasi, kami dapat mensimulasikan kerja berkualitas buruk dan spesifik dengan soket. Kartu SIM GSM di sensor tidak memiliki alamat IP "putih", dan kami dapat menerima data dari IP yang berbeda 50 kali sehari. Dan sering terjadi koneksi dibuka, kami mulai mentransfer data, kemudian alamat IP berubah, dan server membuka koneksi baru tanpa menutup yang lama. Jika kami tidak memperhitungkan ini, maka dalam beberapa hari kami akan kehabisan port gratis di server.
Ada juga masalah dengan sensor kecepatan yang berbeda. Perangkat yang lambat dapat membuka koneksi dan membeku untuk sementara waktu, sementara perangkat yang cepat akan mengirim sesuatu. Dan semua ini perlu diproses dengan benar. Dalam peniruan, simulasi situasi yang sama adalah mudah menggunakan jeda.
Ini hanya bagian dari skenario yang dapat dimasukkan ke dalam model.temuan
Tampak bagi saya bahwa justru kemungkinan simulasi yang sangat membedakan IOT dari proyek lain. Mensimulasikan perilaku perangkat lebih mudah daripada perilaku manusia. Pada input, kami mendapatkan nilai deterministik yang berkorelasi baik dengan model kami, dan bukan tindakan manusia yang acak. Karena perilaku perangkat secara logis lebih mudah dijelaskan daripada perilaku orang, dan pengujian sistem menjadi lebih mudah.Kami melihat beberapa aspek perkembangan di IoT.
Jika Anda melewatkan dua bagian sebelumnya dari artikel ini, Anda dapat menemukannya di sini:IoT di mana Anda tidak menunggu (Bagian 1) - Area subjek dan masalahIoT di mana Anda tidak menunggu (Bagian 2) - Arsitektur aplikasi dan pengujian IoT untuk hal-hal tertentuGithub dengan alat pengujian yang dimaksud.. , Heisenbug , IoT. , ! JPoint, . Heisenbug JPoint 6 . !