हार्डवेयर के साथ टीडीडी कैसे करें

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

अद्यतन: मेरे प्रश्न के साथ स्पष्ट नहीं होने के लिए खेद है।

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

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

दूसरा अपडेट: मैं कुछ ठोस उदाहरणों की भी तलाश कर रहा हूं कि लोगों ने इस स्थिति को कैसे निपटाया है।

स्रोत

2009-02-25 Matt Warren

क्या आपका प्रश्न केवल हार्डवेयर के साथ इंटरफेस करने या हार्डवेयर के परीक्षण के बारे में आपके कोड का परीक्षण करने के बारे में है? – OregonGhost

दोनों मुझे लगता है, लेकिन हार्डवेयर के साथ बातचीत करने वाला मेरा कोड काफी पतली परत है। यह सिर्फ तृतीय पक्ष लाइब्रेरी में कॉल करता है जो वास्तव में हार्डवेयर को नियंत्रित करता है। –

इस समस्या का असली क्रूक्स यह है कि अगर हार्डवेयर में सवाल हार्डवेयर में पूरी तरह वर्णित किया गया था, तो आपको हार्डवेयर की आवश्यकता नहीं होगी। : पी – meawoppl

स्प्लिट को दो भागों में अपने टेस्ट स्वीट:

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

भाग # 1 मैन्युअल रूप से चलाना हो जाता है के बाद क्या आप वाकई हार्डवेयर सही ढंग से तार, आदि है बनायाएक अच्छा विचार है कि कारखाने द्वारा लौटाए गए कुछ परीक्षणों के खिलाफ चलने वाले परीक्षणों का एक सूट तैयार करना और इन परीक्षणों को दो बार चलाएं: एक बार कारखाने के साथ जो वास्तविक "चालक" लौटाता है और एक बार आपके नकली वस्तुओं के कारखाने के खिलाफ होता है। इस तरह, आप सुनिश्चित करें कि आपके mocks असली बात के रूप में ठीक उसी तरह काम किया जा सकता है:

class YourTests extends TestCase { 
    public IDriver getDriver() { return new MockDriver(); } 
    public boolean shouldRun() { return true; } 
    public void testSomeMethod() throws Exception { 
     if (!shouldRun()) return; // Allows to disable all tests 
     assertEquals ("1", getDriver().someMethod()); 
    } 
}

मेरे कोड में, मैं आमतौर पर मैनुअल परीक्षण टॉगल करने के लिए एक प्रणाली संपत्ति (-Dmanual हाँ =) का उपयोग करें:

class HardwareTests extends YourTests { 
    public IDriver getDriver() { return new HardwareDriver(); } 
    public boolean shouldRun() { return "yes".equals (System.getProperty("manual")); } 
}

स्रोत

2009-02-25 12:17:39

यदि आपके पास सिम्युलेटर है, तो आप सिम्युलेटर के खिलाफ परीक्षण लिख सकते हैं और हार्डवेयर के खिलाफ इन परीक्षणों को चला सकते हैं।

यह चतुराई से :-)

स्रोत

2009-02-25 11:11:20

इसके बारे में क्षमा करें, मैं थोड़ा अस्पष्ट था। मैंने सवाल में कुछ और जानकारी डाली है, क्या इससे मदद मिलती है? –

नकली इतने कम विस्तार के साथ सवालों के जवाब मुश्किल है।

स्रोत

2009-02-25 11:21:14 adolfojp

+1 जब मैं एम्बेडेड डिवाइस पर काम कर रहा था तो यह वह मार्ग है जिसे हमने लिया था। –

क्या आपके पास कोई उदाहरण है कि मैं यह कैसे करता हूं? उदाहरण के लिए, मैं मूल रूप से एक डिवाइस चालक का नकल कैसे करूं, क्या मैं अपना खुद का सिम्युलेटर लिखता हूं जो घटनाओं/त्रुटियों का उत्पादन कर सकता है? –

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

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

यदि आप पीसीआई डिवाइस ड्राइवर या समकक्ष स्तर के सॉफ्टवेयर लिख रहे हैं, तो आप शायद सॉफ्टवेयर स्टैंड-इन नहीं बना सकते हैं।

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

