मैं रोबोट (और अन्य यांत्रिक उपकरणों) के लिए इकाई परीक्षण कैसे लिखूं?

22

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

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

विस्तार से, किसी भी यांत्रिक उपकरण को संचालित करने के लिए कोड के लिए इकाई परीक्षण कैसे लिखे जा सकते हैं? यह मुझे लगता है कि आप केवल मशीन के संचालन का निरीक्षण करके त्रुटियों को पकड़ सकते हैं।

या मैं सिर्फ गलतफहमी है कि यूनिट परीक्षण कैसे काम करना चाहिए?

( यदि यह मायने रखता है, तो यहां कोड , यह C ++ में लिखा गया है, और मैं FRC में भाग ले रहा हूं )

unit-testing

— Michael0x2a
स्रोत

21

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

दुर्भाग्य से कुछ समस्याएं हैं जिन्हें आपको दूर करना होगा:

अपेक्षाकृत निम्न-स्तरीय भाषाओं में मज़ाक करना अधिक कठिन है (और इस प्रकार, बहुत अधिक काम)

मॉकिंग हार्डवेयर-स्तरीय सामान अधिक कठिन है (और इस प्रकार, बहुत अधिक काम)

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

— Oleksi
स्रोत

1

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

— दाऊद का कहना है कि मोनिका

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

— मैटनज़

4

@DavidWallace TDD / BDD का उपयोग करते समय विचार के लिए थोड़ा भोजन के रूप में, यूनिट परीक्षण के लाभ तुरंत होते हैं। पहली जगह में कोड को तुरंत विश्वास में लेने की अनुमति देकर, और दूसरी बात यह कि परीक्षणों को संतुष्ट करने के लिए कार्यान्वयन को न्यूनतम कार्यान्वयन तक सीमित रखने के लिए प्रोत्साहित करने से।

— रॉबिन्स

4

@mattnz बुरा विचार है, और मैं अनुभव से जानता हूं। क्या होगा अगर परीक्षण के तहत कोड बहुत मुश्किल से विफल होता है और रोबोटर्म दीवार के खिलाफ दुर्घटनाग्रस्त हो जाता है, xxxx $ हार्डवेयर का एक टुकड़ा बर्बाद कर रहा है ???

— stijn

2

@ मट्टनज़: हमारे रोबोट लगभग 2 फीट 3 फीट 4 फीट के हैं, और उनका वजन लगभग 150 पाउंड है। किट / पंजीकरण की लागत हर साल 5 हजार डॉलर होती है, और हम आमतौर पर अतिरिक्त भागों की खरीद के लिए एक और 5 से 10k तक धन उगाहते हैं। सबसे खराब स्थिति शायद $ 10 से अधिक होगी;)

— माइकल0x2 ए

10

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

उदाहरण के लिए, यदि आपको एक I2C- आधारित सिग्नलिंग प्रोटोकॉल डिज़ाइन करने की आवश्यकता है, तो आप परीक्षण कर सकते हैं कि आपका कोड आपके परीक्षण में हार्डवेयर को हुक करने की आवश्यकता के बिना सही I2C सिग्नल उत्पन्न कर रहा है।

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

यह मूल रूप से ओलेक्सी ने अपने उत्तर में कही गई बातों के साथ फिट बैठता है , इसमें आमतौर पर हार्डवेयर-स्तर के सामान को मॉक करने के लिए अधिक काम किया जाता है, हालांकि यह इतना मुश्किल नहीं है यदि आप सबसे कम संभव न्यूनतम-कोड / कॉल लेयर को रखते हैं जो आप के लिए बना सकते हैं हार्डवेयर।

जब आपके पास कोड है जो इसके सभी परीक्षणों को पारित करता है, तो आपको अभी भी मैन्युअल परीक्षणों की एक श्रृंखला के माध्यम से चलाने की आवश्यकता होगी ताकि यह सुनिश्चित हो सके कि आपने अपनी हार्डवेयर परत में सब कुछ सही ढंग से बनाया है।

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

— S.Robins
स्रोत

2

मैं आपको बता सकता हूं कि वे फ्लाइट सिमुलेटर पर कैसे करते हैं

सबसे पहले, आप केवल आधा उत्तर प्राप्त करने जा रहे हैं यदि आप केवल प्रोग्रामर से यह सवाल पूछते हैं, तो आपको इसे http://electronics.stackexchange.com पर पोस्ट करते समय इसे पार करना चाहिए ।

मैंने रोबोट के साथ कोई काम नहीं किया है, लेकिन मैंने उड़ान सिमुलेटर पर हार्डवेयर करने में 5 साल बिताए हैं, इसलिए मैं आपको बता सकता हूं कि उनकी वास्तुकला कैसे काम करती है।

हार्डवेयर लेयर गूंगा है

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

अंशांकन एक साधारण तालिका है जिसमें न्यूनतम / अधिकतम मानों के बीच सेक्शन किया हुआ होता है। इन पर इनपुट को मापने के लिए, आम तौर पर एक इमदादी का उपयोग किया जाता है (उदाहरण के लिए एक रैखिक पोटेंशियोमीटर, ट्रांसड्यूसर, एक्सेलेरोमीटर, आदि)। या इंस्ट्रूमेंटेशन के मामले में, आप बस सटीकता को दृष्टिगत रूप से देखते हैं और कैलिब्रेटेड होने तक समायोजित करते हैं।

सॉफ्टवेयर लेयर इसके विपरीत है

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

उड़ान सिम्युलेटर पर इसे क्यूटीजी (क्वालिफिकेशन टेस्ट गाइड) कहा जाता है। इसके मूल में यह एक 2 डी ग्रिड पर डेटा प्लॉट करता है जहां एक आयाम समय और दूसरा आउटपुट है।

मानो या न मानो, कि वे कैसे मॉडल विकसित करने का सार है। एक वास्तविक विमान सेंसर के एक टन से सुसज्जित है और नियंत्रित परिदृश्यों के आसपास उड़ाया जाता है। क्योंकि सभी नियंत्रणों को मानव संपर्क के बिना संचालित किया जा सकता है, इसलिए परीक्षण कंप्यूटर द्वारा चलाए जाते हैं (यानी सिम खुद ही उड़ जाता है) और डेटा की तुलना की जाती है।

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

जब तक परिणाम पूर्वानुमेय, मापने योग्य और प्रतिलिपि प्रस्तुत करने योग्य न हो जाएं, तब तक परीक्षण आवश्यक रूप से जटिल होने की आवश्यकता नहीं है।

— इवान प्लाइस
स्रोत

1

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

— martiert
स्रोत