सिग्नल प्रोसेसिंग लाइब्रेरीज़ के लिए टेस्ट संचालित विकास

Question

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

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

एक स्थापित टीडीडी ढांचे का उपयोग करना अच्छा होगा जहां मेरे पास एक परीक्षण सूट हो सकता है, लेकिन मुझे नहीं लगता कि मैं बिना परीक्षण के प्रसंस्करण ब्लॉक की कार्यक्षमता को कैसे सत्यापित कर सकता हूं जो परीक्षण के तहत कोड के समान जटिल है । परीक्षण के बिना एक प्रसंस्करण ब्लॉक को प्रमाणित करने के लिए मैं एक सी ++ परीक्षण में संदर्भ सिग्नल कैसे उत्पन्न करूं?

अगर किसी के पास इस क्षेत्र में अनुभव है, या कुछ तरीकों का सुझाव दे सकता है जो मैं पढ़ सकता हूं, तो यह बहुत अच्छा होगा।

Answer 1

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

• FFTs: डीसी, Fs/Nfft, Fs/2 और विभिन्न चरणों आदि: ज्ञात आवृत्तियों पर परीक्षण संकेतों चोटी और चरण की जांच करें, जैसा कि आप उम्मीद करते हैं, सामान्यीकरण स्थिरता की जांच करें, जैसा कि आप
• चोटी चुनना: परीक्षण करें कि आप सही ढंग से अधिकतम/मिनीमा
• फ़िल्टर: ज्ञात आवृत्तियों पर इनपुट उत्पन्न करें और आउटपुट आयाम और चरण की जांच करें जैसा कि अपेक्षित है।

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

Answer 2

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

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

दूसरी ओर, मैं हमेशा यह कहना चाहते हैं: "यदि इसकी जांच नहीं की, इसके टूट" की :)

Answer 3

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

इसके अलावा, आप व्यक्तिगत गणना घटकों के लिए एपीआई बनाए रख सकते हैं, न केवल पूरे अंत-टू-एंड सिस्टम के लिए।

Answer 4

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

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