ब्लैक बॉक्स यूनिट परीक्षण क्या है?

Question

मैंने हाल ही में अपने मास्टर्स प्रोग्राम के लिए एक सॉफ्टवेयर इंजीनियरिंग कोर्स के लिए अपनी अंतिम परीक्षा दी थी और परीक्षा पर एक प्रश्न निम्नलिखित था:

Unit Testing is considered:
a. White-box Testing
b. Black-box Testing
c. Either

सॉफ्टवेयर विकास के मेरे 7 वर्षों के अनुभव में, यूनिट परीक्षण ने हमेशा एक सफेद बॉक्स दृष्टिकोण लिया है। परीक्षण लिखने के दौरान परीक्षक को हमेशा इकाई के कार्यान्वयन का पूर्ण ज्ञान होता है। ब्लैक बॉक्स परीक्षण हमेशा एकीकरण, प्रणाली और स्वीकृति परीक्षण के रूपों में बाद में आया।

हालांकि, परीक्षा (प्रोफेसर के अनुसार) का सही उत्तर यह है कि यूनिट परीक्षण या तो सफेद या ब्लैक बॉक्स परीक्षण हो सकता है।

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

क्या कोई मुझे समझा सकता है कि ब्लैक बॉक्स यूनिट परीक्षण कैसे काम करता है (यदि यह वास्तव में एक चीज है) और यह सफेद बॉक्स यूनिट परीक्षण से कैसे भिन्न होता है?

Comments

