View source for प्रतिगमन परीक्षण

{{About|software development|the statistical analysis process|Regression analysis|}}
{{Short description|Checking whether changes to software have broken functionality that used to work}}
{{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 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 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=":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>{{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}}

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

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

*[[गुणवत्ता नियंत्रण]]
*[[परीक्षण संचालित विकास]]

==संदर्भ==
{{reflist}}


==बाहरी संबंध==
* [https://learn.microsoft.com/en-us/azure/load-testing/tutorial-identify-performance-regression-with-cicd?tabs=pipelines Microsoft regression testing recommendations]

{{Software testing}}

{{DEFAULTSORT:Regression Testing}}[[Category: सॉफ़्टवेयर परीक्षण]] [[Category: चरम कार्यक्रम]] 



[[Category: Machine Translated Page]]
[[Category:Created On 02/03/2023]]