परीक्षणों का परीक्षण कैसे करें?

Question

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

मैं परीक्षणों में तीन संभावित प्रकार की त्रुटियों के बारे में सोच सकता हूं:

1. तार्किक त्रुटियां, जब प्रोग्रामर हाथ में काम को गलत समझता है, और परीक्षण वह करता है जो उसने सोचा था कि उन्हें करना चाहिए, जो गलत है;

2. अंतर्निहित परीक्षण ढांचे में त्रुटियां (जैसे। एक टपका हुआ मॉकिंग अमूर्त);

3. परीक्षणों में कीड़े: परीक्षण उस प्रोग्रामर के विचार से थोड़ा अलग है जो वह करता है।

टाइप (1) त्रुटियों को रोकने के लिए असंभव प्रतीत होता है (जब तक कि प्रोग्रामर सिर्फ ... होशियार नहीं हो जाता)। हालाँकि, (2) और (3) ट्रैक्टेबल हो सकते हैं। आप इस प्रकार की त्रुटियों से कैसे निपटते हैं? क्या आपके पास उनसे बचने के लिए कोई विशेष रणनीति है? उदाहरण के लिए, क्या आप कुछ विशेष "खाली" परीक्षण लिखते हैं, जो केवल परीक्षण लेखक के अनुमानों की जांच करते हैं? इसके अलावा, आप एक टूटे हुए परीक्षण के मामले में डिबगिंग कैसे करते हैं

Comments

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

— कार्सन 63000

@ Carson63000 अगर यह एक साधारण परीक्षण है जो एक परीक्षण किए गए नकली के साथ कुछ परीक्षण कर रहा है , तो जटिलता विभाजित है और नियंत्रण में है (, मुझे लगता है)।

— mlvljr

लेकिन फिर आप परीक्षण परीक्षण कैसे करते हैं?

— 21

+1। आइटम 1 आवश्यकताओं में त्रुटि हो सकती है। केवल आवश्यकताओं की समीक्षा करके इसे रोका जा सकता है। प्रोग्रामर के हाथों से संभवतः बाहर जब तक कि वे भी आवश्यकताओं के विश्लेषक नहीं हैं

— मार्कजे

@ocodo: ठीक उसी तरह जिस तरह आप वॉचर्स देखते हैं। :)

— ग्रेग बरगद्ट

Answer 1

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

1. कुछ तकनीकें हैं जो आपको अपने कोड और परीक्षणों दोनों में समान बग को जोड़ने से रोकती हैं:

   1. ग्राहक को कार्यान्वयनकर्ता से अलग व्यक्ति होना चाहिए।
   2. पहले टेस्ट लिखें और फिर कोड (जैसे टेस्ट ड्रिवेन डेवलपमेंट)।

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

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

Comments

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

— रेज़्ज़र्ड स्ज़ोपा

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

— jwenting

Answer 2

व्यक्तिगत परीक्षणों को यथासंभव छोटा (छोटा) बनाने का प्रयास करें।

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

अंत में, यह शायद सिर्फ अनुभव की बात है। आप जितने अधिक परीक्षण लिखते हैं, आप उतने ही बेहतर बनते हैं, जितना कम मौका आपको भद्दे परीक्षण करने का होता है।

Comments

क्या होगा यदि परीक्षणों को कुछ जटिल सेटअप की आवश्यकता है? कभी-कभी इस प्रकार की चीजें आपके नियंत्रण में नहीं होती हैं।

— Ryszard Szopa

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

— हनीबल लेक्टर

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

— रिसजार्ड स्ज़ोपा

यदि प्रारंभिक स्थितियाँ सही नहीं हैं, तो आपका परीक्षण विफल हो जाना चाहिए, यही पूरा बिंदु है। जब राज्य में A, आप परिणाम की उम्मीद करते हैं B। यदि आपके पास राज्य नहीं है A, तो एक परीक्षण विफल होना चाहिए। उस बिंदु पर आप जांच कर सकते हैं कि यह विफल क्यों हुआ, खराब प्रारंभिक शर्तें या खराब परीक्षण, लेकिन यह दोनों मामलों में विफल होना चाहिए । यहां तक कि अगर यह है, जैसा कि आप कहते हैं, "थोड़ा बंद" (यानी "A" => "B", "a" => "b", लेकिन कभी नहीं "a" => "B"या अपने परीक्षण बुरा है)।

