इकाई परीक्षण विकास या परीक्षण है?


24

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

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

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

  2. मुझे इकाई (सिस्टम) परीक्षक को इकाई और एकीकरण परीक्षणों की चौड़ाई और गहराई को संप्रेषित करने में कोई मूल्य नहीं दिखता है। मान लीजिए मैं एक रिपोर्ट लिखता हूं जो यह बताता है कि किसी विशेष व्यवसाय परत वर्ग पर किस प्रकार के यूनिट परीक्षण किए जाते हैं। वह क्या है / वह उससे दूर करने वाली है?

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

यह बेकार अकादमिक चर्चा की तरह लग सकता है, लेकिन यदि आप एक कड़ाई से औपचारिक वातावरण में काम करते हैं जैसा कि मैं करता हूं, यह वास्तव में यह निर्धारित करने में महत्वपूर्ण है कि हम चीजों को कैसे करते हैं। वैसे भी, क्या मैं पूरी तरह से गलत हूं?


9
फर्क पड़ता है क्या?
यानि

5
@YannisRizos शीर्षक से, नहीं। पूरे प्रश्न से, यह प्रमाणित होता है कि यह पूछने वाला व्यक्ति कितना कठोर है
लुडविग मैगनसन

2
@Rubio आपके प्रश्न से मैं सहमत हूँ कि यूनिट टेस्ट पर रिपोर्ट सिस्टम परीक्षक के लिए बेकार हैं। इकाई परीक्षण डेवलपर के लिए एक सहायक उपकरण है। आपका परीक्षण प्रबंधक इन रिपोर्टों की आवश्यकता को कैसे प्रेरित करता है?
लुडविग मैग्यूसन

2
@LudwigMagnusson सच है, हालांकि अगर यह केवल पूछने वाले व्यक्ति के लिए मायने रखता है , तो यह बहुत स्थानीय है।
यानि

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

जवाबों:


30

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

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

इसका मतलब है कि जिम्मेदारियां इस तरह होनी चाहिए:

  • डेवलपर्स स्वचालित परीक्षण लिखते हैं
  • डेवलपर्स अपने विकास वर्कफ़्लो के हिस्से के रूप में आवश्यकतानुसार व्यक्तिगत स्वचालित परीक्षण चलाते हैं
  • क्यूए परीक्षण के पहले चरणों में से एक के रूप में सभी स्वचालित परीक्षणों को चलाता है

यदि आपके पास एक बिल्ड सर्वर है, तो क्यूए का कार्य (स्वचालित परीक्षणों के बारे में) "सर्वर की बिल्ड रिपोर्ट खोलें और सत्यापित करें कि सब कुछ हरा है" पर फोड़ा जाता है।


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

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

आह हाँ, सहमत 100% एक चेकपॉइंट की तरह, क्या वे वहां हैं, क्या वे पास करते हैं, आदि
dardo

@ निर्माता - परीक्षण गुणवत्ता आश्वासन का केवल एक छोटा सा हिस्सा है।
मैथ्यू फ्लिन

2
उत्कृष्ट उत्तर, हालांकि मैं इस बात से सहमत नहीं हूं कि परीक्षणों को देखा जाना चाहिए an authoritative source of technical specifications। टेस्ट विनिर्देशों की पुष्टि होनी चाहिए, लेकिन निश्चित रूप से एक प्रतिस्थापन नहीं है। यह कहने के लिए नहीं है कि मैं बड़े अप फ्रंट स्पेस के लिए वकालत कर रहा हूं, बल्कि यह कि मैं यह भेद कर रहा हूं कि हम उन चीजों को मान्य करने के लिए परीक्षण लागू करें, जिनके बारे में हम जानते हैं कि सिस्टम को किस तरह से व्यवहार करना चाहिए, बजाय परीक्षण व्यवहार को परिभाषित करते हैं। एक पांडित्य भेद शायद, लेकिन फिर भी महत्वपूर्ण है।
रॉबिंस

10

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

अलग-अलग स्पष्टीकरण हो सकते हैं (जैसा कि कई उत्तरों द्वारा सुझाया गया है), जिसके लिए बहुत अलग रणनीतियों की आवश्यकता होती है।

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

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

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

7

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

इस कारण से, हमारी क्यूए टीम ने उन सभी की परवाह नहीं की जो परीक्षण करना शुरू करने से पहले क्या है और यूनिट परीक्षण नहीं किया है।

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


5

उन्होंने जोर देकर कहा कि देवों की रिपोर्ट है कि उनके पास इकाई और एकीकरण क्या है और कैसे।

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

मैंने स्कूल से ठीक पहले एक परीक्षण टीम में काम किया, इससे पहले कि मैं एक विकास की भूमिका में आया, और मैं देख सकता हूँ कि यह उसके और उसकी टीम के लिए कैसे मूल्यवान हो सकता है।


1
लेकिन चश्मा से ध्यान नहीं आना चाहिए? ऐसी परिस्थितियां होती हैं जब कोड परिवर्तन में अप्रत्याशित नतीजे होते हैं और फिर देव के लिए यह संवाद करना बहुत महत्वपूर्ण होता है कि परीक्षण को यह और यह भी कवर करना चाहिए।
Rubio

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

@Rubio: हाँ, लेकिन यदि आप TDD (यानी BDD) को ठीक से कर रहे हैं, तो आपके परीक्षण पहले स्थान के चश्मे के विरुद्ध होने चाहिए। यदि आपकी कंपनी वास्तव में प्रबुद्ध थी, तो परीक्षण टीम देव टीम के लिए परीक्षण लिख सकती थी।
gbjbaanb

2
क्या परीक्षण किया गया है: स्वचालित रूप से उत्पन्न कोड कवरेज रिपोर्ट। इसका परीक्षण कैसे किया जाता है: इकाई परीक्षण कोड पढ़ें। @ जीबीजैनब: "टेस्ट टीम देव टीम के लिए टेस्ट लिख सकती थी।" उस कथन के साथ बहुत सी गलत बातें हैं, मुझे नहीं पता कि कहां से शुरू करना है, सिवाय वेरी बैड आइडिया के
ब्रायन

5

मैं नहीं देखता कि यह बहुत ज्यादा मायने रखता है।

यदि आप उन्हें क्यूए / परीक्षण के लिए प्रदान नहीं करते हैं, और वे उचित परीक्षण नहीं करते हैं, और यह उत्पादन में विफल रहता है, तो यह क्यूए के माध्यम से इसे उत्पादन के रूप में निर्दिष्ट किए बिना काम करने देने में उनकी गलती है।

यदि आप उन्हें क्यूए / परीक्षण के लिए प्रदान करते हैं, और वे उचित परीक्षण नहीं करते हैं ... तो जैसे कि आपने उन्हें प्रदान नहीं किया था।

हालाँकि, यदि आप उन्हें प्रदान करते हैं, तो वे उनकी तुलना युक्ति से भी कर सकते हैं, और / या सुझाव दे सकते हैं कि कौन से परीक्षण त्रुटिपूर्ण हो सकते हैं, या उन्हें बदलने की आवश्यकता है क्योंकि उन्हें बग नहीं मिला।

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

देवता गलतियाँ करते हैं, क्यूए गलतियाँ करते हैं, आदर्श रूप से वे दोनों एक ही आइटम पर गलती नहीं करते हैं ... और यदि वे करते हैं ... यह संभवतः एक विश्लेषक है जिसने एक अस्पष्ट कल्पना लिखने वाली गेंद को गिरा दिया।


2
मेरे लिए नकारात्मक अतिरिक्त काम है जो कोई या कम मूल्य प्रदान नहीं करता है।
रुबियो

@Rubio, क्या अतिरिक्त काम? बस परिणाम का प्रिंट आउट लें। यदि उन्हें अच्छी तरह से नामित किया जाता है, तो यह उन्हें बताता है कि आप क्या परीक्षण कर रहे हैं। विधि को कैसे काम करता है इसका वास्तविक कोड या विवरण चाहिए। यदि वे करते हैं, तो वे इसे स्वयं देख सकते हैं।
कैफीक जुने

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

1
@Rubio - स्वचालन आपका मित्र है। आप एक निरंतर एकीकरण सर्वर सेट कर सकते हैं जो किसी भी समय चेकइन की रिपोर्ट करता है (यह आपको भी मदद करेगा)। यदि QA परीक्षण और कोड के स्पष्टीकरण का अनुरोध कर रहा है, तो ऐसा लगता है कि वे तर्कशीलता के स्तर से परे हो गए हैं और "अवधारणा को समझने में असफल" हैं। यदि वे कोड को पढ़ या नहीं सकते हैं, तो वे बेकार हैं। उस समय, आपके प्रबंधक के साथ एक चैट करना फायदेमंद होगा, और आप इसे बाहर रख सकते हैं, जैसे "क्यूए चाहता है कि मैं अपने समय का x% खर्च कर उन्हें कोड पढ़ने में मदद करूं, क्या यह ठीक है?"
ब्रायन

1
+1 यह कहने के लिए कि यह सॉफ़्टवेयर को स्वतंत्र रूप से परीक्षण करने के लिए क्यूए की जिम्मेदारी से वंचित नहीं है ।

2

यूनिट परीक्षण डेवलपर्स की जिम्मेदारी है कि यह समझने के लिए परीक्षण उपयोगी हो सकते हैं कि कोड के टुकड़े अपने आप कैसे काम करते हैं। कुछ इसे दस्तावेज़ीकरण के रूप में देख सकते हैं और इस प्रकार कुछ मूल्य हैं हालांकि यूनिट परीक्षण नियमित रूप से बदलने पर ओवरहेड हो सकता है।

परीक्षणों को पारित करने में अन्य मूल्य यह है कि यह उन परीक्षणों पर दोहरीकरण से बच सकता है जो बुनियादी कार्यक्षमता सुनिश्चित करने के मामले में निरर्थक हो सकते हैं।

उपयोगकर्ता स्वीकृति परीक्षण भी है जो इस सब से अलग है क्योंकि अंतिम उपयोगकर्ता की अपनी समझ हो सकती है कि सिस्टम कैसे कार्य करता है।


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

2

यदि आपकी कंपनी के पास अपने उत्पादों की गुणवत्ता सुनिश्चित करने के लिए एक परिभाषित पद्धति है (यदि वे SOX आज्ञाकारी हैं, या अपने CMMI स्तर में सुधार करने की कोशिश कर रहे हैं, तो वे शायद ऐसा करते हैं), तो उत्पादों को यह दिखाने के लिए ऑडिट करने में सक्षम होना चाहिए कि प्रक्रिया पीछा किया गया था।

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

सोनार जैसे उपकरण को देखें ताकि आपकी सहायता की जा सके - यह कोड कवरेज के स्तर और आपकी इकाई परीक्षण के परिणामों को रिपोर्ट करेगा।


SOX नहीं, CMMI हाँ। हमारी इकाई / एकीकरण परीक्षण कोड समीक्षा प्रक्रिया का हिस्सा हैं और यह ऑडिट के लिए खड़ा है। मैं एक यूनिट / इंटीग्रेशन टेस्ट रन से उत्पन्न रिपोर्ट प्राप्त कर सकता हूं, लेकिन एक परीक्षक के लिए यह बहुत ही गूढ़ है। कवरेज भी रिपोर्ट में है, लेकिन अपने आप में इसका मतलब कुछ भी नहीं है।
Rubio

सबसे पहले, अपने परीक्षणों को गुप्त नाम न दें। की जाँच करें dannorth.net/introducing-bdd । दूसरा, कोड कवरेज परीक्षणों की गुणवत्ता के बारे में बहुत कुछ नहीं कह सकता है, लेकिन यह कम से कम दिखाता है कि परीक्षण की जा रही इकाइयां कोड के सभी के लिए सबसे अधिक चलने पर कोई झटका नहीं देती हैं।
मैथ्यू फ्लिन

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

2

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

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

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


1

मुझे लगता है कि इस प्रकार की चीज प्रदान करना फायदेमंद होगा। यूनिट टेस्ट कवरेज कुछ ऐसी होनी चाहिए जो विकास और परीक्षण द्वारा जानी जाती है ताकि वे उसके लिए जिम्मेदार हो सकें।

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


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

1

यह पुस्तक "हाउ गूगल टेस्ट सॉफ़्टवेयर" में चर्चा किए गए दृष्टिकोण का उल्लेख करने योग्य है: परीक्षण और गुणवत्ता नियंत्रण हर किसी की जिम्मेदारी है, और मानक कठोर हैं।

पारंपरिक रूप से जिसे "परीक्षण" विभाग कहा जाता है, की वास्तविक भूमिका वास्तव में डेवलपर उत्पादकता है; आर्थिक रूप से कठोर स्तर तक संगठन को सक्षम बनाने के लिए ऑटोमेशन यानी स्वचालन।

हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.