🧙🏼 🙏🏽 🐕 IoT जहां आपने इंतजार नहीं किया (भाग 3)। एक सिमुलेशन मॉडल का निर्माण 🏼 🍲 ✊🏼

जैसा कि मैंने पहले ही अंतिम भाग में कहा था , जब एक IoT प्रोजेक्ट विकसित कर रहा था, उपकरणों के साथ बातचीत के लिए प्रोटोकॉल बल्कि अस्थिर हैं, और फर्मवेयर अपडेट करने के बाद परीक्षण उपकरणों के साथ संपर्क खोने की संभावना काफी बड़ी थी। कई टीमें विकास में शामिल थीं, और एक सख्त आवश्यकता थी - आवेदन की व्यावसायिक परत का परीक्षण करने की क्षमता को न खोने के लिए, भले ही उपकरणों को फ्लैश करने से सेंसर के साथ काम करने का पूरा प्रवाह टूट जाए।

व्यवसाय विश्लेषकों द्वारा डेटा पर अपनी परिकल्पना को वास्तविकता के समान परीक्षण करने के लिए, हमने डिवाइस का एक सिमुलेशन मॉडल बनाया। इस प्रकार, यदि डिवाइस नए फर्मवेयर के कारण टूट गया, और डेटा को तत्काल प्राप्त करने की आवश्यकता है, तो हमने नेटवर्क पर एक वास्तविक डिवाइस के बजाय एक सिमुलेशन मॉडल लॉन्च किया, जिसने पुराने प्रारूप में डेटा का पीछा किया और परिणाम का उत्पादन किया।

इसके अलावा, मॉडल का लाभ यह था कि व्यवसाय केवल एक परिकल्पना का परीक्षण करने के लिए उपकरणों का एक बड़ा बैच कभी नहीं खरीदेगा। उदाहरण के लिए, व्यापार विश्लेषण टीम ने फैसला किया कि कंटेनर भरने के समय की भविष्यवाणी करना अलग तरीके से काम करना चाहिए। और उनकी परिकल्पना का परीक्षण करने के लिए, कोई भी 10,000 सेंसर खरीदने के लिए नहीं चलेगा।

सिमुलेशन मॉडल का विकास

सिमुलेशन मॉडल स्वयं निम्नानुसार था:

कचरा और राज्य के व्यवहार का वर्णन एक नियमित राज्य मशीन द्वारा किया जा सकता है। सबसे पहले, हम राज्य मशीन को राज्य `EMPTY (स्तर = 0)` के साथ आरंभीकृत करते हैं और हम उस पर कुछ क्रिया कर सकते हैं, अर्थात्, कंटेनर में कचरा फेंकते हैं। अब आपको यह तय करने की आवश्यकता है कि क्या कंटेनर खाली रहता है `(स्तर? MAX_LEVEL)` या यह पूर्ण है `(स्तर> = MAX_LEVEL)`। यदि दूसरा है, तो स्थिति `पूर्ण` में बदल जाती है।

कोई व्यक्ति एक पूर्ण कंटेनर से कचरा अनलोड कर सकता है, या चौकीदार अपनी गंदगी को साफ करने के लिए आया है, और हमें यह तय करने की आवश्यकता है कि किस राज्य में स्विच करना है। `CHOICE` राज्य एक कार्रवाई को चुनने के लिए जिम्मेदार है - एक राज्य मशीन की शब्दावली में, अगर एक ब्लॉक के समान कुछ।

एक और कंटेनर जल सकता है, और फिर राज्य-मशीन की स्थिति `FIRE` में बदल जाती है। इसके अलावा, कंटेनर गिर सकता है, और इसकी स्थिति `FALL` हो जाती है (रिपोर्ट में मैंने इस बारे में बात की थी कि किन अप्रत्याशित कारणों से कंटेनर गिर सकता है)। लेकिन एक अन्य `LOST` राज्य है, जो किसी भी अन्य राज्य से मान्य है - यह कनेक्शन खो जाने पर सेट किया जाता है।

