16

क्या बेहतर है कि या तो ए

नियतात्मक परीक्षण सूट, एक ही परीक्षण सफल होने का परिणाम है
गैर-निर्धारक परीक्षण सूट, जो संभवतः संभवतः अधिक मामलों को कवर करता है

?

उदाहरण: आप MVC अनुप्रयोग में नियंत्रक कार्यक्षमता का परीक्षण करने के लिए एक परीक्षण सूट लिखते हैं। नियंत्रक को परीक्षण के दौरान इनपुट के रूप में डेटाबेस से एप्लिकेशन डेटा की आवश्यकता होती है। ऐसा करने के लिए दो विकल्प हैं:

आप परीक्षण डेटाबेस से किस पंक्ति (रों) को इनपुट के रूप में चुना जाता है (जैसे 10 वीं और 412 वीं पंक्ति)
आप डेटाबेस से डेटा लेने के लिए एक यादृच्छिक संख्या जनरेटर का उपयोग करते हैं, डेटाबेस से डेटा उठाते हैं (एक यादृच्छिक संख्या जनरेटर द्वारा चयनित दो पंक्तियाँ)

पहला निर्धारक है: कोड के एक ही संशोधन के लिए परीक्षण के प्रत्येक रन को एक ही परिणाम प्राप्त करना चाहिए। दूसरा गैर-निर्धारक है: परीक्षण सूट के प्रत्येक रन में एक अलग परिणाम प्राप्त करने की संभावना है। बेतरतीब ढंग से उठाया गया डेटा हालांकि डेटा एज मामलों का बेहतर प्रतिनिधित्व हो सकता है। यह एक उपयोगकर्ता को अप्रत्याशित डेटा के साथ हमारे नियंत्रकों को बेहतर तरीके से खिलाने का अनुकरण कर सकता है?

एक के बाद दूसरे को चुनने के क्या कारण हैं?

testing mvc

— DCKing
स्रोत

5

वह परीक्षा कभी-कभी असफल हो जाती है। martinfowler.com/articles/nonDeterminism.html

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

— DCKing

2

पढ़ने की सिफारिश की: क्यों "सबसे अच्छा अभ्यास" एक बुरी बात पर एक सवाल पूछ रहा है?

— gnat

10

@DCKing: विचार करें कि क्या होता है यदि आपका परीक्षण विफल हो जाता है। ठीक है, आपके पास एक बग है। उह, अब क्या? इसे फिर से डिबग मोड में चलाएं! जहाँ यह सफल होता है! जैसे कि यह अगले सौ बार आप इसे चलाते हैं, और फिर आप इस मुद्दे को लौकिक किरण हड़ताल के रूप में लिखते हैं। परीक्षणों में गैर-नियतांक बिल्कुल अटूट लगता है। यदि आप अपने परीक्षण मामलों में अधिक जमीन को कवर करने की आवश्यकता महसूस करते हैं, तो अधिक जमीन को कवर करें। अपने RNG को एक निर्धारित बीज के साथ सम्मिलित करें और लगातार यादृच्छिक मूल्यों के साथ "परीक्षण" को कुछ सौ बार चलाएं।

— फिशी

1