— हेनिबल लेक्टर

Answer 3

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

टेस्ट सूट की गुणवत्ता का परीक्षण करने के लिए एक अधिक संपूर्ण तरीका म्यूटेशन परीक्षण का उपयोग करना है ।

Comments

और यह कि आपका परीक्षण सही कारण से विफल हो जाता है ।

— फ्रैंक शियरर

@ फ्रांक - हाँ। मैं उसे उत्तर में जोड़ दूंगा।

— डॉन रॉबी

और आप नए व्यवहार के लिए एक नया परीक्षण जोड़ रहे हैं। मौजूदा परीक्षणों में न जोड़ें।

— Huperniketes 17

@DonRoby, क्या आपने उत्परिवर्तन परीक्षण को व्यवहार में उपयोगी पाया है? आपके परीक्षण के मामलों में आपको कौन सी कमियां मिली हैं?

— dzieciou

Answer 4

# 1 और # 3 के लिए: यूनिट परीक्षणों में कोई तर्क नहीं होना चाहिए, यदि आप करते हैं तो आप शायद अपने यूनिट टेस्ट में एक से अधिक चीजों का परीक्षण कर रहे हैं। यूनिट टेस्टिंग के लिए एक सबसे अच्छा अभ्यास केवल एक टेस्ट प्रति यूनिट टेस्ट है।

यूनिट टेस्ट को अच्छी तरह से लिखने के तरीके के बारे में अधिक जानने के लिए रॉय ओशेरोव द्वारा इस वीडियो को देखें ।

Comments

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

— रिसजार्ड स्ज़ोपा

जब आप कहते हैं कि 'थोड़ी गलत वस्तुएं' का मतलब है कि वस्तु स्थिति सही नहीं है या वस्तु का वास्तविक डिजाइन सही नहीं है? ऑब्जेक्ट स्थिति के लिए आप शायद इसकी वैधता की जांच करने के लिए परीक्षण लिख सकते हैं। यदि डिजाइन गलत है, तो परीक्षण में विफल होना चाहिए।

— पियर्स मायर्स

Answer 5

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

Answer 6

एक बिंदु होना चाहिए जब एक इकाई परीक्षण की कोशिश करना बंद कर देना चाहिए। पता होना चाहिए कि लाइन कब खींचनी है। क्या हमें परीक्षण मामलों का परीक्षण करने के लिए परीक्षण मामलों को लिखना चाहिए? परीक्षण मामलों के परीक्षण के लिए लिखे गए नए परीक्षण मामलों के बारे में क्या? हम उनका परीक्षण कैसे करेंगे?

if (0 > printf("Hello, world\n")) {
  printf("Printing \"Hello, world\" failed\n");
}

संपादित करें: टिप्पणी द्वारा सुझाए गए स्पष्टीकरण के साथ अपडेट किया गया।

Comments

-1 क्या? इसकी कोई प्रासंगिकता नहीं है।

— वैकल्पिक

एक बिंदु होना चाहिए जब एक इकाई परीक्षण की कोशिश करना बंद कर देना चाहिए। पता होना चाहिए कि लाइन कब खींचनी है। क्या हमें परीक्षण मामलों का परीक्षण करने के लिए परीक्षण मामलों को लिखना चाहिए? परीक्षण मामलों के परीक्षण के लिए लिखे गए नए परीक्षण मामलों के बारे में क्या? हम उनका परीक्षण कैसे करेंगे?

— aufather

प्रोसेस ब्रेन ने आपके बयान को एक्सट्रा करने की कोशिश करते हुए EInfiniteRecursion उठाया ...

— मेसन व्हीलर

अपने उत्तर को अपनी टिप्पणी से बदलें और आपको एक +1

— स्व पर ध्यान दें -

सभी निष्पक्षता में, आपका उदाहरण एक पुआल आदमी है। आप C लाइब्रेरी में प्रिंटफ़ () सबसिस्टम का परीक्षण कर रहे हैं, न कि प्रिंटफ़ () कॉल करने वाले वास्तविक प्रोग्राम का। हालांकि, मैं मानता हूं कि कुछ बिंदु पर परीक्षणों के पुनरावर्ती परीक्षण को तोड़ना चाहिए।