ऐसी एक राज्य मशीन कंटेनर के लगभग सभी व्यवहार और उस पर सेंसर का वर्णन करती है। लेकिन यह एक सिमुलेशन मॉडल बनाने के लिए पर्याप्त नहीं है, क्योंकि हम उनसे संभावित राज्यों और संक्रमणों के बारे में जानते हैं, लेकिन हम नहीं जानते कि इन घटनाओं की संभावना क्या है और वे कब घटित होंगे।

वास्तव में, यह पता चला कि घटनाओं की संभावना दिन के समय पर निर्भर करती है, क्योंकि:

वाहक रात में काम नहीं करते हैं;
लोग कुछ घंटों में (काम से पहले सुबह और शाम को) अधिक कचरा फेंकते हैं।

इसलिए, हमने व्यवसाय विश्लेषण टीम के लिए सिमुलेशन व्यवहार को अनुकूलित करना संभव बना दिया। दिन के एक निश्चित समय में किसी घटना की संभावना निर्धारित करना संभव था।

सरल और सहज तनाव परीक्षण

नकली खुद के कई फायदे हैं, और उनमें से एक सस्ता लोड परीक्षण है। यह सस्ता है क्योंकि नकल वास्तव में, राज्य मशीन को शुरू करने वाला एक अलग धागा है, इस पर घटनाओं को लागू करता है, और घटनाओं को स्वयं वास्तविक सर्वर पर भेजा जाता है।

इसलिए, बैकएंड के लिए सिमुलेशन वास्तविक सेंसर से अलग नहीं है। और अगर हमें 1000 सेंसर चलाने, 1000 धागे चलाने और काम करने की आवश्यकता है। इसके अलावा, सिमुलेशन पूरी तरह से तराजू।

एक ओर, यह लोड का परीक्षण करने के लिए कठोर है, लेकिन दूसरी ओर, सिमुलेशन ने पूरे प्रोजेक्ट के लिए वास्तविकता के बहुत सारे डेटा को ड्राइव करना संभव बना दिया। और गिफ्ट किए गए चीनी डेवलपर्स के बारे में मत भूलना जिन्होंने एमक्यूटीटी जैसे मानक प्रोटोकॉल को नजरअंदाज कर दिया और सॉकेट्स के ऊपर अपने प्रोटोकॉल को देखा। इसलिए, हमें एक सर्वर का अपना कार्यान्वयन करना था जो इस स्वामित्व प्रोटोकॉल के तहत सॉकेट्स पर डेटा स्वीकार करता है।

ऐसे सर्वर को बहु-थ्रेडेड होना पड़ता था, क्योंकि कई इनपुट सेंसर होते हैं। और इस भाग को भी प्रदर्शन परीक्षणों का उपयोग करके अलग से परीक्षण करने की आवश्यकता है। आप JMeter ले सकते हैं (एक विशिष्ट परीक्षण स्क्रिप्ट लिख सकते हैं), JMH / JCStress (अलग-थलग भागों का परीक्षण करें और एक पतला बेंचमार्क बनाएं), या अपने खुद के कुछ और। जब आप एक समान स्थिति में निर्णय लेते हैं, तो मैं आपको पेशेवरों को सुनने की सलाह देता हूं, उदाहरण के लिए, अलेक्सी शिपिलेव। JPoint 2017 में, वह बहुत आराम से के बारे में बात बेंचमार्क अलग अलग बातें करने के लिए कैसे और क्या आप जब प्रदर्शन परीक्षण कर के बारे में सोचने की जरूरत है।

हमने अपने स्वयं के कुछ करने का विकल्प चुना, क्योंकि परियोजना में क्यूए के लिए एक असामान्य दृष्टिकोण था - हमारे पास परीक्षकों की एक अलग टीम नहीं है, और बैकेंड टीम ने स्वयं कार्यक्षमता का परीक्षण किया। अर्थात्, सॉकेट सर्वर लिखने वाले व्यक्ति को साधारण इकाइयों, एकीकरण और प्रदर्शन परीक्षणों के साथ कोड को कवर करना था।

