स्वचालित प्रतिगमन परीक्षण दृष्टिकोण

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

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

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

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

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

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

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

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

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

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

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

प्रतिगमन परीक्षणों की पहचान और कार्यान्वयन

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

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

• उत्पादन से डेटाबेस बैकअप, दो बार बहाल;
• दो परीक्षण प्रणाली स्थापित हैं जो समानांतर में काम करती हैं:
  
  • एक उत्पादन कोड के साथ एक;
  • परीक्षण के तहत आवेदन के वर्तमान संस्करण के साथ एक और।

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

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

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

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

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

इस ऑपरेशन के लिए, हम वेब सेवा इंटरफ़ेस का उपयोग करते हैं। सभी रिपोर्टों को दो प्रणालियों पर समानांतर में भेजा जाता है, परिणामस्वरूप, JSON प्रारूप में प्राप्त प्रतिक्रिया की तुलना की जाती है।

तुलना तीन मोर्चों पर होती है:

• स्रोत (उत्पादन) माइनस लक्ष्य (परीक्षण के तहत आवेदन);
• लक्ष्य शून्य स्रोत;
• चौराहे को प्राप्त करने के लिए मूल्यों की तुलना।

यह विधि XML, XLS, CSV तय चौड़ाई या किसी अन्य प्रारूप के लिए काम करेगी। हमें यह सुनिश्चित करने की आवश्यकता है कि कोई अनावश्यक रिकॉर्ड नहीं हैं, कोई रिकॉर्ड गायब नहीं हैं, और रिकॉर्ड के सभी मान मेल खाते हैं।

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

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

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

कार्यक्रम की स्थापना

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

• ई-मेल आइडेंटिफ़ायर या अन्य गोपनीय जानकारी को हटाकर उत्पादन से "भ्रमित करें" डेटा, या इसे काल्पनिक डेटा से बदल दें;

  
  

• परीक्षण चलाने के लिए उचित रूप में डेटा प्राप्त करें;

  
  

• क्यूए पर्यावरण के लिए अनुकूली सेटिंग्स, उदाहरण के लिए, एकीकरण संबंधों को बदलकर।

  
  

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

  
  

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

  
  

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

  
  

  भिन्नताएँ प्रौद्योगिकियों के साथ शुरू हो सकती हैं - JSON, XML, या स्केलर्स (int / string / float), और तब तक विस्तृत करें जब तक परीक्षण और उत्पादन के तहत आवेदन विभिन्न संरचनाओं के साथ प्रतिक्रिया नहीं करता, लेकिन फिर भी वास्तुकला का अनुपालन करता है। उदाहरण के लिए, उत्पादन संस्करण पुरानी JAR फ़ाइल का उपयोग कर सकता है, जो एक विशिष्ट प्रारूप में काम करता है, और नए संस्करण में JAR फ़ाइल को अद्यतन किया गया था और अब प्रतिक्रिया स्वरूप बदल गया है, इसलिए उनकी तुलना असंगतता दिखाएगी। उन्हें ठीक से तुलना करने के लिए, आपको एक अस्थायी प्लग-इन की आवश्यकता है।

  
  

  शायद ऐसी कुछ ही स्थितियाँ होंगी। ऐसे मामलों में, कभी-कभी डिज़ाइन को मोड़ना या उन्हें वर्कअराउंड के संदर्भ में विचार करना अधिक आसान होता है।

  
  

  इस तरह की तुलना से निपटने के लिए कई विकल्प हैं:

  
  

• कुछ फ़ील्ड्स को अनदेखा करें, जैसे कि पहचानकर्ता और दिनांक;

  
  

• 0.0001 से कम संख्यात्मक अंतर पर ध्यान न दें;

  
  

• मामले की संवेदनशीलता को अनदेखा करें;

  
  

• संरचना दो उत्तरों में बदलती है।

  
  

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

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

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

अनुवाद विशेष रूप से "पायथन क्यूए इंजीनियर" पाठ्यक्रम के छात्रों के लिए तैयार किया गया था।