इकाई परीक्षण के लिए परीक्षण मामलों को कैप्चर करने में कठोरता

आइए मान लें कि हमारे पास एक छद्म भाषा में परिभाषित एक सरल कार्य है।

List SortNumbers(List unsorted, bool ascending);

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

मेरे अनुभव में, कुछ लोग दूसरों की तुलना में सीमा की स्थिति को पकड़ने में बेहतर हैं। सवाल यह है, "आप कैसे जानते हैं कि जब आप परीक्षण मामलों को कैप्चर करते हैं तो" किया जाता है "?

हम अब मामलों को सूचीबद्ध करना शुरू कर सकते हैं और कुछ चालाक व्यक्ति निस्संदेह 'एक और' मामले के बारे में सोचेंगे जो किसी भी पिछले द्वारा कवर नहीं किया गया है।

0
ro fr bn
एक सरल, स्वयं निहित विधि के साथ, इसे Pex के माध्यम से चलाने का प्रयास करें। आप आश्चर्यचकित हो सकते हैं कि यह क्या मिल सकता है। research.microsoft.com/en-us/projects/pex
जोड़ा लेखक Dan Bryant, स्रोत

5 उत्तर

@Keith

मुझे लगता है कि आपने इसे दबाया है, यह देखने के लिए कोड कवरेज महत्वपूर्ण है कि आप देखना चाहते हैं कि "कैसे किया गया" है, लेकिन मुझे लगता है कि 100% थोड़ा अवास्तविक लक्ष्य है। 75-90% के लिए प्रयास करने से आपको ओवरबोर्ड पर जाने के बिना बहुत अच्छा कवरेज मिलेगा ... 100% मारने की शुद्ध खातिर परीक्षण न करें, क्योंकि उस समय आप अपना समय बर्बाद कर रहे हैं।

0
जोड़ा

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

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

0
जोड़ा

एक अच्छा कोड कवरेज उपकरण वास्तव में मदद करता है।

100% कवरेज का मतलब यह नहीं है कि यह निश्चित रूप से पर्याप्त रूप से परीक्षण किया जाता है, लेकिन यह एक अच्छा संकेतक है।

.Net NCover के लिए काफी अच्छा है, लेकिन अब खुला स्रोत नहीं है।


@ माइक स्टोन - हाँ, शायद यह "उच्च कवरेज" होना चाहिए था - हमारा लक्ष्य 80% न्यूनतम है, पिछले 9 5% से अधिक आमतौर पर रिटर्न कम हो जाता है, खासकर यदि आपके पास बेल्ट 'एन' ब्रेसिज़ कोड है।

0
जोड़ा

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

0
जोड़ा

आप कैसे जानते हैं कि जब आप टेस्ट केस कैप्चरिंग कर रहे हैं?

आप नहीं करते हैं। आप सबसे मामूली मामलों को छोड़कर 100% तक नहीं पहुंच सकते हैं। 100% कवरेज (लाइनों, पथों, शर्तों ...) आपको यह नहीं बताती कि आपने सभी सीमा शर्तों को मारा है।

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

ग्लेनफोर्ड जे द्वारा सॉफ़्टवेयर परीक्षण की कला का एक अंश मायर्स:

  1. यदि कोई इनपुट स्थिति मानों की एक श्रृंखला निर्दिष्ट करती है, तो सीमा के सिरों के लिए परीक्षण केस लिखें, और अस्थायी-इनपुट परीक्षण मामलों को केवल सिरों से परे स्थितियों के लिए लिखें।
  2. यदि कोई इनपुट स्थिति कई मान निर्दिष्ट करती है, तो न्यूनतम और अधिकतम संख्या के मानों के लिए टेस्ट केस लिखें और इन मानों के नीचे और नीचे।
  3. प्रत्येक आउटपुट स्थिति के लिए दिशानिर्देश 1 का उपयोग करें।
  4. प्रत्येक आउटपुट स्थिति के लिए दिशानिर्देश 2 का उपयोग करें।
  5. यदि किसी प्रोग्राम का इनपुट या आउटपुट सेट के पहले और अंतिम तत्वों पर ऑर्डर किए गए सेट पर ध्यान केंद्रित करता है।
  6. इसके अतिरिक्त, अन्य सीमा शर्तों की खोज करने के लिए अपनी सरलता का उपयोग करें

( मैंने कॉपीराइट कारणों से केवल न्यूनतम ही चिपकाया है। )

अंक 3. और 4. ऊपर बहुत महत्वपूर्ण हैं। लोग आउटपुट के लिए सीमा की स्थिति भूल जाते हैं। 5. ठीक है। 6. वास्तव में मदद नहीं करता है :-)

लघु परीक्षा

यह दिखने से कहीं अधिक कठिन है। मायर्स इस परीक्षा की पेशकश करता है:

प्रोग्राम इनपुट संवाद से तीन पूर्णांक मान पढ़ता है। तीन मान त्रिभुज के किनारों की लंबाई का प्रतिनिधित्व करते हैं। कार्यक्रम एक संदेश प्रदर्शित करता है जो बताता है कि त्रिभुज स्केलिन, आइसोसेलस या समतुल्य है।

     

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

अपने परीक्षण के मामलों को लिखें। तुम्हारे पास कितना है? मायर्स आपके टेस्ट सेट के बारे में 14 प्रश्न पूछते हैं और रिपोर्ट करते हैं कि अत्यधिक योग्य पेशेवर कार्यक्रम संभव 14 में से 7.8 औसत औसत हैं।

0
जोड़ा
QAIndia
QAIndia
160 प्रतिभागियों की

QA India ! Unite Here we share job postings , prepare for interviews and share tips/techniques in QA. Please follow following guideline while sharing any job ... QA job # location : # title Company : Title : Requirement: Responsibility: Apply: