14

एक बहुत छोटी टीम पर, जहां ब्लैक बॉक्स और व्हाइट बॉक्स का परीक्षण उसी व्यक्ति द्वारा किया जाता है, जिसे परीक्षक को पहले करना चाहिए?

testing

— नमक का खंभा
स्रोत

1

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

— क्रिस

11

जो भी हो सबसे सही होना चाहिए।

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

ब्लैक-बॉक्स परीक्षण (उपयोगकर्ता / सिस्टम इंटरफ़ेस के माध्यम से परीक्षण) आम तौर पर अधिकांश परीक्षक क्या करते हैं।

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

— बेरिन लोरिट्श
स्रोत

1

अच्छी तरह से कहा, सबसे अच्छा जवाब मैं इस प्रकार दूर पढ़ा।

— क्रिस

5

काली

सुविधाओं को सत्यापित करने के लिए ब्लैक-बॉक्स परीक्षण। यदि आवश्यक हो तो सफेद बॉक्स परीक्षण आवश्यक है। यदि सभी ब्लैक-बॉक्स परीक्षण पास हो जाते हैं और कवरेज अच्छा है, तो व्हाइट-बॉक्स परीक्षण अनावश्यक है।

— स्टीवन ए लोव
स्रोत

2

जब तक, निश्चित रूप से, ब्लैक बॉक्स परीक्षण कार्यक्षमता या कॉन्फ़िगरेशन के एक महत्वपूर्ण टुकड़े का परीक्षण करने से चूक गए:}

— एलन

3

@Alan: व्हाइट-बॉक्स परीक्षण के लिए भी यही तर्क लागू होता है, इसलिए 'कवरेज अच्छी है' चेतावनी

— स्टीवन ए। लोव

1

सहमत - मुझे लगता है कि मेरा कथन अच्छी कवरेज की आपकी परिभाषा पर निर्भर करता है।

— एलन

1

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

— साममी

1

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

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

3

ब्लैक बॉक्स।

व्हाइट बॉक्स घटक आमतौर पर ब्लैक बॉक्स घटकों पर निर्भर होते हैं, इसलिए मैं पहले ब्लैक बॉक्स का परीक्षण करना चाहूंगा और फिर सफेद बॉक्स पर आगे बढ़ूंगा।

— वाल्टर
स्रोत

2

मुझे यकीन नहीं है कि आप "ब्लैक बॉक्स घटकों" और "व्हाइट बॉक्स घटकों" से क्या मतलब है - मेरे लिए वे सिर्फ "घटक" हैं (जिन्हें अंतर्निहित कोड या आर्किटेक्चर के ज्ञान के साथ या बिना परीक्षण किया जा सकता है।

— एलन

मैं आपके द्वारा सुझाए गए "निर्भर" रिश्ते को नहीं समझता। सफेद काले और काले बॉक्स घटक नहीं हैं, एलन मेंशन के रूप में किसी भी घटक के परीक्षण की एक शैली का अधिक। अंतर प्रश्न में घटक का परीक्षण करने के लिए उठाए गए दृष्टिकोण में है।

— क्रिस

2

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

— एनरिक
स्रोत

2

यदि आप एक अच्छा परीक्षण चक्र रखना चाहते हैं, तो आपको अलग-अलग लोगों को दोनों करना चाहिए :

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

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

— जस्टिन एथियर
स्रोत

1

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

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

— एलन
स्रोत

1

मैं कहूंगा कि ब्लैक बॉक्स परीक्षण पहले, केवल क्योंकि TDD के एक प्रस्तावक के रूप में, परीक्षण कोड (या बॉक्स) से पहले लिखे जाते हैं…

व्हाइट बॉक्स परीक्षण (जहां तक मैं समझता हूं) डिबगिंग मानसिकता में अधिक उपयोगी है।

— मैथ्यू एम।
स्रोत

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

— डॉक ब्राउन

1

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

— मैथ्यू एम।

1

ब्लैक बॉक्स परीक्षण, क्योंकि आप कोड मौजूद होने से पहले परीक्षण लिख रहे हैं। परीक्षक को छोटी टीम पर कुशल होने के लिए डेवलपर लेखन कोड के साथ समानांतर में समय लेने वाली स्वचालित परीक्षण विकसित करने की आवश्यकता होती है।

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

— एथेल इवांस
स्रोत

0

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

मेरा लक्ष्य अच्छे परीक्षण लिखने पर ध्यान केंद्रित करना है, न कि कौन सा रंग पहले लिखना है।

— स्टीवन एवर्स
स्रोत

'व्हाइट' और 'ब्लैक' यूनिट परीक्षण की शर्तें नहीं हैं, इसलिए निश्चित रूप से आप इसके बारे में चिंता नहीं कर रहे हैं। यूनिट परीक्षण डी वास्तविक सफेद बॉक्स हैं।

— एथेल इवांस

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

— स्टीवन एवर्स

0

पहले यह सफेद बॉक्स परीक्षण करते हैं ।

दूसरा ब्लैक बॉक्स परीक्षण के लिए जाना।

> ब्लैक बॉक्स परीक्षण

I. परीक्षक को एप्लिकेशन के कार्यात्मक की जाँच करनी चाहिए, जैसे टेक्स्ट बॉक्स, रेडियो बटन, सूची बॉक्स, कमांड बटन, ... आदि। ,,।

द्वितीय। परीक्षक को आवेदन के गैर कार्यात्मक, ऐसे लोगो, छवि, वर्तनी, .. आदि की जांच करनी चाहिए। ,,।

तृतीय। परीक्षक को आवेदन के पूरे प्रवाह की जांच करनी चाहिए।

नोट: सकारात्मक और नकारात्मक स्थितियों की जांच करने के लिए।

ब्लैक बॉक्स या व्हाइट बॉक्स परीक्षण - जो आप पहले करते हैं?

काली