— टिम पोस्ट

Answer 7

अरे।
आपको आवेदन करना होगा:

• आपका उत्पाद
• उस उत्पाद के लिए आपका परीक्षण।

जब आप अपने उत्पाद के खिलाफ परीक्षण चला रहे होते हैं, तो आप वास्तव में परीक्षण में ही नहीं, बल्कि आपके उत्पाद और आपके परीक्षणों के बीच के अंतःक्रिया में होते हैं । यदि परीक्षण विफल रहता है तो यह नहीं कहता कि आवेदन में बग है। यह कहता है कि उत्पाद और परीक्षण के बीच बातचीत सफल नहीं थी । अब यह निर्धारित करना आपका काम है कि क्या गलत हुआ। यह या तो हो सकता है:

• एप्लिकेशन आपके द्वारा अपेक्षित व्यवहार नहीं कर रहा है (यह अपेक्षा आपके परीक्षण में व्यक्त की गई है)
• एप्लिकेशन सही ढंग से व्यवहार कर रहा है, आपने अभी इस व्यवहार को सही तरीके से प्रलेखित नहीं किया है (आपके परीक्षणों में)

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

टेस्ट केवल आवेदन के कुछ हिस्सों की जाँच कर रहे हैं। मैं आवेदन का परीक्षण करता हूं, मैं परीक्षण का परीक्षण करता हूं।

Answer 8

टेस्ट कीड़े को परेशान करने के लिए "स्मार्ट" नहीं होना चाहिए।

जिस कोड को आप लिख रहे हैं वह विनिर्देशों का एक सेट है। (यदि X तब Y, जब तक कि Z किस स्थिति में Q, आदि)। सभी परीक्षण को पूरा करने का प्रयास करना चाहिए यह निर्धारित करना है कि एक्स वास्तव में वाई है जब तक कि जेड किस स्थिति में नहीं है। इसका मतलब है कि सभी परीक्षण जो होना चाहिए वह है एक्स को सेट करना और वाई को सत्यापित करना।

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

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

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

TL: DR: यदि आपके परीक्षणों को परीक्षण की आवश्यकता है तो आप इसे गलत कर रहे हैं। गूंगा परीक्षण लिखें ।

Answer 9

उत्तर नहीं (मेरे पास टिप्पणी करने का विशेषाधिकार नहीं है), लेकिन सोच रहा था कि क्या आप परीक्षण मामलों को विकसित करने के अन्य कारणों को भूल गए हैं ...
एक बार जब आप परीक्षणों में सभी बगों का पता लगा लेते हैं, तो आप आसानी से अपने आवेदन का परीक्षण कर सकते हैं। एकीकरण से पहले, स्वचालित परीक्षण सूट आपको समस्याओं को खोजने में मदद करेंगे। आवश्यकताओं में बदलाव परीक्षण के लिए अपेक्षाकृत आसान है, क्योंकि परिवर्तन नए बन सकते हैं, पुराने परीक्षण मामलों के परिवर्तित संस्करण जो बीत जाते हैं, और पुराने मामले विफलताओं को उठाते हैं।

Answer 10

संक्षिप्त उत्तर: उत्पादन कोड परीक्षणों का परीक्षण करता है ।

इसकी तुलना अर्थशास्त्र में प्रयुक्त क्रेडिट / डेबिट मॉडल से करें। यांत्रिकी बहुत सरल हैं - यदि क्रेडिट डेबिट से अलग है तो कुछ गड़बड़ है।

वही इकाई परीक्षणों के लिए जाता है - यदि कोई परीक्षण विफल रहता है तो यह इंगित करता है कि कुछ गलत है। यह उत्पादन कोड हो सकता है, लेकिन यह परीक्षण कोड हो सकता है! यह पिछले भाग अगर महत्वपूर्ण

ध्यान दें कि आपके प्रकार (1) बग को यूनिट परीक्षणों द्वारा नहीं पाया जा सकता है। इस प्रकार के कीड़ों से बचने के लिए आपको अन्य उपकरणों की आवश्यकता होती है।