जब आपने उनसे इस बारे में पूछा तो प्रोफेसर ने इसे कैसे स्पष्ट किया? (यह भी देखें कि इंटरव्यू प्रश्न खराब सॉफ्टवेयर इंजीनियरिंग क्यों बनाते हैं।

— ईए

"जो कोई भी परीक्षा लिख ​​रहा है, उसके बारे में आम तौर पर बहुत अच्छा विचार है कि परीक्षा कैसे लागू की जा रही है" - यह इस बारे में नहीं है कि आप जानते हैं कि परीक्षा कैसे लागू की जाती है, लेकिन क्या आप जानते हैं (श्वेत) या नहीं (काला) कैसे बात है आप परीक्षण कर रहे हैं कार्यान्वित किया जाता है।

— जेस्पर

@ जेस्पर सॉरी। मेरे कहने का मतलब "सोर्स कोड कैसे लागू होने वाला है"। मैंने इसे प्रश्न में तय किया है।

— बैककैब

While the implementation does not yet exist, whoever is writing the test generally has a pretty good idea about how the source code is going to be implemented.- हाँ, लेकिन परीक्षण ही नहीं करता है। व्हाइट-बॉक्स परीक्षण का अर्थ है किसी विधि के आंतरिक या वर्ग का परीक्षण करना, जैसे कि एक चर का मान। इसका मतलब यह नहीं है कि परीक्षण लेखक जानता है कि परीक्षण के तहत कोड कैसा दिखता है।

— रॉबर्ट हार्वे

संबंधित, एक डुप्लिकेट के रूप में देखा जा सकता है: क्या TDD औपचारिक रूप से इकाई परीक्षणों के पूरक के लिए ब्लैक बॉक्स परीक्षण का उपयोग करता है

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

Answer 1

आपका प्रोफेसर सही है: इकाई परीक्षण या तो ब्लैक-बॉक्स या व्हाइट-बॉक्स हो सकता है। अंतर यह है कि परीक्षक क्या जानता है, इसके बारे में कम है, लेकिन आप परीक्षण मामलों को कैसे उत्पन्न करते हैं, इसके बारे में अधिक।

ब्लैक बॉक्स परीक्षण के साथ, आप केवल इंटरफ़ेस को देखते हैं और (यदि यह मौजूद है) एक घटक के लिए विनिर्देश। जब किसी फ़ंक्शन में हस्ताक्षर होते हैं int foo(int a, int b), तो मैं तुरंत दिलचस्प पूर्णांक का परीक्षण करके कुछ परीक्षण मामलों को उत्पन्न कर सकता हूं: शून्य, एक, शून्य से एक, बहु-अंक संख्या, INT_MAX, INT_MAX - 1 और इसी तरह। ब्लैक बॉक्स परीक्षण महान हैं क्योंकि वे कार्यान्वयन से स्वतंत्र हैं। लेकिन वे भी महत्वपूर्ण मामलों को याद कर सकते हैं।

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

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

Comments

"चूंकि एक सफेद-बॉक्स परीक्षण कार्यान्वयन से लिया गया है, यह केवल बाद में लिखा जा सकता है" - ठीक है, अगर मैं अगले नई सुविधा के लिए TDD शैली में एक असफल परीक्षण लिखने जा रहा हूं जिसे मैं अपने मौजूदा फ़ंक्शन या वर्ग में जोड़ना चाहता हूं , मैं वर्तमान कार्यान्वयन पर गौर करता हूं यह जानने के लिए कि अब तक क्या समर्थित नहीं है, इसलिए मैं अधिक सार्थक डिजाइन कर सकता हूं - शुरू में असफल - परीक्षण। मैं इसे परीक्षण-प्रथम व्हाइटबॉक्स दृष्टिकोण कहता हूं, न कि बाद में लिखा गया परीक्षण। (फिर भी, मुझसे +1)।

— Doc Brown

Answer 2

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

आखिरकार, जब आप एक परीक्षण लिखते हैं, तो आप क्या परीक्षण कर रहे हैं? सार्वजनिक तरीके / कार्य।

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

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

Consider टॉयलेट पर परीक्षण - टेस्ट बिहेवियर इम्प्लीमेंटेशन ’पर विचार करें , जिसमें किसी वर्ग के कार्यान्वयन को बदल दिया जाता है, लेकिन परीक्षण अभी भी मान्य होना चाहिए।

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

Comments

If you were to write the interface for a class, and then write the tests, and then you get hit by a bus, the guy who writes the class while you're in hospital should be able to do so from your interface, right?-- बिल्कुल नहीं। अधिकांश एपीआई अनुबंध वास्तव में केवल विधि हस्ताक्षर निर्दिष्ट करते हैं, न कि शब्दार्थ या व्यवहार।

— रॉबर्ट हार्वे

आप सही हे; मैंने इसे एक दिया के रूप में लिया है कि आपके इंटरफ़ेस में वह युक्ति शामिल होगी जिसमें से यह लिखा गया था, न कि केवल MyClassInterface का पाठ।

— एडमजेएस

@RobertHarvey यह सच है कि अधिकांश इंटरफेस स्पष्ट रूप से शब्दार्थ या व्यवहार का वर्णन नहीं करते हैं, लेकिन मुझे लगता है कि यह आम तौर पर निहित है। यदि यह नहीं था, तो कोड जिसे कुछ शब्दार्थों की आवश्यकता होती है, वह अमूर्तता पर निर्भर नहीं हो पाएगा। और टिप्पणी / docblocs के रूप में शब्दार्थ और व्यवहार के विवरण सहित इंटरफेस को रोकने के लिए कुछ भी नहीं है। उदाहरण के लिए देखें github.com/php-fig/http-message/blob/master/src/…

— bdsl

Answer 3

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

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

निष्कर्ष: यदि आप इकाई परीक्षणों के साथ सफेद बॉक्स परीक्षण करते हैं, तो आपके पास खराब निर्मित परीक्षण हैं। उन यूनिट परीक्षणों के साथ केवल बैक बॉक्स परीक्षण। आप प्रोफेसर सही हैं: यह या तो हो सकता है। लेकिन केवल अगर बुरी तरह से किया।

Answer 4

मैं सिर्फ यूनिट टेस्ट लिखने की प्रक्रिया में था जो ब्लैक-बॉक्स परीक्षण करता है। यही है, मैं एक कक्षा में सार्वजनिक विधियों का परीक्षण कर रहा हूं और परिणाम के तर्क का परीक्षण निजी तरीकों में करता हूं जिसे वे कहते हैं।

मैं यह करता हूं कि सार्वजनिक पद्धति के इनपुटों को बदलकर यूनिट परीक्षण किया जा रहा है और अपेक्षित आउटपुट का परीक्षण किया जा रहा है जो सहायक निजी तरीकों में तर्क द्वारा निर्धारित या उत्परिवर्तित हैं, जिसके कार्यान्वयन, मेरे "यूनिट परीक्षणों" के बारे में कुछ भी पता नहीं है।

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