(अंत में एक मशीन के आसपास मिला, जहां मैं ट्विटर को ठीक से खोज सकता था - " वह परीक्षण कभी-कभी विफल हो जाता है " ट्विटर पर

30

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

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

संपादित करें: कुछ परीक्षण डेटा लेने के लिए एक यादृच्छिक संख्या जनरेटर का उपयोग करना IMHO कभी-कभी अच्छा परीक्षण डेटा चुनने के बारे में बहुत आलसी होने के लिए एक संकेत है । 100,000 बेतरतीब ढंग से चुना हुआ मान फेंकने के बजाय और उम्मीद करें कि यह संयोग से सभी गंभीर कीड़े खोजने के लिए पर्याप्त होगा, अपने मस्तिष्क का बेहतर उपयोग करें, 10 से 20 "दिलचस्प" मामलों को चुनें, और उन्हें परीक्षण सूट के लिए उपयोग करें। यह न केवल आपके परीक्षणों की बेहतर गुणवत्ता का परिणाम देगा, बल्कि सूट के बहुत उच्च प्रदर्शन में भी होगा।

— डॉक्टर ब्राउन
स्रोत

आपके उत्तर के लिए धन्यवाद। मेरे प्रश्न पर की गई टिप्पणी पर आपकी क्या राय है?

— DCKing

1

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

— डॉक ब्राउन

एक बार फिर धन्यवाद। मेरे उत्तर को अपडेट किया ताकि यह सिर्फ MVC ऐप पर लागू न हो।

— DCKing

1

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

— रोबोट को

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

— डॉक्टर ब्राउन

4

नियतात्मक और गैर-निर्धारक दोनों का एक स्थान होता है

मैं उन्हें इस प्रकार विभाजित करूंगा:

यूनिट परीक्षण।

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

कार्यात्मक और इनपुट तनाव परीक्षण।

ये निम्नलिखित केवतों के साथ गैर-नियतात्मक दृष्टिकोण का उपयोग कर सकते हैं:

इस तथ्य को स्पष्ट रूप से चित्रित किया गया है और बाहर बुलाया गया है
चयनित यादृच्छिक मान लॉग किए गए हैं और उन्हें मैन्युअल रूप से पुन: आज़माया जा सकता है

— माइकल डुरंट
स्रोत

3

दोनों।

नियतात्मक और nondeterministic परीक्षणों में आपके सूट के लिए अलग-अलग उपयोग के मामले और विभिन्न मूल्य हैं। आमतौर पर नॉन्डेटेरिमिनिस्टिक नियतात्मक परीक्षण के समान सटीकता प्रदान नहीं कर सकता है, जो धीरे-धीरे "नॉन्डेटेरमिनिस्टिक परीक्षण में कोई मूल्य नहीं प्रदान करता है।" यह गलत है। वे कम सटीक हो सकते हैं, लेकिन वे बहुत व्यापक भी हो सकते हैं, जिनके अपने फायदे हैं।

एक उदाहरण लेते हैं: आप एक फ़ंक्शन लिखते हैं जो पूर्णांकों की सूची को सॉर्ट करता है। नियतात्मक इकाई परीक्षणों में से कुछ क्या होगा जो आप उपयोगी पाएंगे?

एक खाली सूची
सिर्फ एक तत्व के साथ एक सूची
एक ही तत्व के सभी के साथ एक सूची
एकाधिक अद्वितीय तत्वों के साथ एक सूची
कई तत्वों के साथ एक सूची, जिनमें से कुछ डुप्लिकेट हैं
एक सूची के साथ NaN, INT_MINऔरINT_MAX
एक सूची जो पहले से ही आंशिक रूप से क्रमबद्ध है
10,000,000 तत्वों के साथ एक सूची

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

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

अपने कोड में बग ढूंढने के लिए nondeterministic परीक्षण का उपयोग करें ।
अपने कोड में सुधारों को सत्यापित करने के लिए निर्धारक परीक्षणों का उपयोग करें ।

ध्यान दें कि इसका मतलब है इकाई परीक्षणों के बारे में बहुत सी ठोस सलाह जरूरी नहीं कि वे nondeterministic परीक्षण पर लागू हों। उदाहरण के लिए, कि वे तेज होना चाहिए। निम्न-स्तरीय संपत्ति परीक्षण तेज़ होना चाहिए, लेकिन "उपयोगकर्ता द्वारा आपकी वेबसाइट पर बेतरतीब ढंग से क्लिक किए गए बटन का अनुकरण करना और सुनिश्चित करें कि आपको कभी भी 500 त्रुटि प्राप्त न हो" जैसे एक nondeterministic परीक्षण को गति पर व्यापकता का पक्ष लेना चाहिए। बस एक परीक्षण है कि अपनी निर्माण प्रक्रिया के स्वतंत्र रूप से चलाएं ताकि यह विकास धीमा न हो। उदाहरण के लिए, इसे अपने निजी स्टेजिंग बॉक्स पर चलाएं।

— Hovercouch
स्रोत

-1

आप वास्तव में निर्धारक बनाम गैर-नियतात्मक नहीं चाहते हैं।

आप जो चाहते हैं वह "हमेशा समान" बनाम "हमेशा समान नहीं" हो सकता है।

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

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

— gnasher729
स्रोत

1

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

— रेमकोगर्लिच

परीक्षण: नियतात्मक या गैर-नियतात्मक?

नियतात्मक और गैर-निर्धारक दोनों का एक स्थान होता है

मैं उन्हें इस प्रकार विभाजित करूंगा:

यूनिट परीक्षण।

कार्यात्मक और इनपुट तनाव परीक्षण।

दोनों।