स्वचालन प्रणाली एकीकरण परीक्षण

नमस्कार, खभ्रवर्णों!

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

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

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

हमने इसकी कल्पना कैसे की

तस्वीर सरल थी और सभी ने इसे पसंद किया।

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

सेवा वर्चुअलाइजेशन (मोक्स, स्टब्स)

सवाल उठता है, और बैक-एंड सिस्टम के रूप में हमारे पर्यावरण में क्या उपयोग करना है? जाहिर है, एक वास्तविक बैक-एंड सिस्टम कई कारणों से उपयुक्त नहीं है:

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

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

यह पता चला कि वहाँ कहीं भी देखने के लिए नहीं है, क्योंकि बाजार पर केवल 5 ऐसे उत्पाद हैं:

• पैरासॉफ्ट सोआटेस्ट
• सीए लिसा सेवा वर्चुअलाइजेशन
• आईबीएम तर्कसंगत सेवा परीक्षक
• एचपी सेवा वर्चुअलाइजेशन
• साबुन यूआई

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

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

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

प्रत्येक आभासी सेवा एक मावेन परियोजना है। प्रोजेक्ट कॉन्फ़िगरेशन (सेवा-डिस्क्रिप्टर.एक्सएमएल, प्रतिक्रिया-चयनकर्ता.एक्सएलएम) में यह लिखा जाता है कि कैसे, HTTP अनुरोध के आधार पर, यह निर्धारित करने के लिए कि किस सेवा को कहा जाता है, किस ऑपरेशन की आवश्यकता है, और HTTP प्रतिक्रिया वापस करने के लिए किस नियम से।



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

और अब हम एक परीक्षण लिख रहे हैं

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

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



जेनकिन्स में हर रात टेस्ट अपने आप चलता है।

डेटा निर्माण का परीक्षण करें

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

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

क्या हुआ?

बेशक, हम पूरी तरह से एकीकरण परत को कवर करने में सक्षम नहीं थे, जो दस वर्षों में परीक्षण के साथ बनाया गया था।

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

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

भविष्य की योजना

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

क्या आप एकीकरण का परीक्षण करते हैं? अपना अनुभव साझा करें!