परीक्षण प्रभाव विश्लेषण - यह क्या है, इसका परीक्षण कैसे करें, और बाकी सब कुछ जो आपको जानना चाहिए

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

DevOps में विस्फोटक वृद्धि के बावजूद, हार्वर्ड बिजनेस रिव्यू सर्वे के केवल 10% उत्तरदाताओं ने अपने व्यवसाय का वर्णन "तेजी से सॉफ्टवेयर विकास और परिनियोजन में बहुत सफल" के रूप में किया है।

DevOps परिवर्तन के लिए तेज़ लॉन्च और परिनियोजन की आवश्यकता होती है, लेकिन बिल्ड की आवृत्ति बढ़ने से अधिक परीक्षण बनते हैं और विकास की अड़चनें पैदा होती हैं।

ऐसी स्थिति में टीमों के लिए जहां धीमे परीक्षण चक्र तेजी से विकास को रोक रहे हैं, परीक्षण प्रभाव विश्लेषण केवल परिवर्तित स्रोत कोड के लिए प्रासंगिक परीक्षण चलाकर विकास चक्र को तेज करने का एक तरीका है।

परीक्षण प्रभाव विश्लेषण क्या है?

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

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

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

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

परीक्षण प्रभाव विश्लेषण कैसे करें

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

कार्यक्रम संशोधित फ़ाइलों की समीक्षा करता है और देखता है कि परिवर्तन के लिए आपको कौन से परीक्षण चलाने की आवश्यकता है।

समय के साथ कोड परिवर्तन के रूप में सटीक निर्भरता ग्राफ रखने के लिए आपको मानचित्र को नियमित रूप से अपडेट करने की आवश्यकता है।

हैंड्स-ऑन पायथन कोड उदाहरण: मैनुअल टेस्ट इम्पैक्ट एनालिसिस

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

• लॉग इन करें
• खाता निर्माण
• पासवर्ड रीसेट

प्रत्येक संशोधित घटक के लिए, परीक्षण को उस सूची में जोड़ें जिसे हम परीक्षण निष्पादन ढांचे में पारित कर सकते हैं।

 # Define a dictionary that maps test names to the modules or components they are testing tests_by_component = { "test_login": ["login_module"], "test_account_creation": ["account_creation_module"], "test_password_reset": ["password_reset_module"] } # Define a list of the components that have been modified # This should be dynamically generated based on the code changes. modified_components = ["login_module"] # Determine which tests are likely to be affected by the changes affected_tests = [] for test, components in tests_by_component.items(): for component in components: if component in modified_components: affected_tests.append(test) # Now, we can pass the affected tests to our test harness. print(affected_tests) # Output: ["test_login"]

परीक्षण प्रभाव विश्लेषण के लाभ और चुनौतियाँ

कुशलतापूर्वक किए जाने पर, परीक्षण प्रभाव विश्लेषण कई लाभों के साथ आता है, जिनमें निम्न शामिल हैं:

• पुन: परीक्षण पर लगने वाले समय को कम करना

• परीक्षण प्रक्रिया की समग्र दक्षता में सुधार

• बेहतर डेवलपर अनुभव

  
  

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

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

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

बढ़ते हुए संगठन में सॉफ्टवेयर परीक्षण: परीक्षण की सामान्य स्थिति

आइए एक बहुत ही परिचित परिदृश्य के माध्यम से चलते हैं - एक मिडसाइज़्ड टेक स्टार्टअप में एक सॉफ्टवेयर डेवलपमेंट टीम ने पिछले तीन वर्षों में विस्फोटक वृद्धि का आनंद लिया है।

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

यहाँ से काँहा जायेंगे?

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

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

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

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

इंजीनियरिंग टीम को चिंता होने लगी है कि यह स्थिति अस्थिर है।

• क्या होता है अगर कोई टूटे हुए कोड को मर्ज कर देता है क्योंकि उन्होंने उस परीक्षण को नजरअंदाज कर दिया है जो समस्या को पकड़ लेता?

• परतदार परीक्षणों को फिर से चलाने के लिए टीम क्लाउड संसाधनों पर कितना पैसा खर्च कर रही है जिसे वे अंततः अनदेखा करते हैं?

• परीक्षणों के चलने की प्रतीक्षा में वे कितना समय बर्बाद कर रहे हैं?

  
  

स्टार्टअप के इंजीनियरिंग प्रमुख ने फैसला किया कि इससे पहले कि यह एक महंगी घटना का कारण बनता है, DevOps तकनीकी ऋण से आगे निकलने का समय आ गया है।

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

भविष्य कहनेवाला परीक्षण चयन के साथ परीक्षण प्रभाव विश्लेषण को आगे बढ़ाना

भविष्य कहनेवाला परीक्षण चयन परीक्षण प्रभाव विश्लेषण की एक शाखा है जो डेटा का उपयोग यह अनुमान लगाने के लिए करता है कि ऐतिहासिक परीक्षण परिणामों और कोड परिवर्तनों के आधार पर आपके CI सिस्टम को कौन से परीक्षण चलाने की आवश्यकता है।

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

लॉन्चेबल का प्रिडिक्टिव टेस्ट सिलेक्शन सॉफ्टवेयर डेवलपमेंट को कारगर बनाने के लिए मशीन लर्निंग की शक्ति का उपयोग करके टेस्ट इम्पैक्ट एनालिसिस को हल करता है। प्रिडिक्टिव टेस्ट सिलेक्शन डेटा-संचालित इंटेलिजेंस का उपयोग यह निर्धारित करने के लिए करता है कि कौन से परीक्षण प्रत्येक प्रकार के परिवर्तन के लिए सबसे उपयुक्त हैं।

आप कम बर्बाद संसाधनों के साथ टेस्ट रन की संख्या कम कर सकते हैं और डिलीवरी के समय में तेजी ला सकते हैं।

इस अभ्यास के अभाव में, टीमों को मैन्युअल रूप से " धूम्रपान परीक्षणों " के सबसेट बनाने पड़ते हैं या उनके परीक्षणों को समानांतर करना पड़ता है।

पिछले परिदृश्य में, स्टार्टअप की विकास टीम प्रिडिक्टिव टेस्ट सिलेक्शन से लाभान्वित हो सकती है। उनके डेवलपर सबसे महत्वपूर्ण सुविधाओं को वितरित करने पर ध्यान केंद्रित कर सकते हैं, अपने वर्कफ़्लो को तेज़ कर सकते हैं और टेस्ट सूट पर फिर से भरोसा कर सकते हैं।

हैंड्स-ऑन पायथन कोड सैंपल: लॉन्चेबल और पाइस्टेस्ट के साथ प्रेडिक्टिव टेस्ट सिलेक्शन

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

लॉन्च करने योग्य के साथ पाइस्टेस्ट सेटअप और निष्पादन

1. अपने वातावरण में पाइस्टेस्ट-लॉन्चेबल स्थापित करने के लिए pip3 install pytest-launchable उपयोग करें

   
   

2. लॉन्च करने योग्य कॉन्फ़िगरेशन फ़ाइल चलाकर launchable-config --create फ़ाइल जनरेट करें ।

   
   

3. https://app.launchableinc.com/ से लॉन्च करने योग्य API कुंजी जेनरेट करें

   
   

   1. इसे परीक्षण चलाने वाली मशीन पर LAUNCHABLE_TOKEN पर्यावरण परिवर्तक के रूप में सेट करें।

      
      

4. आपकी लॉन्च करने योग्य कॉन्फ़िगरेशन फ़ाइल वाली निर्देशिका से, pytest --launchable <your-pytest-project> चलाएँ

   
   

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

परीक्षण प्रभाव विश्लेषण पर अंतिम विचार, भविष्य कहनेवाला परीक्षण चयन, और अपनी पाइपलाइन को डेटा-चालित बनाना

लॉन्चेबल के एमएल-चालित प्रिडिक्टिव टेस्ट चयन के साथ, टीमों को आमतौर पर गुणवत्ता को प्रभावित किए बिना परीक्षण के समय में 60-80% की कमी दिखाई देती है।

लॉन्चेबल के प्रिडिक्टिव सिलेक्शन फीचर को चुनने के प्राथमिक कारण हैं:

• डेवलपर का समय बचाएं

• इंफ्रास्ट्रक्चर खर्च कम करें

• शिप कोड तेजी से

  
  

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

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

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