सख्त अर्थों में, परीक्षण सूट की गुणवत्ता स्थापित होने तक कोई भी दावा करना उचित नहीं है। यदि परीक्षणों में से अधिकांश एक-दूसरे के साथ तुच्छ या दोहराव वाले हों, तो शत-प्रतिशत परीक्षण पास करना सार्थक नहीं है।
सवाल यह है: परियोजना के इतिहास में, उन परीक्षणों में से किसी ने बग को उजागर किया? एक परीक्षण का लक्ष्य बग ढूंढना है। और अगर वे नहीं करते थे, तो वे परीक्षण के रूप में विफल रहे। कोड की गुणवत्ता में सुधार के बजाय, वे केवल आपको सुरक्षा की झूठी भावना दे सकते हैं।
परीक्षण डिज़ाइनों को बेहतर बनाने के लिए, आप (1) व्हाइटबॉक्स तकनीकों, (2) ब्लैकबॉक्स तकनीकों और (3) उत्परिवर्तन परीक्षण का उपयोग कर सकते हैं।
(1) आपके परीक्षण डिजाइनों पर लागू करने के लिए कुछ अच्छी व्हाइटबॉक्स तकनीकें यहां दी गई हैं। एक व्हाइटबॉक्स परीक्षण का निर्माण विशिष्ट स्रोत कोड को ध्यान में रखकर किया जाता है। व्हाइटबॉक्स परीक्षण का एक महत्वपूर्ण पहलू कोड कवरेज है:
- हर फंक्शन कहा जाता है? [कार्यात्मक कवरेज]
- क्या हर बयान पर अमल होता है? [कथन कवरेज-- कार्यात्मक कवरेज और स्टेटमेंट कवरेज दोनों ही बहुत बुनियादी हैं, लेकिन कुछ भी नहीं से बेहतर]
- प्रत्येक निर्णय (जैसे
ifया while) के लिए, क्या आपके पास एक परीक्षण है जो इसे सच होने के लिए मजबूर करता है, और अन्य जो इसे गलत होने के लिए मजबूर करते हैं? [निर्णय कवरेज]
- प्रत्येक स्थिति के लिए जो एक संयुग्मन (उपयोग करता है
&&) या अव्यवस्था (उपयोग करता है ||) है, क्या प्रत्येक उपप्रकार का एक परीक्षण होता है जहां यह सच है या गलत है? [स्थिति कवरेज]
- लूप कवरेज: क्या आपके पास एक परीक्षण है जो 0 पुनरावृत्तियों, 1 पुनरावृत्ति, 2 पुनरावृत्तियों को मजबूर करता है?
- क्या प्रत्येक
breakलूप से कवर किया गया है?
(2) आवश्यकताएं उपलब्ध होने पर ब्लैकबॉक्स तकनीकों का उपयोग किया जाता है, लेकिन कोड स्वयं नहीं है। ये उच्च-गुणवत्ता परीक्षण कर सकते हैं:
- क्या आपके ब्लैकबॉक्स परीक्षण कई परीक्षण लक्ष्यों को कवर करते हैं? आप चाहते हैं कि आपके परीक्षण "मोटे" हों: न केवल वे फीचर एक्स का परीक्षण करते हैं, बल्कि वे वाई और जेड का भी परीक्षण करते हैं। विभिन्न विशेषताओं की परस्पर क्रिया बग को खोजने का एक शानदार तरीका है।
- एकमात्र मामला जिसे आप "वसा" परीक्षण नहीं चाहते हैं, जब आप एक त्रुटि स्थिति का परीक्षण कर रहे हैं। उदाहरण के लिए, अमान्य उपयोगकर्ता इनपुट के लिए परीक्षण। यदि आपने कई अमान्य इनपुट परीक्षण लक्ष्यों (उदाहरण के लिए, एक अमान्य ज़िप कोड और एक अमान्य सड़क पता) को प्राप्त करने का प्रयास किया है, तो संभावना है कि एक मामला दूसरे को मास्क कर रहा है।
- इनपुट प्रकारों पर विचार करें और इनपुट के प्रकारों के लिए "समतुल्यता वर्ग" बनाएं। उदाहरण के लिए, यदि आपका कोड यह देखने के लिए परीक्षण करता है कि क्या त्रिभुज समबाहु है, तो परीक्षण जो पक्षों के साथ एक त्रिकोण का उपयोग करता है (1, 1, 1) संभवतः उसी प्रकार की त्रुटियां पाएंगे जो परीक्षण डेटा (2, 2, 2) और (3, 3, 3) मिलेगा। इनपुट के अन्य वर्गों के बारे में सोचकर अपना समय बिताना बेहतर है। उदाहरण के लिए, यदि आपका कार्यक्रम करों को संभालता है, तो आप प्रत्येक टैक्स ब्रैकेट के लिए एक परीक्षण चाहते हैं। [इसे समतुल्य विभाजन कहते हैं।]
- विशेष मामले अक्सर दोषों से जुड़े होते हैं। आपके परीक्षण डेटा में सीमा मूल्य भी होना चाहिए, जैसे कि समतुल्य कार्य के किनारों पर, ऊपर या नीचे। उदाहरण के लिए, एक छँटाई एल्गोरिथ्म का परीक्षण करने में, आप एक खाली सरणी, एक एकल तत्व सरणी, दो तत्वों के साथ एक सरणी और फिर एक बहुत बड़ी सरणी के साथ परीक्षण करना चाहेंगे। आपको न केवल इनपुट के लिए, बल्कि आउटपुट के लिए भी सीमा मामलों पर विचार करना चाहिए। [यह कॉल सीमा-मूल्य विश्लेषण है।]
- एक और तकनीक है "त्रुटि अनुमान लगाना।" क्या आपके पास कुछ विशेष संयोजन का प्रयास करने की भावना है जो आप अपने कार्यक्रम को तोड़ने के लिए प्राप्त कर सकते हैं? तो बस कोशिश करो! याद रखें: आपका लक्ष्य बग ढूंढना है, यह पुष्टि करने के लिए नहीं कि कार्यक्रम वैध है । कुछ लोगों को त्रुटि अनुमान लगाने की आदत है।
(3) अंत में, मान लीजिए कि आपके पास पहले से ही व्हाइटबॉक्स कवरेज के लिए बहुत सारे अच्छे परीक्षण हैं, और लागू ब्लैकबॉक्स तकनीकें हैं। आप और क्या कर सकते हैं? यह आपके टेस्ट का परीक्षण करने का समय है । एक तकनीक जिसे आप उपयोग कर सकते हैं वह है म्यूटेशन टेस्टिंग।
बग के निर्माण की उम्मीद में, म्यूटेशन टेस्टिंग के तहत, आप अपने प्रोग्राम में (प्रति की) एक संशोधन करते हैं। एक उत्परिवर्तन हो सकता है:
एक चर के संदर्भ को दूसरे चर में बदलें; एब्स डालें () फ़ंक्शन; कम-से-अधिक से अधिक-से बदलें; एक बयान को हटा दें; एक स्थिर के साथ एक चर बदलें; ओवरराइडिंग विधि को हटा दें; एक सुपर विधि का संदर्भ हटाएं; तर्क क्रम बदलें
अपने कार्यक्रम में विभिन्न स्थानों पर कई दर्जन म्यूटेंट बनाएं [कार्यक्रम को परीक्षण करने के लिए अभी भी संकलन करने की आवश्यकता होगी]। यदि आपके परीक्षणों में ये बग नहीं पाए जाते हैं, तो अब आपको एक परीक्षण लिखने की आवश्यकता है जो आपके प्रोग्राम के उत्परिवर्तित संस्करण में बग को ढूंढ सकता है। एक बार बग का परीक्षण करने के बाद, आपने उत्परिवर्ती को मार दिया है और दूसरा प्रयास कर सकते हैं।
परिशिष्ट : मैं इस प्रभाव का उल्लेख करना भूल गया था: कीड़े क्लस्टर करते हैं । इसका मतलब यह है कि एक मॉड्यूल में जितने अधिक कीड़े हैं, उतनी ही अधिक संभावना है कि आपको अधिक बग मिलेंगे। इसलिए, यदि आपके पास एक परीक्षण है जो विफल रहता है (जो कहना है, परीक्षण सफल है, क्योंकि लक्ष्य बग ढूंढना है), न केवल आपको बग को ठीक करना चाहिए, बल्कि आपको मॉड्यूल के लिए और अधिक परीक्षण भी लिखना चाहिए, तकनीकें ऊपर।
जब तक आप एक स्थिर दर पर कीड़े पा रहे हैं, परीक्षण के प्रयास जारी रखने चाहिए। केवल तभी जब नए कीड़ों की दर में गिरावट देखी गई है, आपको विश्वास होना चाहिए कि आपने विकास के उस चरण के लिए अच्छे परीक्षण प्रयास किए हैं।