2008-10-30 15 views
6

मुझे सिखाया गया था कि एक रिग्रेशन टेस्ट एक छोटा था (केवल यह साबित करने के लिए पर्याप्त था कि आपने परिवर्तन या नए मॉड्यूल के परिचय के साथ कुछ तोड़ नहीं दिया) समग्र परीक्षणों का नमूना। हालांकि, this article रॉन मॉरिसन और ग्रेडी बूच से मुझे अलग तरह से सोचने बनाता है:क्या रिग्रेशन पूरे टेस्ट सूट या परीक्षणों का नमूना परीक्षण करता है?

वांछित रणनीति एक समय में एक में प्रत्येक इकाई लाने के लिए एक व्यापक प्रतिगमन परीक्षण, कोई दोष दुरुस्त करने के बाद अगले करने के लिए आगे बढ़ना होगा इकाई।

ही दस्तावेज़ भी कहते हैं:

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

जब धुआं परीक्षण का वर्णन, लेखकों का कहना है कि इस:

यह भी महत्वपूर्ण है कि धुआँ टेस्ट पूरे सिस्टम की एक त्वरित जांच ही नहीं, नए घटक (रों) प्रदर्शन करते हैं।

मैंने कभी भी "व्यापक" और "प्रतिगमन परीक्षण" को कभी भी नहीं देखा है और न ही एक रिग्रेशन टेस्ट जिसे "संपूर्ण प्रणाली पूरी तरह से प्रतिक्रिया प्रणाली" के रूप में वर्णित किया गया है। रिग्रेशन परीक्षण जितना संभव हो उतना हल्का और तेज़ होना चाहिए। और धूम्रपान परीक्षण की परिभाषा वह है जिसे मैंने एक रिग्रेशन टेस्ट सीखा था।

मैं गलत था कि मैं क्या सिखाया गया था? क्या मैंने गलत तरीके से पढ़ाया था? या "रिग्रेशन टेस्ट" की कई व्याख्याएं हैं?

उत्तर

4

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

"अगर यह संभवतः तोड़ सकता है, इसका परीक्षण करें" अंगूठे का नियम यहां लागू होता है। यदि Foo में कोई परिवर्तन Bar को प्रभावित कर सकता है, तो दोनों के लिए रिग्रेशन चलाएं।

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

+0

ठीक है, मैंने सीखा कि प्रतिगमन परीक्षण दो चीजें करना चाहिए। (1) बदले गए घटकों का अच्छी तरह से परीक्षण किया जाना चाहिए। (2) सिस्टम के किसी भी महत्वपूर्ण घटक, यहां तक ​​कि बदले गए लोगों को भी एक रिग्रेशन टेस्ट में परीक्षण किया जाना चाहिए। –

+1

यह एक बुरा नियम नहीं है। सावधान रहें यदि हर घटक अचानक "महत्वपूर्ण" बन जाता है। –

+0

अच्छा, आपको "महत्वपूर्ण" परिभाषित करना होगा। लेकिन हां। –

1

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

+0

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

+0

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

+0

"रिग्रेशन" का मतलब परीक्षणों का पूरा सूट नहीं है। इसका मतलब यह है कि नए कोड को तोड़ने के लिए मौजूदा परीक्षणों को दोबारा शुरू करना है। यह (जरूरी नहीं) का मतलब है कि आपको पूरा सूट चलाने की ज़रूरत है, लेकिन यह कर सकता है। मैं बस एक सूक्ष्म अंतर इंगित कर रहा हूँ। –

1

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

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

+0

यह सिस्टम (एकीकरण) परीक्षण है। –

+0

नहीं, यह नहीं है। सिस्टम (एकीकरण) परीक्षण नई कार्यक्षमता के लिए है। रिग्रेशन परीक्षण उन सामानों के लिए है जो हमने वर्तमान निर्माण के दौरान नहीं बदला था। हमारे रिग्रेशन टेस्ट सूट लगातार बढ़ रहे हैं क्योंकि हम और अधिक फ़ंक्शन जोड़ते हैं। – Elie

+0

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

1

शब्द 'प्रतिगमन परीक्षण' की मेरी समझ है:

  • इकाई परीक्षण सुविधाओं का परीक्षण के लिए लिखा जाता है जब सिस्टम बनाई गई है
  • जब कीड़े की खोज कर रहे हैं, और अधिक इकाई परीक्षण बग पुन: पेश करने में लिखा जाता है और सत्यापित करें कि इसे
  • एक रिग्रेशन टेस्ट परीक्षणों के पूरे सेट को चलाता है साबित करता है कि सबकुछ अभी भी काम करता है जिसमें कोई पुरानी बग फिर से दिखाई नहीं दे रही है [यानी यह साबित करने के लिए कि कोड "regressed" नहीं है]

अभ्यास में, परिवर्तनों के दौरान सभी मौजूदा यूनिट परीक्षणों को हमेशा चलाने के लिए सबसे अच्छा है। एकमात्र बार जब मैं परीक्षण के सबसेट के साथ परेशान होता हूं तो पूर्ण यूनिट टेस्ट सूट चलाने के लिए "बहुत लंबा" होता है [जहां "बहुत लंबा" काफी व्यक्तिपरक होता है]

0

जो आप पूरा करने की कोशिश कर रहे हैं उसके साथ शुरू करें। फिर वह लक्ष्य पूरा करने के लिए आपको क्या करने की ज़रूरत है। और उसके बाद एक शब्द असाइन करने के लिए buzzword bingo का उपयोग करें जो आप वास्तव में करते हैं। बस हर किसी की तरह :-) शुद्धता सभी महत्वपूर्ण नहीं है।

+0

स्पष्ट रूप से संचार करना महत्वपूर्ण है। अगर हम एक ही शब्दकोश का उपयोग करते हैं तो यह मदद करता है। –

0

... प्रतिगमन परीक्षण एक छोटे (केवल साबित करने के लिए आप कोई परिवर्तन या नए मॉड्यूल की शुरूआत के साथ कुछ भी नहीं तोड़ा पर्याप्त) समग्र परीक्षण के नमूने

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

0

सामान्य रूप से, उत्पाद के संस्करण एक्स में पेश की गई नई सुविधा के लिए फीचर परीक्षणों का एक सबसेट संस्करण एक्स + 1, एक्स + 2, और इसी तरह के लिए रिग्रेशन परीक्षण का आधार बन जाता है। समय के साथ, आप स्थिर सुविधाओं के फीचर/रिग्रेशन परीक्षणों द्वारा उठाए गए समय को कम कर सकते हैं जो प्रतिगमन से पीड़ित नहीं हैं। यदि कोई सुविधा बहुत से प्रतिक्रियाओं से ग्रस्त है, तो यह सुविधा पर जोर बढ़ाने के लिए फायदेमंद हो सकता है।

मुझे लगता है कि 'व्यापक रिग्रेशन टेस्ट' का जिक्र करने वाला आलेख का अर्थ है (व्यक्तिगत रूप से सरल) रिग्रेशन परीक्षणों का एक व्यापक सेट चलाएं।

5

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