यूनिट परीक्षण और स्वीकृति परीक्षण पर्याप्त हैं?

Question

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

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

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

Answer 1

मैं 2nd edition of Code Complete में अध्याय 20 - 22 पढ़ने की अनुशंसा करता हूं। इसमें सॉफ्टवेयर की गुणवत्ता बहुत अच्छी तरह से शामिल है।

• कोई भी दोष का पता लगाने तकनीक पूरी तरह से प्रभावी है: सॉफ्टवेयर गुणवत्ता लैंडस्केप -

  यहाँ कुछ प्रमुख बिंदुओं का शीघ्र विश्लेषण (सभी क्रेडिट, मैककोनेल को जाता है 2004)

  Chapter 20 है खुद

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

Chapter 21 - सहयोगात्मक निर्माण:

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

Chapter 22 - डेवलपर परीक्षण:

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

को घटा

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

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

Answer 2

कई परीक्षण चक्रों का विचार समस्या को बदलने के दौरान जितनी जल्दी हो सके समस्याओं को पकड़ना है।

इकाइयों को यह सुनिश्चित करने के लिए डेवलपर्स द्वारा यूनिट परीक्षण किया जाना चाहिए ताकि इकाइयों अलगाव में काम कर सकें।

सिस्टम द्वारा आवश्यकताओं को पूरा करने के लिए ग्राहक द्वारा स्वीकृति परीक्षण किया जाना चाहिए।

हालांकि, उन दो बिंदुओं के बीच कुछ बदल गया है जिनका परीक्षण भी किया जाना चाहिए। क्लाइंट को दिए जाने से पहले यह उत्पाद में इकाइयों का एकीकरण है।

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

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

हम नहीं करते हैं, तो उन्हें केवल एक डोडी उत्पाद देना चाहते हैं क्योंकि उस चरण में एक बग फिक्स करना बहुत महंगा है (विशेष रूप से प्रशासन के मामले में) जो कुछ भी हम घर में करते हैं।

Answer 3

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

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

Answer 4

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

Answer 5

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

नहीं टेस्ट केवल सत्यापित कर सकते हैं कि आपने क्या सोचा है। ऐसा नहीं है जिसे आपने नहीं सोचा है।

Answer 6

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

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

Answer 7

संक्षिप्त संख्या में।

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

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

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

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

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

अंत में, उपयोगकर्ता स्वीकृति परीक्षण (यूएटी) है। रिलीज से पहले समग्र प्रणाली का परीक्षण करने के लिए ये उत्पादन मालिक/व्यापार भागीदार द्वारा डिजाइन किए गए परीक्षण हैं। आम तौर पर, अन्य सभी परीक्षणों के कारण, एप्लिकेशन के लिए यूएटी के दौरान शून्य दोषों को वापस करने के लिए असामान्य नहीं है।

Answer 8

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

हालांकि, यदि आपका उत्पाद अन्य स्तरों (जैसे बैकएंड मिडलवेयर/डेटाबेस) पर निर्भर करता है तो आपको एक परीक्षण की आवश्यकता होती है जो साबित करता है कि आपका उत्पाद खुशी से अंत तक लिंक कर सकता है।

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

ग्राहक और/या परीक्षण के लिए लगातार प्रतिक्रिया लूप जो ग्राहक समझते हैं (BDD style में उदाहरण के लिए कहें) वास्तव में मदद कर सकते हैं।

Answer 9

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

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

यह भी ध्यान देने योग्य है कि परीक्षण के विभिन्न सेट उत्पाद/कोड को एक अलग "दृष्टिकोण" से परीक्षण करते हैं। वैसे ही क्यूए उन बगों को उठा सकता है जिन्हें कभी परीक्षण नहीं किया जाता है, परीक्षणों का एक सेट अन्य चीजों को नहीं ढूंढ सकता है।

Answer 10

अगर मैं प्रत्येक वर्ग और/या सदस्य समारोह और स्वीकृति परीक्षण हर उपयोगकर्ता कहानी के लिए के लिए इकाई परीक्षण है मैं अपेक्षा के अनुरूप परियोजना कार्यों सुनिश्चित करने के लिए पर्याप्त परीक्षण के लिए है?

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

Answer 11

शायद नहीं, जब तक कि आपका सॉफ्टवेयर वास्तव में सरल नहीं है, और केवल एक घटक है।

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

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

तुम भी परीक्षण के निम्नलिखित प्रकार है, जो आम तौर पर परीक्षकों द्वारा लिखा जाता है पर विचार करना चाहिए:

• कार्यात्मक परीक्षण है, जो कार्यक्षमता के टुकड़े को कवर किया जाएगा। इसमें एपीआई परीक्षण और घटक-स्तर परीक्षण शामिल हो सकता है। आप आमतौर पर यहां अच्छे कोड-कवरेज भी चाहते हैं।
• एकीकरण परीक्षण, जो एक साथ काम करने के लिए दो या दो से अधिक घटकों को एक साथ रखता है। आप नहीं चाहते कि एक घटक सरणी में स्थिति डालने के लिए जहां ऑब्जेक्ट (0-आधारित) है, अन्य घटक ऑब्जेक्ट की गणना ("nth object", जो 1-आधारित है) की अपेक्षा करता है, उदाहरण के लिए। यहां, फोकस कोड कवरेज पर नहीं है बल्कि घटकों के बीच इंटरफेस (सामान्य इंटरफेस, कोड इंटरफेस नहीं) के कवरेज पर है।
• सिस्टम-स्तरीय परीक्षण, जहां आप सबकुछ एक साथ रखते हैं और सुनिश्चित करते हैं कि यह अंत तक काम करता है।
• निष्पादन, विश्वसनीयता, स्केलेबिलिटी, सुरक्षा, और उपयोगकर्ता-मित्रता जैसे गैर-कार्यात्मक विशेषताओं के लिए परीक्षण (अन्य हैं, सभी हर परियोजना से संबंधित नहीं होंगे)।

Answer 12

यदि प्रणाली हाथ में है तो स्वीकार्य परीक्षण क्लाइंट द्वारा मैन्युअल रूप से भी किया जा सकता है।

इकाई और छोटे एकीकरण परीक्षण (परीक्षण जैसे इकाई शामिल हैं) आपके लिए टिकाऊ प्रणाली बनाने के लिए हैं।

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

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