प्रतिगमन परीक्षण: Difference between revisions

From Vigyanwiki
(Created page with "{{About|software development|the statistical analysis process|Regression analysis|}} {{Short description|Checking whether changes to software have broken functionality that us...")
 
No edit summary
Line 1: Line 1:
{{About|software development|the statistical analysis process|Regression analysis|}}
{{About|सॉफ्टवेयर डेवलपमेंट|सांख्यिकीय विश्लेषण प्रक्रिया|प्रतिगमन विश्लेषण|}}
{{Short description|Checking whether changes to software have broken functionality that used to work}}
{{Short description|Checking whether changes to software have broken functionality that used to work}}
{{Software development process}}
{{Software development process}}
प्रतिगमन परीक्षण (शायद ही कभी, ''गैर-प्रतिगमन परीक्षण''<ref>{{cite book |last1=Pezzè |first1=Mauro |last2=Young |first2=Michal |title=Software testing and analysis: process, principles, and techniques |date=2008 |publisher=Wiley |url=https://www.google.com/search?q=Mauro+%22non-regression%22+%22regression+testing%22 |quote=Testing activities that focus on regression problems are called (non) regression testing. Usually "non" is omitted}}</ref>) कार्यात्मक परीक्षण और [[गैर-कार्यात्मक परीक्षण]] | गैर-कार्यात्मक परीक्षण फिर से चला रहा है ताकि यह सुनिश्चित किया जा सके कि पहले विकसित और परीक्षण किए गए सॉफ़्टवेयर अभी भी परिवर्तन के बाद अपेक्षित प्रदर्शन करते हैं।<ref>{{cite book|last=Basu|first=Anirban| title=सॉफ्टवेयर गुणवत्ता आश्वासन, परीक्षण और मेट्रिक्स| year=2015| publisher=PHI Learning| isbn=978-81-203-5068-7| url=https://books.google.com/books?id=aNTiCQAAQBAJ&pg=PA150}}</ref> यदि नहीं, तो उसे [[सॉफ्टवेयर प्रतिगमन]] कहा जाएगा।
'''प्रतिगमन परीक्षण (संभवतः ही कभी, ''गैर-प्रतिगमन परीक्षण'') कार्यात्मक परीक्षण और [[गैर-कार्यात्मक परीक्षण]] | गैर-कार्यात्मक परीक्षण पुन: चला रहा है जिससे यह सुनिश्चित किया जा सके कि पहले विकसित और परीक्षण किए गए सॉफ़्टवेयर अभी भी परिवर्तन के बाद अपेक्षित प्रदर्शन करते हैं। यदि नहीं, तो उसे [[सॉफ्टवेयर प्रतिगमन]] कहा जाएगा।'''


जिन परिवर्तनों के लिए प्रतिगमन परीक्षण की आवश्यकता हो सकती है उनमें [[सॉफ्टवेयर बग]] फिक्स, सॉफ़्टवेयर संवर्द्धन, [[विन्यास फाइल]] परिवर्तन और यहां तक ​​कि [[इलेक्ट्रॉनिक घटक]]ों का प्रतिस्थापन शामिल है।<ref>[[National Academies of Sciences, Engineering, and Medicine|National Research Council]] Committee on Aging Avionics in Military Aircraft: [https://www.nap.edu/catalog/10108/aging-avionics-in-military-aircraft ''Aging Avionics in Military Aircraft'']. The National Academies Press, 2001, page 2: ″Each technology-refresh cycle requires regression testing.″</ref> चूंकि प्रतिगमन परीक्षण सूट प्रत्येक पाए गए दोष के साथ बढ़ने लगते हैं, परीक्षण स्वचालन अक्सर शामिल होता है। स्पष्ट अपवाद [[ ग्राफिकल यूज़र इंटरफ़ेस ]] रिग्रेशन टेस्टिंग है, जिसे आम तौर पर मैन्युअल रूप से निष्पादित किया जाना चाहिए। कभी-कभी परीक्षणों के उपयुक्त सबसेट (गैर-रिग्रेशन विश्लेषण) को निर्धारित करने के लिए एक परिवर्तन प्रभाव विश्लेषण किया जाता है<ref>{{cite book |last1=Boulanger |first1=Jean-Louis |title=CENELEC 50128 and IEC 62279 Standards |date=2015 |publisher=Wiley |isbn=978-1119122487 |url=https://books.google.com/books?id=IbZNCAAAQBAJ&pg=PA149}}</ref>).
प्रतिगमन परीक्षण (संभवतः ही कभी, गैर-प्रतिगमन परीक्षण<ref>{{cite book |last1=Pezzè |first1=Mauro |last2=Young |first2=Michal |title=Software testing and analysis: process, principles, and techniques |date=2008 |publisher=Wiley |url=https://www.google.com/search?q=Mauro+%22non-regression%22+%22regression+testing%22 |quote=Testing activities that focus on regression problems are called (non) regression testing. Usually "non" is omitted}}</ref>) यह सुनिश्चित करने के लिए कार्यात्मक और [[गैर-कार्यात्मक परीक्षण]] पुन: चला रहा है कि पहले विकसित और परीक्षण किए गए सॉफ़्टवेयर अभी भी परिवर्तन के बाद अपेक्षित प्रदर्शन करते हैं।<ref>{{cite book|last=Basu|first=Anirban| title=सॉफ्टवेयर गुणवत्ता आश्वासन, परीक्षण और मेट्रिक्स| year=2015| publisher=PHI Learning| isbn=978-81-203-5068-7| url=https://books.google.com/books?id=aNTiCQAAQBAJ&pg=PA150}}</ref> यदि नहीं, तो इसे [[सॉफ्टवेयर प्रतिगमन|प्रतिगमन]] कहा जाएगा।
 
जिन परिवर्तनों के लिए प्रतिगमन परीक्षण की आवश्यकता हो सकती है उनमें [[सॉफ्टवेयर बग]] फिक्स, सॉफ़्टवेयर संवर्द्धन, [[विन्यास फाइल]] परिवर्तन और यहां तक ​​कि [[इलेक्ट्रॉनिक घटक|इलेक्ट्रॉनिक घटकों]] का प्रतिस्थापन सम्मिलित है।<ref>[[National Academies of Sciences, Engineering, and Medicine|National Research Council]] Committee on Aging Avionics in Military Aircraft: [https://www.nap.edu/catalog/10108/aging-avionics-in-military-aircraft ''Aging Avionics in Military Aircraft'']. The National Academies Press, 2001, page 2: ″Each technology-refresh cycle requires regression testing.″</ref> चूंकि प्रतिगमन परीक्षण सूट प्रत्येक पाए गए दोष के साथ बढ़ने लगते हैं, परीक्षण स्वचालन अधिकांशतः सम्मिलित होता है। स्पष्ट अपवाद [[ ग्राफिकल यूज़र इंटरफ़ेस | जीयूआई]] '''जीयूआई''' प्रतिगमन परीक्षण है '''प्रतिगमन टेस्टिंग है''', जिसे सामान्यतः मैन्युअल रूप से निष्पादित किया जाना चाहिए। कभी-कभी परीक्षणों के उपयुक्त सबसेट (गैर-प्रतिगमन विश्लेषण) को निर्धारित करने के लिए एक परिवर्तन प्रभाव विश्लेषण किया जाता है।<ref>{{cite book |last1=Boulanger |first1=Jean-Louis |title=CENELEC 50128 and IEC 62279 Standards |date=2015 |publisher=Wiley |isbn=978-1119122487 |url=https://books.google.com/books?id=IbZNCAAAQBAJ&pg=PA149}}</ref>


== पृष्ठभूमि ==
== पृष्ठभूमि ==
जैसा कि सॉफ़्टवेयर को अद्यतन या परिवर्तित किया जाता है, या एक संशोधित लक्ष्य पर पुन: उपयोग किया जाता है, नए दोषों का उभरना और/या पुराने दोषों का फिर से उभरना काफी आम है।
जैसा कि सॉफ़्टवेयर को अद्यतन या परिवर्तित किया जाता है, या एक संशोधित लक्ष्य पर पुन: उपयोग किया जाता है, नए दोषों का उभरना और/या पुराने दोषों का पुन: उभरना अधिक सामान्य है।
 
कभी-कभी पुन: उभरना होता है क्योंकि खराब [[संशोधन नियंत्रण]] प्रथाओं (या संशोधन नियंत्रण में साधारण मानवीय त्रुटि) के माध्यम से एक सुधार खो जाता है। अधिकांशतः, एक समस्या के लिए एक फिक्स "भंगुर" होगा क्योंकि यह समस्या को संकीर्ण स्थिति में ठीक करता है जहां इसे पहली बार देखा गया था लेकिन अधिक सामान्य स्थितियों में नहीं जो सॉफ्टवेयर के जीवनकाल में उत्पन्न हो सकते हैं। अधिकांशतः, एक क्षेत्र में किसी समस्या का समाधान अनजाने में दूसरे क्षेत्र में सॉफ़्टवेयर बग का कारण बनता है।
 
अंत में, ऐसा हो सकता है कि, जब कुछ फीचर को पुन: डिज़ाइन किया जाता है, तो कुछ वही गलतियाँ जो फीचर के मूल कार्यान्वयन में की गई थीं, रीडिज़ाइन में की जाती हैं। इसलिए, अधिकांश सॉफ्टवेयर विकास स्थितियों में, यह अच्छा कोडिंग अभ्यास माना जाता है, जब एक बग का पता लगाया जाता है और तय किया जाता है, एक परीक्षण रिकॉर्ड करने के लिए जो बग को प्रकट करता है और कार्यक्रम में बाद के परिवर्तनों के बाद नियमित रूप से उस परीक्षण को पुन: चलाता है।<ref name="kolawa">{{cite book | last = Kolawa | first = Adam |author2=Huizinga, Dorota  | title = Automated Defect Prevention: Best Practices in Software Management | url = http://www.wiley.com/WileyCDA/WileyTitle/productCd-0470042125.html | year = 2007 | publisher = Wiley-IEEE Computer Society Press | page=73| isbn = 978-0-470-04212-0 }}</ref>
 
यद्यपि यह प्रोग्रामिंग तकनीकों का उपयोग करके मैन्युअल परीक्षण प्रक्रियाओं के माध्यम से किया जा सकता है, यह अधिकांशतः [[स्वचालित परीक्षण]] उपकरणों का उपयोग करके किया जाता है।<ref>[http://safari.oreilly.com/0201794292/ch08lev1sec4 Automate Regression Tests When Feasible], Automated Testing: Selected Best Practices, Elfriede Dustin, Safari Books Online</ref> इस तरह के [[परीक्षण सूट]] में सॉफ्टवेयर उपकरण होते हैं जो परीक्षण वातावरण को सभी प्रतिगमन परीक्षण स्थितियों को स्वचालित रूप से निष्पादित करने की अनुमति देते हैं; कुछ परियोजनाओं ने निर्दिष्ट अंतरालों पर सभी प्रतिगमन परीक्षणों को पुन: चलाने और किसी भी विफलता को सूचित करने के लिए स्वचालित प्रणाली भी स्थापित किया है (जो एक प्रतिगमन या एक पुराना परीक्षण हो सकता है)।<ref>{{cite web| url=http://www.drdobbs.com/tools/change-code-without-fear/206105233| title=Change Code Without Fear: Utilize a Regression Safety Net|last=daVeiga|first=Nada|work=[[Dr. Dobb's Journal]]| date=2008-02-06}}</ref>


कभी-कभी पुन: उभरना होता है क्योंकि खराब [[संशोधन नियंत्रण]] प्रथाओं (या संशोधन नियंत्रण में साधारण मानवीय त्रुटि) के माध्यम से एक सुधार खो जाता है। अक्सर, किसी समस्या का समाधान सॉफ़्टवेयर की भंगुरता होगी, जिसमें यह समस्या को संकीर्ण मामले में ठीक करता है जहां इसे पहली बार देखा गया था, लेकिन अधिक सामान्य मामलों में नहीं जो सॉफ़्टवेयर के जीवनकाल में उत्पन्न हो सकते हैं। अक्सर, एक क्षेत्र में किसी समस्या का समाधान अनजाने में दूसरे क्षेत्र में सॉफ़्टवेयर बग का कारण बनता है।
प्रत्येक सफल संकलन (छोटी परियोजनाओं के लिए), हर रात, या सप्ताह में एक बार ऐसी प्रणाली को चलाने के लिए सामान्य रणनीतियाँ हैं। उन रणनीतियों को बाहरी उपकरण द्वारा स्वचालित किया जा सकता है।


अंत में, ऐसा हो सकता है कि, जब कुछ फीचर को फिर से डिज़ाइन किया जाता है, तो कुछ वही गलतियाँ जो फीचर के मूल कार्यान्वयन में की गई थीं, रीडिज़ाइन में की जाती हैं। इसलिए, अधिकांश सॉफ्टवेयर विकास स्थितियों में, जब एक बग का पता लगाया जाता है और तय किया जाता है, तो यह सबसे अच्छा कोडिंग अभ्यास माना जाता है, एक परीक्षण रिकॉर्ड करने के लिए जो बग को उजागर करता है और कार्यक्रम में बाद के बदलावों के बाद नियमित रूप से उस परीक्षण को फिर से चलाता है।<ref name="kolawa">{{cite book | last = Kolawa | first = Adam |author2=Huizinga, Dorota  | title = Automated Defect Prevention: Best Practices in Software Management | url = http://www.wiley.com/WileyCDA/WileyTitle/productCd-0470042125.html | year = 2007 | publisher = Wiley-IEEE Computer Society Press | page=73| isbn = 978-0-470-04212-0 }}</ref> यद्यपि यह प्रोग्रामिंग तकनीकों का उपयोग करके मैन्युअल परीक्षण प्रक्रियाओं के माध्यम से किया जा सकता है, यह अक्सर [[स्वचालित परीक्षण]] उपकरणों का उपयोग करके किया जाता है।<ref>[http://safari.oreilly.com/0201794292/ch08lev1sec4 Automate Regression Tests When Feasible], Automated Testing: Selected Best Practices, Elfriede Dustin, Safari Books Online</ref> इस तरह के [[परीक्षण सूट]] में सॉफ्टवेयर उपकरण होते हैं जो परीक्षण वातावरण को सभी प्रतिगमन परीक्षण मामलों को स्वचालित रूप से निष्पादित करने की अनुमति देते हैं; कुछ परियोजनाओं ने निर्दिष्ट अंतरालों पर सभी प्रतिगमन परीक्षणों को फिर से चलाने और किसी भी विफलता की रिपोर्ट करने के लिए स्वचालित सिस्टम भी स्थापित किया है (जो एक प्रतिगमन या एक पुराना परीक्षण हो सकता है)।<ref>{{cite web| url=http://www.drdobbs.com/tools/change-code-without-fear/206105233| title=Change Code Without Fear: Utilize a Regression Safety Net|last=daVeiga|first=Nada|work=[[Dr. Dobb's Journal]]| date=2008-02-06}}</ref> प्रत्येक सफल संकलन (छोटी परियोजनाओं के लिए), हर रात, या सप्ताह में एक बार ऐसी प्रणाली को चलाने के लिए सामान्य रणनीतियाँ हैं। उन रणनीतियों को बाहरी उपकरण द्वारा स्वचालित किया जा सकता है।
प्रतिगमन परीक्षण [[चरम कार्यक्रम|चरम प्रोग्रामिंग]] सॉफ्टवेयर विकास पद्धति का एक अभिन्न अंग है। इस पद्धति में, [[सॉफ्टवेयर विकास प्रक्रिया]] के प्रत्येक चरण में पूरे सॉफ्टवेयर पैकेज के व्यापक, दोहराने योग्य और स्वचालित परीक्षण द्वारा डिजाइन दस्तावेजों को परिवर्तित कर दिया जाता है। कार्यात्मक परीक्षण समाप्त होने के बाद प्रतिगमन परीक्षण किया जाता है, यह सत्यापित करने के लिए कि अन्य कार्यात्मकताएं काम कर रही हैं।


प्रतिगमन परीक्षण [[चरम कार्यक्रम]] सॉफ्टवेयर विकास पद्धति का एक अभिन्न अंग है। इस पद्धति में, [[सॉफ्टवेयर विकास प्रक्रिया]] के प्रत्येक चरण में पूरे सॉफ्टवेयर पैकेज के व्यापक, दोहराने योग्य और स्वचालित परीक्षण द्वारा डिजाइन दस्तावेजों को बदल दिया जाता है। कार्यात्मक परीक्षण समाप्त होने के बाद प्रतिगमन परीक्षण किया जाता है, यह सत्यापित करने के लिए कि अन्य कार्यात्मकताएं काम कर रही हैं।
कॉर्पोरेट जगत में, प्रतिगमन परीक्षण परंपरागत रूप से एक सॉफ्टवेयर गुणवत्ता आश्वासन टीम तथा विकास टीम द्वारा काम पूरा करने के बाद किया जाता है। चूंकि, इस स्तर पर पाए गए दोषों को ठीक करना सबसे बहुमूल्य है। इकाई परीक्षण के उदय से इस समस्या का समाधान किया जा रहा है। चूंकि डेवलपर्स ने विकास चक्र के हिस्से के रूप में सदैव परीक्षण स्थितियों को लिखा है, ये परीक्षण स्थिति सामान्यतः या तो कार्यात्मक परीक्षण या इकाई परीक्षण होते हैं जो केवल इच्छित परिणामों को सत्यापित करते हैं। डेवलपर परीक्षण एक डेवलपर को इकाई परीक्षण पर ध्यान केंद्रित करने और सकारात्मक और नकारात्मक दोनों परीक्षण स्थितियों को सम्मिलित करने के लिए विवश करता है।<ref>{{cite web|url=http://www.sys-con.com/read/47359.htm|title=Developer Testing Is 'In': An interview with Alberto Savoia and Kent Beck|last=Dudney|first=Bill|date=2004-12-08|access-date=2007-11-29}}</ref>


कॉर्पोरेट जगत में, प्रतिगमन परीक्षण परंपरागत रूप से एक सॉफ्टवेयर गुणवत्ता आश्वासन टीम द्वारा विकास टीम द्वारा काम पूरा करने के बाद किया जाता है। हालांकि, इस स्तर पर पाए गए दोषों को ठीक करना सबसे महंगा है। इकाई परीक्षण के उदय से इस समस्या का समाधान किया जा रहा है। हालांकि डेवलपर्स ने विकास चक्र के हिस्से के रूप में हमेशा परीक्षण मामलों को लिखा है, ये परीक्षण मामले आम तौर पर या तो कार्यात्मक परीक्षण या यूनिट परीक्षण होते हैं जो केवल इच्छित परिणामों को सत्यापित करते हैं। डेवलपर परीक्षण एक डेवलपर को इकाई परीक्षण पर ध्यान केंद्रित करने और सकारात्मक और नकारात्मक दोनों परीक्षण मामलों को शामिल करने के लिए मजबूर करता है।<ref>{{cite web|url=http://www.sys-con.com/read/47359.htm|title=Developer Testing Is 'In': An interview with Alberto Savoia and Kent Beck|last=Dudney|first=Bill|date=2004-12-08|access-date=2007-11-29}}</ref>




== तकनीक ==
== तकनीक ==
विभिन्न प्रतिगमन परीक्षण तकनीकें हैं:
विभिन्न प्रतिगमन परीक्षण विधियाँ हैं:


=== सभी का पुन: परीक्षण करें ===
=== सभी का पुन: परीक्षण करें ===
यह तकनीक इसकी अखंडता की जांच करने के लिए वर्तमान कार्यक्रम पर सभी परीक्षण मामलों की जांच करती है। हालांकि यह महंगा है क्योंकि इसे सभी मामलों को फिर से चलाने की जरूरत है, यह सुनिश्चित करता है कि संशोधित कोड के कारण कोई त्रुटि न हो।<ref name=":0">{{Cite conference|date=2008-03-29|title=प्रतिगमन परीक्षण तकनीकों को समझना|first1=Gaurav|last1=Duggal|first2=Bharti|last2=Suri|conference=National Conference on Challenges and Opportunities|location=Mandi Gobindgarh, Punjab, India|citeseerx=10.1.1.460.5875}}</ref>
यह विधि इसकी अखंडता की जांच करने के लिए वर्तमान कार्यक्रम पर सभी परीक्षण स्थितियों की जांच करती है। चूंकि यह बहुमूल्य है क्योंकि इसे सभी स्थितियों को पुन: चलाने की आवश्यकता है, यह सुनिश्चित करता है कि संशोधित कोड के कारण कोई त्रुटि न हो।<ref name=":0">{{Cite conference|date=2008-03-29|title=प्रतिगमन परीक्षण तकनीकों को समझना|first1=Gaurav|last1=Duggal|first2=Bharti|last2=Suri|conference=National Conference on Challenges and Opportunities|location=Mandi Gobindgarh, Punjab, India|citeseerx=10.1.1.460.5875}}</ref>




=== प्रतिगमन परीक्षण चयन ===
=== प्रतिगमन परीक्षण चयन ===
रिटेस्ट ऑल के विपरीत, यह तकनीक टेस्ट सूट का एक हिस्सा चलाती है (सभी को फिर से टेस्ट करने की लागत के कारण) यदि टेस्ट सूट के हिस्से को चुनने की लागत रीटेस्ट ऑल तकनीक से कम है।<ref name=":0" />
पुन: परीक्षण के विपरीत, यह तकनीक परीक्षण सूट का एक हिस्सा चलाती है (सभी को पुन: परीक्षण करने की व्यय के कारण) यदि परीक्षण सूट के हिस्से को चुनने की व्यय पुन: परीक्षण करने की विधि से कम है।<ref name=":0" />




=== टेस्ट केस प्राथमिकता ===
=== परीक्षण स्थिति की प्राथमिकता ===
परीक्षण सूट की गलती का पता लगाने की दर बढ़ाने के लिए परीक्षण मामलों को प्राथमिकता दें। टेस्ट केस प्रायोरिटी तकनीक टेस्ट केस को शेड्यूल करती है ताकि प्राथमिकता में उच्च वाले टेस्ट केस को कम प्राथमिकता वाले टेस्ट केस से पहले निष्पादित किया जा सके।<ref name=":0" />
परीक्षण सूट की गलती का पता लगाने की दर बढ़ाने के लिए परीक्षण स्थितियों को प्राथमिकता दें। परीक्षण स्थिति की प्राथमिकता विधि परीक्षण स्थिति को शेड्यूल करती है जिससे प्राथमिकता में उच्च वाले परीक्षण स्थिति को कम प्राथमिकता वाले परीक्षण स्थिति से पहले निष्पादित किया जा सके।<ref name=":0" />






==== टेस्ट केस प्राथमिकता के प्रकार ====
==== परीक्षण स्थिति की प्राथमिकता के प्रकार ====
* सामान्य प्राथमिकता - उन परीक्षण मामलों को प्राथमिकता दें जो बाद के संस्करणों पर लाभकारी होंगे
* सामान्य प्राथमिकता - उन परीक्षण स्थितियों को प्राथमिकता दें जो बाद के संस्करणों पर लाभकारी होंगे।
* संस्करण-विशिष्ट प्राथमिकता - सॉफ़्टवेयर के किसी विशेष संस्करण के संबंध में परीक्षण मामलों को प्राथमिकता दें।
* संस्करण-विशिष्ट प्राथमिकता - सॉफ़्टवेयर के किसी विशेष संस्करण के संबंध में परीक्षण स्थितियों को प्राथमिकता दें।


=== हाइब्रिड ===
=== हाइब्रिड ===
यह तकनीक प्रतिगमन परीक्षण चयन और परीक्षण मामले की प्राथमिकता का एक संकर है।<ref name=":0" />
यह तकनीक प्रतिगमन परीक्षण चयन और परीक्षण स्थिति की प्राथमिकता का एक संकर है।<ref name=":0" />




== लाभ और कमियां ==
== लाभ और कमियां ==
प्रतिगमन परीक्षण तब किया जाता है जब सॉफ़्टवेयर की मौजूदा कार्यक्षमता में परिवर्तन किए जाते हैं या यदि सॉफ़्टवेयर में कोई बग फिक्स होता है। प्रतिगमन परीक्षण कई दृष्टिकोणों के माध्यम से प्राप्त किया जा सकता है; यदि एक परीक्षण सभी दृष्टिकोण का पालन किया जाता है, तो यह निश्चितता प्रदान करता है कि सॉफ़्टवेयर में किए गए परिवर्तनों ने मौजूदा कार्यात्मकताओं को प्रभावित नहीं किया है, जो अपरिवर्तित हैं।<ref name=":1">{{cite journal |last1=Yoo |first1=S. |last2=Harman |first2=M. |title=Regression testing minimization, selection and prioritization: a survey |journal=Software Testing, Verification and Reliability |date=2010 |volume=22 |issue=2 |pages=67–120|doi=10.1002/stvr.430}}</ref>
प्रतिगमन परीक्षण तब किया जाता है जब सॉफ़्टवेयर की वर्तमान कार्यक्षमता में परिवर्तन किए जाते हैं या यदि सॉफ़्टवेयर में कोई बग फिक्स होता है। प्रतिगमन परीक्षण कई दृष्टिकोणों के माध्यम से प्राप्त किया जा सकता है; यदि एक परीक्षण द्वारा सभी दृष्टिकोण का पालन किया जाता है, तो यह निश्चितता प्रदान करता है कि सॉफ़्टवेयर में किए गए परिवर्तनों ने वर्तमान कार्यात्मकताओं को प्रभावित नहीं किया है, जो अपरिवर्तित हैं।<ref name=":1">{{cite journal |last1=Yoo |first1=S. |last2=Harman |first2=M. |title=Regression testing minimization, selection and prioritization: a survey |journal=Software Testing, Verification and Reliability |date=2010 |volume=22 |issue=2 |pages=67–120|doi=10.1002/stvr.430}}</ref>
[[चुस्त सॉफ्टवेयर विकास]] में- जहां सॉफ्टवेयर विकास जीवन चक्र बहुत कम हैं, संसाधन दुर्लभ हैं, और सॉफ्टवेयर में परिवर्तन बहुत बार-बार होते हैं-रिग्रेशन परीक्षण बहुत अधिक अनावश्यक ओवरहेड पेश कर सकता है।<ref name=":1" />
 
[[चुस्त सॉफ्टवेयर विकास|एजाइल सॉफ्टवेयर विकास]] में- जहां सॉफ्टवेयर विकास जीवन चक्र बहुत कम हैं, संसाधन दुर्लभ हैं, और सॉफ्टवेयर में परिवर्तन बार-बार होते हैं- प्रतिगमन परीक्षण बहुत अधिक अनावश्यक ओवरहेड प्रस्तुत कर सकता है।<ref name=":1" />
 
एक सॉफ़्टवेयर डेवलपमेंट परिवेश में जो किसी तृतीय पक्ष के [[ब्लैक बॉक्स]] घटकों का उपयोग करता है, प्रतिगमन परीक्षण करना जटिल हो सकता है, क्योंकि तृतीय-पक्ष घटक में कोई भी परिवर्तन शेष प्रणाली के साथ हस्तक्षेप कर सकता है (और तृतीय-पक्ष घटक पर प्रतिगमन परीक्षण करना कठिन है, क्योंकि यह एक अज्ञात इकाई है)।<ref name=":1" />


एक सॉफ़्टवेयर डेवलपमेंट परिवेश में जो किसी तृतीय पक्ष के [[ब्लैक बॉक्स]] घटकों का उपयोग करता है, प्रतिगमन परीक्षण करना मुश्किल हो सकता है, क्योंकि तृतीय-पक्ष घटक में कोई भी परिवर्तन शेष सिस्टम के साथ हस्तक्षेप कर सकता है (और तृतीय-पक्ष पर प्रतिगमन परीक्षण निष्पादित कर सकता है) पार्टी घटक कठिन है, क्योंकि यह एक अज्ञात इकाई है)।<ref name=":1" />




== उपयोग करता है ==
== उपयोग '''करता है''' ==
प्रतिगमन परीक्षण का उपयोग न केवल किसी प्रोग्राम की [[शुद्धता (कंप्यूटर विज्ञान)]] के परीक्षण के लिए किया जा सकता है, बल्कि अक्सर इसके आउटपुट की गुणवत्ता पर नज़र रखने के लिए भी किया जा सकता है।<ref>{{cite web |url=http://www.wrox.com/WileyCDA/Section/id-291252.html |title=प्रतिगमन परीक्षण, प्रोग्रामर से प्रोग्रामर|last=Kolawa |first=Adam |author-link=Adam Kolawa |work=Wrox }}</ref> उदाहरण के लिए, एक [[ संकलक ]] के डिजाइन में, प्रतिगमन परीक्षण कोड आकार को ट्रैक कर सकता है और परीक्षण सूट के मामलों को संकलित और निष्पादित करने में लगने वाला समय।
प्रतिगमन परीक्षण का उपयोग न केवल किसी प्रोग्राम की [[शुद्धता (कंप्यूटर विज्ञान)]] के परीक्षण के लिए किया जा सकता है, बल्कि अधिकांशतः इसके आउटपुट की गुणवत्ता पर ध्यान रखने के लिए भी किया जा सकता है।<ref>{{cite web |url=http://www.wrox.com/WileyCDA/Section/id-291252.html |title=प्रतिगमन परीक्षण, प्रोग्रामर से प्रोग्रामर|last=Kolawa |first=Adam |author-link=Adam Kolawa |work=Wrox }}</ref> उदाहरण के लिए, एक [[ संकलक | कंपाइलर]] के डिजाइन में, प्रतिगमन परीक्षण कोड आकार और परीक्षण सूट के स्थितियों को संकलित और निष्पादित करने में लगने वाले समय को ट्रैक कर सकता है ।


{{Quotation |text=Also as a consequence of the introduction of new bugs, program maintenance requires far more system testing per statement written than any other programming. Theoretically, after each fix, one must run the entire batch of test cases previously run against the system to ensure that it has not been damaged in an obscure way. In practice, such ''regression testing'' must indeed approximate this theoretical idea, and it is very costly.|author=[[Fred Brooks]]|title=''[[The Mythical Man Month]]''|source=p. 122}}
{{Quotation |text=साथ ही नए बगों के प्रारंभ के परिणामस्वरूप, प्रोग्राम की देखभाल के लिए किसी भी अन्य प्रोग्रामिंग की तुलना में लिखे गए प्रति कथन में कहीं अधिक प्रणाली परीक्षण की आवश्यकता होती है। सैद्धांतिक रूप से, प्रत्येक फिक्स के बाद, यह सुनिश्चित करने के लिए प्रणाली के विरुद्ध पहले चलाए गए परीक्षण स्थितियों के पूरे बैच को चलाना चाहिए जिससे यह सुनिश्चित हो सके कि यह अस्पष्ट विधि से क्षतिग्रस्त नहीं हुआ है। व्यवहारतः, इस तरह के 'प्रतिगमन परीक्षण' को वास्तव में इस सैद्धांतिक विचार का अनुमान लगाना चाहिए, और यह बहुत बहुमूल्य है।|author=[[फ्रेड ब्रूक्स]]|title=''[[द मिथिकल मैन मंथ]]''|source=p. 122}}


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


== यह भी देखें ==
== यह भी देखें ==

Revision as of 23:02, 9 March 2023

This article is about सॉफ्टवेयर डेवलपमेंट. For सांख्यिकीय विश्लेषण प्रक्रिया, see प्रतिगमन विश्लेषण.
Part of a series on
Software development
Core activities
Paradigms and models
Methodologies and frameworks
Supporting disciplines
Practices
Tools
Standards and Bodies of Knowledge
Glossaries
Outlines

प्रतिगमन परीक्षण (संभवतः ही कभी, गैर-प्रतिगमन परीक्षण) कार्यात्मक परीक्षण और गैर-कार्यात्मक परीक्षण | गैर-कार्यात्मक परीक्षण पुन: चला रहा है जिससे यह सुनिश्चित किया जा सके कि पहले विकसित और परीक्षण किए गए सॉफ़्टवेयर अभी भी परिवर्तन के बाद अपेक्षित प्रदर्शन करते हैं। यदि नहीं, तो उसे सॉफ्टवेयर प्रतिगमन कहा जाएगा।

प्रतिगमन परीक्षण (संभवतः ही कभी, गैर-प्रतिगमन परीक्षण[1]) यह सुनिश्चित करने के लिए कार्यात्मक और गैर-कार्यात्मक परीक्षण पुन: चला रहा है कि पहले विकसित और परीक्षण किए गए सॉफ़्टवेयर अभी भी परिवर्तन के बाद अपेक्षित प्रदर्शन करते हैं।[2] यदि नहीं, तो इसे प्रतिगमन कहा जाएगा।

जिन परिवर्तनों के लिए प्रतिगमन परीक्षण की आवश्यकता हो सकती है उनमें सॉफ्टवेयर बग फिक्स, सॉफ़्टवेयर संवर्द्धन, विन्यास फाइल परिवर्तन और यहां तक ​​कि इलेक्ट्रॉनिक घटकों का प्रतिस्थापन सम्मिलित है।[3] चूंकि प्रतिगमन परीक्षण सूट प्रत्येक पाए गए दोष के साथ बढ़ने लगते हैं, परीक्षण स्वचालन अधिकांशतः सम्मिलित होता है। स्पष्ट अपवाद जीयूआई जीयूआई प्रतिगमन परीक्षण है प्रतिगमन टेस्टिंग है, जिसे सामान्यतः मैन्युअल रूप से निष्पादित किया जाना चाहिए। कभी-कभी परीक्षणों के उपयुक्त सबसेट (गैर-प्रतिगमन विश्लेषण) को निर्धारित करने के लिए एक परिवर्तन प्रभाव विश्लेषण किया जाता है।[4]

पृष्ठभूमि

जैसा कि सॉफ़्टवेयर को अद्यतन या परिवर्तित किया जाता है, या एक संशोधित लक्ष्य पर पुन: उपयोग किया जाता है, नए दोषों का उभरना और/या पुराने दोषों का पुन: उभरना अधिक सामान्य है।

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

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

यद्यपि यह प्रोग्रामिंग तकनीकों का उपयोग करके मैन्युअल परीक्षण प्रक्रियाओं के माध्यम से किया जा सकता है, यह अधिकांशतः स्वचालित परीक्षण उपकरणों का उपयोग करके किया जाता है।[6] इस तरह के परीक्षण सूट में सॉफ्टवेयर उपकरण होते हैं जो परीक्षण वातावरण को सभी प्रतिगमन परीक्षण स्थितियों को स्वचालित रूप से निष्पादित करने की अनुमति देते हैं; कुछ परियोजनाओं ने निर्दिष्ट अंतरालों पर सभी प्रतिगमन परीक्षणों को पुन: चलाने और किसी भी विफलता को सूचित करने के लिए स्वचालित प्रणाली भी स्थापित किया है (जो एक प्रतिगमन या एक पुराना परीक्षण हो सकता है)।[7]

प्रत्येक सफल संकलन (छोटी परियोजनाओं के लिए), हर रात, या सप्ताह में एक बार ऐसी प्रणाली को चलाने के लिए सामान्य रणनीतियाँ हैं। उन रणनीतियों को बाहरी उपकरण द्वारा स्वचालित किया जा सकता है।

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

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


तकनीक

विभिन्न प्रतिगमन परीक्षण विधियाँ हैं:

सभी का पुन: परीक्षण करें

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


प्रतिगमन परीक्षण चयन

पुन: परीक्षण के विपरीत, यह तकनीक परीक्षण सूट का एक हिस्सा चलाती है (सभी को पुन: परीक्षण करने की व्यय के कारण) यदि परीक्षण सूट के हिस्से को चुनने की व्यय पुन: परीक्षण करने की विधि से कम है।[9]


परीक्षण स्थिति की प्राथमिकता

परीक्षण सूट की गलती का पता लगाने की दर बढ़ाने के लिए परीक्षण स्थितियों को प्राथमिकता दें। परीक्षण स्थिति की प्राथमिकता विधि परीक्षण स्थिति को शेड्यूल करती है जिससे प्राथमिकता में उच्च वाले परीक्षण स्थिति को कम प्राथमिकता वाले परीक्षण स्थिति से पहले निष्पादित किया जा सके।[9]


परीक्षण स्थिति की प्राथमिकता के प्रकार

  • सामान्य प्राथमिकता - उन परीक्षण स्थितियों को प्राथमिकता दें जो बाद के संस्करणों पर लाभकारी होंगे।
  • संस्करण-विशिष्ट प्राथमिकता - सॉफ़्टवेयर के किसी विशेष संस्करण के संबंध में परीक्षण स्थितियों को प्राथमिकता दें।

हाइब्रिड

यह तकनीक प्रतिगमन परीक्षण चयन और परीक्षण स्थिति की प्राथमिकता का एक संकर है।[9]


लाभ और कमियां

प्रतिगमन परीक्षण तब किया जाता है जब सॉफ़्टवेयर की वर्तमान कार्यक्षमता में परिवर्तन किए जाते हैं या यदि सॉफ़्टवेयर में कोई बग फिक्स होता है। प्रतिगमन परीक्षण कई दृष्टिकोणों के माध्यम से प्राप्त किया जा सकता है; यदि एक परीक्षण द्वारा सभी दृष्टिकोण का पालन किया जाता है, तो यह निश्चितता प्रदान करता है कि सॉफ़्टवेयर में किए गए परिवर्तनों ने वर्तमान कार्यात्मकताओं को प्रभावित नहीं किया है, जो अपरिवर्तित हैं।[10]

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

एक सॉफ़्टवेयर डेवलपमेंट परिवेश में जो किसी तृतीय पक्ष के ब्लैक बॉक्स घटकों का उपयोग करता है, प्रतिगमन परीक्षण करना जटिल हो सकता है, क्योंकि तृतीय-पक्ष घटक में कोई भी परिवर्तन शेष प्रणाली के साथ हस्तक्षेप कर सकता है (और तृतीय-पक्ष घटक पर प्रतिगमन परीक्षण करना कठिन है, क्योंकि यह एक अज्ञात इकाई है)।[10]


उपयोग करता है

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

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

— फ्रेड ब्रूक्स, द मिथिकल मैन मंथ, p. 122

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

यह भी देखें

संदर्भ

  1. ↑ Pezzè, Mauro; Young, Michal (2008). Software testing and analysis: process, principles, and techniques. Wiley. Testing activities that focus on regression problems are called (non) regression testing. Usually "non" is omitted
  2. ↑ Basu, Anirban (2015). सॉफ्टवेयर गुणवत्ता आश्वासन, परीक्षण और मेट्रिक्स. PHI Learning. ISBN 978-81-203-5068-7.
  3. ↑ National Research Council Committee on Aging Avionics in Military Aircraft: Aging Avionics in Military Aircraft. The National Academies Press, 2001, page 2: ″Each technology-refresh cycle requires regression testing.″
  4. ↑ Boulanger, Jean-Louis (2015). CENELEC 50128 and IEC 62279 Standards. Wiley. ISBN 978-1119122487.
  5. ↑ Kolawa, Adam; Huizinga, Dorota (2007). Automated Defect Prevention: Best Practices in Software Management. Wiley-IEEE Computer Society Press. p. 73. ISBN 978-0-470-04212-0.
  6. ↑ Automate Regression Tests When Feasible, Automated Testing: Selected Best Practices, Elfriede Dustin, Safari Books Online
  7. ↑ daVeiga, Nada (2008-02-06). "Change Code Without Fear: Utilize a Regression Safety Net". Dr. Dobb's Journal.
  8. ↑ Dudney, Bill (2004-12-08). "Developer Testing Is 'In': An interview with Alberto Savoia and Kent Beck". Retrieved 2007-11-29.
  9. ↑ 9.0 9.1 9.2 9.3 Duggal, Gaurav; Suri, Bharti (2008-03-29). प्रतिगमन परीक्षण तकनीकों को समझना. National Conference on Challenges and Opportunities. Mandi Gobindgarh, Punjab, India. CiteSeerX 10.1.1.460.5875.
  10. ↑ 10.0 10.1 10.2 Yoo, S.; Harman, M. (2010). "Regression testing minimization, selection and prioritization: a survey". Software Testing, Verification and Reliability. 22 (2): 67–120. doi:10.1002/stvr.430.
  11. ↑ Kolawa, Adam. "प्रतिगमन परीक्षण, प्रोग्रामर से प्रोग्रामर". Wrox.


बाहरी संबंध

Retrieved from ‘https://www.vigyanwiki.in/index.php?title=प्रतिगमन_परीक्षण&oldid=103573’