मैं एक सॉफ्टवेयर इंजीनियर हूं जो फर्मवेयर परीक्षण इंजीनियर के रूप में किराए पर लिया जा सकता है। मैं फर्मवेयर परीक्षण में इस्तेमाल बाजार में उपलब्ध कुछ सॉफ्टवेयर टूल्स का विचार प्राप्त करना चाहता हूं। क्या आप उन्हें बता सकते हैं और फर्मवेयर को किस तरह के परीक्षण प्रदान करते हैं, इस बारे में थोड़ा सा समझा सकते हैं? अग्रिम में धन्यवाद।आज फर्मवेयर परीक्षण में उपयोग किए जाने वाले कुछ उपलब्ध सॉफ़्टवेयर टूल क्या हैं?
परीक्षण कई रूपों में आता है और विभिन्न चरणों में किया जा सकता है। कोड से पहले डिज़ाइन सत्यापन के अलावा, कोड परीक्षण भी यूनिट परीक्षण, एकीकरण परीक्षण, सिस्टम परीक्षण और स्वीकृति परीक्षण में विभाजित किया जा सकता है (हालांकि सटीक शब्द और चरणों की संख्या बहुत हो सकती है)। वी मॉडल में, ये आवश्यकताओं और डिजाइन विकास में चरणों के साथ क्षैतिज रूप से मेल खाते हैं। विकास और रखरखाव में भी आप रिग्रेशन परीक्षण कर सकते हैं - यह सुनिश्चित करना कि अन्य परिवर्तन लागू होने पर निश्चित बग तय रहें।
जहां तक उपकरण का संबंध है, इन्हें स्थिर विश्लेषण और गतिशील विश्लेषण में विभाजित किया जा सकता है। स्टेटिक टूल निष्पादन के बिना स्रोत कोड का विश्लेषण करते हैं, जबकि गतिशील विश्लेषण निष्पादन के दौरान कोड के व्यवहार से संबंधित है। कुछ (महंगा) उपकरण प्रदर्शन "सार निष्पादन" जो एक स्थिर विश्लेषण तकनीक तय करता है कि कोड वास्तविक निष्पादन के बिना निष्पादन के दौरान विफल हो सकता है है, इस दृष्टिकोण computationally महंगा है लेकिन कहीं अधिक निष्पादन रास्तों और पारंपरिक गतिशील विश्लेषण से चर राज्यों पर कार्रवाई कर सकते हैं।
स्थिर विश्लेषण का सबसे सरल रूप कोड समीक्षा है; अपने कोड को पढ़ने के लिए एक इंसान हो रही है। SmartBear's Code Collaborator जैसे इस स्पष्ट रूप से मैन्युअल प्रक्रिया के साथ भी सहायता करने के लिए टूल हैं। इसी तरह गतिशील विश्लेषण का सबसे सरल रूप है बस अपने डीबगर में अपने कोड से कदम उठाना या यहां तक कि अपने परीक्षण को विभिन्न परीक्षण परिदृश्यों के साथ चलाने के लिए। पहला यूनिट डेवलपमेंट और डिबगिंग के दौरान प्रोग्रामर द्वारा किया जा सकता है, जबकि उत्तरार्द्ध स्वीकृति या एकीकरण परीक्षण के लिए अधिक अनुकूल है।
जबकि कोड समीक्षा अच्छी तरह से की गई है, तो बड़ी संख्या में त्रुटियों को हटा सकते हैं, विशेष रूप से डिज़ाइन त्रुटियों, प्रोग्रामिंग भाषाओं के सूक्ष्म या आर्केन अर्थशास्त्र के कारण कुछ प्रकार की त्रुटियों को खोजने में शायद यह इतना कुशल नहीं है। इस तरह की त्रुटि स्थिर विश्लेषण उपकरण जैसे Gimpel's PC-Lint and FlexeLint tools, या Programming Research's QA tools का उपयोग करके स्वचालित पहचान के लिए खुद को उधार देती है, हालांकि कम लागत वाले दृष्टिकोण जैसे कि आपके कंपाइलर के चेतावनी स्तर को उच्च और एक से अधिक कंपाइलर के साथ संकलित करना भी उपयोगी है।
गतिशील विश्लेषण उपकरण कोड कवरेज विश्लेषण, कोड प्रदर्शन प्रोफाइलिंग, मेमोरी प्रबंधन विश्लेषण और सीमाओं की जांच जैसे कई रूपों में आते हैं।
उच्च अंत उपकरण/विक्रेताओं Coverity, PolySpace (एक सार विश्लेषण उपकरण), Cantata, LDRA, और Klocwork की पसंद में शामिल हैं। निचले सिरे पर (मूल्य में, जरूरी नहीं कि प्रभावशीलता) इस तरह के पीसी-एक प्रकार का वृक्ष और Tessy, या यहाँ तक खुला स्रोत splint (सी केवल), और unit testing tools
यह जोर देना महत्वपूर्ण है कि बेहद महंगा स्थिर विश्लेषकों की कीमत 10 वीं की लागत से बेहतर नहीं है। मैं स्वयं एलडीआरए का उपयोग कर रहा हूं और यह एक भाग्य खर्च करता है, लेकिन यह अन्य उपकरणों की तुलना में बेहतर प्रदर्शन नहीं करता है। अंतर यह है कि एलडीआरए बेहद ट्रिगर-खुश है और बड़ी संख्या में चेक हटा दिए जाने के साथ भी, यह हर वास्तविक मुद्दे के लिए लगभग 100 झूठी त्रुटियां देता है। कई अलग-अलग विश्लेषकों के साथ कोड की जांच करना एक अच्छा विचार है, क्योंकि उनमें सभी की त्रुटियां हैं। – Lundin
@ लुंडिन: बिलकुल। मैंने उल्लेख किया कि, हालांकि शायद जोर से नहीं। @ लेमल उपलब्ध टूल के बारे में जानना चाहता था, मुझे लगता है कि वह जानना चाहता है कि वह क्या सामना कर सकता है। अगर उसे इस तरह के एक उपकरण के चयन के साथ काम सौंपा गया था, तो वह एक अलग तरह का जवाब वारंट करेगा। – Clifford
यहाँ कुछ फर्मवेयर परीक्षण तकनीक जो मुझे उपयोगी ... पीसी पर
यूनिट परीक्षण कर रहे हैं; यानी, फर्मवेयर से फ़ंक्शन निकालें, और संकलित करें और इसे एक तेज़ प्लेटफ़ॉर्म पर परीक्षण करें। यह आपको उदाहरण के लिए, एक समारोह का पूरी तरह से परीक्षण करेगा, जबकि यह समय-समय पर सीटू में उपभोग करने वाला होगा।
फर्मवेयर एक मुक्त चलने वाले हार्डवेयर टाइमर का उपयोग करके हैंडलर को बाधित करता है: प्रवेश और निकास पर टिकता है, और इंटरप्ट की गणना करता है। प्रत्येक इंटरप्ट हैंडलर के लिए न्यूनतम और अधिकतम आवृत्ति और अवधि का ट्रैक रखें। इस डेटा का उपयोग रेट मोनोटोनिक विश्लेषण या डेडलाइन मोनोटोनिक विश्लेषण करने के लिए किया जा सकता है।
मांग पर उपलब्ध स्थिति डेटा की एक सरणी बनाने के लिए, मॉडबस आरटीयू जैसे मानक प्रोटोकॉल का उपयोग करें। इसका उपयोग कॉन्फ़िगरेशन और सत्यापन डेटा के लिए किया जा सकता है।
स्वचालित निर्माण प्रक्रिया का उपयोग कर फर्मवेयर संस्करण संख्या को कोड में बनाएं, उदाहरण के लिए, स्रोत कोड भंडार से संस्करण जानकारी प्राप्त करके। # 3 का उपयोग कर संस्करण संख्या उपलब्ध कराएं।
लिंट या अन्य स्थिर विश्लेषण उपकरण का उपयोग करें। लिंट से और कंपाइलर से -वॉल से शून्य चेतावनियों की मांग करें।
फर्मवेयर के सीआरसी को कोड में एम्बेड करने और इसे रनटाइम पर जांचने के साधनों के साथ अपने निर्माण उपकरण को बढ़ाएं।
की एक बड़ी संख्या के रूप में उपकरण मैं तनाव परीक्षणों उपयोगी पाया है कर रहे हैं । इसका आमतौर पर एक सिस्टम को थोड़े समय में बहुत अधिक इनपुट देना होता है और देखें कि यह इसे कैसे संभालता है। इनपुट
इस प्रकार के परीक्षण बहुत सारी चीजें निकाल सकते हैं (विशेष रूप से उन प्रणालियों में जहां प्रदर्शन महत्वपूर्ण और सीमित है)। तनाव परीक्षण द्वारा उठाए गए त्रुटियों के कारणों को ट्रैक करने के लिए एक अच्छी लॉगिंग प्रणाली भी अच्छी है।
मुझे एम्बेडेड-शैली के काम के लिए बहुत सारी नौकरी पोस्टिंग दिखाई देती हैं [jtag] (http://en.wikipedia.org/wiki/Joint_Test_Action_Group) डीबगिंग के साथ परिचित होना चाहते हैं। – sarnold
@ कर्नाल्ड: जेएफई स्वयं "परीक्षण उपकरण" नहीं है; यह केवल एक विकास मेजबान डीबगर और ऑन-चिप डीबग हार्डवेयर को शामिल करने वाला प्रोसेसर, महंगे बाहरी इन-सर्किट एमुलेटर हार्डवेयर की आवश्यकता से बचने, या कम मजबूत सॉफ्टवेयर आधारित रिमोट डीबग मॉनीटर के बीच भौतिक कनेक्शन और संचार को संदर्भित करता है। कोई भी जो इसे एक विशिष्ट नौकरी की आवश्यकता के रूप में रखता है, शायद इसकी सटीक समझ में आता है कि वास्तव में यह क्या है, और वास्तव में केवल हार्डवेयर डीबगर/आईसीई अनुभव सामान्य रूप से चाहता है। किसी भी तरह से मुझे नहीं लगता कि यह हाथ में सवाल के लिए बेहद प्रासंगिक है। – Clifford