यूनिट परीक्षण एंबेडेड सॉफ्टवेयर

Question

यूनिट परीक्षण एम्बेडेड सॉफ़्टवेयर में आपने सर्वोत्तम प्रथाओं का उपयोग किया है जो एम्बेडेड सिस्टम के लिए विशिष्ट हैं?

Answer 1

एंबेडेड सॉफ्टवेयर पिछले 10 वर्षों में एक लंबा सफर तय हो सकता है लेकिन हम आम तौर पर किया था निम्नलिखित:

एल्गोरिदम कि लक्ष्य हार्डवेयर पर निर्भर नहीं किया
• , हम बस इकाई परीक्षण है कि निर्माण किया गया था और एक गैर एम्बेडेड मंच पर परीक्षण किया। हार्डवेयर की आवश्यकता वाले सामानों के लिए
• , यूनिट परीक्षणों को जो भी हार्डवेयर उपलब्ध था, का उपयोग करने के लिए कोड में सशर्त रूप से संकलित किया गया था। हमारे मामले में, यह परिणामों को दूसरे, अधिक सक्षम, मशीन पर धक्का देने के लक्ष्य पर एक धारावाहिक बंदरगाह था जहां परीक्षणों को शुद्धता के लिए जांच की गई थी।
• हार्डवेयर के आधार पर, आप कभी-कभी गैर-एम्बेडेड प्लेटफ़ॉर्म पर "वर्चुअल" डिवाइस को डमी कर सकते हैं। इसमें आम तौर पर प्रोग्राम द्वारा उपयोग की जाने वाली मेमोरी बदलने के निष्पादन (या सिग्नल फ़ंक्शन) का एक और धागा होता है। स्मृति मैप किए गए I/O के लिए उपयोगी लेकिन आईआरक्यू और ऐसे नहीं।
• आम तौर पर, आप केवल एक ही समय में पूर्ण कोड के एक छोटे से सबसेट (स्मृति बाधाओं के कारण) परीक्षण कर सकते हैं। समय-संवेदी चीजों के परीक्षण के लिए
• , हमने नहीं किया। सादा और सरल। हमारे द्वारा उपयोग किए जाने वाले हार्डवेयर (8051 और 68302) हमेशा धीमे नहीं होने पर काम नहीं करते थे। उस तरह के डिबगिंग को सीआरओ (ऑसिलोस्कोप) के साथ शुरुआत में किया जाना था और (जब हमारे पास कुछ और पैसा था) एक आईसीई (इन-सर्किट एमुलेटर)।

उम्मीद है कि आखिरकार स्थिति में सुधार हुआ है क्योंकि मैंने इसे आखिरी बार किया है। मैं अपने सबसे बुरे दुश्मन पर वह दर्द नहीं चाहता।

Answer 2

बहुत सारे एम्बेडेड प्रोसेसर eval बोर्डों पर उपलब्ध हैं, इसलिए यद्यपि आपके पास वास्तविक आई/ओ डिवाइस नहीं हो सकते हैं, अक्सर आप अपने एल्गोरिदम का एक अच्छा सौदा निष्पादित कर सकते हैं और इस तरह की चीजों में से किसी एक पर तर्क कर सकते हैं, अक्सर w/jtag के माध्यम से हार्डवेयर डीबगिंग उपलब्ध है। और 'यूनिट' परीक्षण आमतौर पर आपके तर्क के बारे में अधिक हैं I/o वैसे भी। समस्या आमतौर पर इन परीक्षणों में से एक के से आपकी टेस्ट कलाकृतियों को वापस प्राप्त कर रही है।

Answer 3

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

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

• जितना संभव हो सके हार्डवेयर पर निर्भर करें।

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

Answer 4

डिवाइस-निर्भर & डिवाइस-स्वतंत्र के बीच कोड को विभाजित करें। स्वतंत्र कोड बहुत अधिक दर्द के बिना इकाई परीक्षण किया जा सकता है। जब तक आपके पास एक चिकनी संचार इंटरफ़ेस न हो तब तक आश्रित कोड को हाथ से परीक्षण करने की आवश्यकता होगी।

आप लेखन संचार इंटरफेस कर रहे हैं, मैं माफी चाहता हूँ।

Answer 5

वहाँ एक बहुत (एक पीसी सी संकलक के साथ अपने कोड संकलन और एक पीसी इकाई परीक्षण ढांचे में अपने कोड चल रहा), एक पीसी वातावरण में इकाई परीक्षण से प्राप्त किया जा करने के लिए किया जा सकता है कई प्रावधानों के साथ:

1. यह स्टार्ट-अप कोड, रैम परीक्षण, हार्डवेयर ड्राइवर सहित आपके निम्न-स्तरीय कोड का परीक्षण करने के लिए लागू नहीं होता है। आपको उन लोगों के अधिक प्रत्यक्ष इकाई परीक्षण का उपयोग करना होगा।
2. आपके एम्बेडेड सिस्टम के कंपाइलर को भरोसेमंद होना चाहिए, इसलिए आप कंपाइलर द्वारा बनाई गई बग का शिकार नहीं कर रहे हैं।
3. हार्डवेयर कोडांकन के साथ, आपके कोड को स्तरित वास्तुकला होना चाहिए। आपको अपने पीसी यूनिट परीक्षण ढांचे के लिए हार्डवेयर ड्राइवर सिमुलेटर लिखने की आवश्यकता हो सकती है।
4. तुम हमेशा stdint.h प्रकार का उपयोग करना चाहिए जैसे uint16_t बल्कि unsigned int सादे से आदि

