2009-04-09 19 views
14

एम्बेडेड वातावरण में या अन्य परिस्थितियों में रिग्रेशन परीक्षण चलाने के लिए क्या अच्छे अभ्यास और रणनीतियां हैं जहां परीक्षण स्वचालित करने की संभावना बहुत सीमित है।एम्बेडेड सिस्टम में रीग्रेशन परीक्षण कैसे करें

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

उचित प्रतिगमन परीक्षण के बिना स्थिति बड़े रिफैक्टरिंग और इस तरह के दौरान भी बदतर हो जाती है।

क्या कोई समस्या को पहचानता है? क्या आपको इस तरह की समस्या से निपटने के लिए एक अच्छा समाधान या प्रक्रिया मिली?

+0

यह प्रश्न भी देखें: [हार्डवेयर के साथ टीडीडी कैसे करें] (https://stackoverflow.com/questions/585593/how-to-do-tdd-with-hardware) – geschema

उत्तर

11

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

यदि मैं एक गैर-x86 मंच पर काम करना चाहता था, तो शायद मैं इसके बजाय एक एमुलेटर लिखूंगा।

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

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

+0

यह सब आवाज वास्तव में मुझे आकर्षक बनाती है, लेकिन मुझे लगता है कि जब मैं स्वचालन विकल्प नहीं हूं तो मैं एक प्रक्रिया की तलाश में हूं।मुझे लगता है कि मैं बीमारी को ठीक करने के बजाय अपनी वर्तमान समस्याओं का समाधान करने के लिए दवा चाहता हूं;) – sris

+1

आपने कहा कि समस्या मैन्युअल परीक्षण थी। समाधान इसलिए स्वचालन का कुछ रूप है। इसे अस्वीकार करते हुए, आप सभी समस्याओं के साथ मैन्युअल परीक्षण पर वापस आ गए हैं। – Paul

4

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

इससे अधिकांश के लिए अभिन्नता सुनिश्चित होगी, लेकिन आपको अभी भी सिस्टम और स्वीकृति परीक्षण मैन्युअल रूप से करने की आवश्यकता होगी।

+0

मैं पूरी तरह सहमत हूं, मेरी वर्तमान समस्या हालांकि यह है कि मैं एक विरासत प्रणाली (> 15 साल) पर काम कर रहा हूं, इसलिए इसके लिए देर हो चुकी है। – sris

+0

हे, हाँ, ठीक है .. कमांडर के साथ शुभकामनाएं 64 ^^ – cwap

1

व्यक्तिगत उपप्रणाली के लिए परीक्षण harnesses/sandboxes/mockups प्रदान करें, और पूरे प्रोजेक्ट के लिए, जो लक्षित वातावरण का अनुकरण करता है।

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

2

क्या कोई समस्या को पहचानता है?

सबसे निश्चित रूप से।

आप एक अच्छा समाधान या प्रक्रिया इस तरह की समस्या से निपटने के लिए मिला?

तकनीक का एक संयोजन:

  • स्वचालित परीक्षण;
  • ब्रूट-फोर्स परीक्षण, यानी जो स्वचालित परीक्षण के रूप में बुद्धिमान नहीं हैं, लेकिन जो लंबे समय तक (घंटे या दिन) पर एक सुविधा का परीक्षण करते हैं, और मानव हस्तक्षेप के बिना चलाने के लिए छोड़े जा सकते हैं;
  • मैन्युअल परीक्षण (अक्सर से बचने के लिए मुश्किल);
  • किसी पीसी पर सॉफ़्टवेयर एमुलेटर पर परीक्षण (या अंतिम उपाय के रूप में, एक हार्डवेयर एमुलेटर)।

एक पीसी संकलक पर संकलन के संबंध में: कि निश्चित रूप से उच्च स्तर के मॉड्यूल के लिए कोई मतलब होता है, और एक परीक्षण उपयुक्त दोहन के साथ निम्न स्तर के मॉड्यूल के लिए।

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

1

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

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

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

यदि मैं इसे फिर से कर रहा हूं तो मैं शायद परीक्षण लाइब्रेरी को परीक्षण दोहन और वास्तविक कोड को कोर संदेश भेजने के लिए लागू किया गया था। मैं फिर lib में पायथन लपेटूंगा (या कुछ समान) तो मेरा परीक्षण थोड़ा और अधिक "स्क्रिप्ट योग्य" हो सकता है।

0

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

1

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

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

2

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

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

1

उपयोग में एक समाधान जहां मैं काम करता हूं स्वचालित रात का निर्माण और परीक्षण प्रक्रिया है।

  1. स्रोत नियंत्रण से ट्रंक हेड कोड देखें।
  2. परियोजना बनाएं और लक्ष्य पर लोड करें।
  3. पीसी संचालित स्वचालित परीक्षण स्क्रिप्ट चलाएं।

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

नकल विकास और बुनियादी प्रारंभिक परीक्षण के लिए अच्छा है, लेकिन असली भौतिक ऑपरेटिंग समय सिस्टम सत्यापन के लिए एकमात्र विश्वसनीय तरीका है। शारीरिक ऑपरेशन गैर-कोड मुद्दों (कोडिंग विधियों के कारण) को फेरेट कर सकता है जैसे कि वोल्टेज sags, शोर, glitches, debounce मुद्दों, दौड़ की स्थिति, आदि

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

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