वैकल्पिक रूप से, डिवाइस के आधार पर, आप इसे 'ज्ञात इनपुट' फ़ीड करने के लिए मानक परीक्षण उपकरण (सिग्नल जनरेटर, आदि) का उपयोग करने में सक्षम हो सकते हैं।

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

स्रोत

2009-02-25 11:41:43

जानकारी के लिए धन्यवाद, हाँ मैं अंतिम भाग के साथ। मैंने हार्डवेयर के खिलाफ टीडीडी के साथ संघर्ष किया है क्योंकि यह मजाक कर रहा है क्योंकि यह वास्तव में हार्डवेयर का परीक्षण नहीं कर रहा है। –

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

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

मैं भी दो भागों में टेस्ट स्वीट बंटवारे के विचार की तरह:

एक है कि वास्तविक हार्डवेयर, जो आप मैन्युअल रूप से
एक है कि सॉफ्टवेयर मॉड्यूल तक पहुँचता है चलाने के लिए, जो के हिस्से के रूप चलाता तक पहुँचता है स्वत: परीक्षण

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

स्रोत

2009-02-25 11:43:58 geschema

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

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

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

हमें एक सॉफ्टवेयर बनाने में बहुत मदद मिली जो एक सीरियल पोर्ट से आने वाले डेटा को सुनता है, इसे लॉग करता है और इसे दूसरे सीरियल पोर्ट पर रीडायरेक्ट करता है। फिर हम यह पता लगाने में सक्षम थे कि पुराना प्रोग्राम (जिसे हम बदल रहे थे) हार्डवेयर के साथ संवाद करते थे, और प्रोटोकॉल को रिवर्स इंजीनियर करते थे। वे इस तरह जंजीर थे: पुराना कार्यक्रम < -> वर्चुअल लूपबैक सीरियल पोर्ट < -> हमारे डेटा लॉगर < -> असली सीरियल पोर्ट < -> हार्डवेयर।

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

स्रोत

2009-02-25 11:44:41

+1, यह अन्य उत्तरों के समान है, लेकिन बहुत अच्छी तरह से रखा गया है। – mghie

जब मैं सेट-टॉप बॉक्स पर काम कर रहा था, तो हमारे पास एक ऐसा टूल था जो डॉक्सिजन टिप्पणियों के साथ किसी भी सी एपीआई से मैक्स उत्पन्न करेगा।

हम फिर हमारे घटकों को यूनिट-परीक्षण करने के लिए हार्डवेयर को वापस लौटना चाहते थे, इसके साथ हम मोक्स का नेतृत्व करेंगे।

तो ऊपर दिए गए उदाहरण में आप फ्रेमग्रेबर_एपीआई_आईएसडीवीसएट के परिणाम को झूठा होने के लिए सेट करेंगे, और जब आपका कोड उस फ़ंक्शन को कॉल करता है तो यह झूठा होता है और आप इसका परीक्षण कर सकते हैं।

परीक्षण करना कितना आसान होगा इस पर निर्भर करता है कि आपका कोड वर्तमान में किस प्रकार संरचित है।

उपकरण जो हम मोजे उत्पन्न करने के लिए उपयोग करते थे वह घर में था, इसलिए मैं आपकी मदद नहीं कर सकता। लेकिन वहाँ कुछ उम्मीद गूगल हिट कर रहे हैं: (अस्वीकरण - मैं इनमें से किसी भी उपयोग किया है, लेकिन उम्मीद है कि वे आप के लिए सहायक हो सकता है)

बस जांच रहा है - क्या आपके पास आपके कोड या कुछ में प्रत्यक्ष ioctl कॉल की तरह कुछ है? वे हमेशा नकली करने के लिए मुश्किल हैं। हमारे पास एक ओएस रैपर परत थी जिसे हम आसानी से मैक्स लिख सकते थे ताकि यह हमारे लिए बहुत आसान हो।

स्रोत

2009-02-28 22:03:31

हार्डवेयर के साथ टीडीडी कैसे करें

उत्तर

संबंधित मुद्दे