हम इन नियमों का पालन किया है, और पाया कि इकाई एक पीसी इकाई परीक्षण ढांचे में आवेदन-परत कोड का परीक्षण करने के बाद, हम भरोसा कर सकते हैं कि यह अच्छी तरह से काम करता है।

पीसी प्लेटफॉर्म पर इकाई परीक्षण के लाभ:

1. आप की वजह से एक इकाई परीक्षण ढांचे को जोड़ने के लिए अपने एम्बेडेड मंच पर रोम में स्थान कम की समस्या का सामना नहीं है।
2. संकलन-लिंक-रन चक्र आमतौर पर पीसी प्लेटफ़ॉर्म पर तेज़ और सरल होता है (और 'लेखन/डाउनलोड' चरण से बचाता है जो संभावित रूप से कई मिनट हो सकता है)।
3. आपके पास प्रगति को देखने के लिए और विकल्प हैं (कुछ एम्बेडेड अनुप्रयोगों में सीमित I/O परिधीय हैं), विश्लेषण के लिए इनपुट/आउटपुट डेटा संग्रहीत करना, अधिक समय लेने वाले परीक्षण चलाना।
4. आप आसानी से उपलब्ध पीसी-आधारित इकाई परीक्षण ढांचे का उपयोग कर सकते हैं जो एक एम्बेडेड प्लेटफ़ॉर्म के लिए उपलब्ध/उपयुक्त नहीं हैं।

Answer 6

यहां अनुभवहीनता की आवाज, लेकिन यह कुछ ऐसा है जो मैं हाल ही में सोच रहा था। ऐसा लगता है कि सबसे अच्छा तरीका या तो

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

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

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

Answer 7

वहाँ है यहाँ अच्छा जवाब के बहुत सारे हैं, कुछ चीजें हैं जो उल्लेख नहीं किया गया है नैदानिक ​​कोड करने के लिए चल रहा है के लिए है:

लॉग एचएएल घटनाओं (बीच में आता है, बस गए संदेशों, आदि)

कोड है अपने संसाधनों का ट्रैक रखने के लिए, (सभी सक्रिय सेमफोर, थ्रेड गतिविधि)

डेडलॉक्स, livelocks, स्मृति रिसाव का पता लगाने और डीबग करने के लिए लगातार भंडारण (हार्ड डिस्क या समकक्ष) को ढेर और स्मृति सामग्री की प्रतिलिपि बनाने के लिए एक कैप्चर रैम तंत्र है , बफर ओवरफ्लो, आदि

Answer 8

आप जेम्स डब्ल्यू ग्रेनिंग द्वारा Test Driven Development for Embedded C देख सकते हैं। पुस्तक अगस्त 2010 में प्रकाशित होने वाली है, लेकिन बीटा पुस्तक अब The Pragmatic Bookshelf पर उपलब्ध है।

Answer 9

जब मैं पिछले साल सामना कर रहा था तो मैं वास्तव में एम्बेडेड प्लेटफॉर्म पर परीक्षण करना चाहता था। मैं एक पुस्तकालय विकसित कर रहा था और मैं आरटीओएस कॉल और एम्बेडेड प्लेटफार्म की अन्य सुविधाओं का उपयोग कर रहा था। कुछ विशिष्ट उपलब्ध नहीं था इसलिए मैंने यूनिटटेस्ट ++ कोड को मेरे उद्देश्यों में अनुकूलित किया। मैं NetBurner परिवार पर प्रोग्राम करता हूं और चूंकि इसमें एक एम्बेडेड वेब सर्वर है, इसलिए यह एक वेब आधारित जीयूआई परीक्षण धावक लिखने के लिए काफी सीधे था जो क्लासिक लाल/ग्रीन फीडबैक देता था। यह turned out pretty well है, और अब इकाई परीक्षण बहुत आसान है और मुझे वास्तविक हार्डवेयर पर कोड काम करने के बारे में और अधिक आत्मविश्वास महसूस होता है। मैं एकीकरण परीक्षण करने के लिए यूनिट परीक्षण ढांचे का भी उपयोग करता हूं। सबसे पहले मैं हार्डवेयर को mocks/stub और परीक्षण करने के लिए उस इंटरफ़ेस इंजेक्षन। लेकिन आखिर में मैं कुछ मैन-इन-द-लूप परीक्षण लिखता हूं जो वास्तविक हार्डवेयर का प्रयोग करते हैं। यह हार्डवेयर के बारे में जानने के लिए एक आसान तरीका साबित होता है और एम्बेडेड जाल से पुनर्प्राप्त करने का एक आसान तरीका है। चूंकि परीक्षण सभी वेब सर्वर पर AJAX कॉलबैक से चलते हैं, इसलिए एक जाल केवल परीक्षण का आविष्कार करने के परिणामस्वरूप होता है और सिस्टम हमेशा जाल के कुछ सेकंड बाद साफ-सफाई करता है।

नेटबर्नर पर्याप्त तेज़ है कि लेखन/संकलन/डाउनलोड/परीक्षण परीक्षण चक्र लगभग 30 सेकंड है।

Answer 10

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

जटिल नियंत्रण प्रणाली, मेमोरी इंटरफेस, कस्टम एसपीआई संचालित आईसीएस और यहां तक ​​कि एक मोनो-डिस्प्ले के लिए विश्वसनीय रूप से काम करने के लिए इसे प्राप्त किया है।