हमारे पास एक छोटा सा उपकरण था, जो हमें भार परिदृश्य का शीघ्रता से वर्णन करने और समानांतर धागे की सही मात्रा में चलाने की अनुमति देता था:

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)
          );

हम कहते हैं कि आपको कितने थ्रेड्स चलाने हैं, कितने मैसेज भेजने हैं, कितने समय तक चलना चाहिए, और प्रत्येक थ्रेड में सॉकेट में डेटा भेजना चाहिए। यह केवल हमारे सर्वर के लिए इस सभी डेटा को सही ढंग से संसाधित करने के लिए प्रतीक्षा करने के लिए बनी हुई है। कोड की केवल कुछ पंक्तियाँ जारी की गई हैं जो किसी भी बैकएंड डेवलपर द्वारा लिखी जा सकती हैं।

नेटवर्क की समस्याओं का अनुकरण

नकल की मदद से, हम सॉकेट्स के साथ खराब-गुणवत्ता और विशिष्ट कार्य दोनों का अनुकरण करने में सक्षम थे। सेंसरों में जीएसएम सिम कार्ड में "सफेद" आईपी पते नहीं होते हैं, और हम दिन में 50 बार विभिन्न आईपी से डेटा प्राप्त कर सकते हैं। और अक्सर ऐसा हुआ कि कनेक्शन खोला गया था, हमने डेटा ट्रांसफर करना शुरू कर दिया, फिर आईपी एड्रेस बदल गया, और सर्वर पुराने को बंद किए बिना एक नया कनेक्शन खोलता है। यदि हम इसे ध्यान में नहीं रखते हैं, तो कुछ दिनों में हम सर्वर पर मुफ्त बंदरगाहों से बाहर निकल जाएंगे।

अलग-अलग स्पीड सेंसर को लेकर भी समस्या थी। एक धीमा डिवाइस कनेक्शन खोल सकता है और थोड़ी देर के लिए फ्रीज कर सकता है, जबकि एक फास्ट डिवाइस कुछ भेज देगा। और यह सब सही ढंग से संसाधित करने की आवश्यकता है। नकल में, पॉज़ का उपयोग करके एक समान स्थिति का अनुकरण करना आसान है।

यह उन परिदृश्यों का एक हिस्सा है जिन्हें मॉडल में शामिल किया जा सकता है।

जाँच - परिणाम

यह मुझे लगता है कि यह वास्तव में सिमुलेशन की संभावना है जो अन्य परियोजनाओं से आईओटी को दृढ़ता से अलग करता है। डिवाइस व्यवहार को अनुकरण करना मानव व्यवहार की तुलना में आसान है। इनपुट में, हम निर्धारक मूल्य प्राप्त करते हैं जो हमारे मॉडल के साथ अच्छी तरह से संबंध रखते हैं, न कि यादृच्छिक मानव क्रियाओं के साथ। क्योंकि लोगों के व्यवहार की तुलना में उपकरणों का व्यवहार तार्किक रूप से आसान है, और सिस्टम का परीक्षण आसान हो जाता है।

हमने IoT में विकास के कुछ अलग पहलुओं को देखा।

यदि आपने इस लेख के पिछले दो भागों को छोड़ दिया है, तो आप उन्हें यहाँ पा सकते हैं:

IoT जहाँ आप प्रतीक्षा नहीं करते थे (भाग 1) -
IoT का विषय क्षेत्र और समस्याएं जहाँ आप इंतजार नहीं करते थे (भाग 2) - अनुप्रयोग वास्तुकला और विशिष्ट चीज़ों का IoT परीक्षण

Github परीक्षण के उपकरण के साथ प्रश्न में।

. , Heisenbug , IoT. , ! JPoint, . Heisenbug JPoint 6 . !

IoT जहां आपने इंतजार नहीं किया (भाग 3)। एक सिमुलेशन मॉडल का निर्माण

सिमुलेशन मॉडल का विकास

सरल और सहज तनाव परीक्षण

नेटवर्क की समस्याओं का अनुकरण

जाँच - परिणाम

More articles: