डीबीएमएस में यूनिट परीक्षण - हम इसे स्पोर्टमास्टर में कैसे करते हैं, भाग एक

हे हबर!

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

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

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

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

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

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

वफादारी का परीक्षण

सबसे पहले, आइए उस परियोजना के बारे में बात करें जहां हमने एक स्वचालित परीक्षण प्रणाली तैनात की है। हमारा प्रोजेक्ट स्पोर्टमास्टर लॉयल्टी सिस्टम है (वैसे, हम इसके बारे में पहले ही लिख चुके हैं ये पद).

यदि आपकी कंपनी काफी बड़ी है, तो आपकी लॉयल्टी प्रणाली में तीन मानक गुण होंगे:

• आपका सिस्टम अत्यधिक लोड हो जाएगा
• आपके सिस्टम में जटिल कंप्यूटिंग प्रक्रियाएँ होंगी
• आपके सिस्टम में सक्रिय रूप से सुधार किया जाएगा.

आइए क्रम से चलें... कुल मिलाकर, यदि हम सभी स्पोर्टमास्टर ब्रांडों पर विचार करें, तो हमारे पास रूस, यूक्रेन, चीन, कजाकिस्तान और बेलारूस में 1000 से अधिक स्टोर हैं। इन स्टोर्स से हर दिन लगभग 300 खरीदारी होती है। यानी हर सेकंड 000-3 चेक हमारे सिस्टम में आते हैं. स्वाभाविक रूप से, हमारी वफादारी प्रणाली अत्यधिक भरी हुई है। और चूंकि इसका सक्रिय रूप से उपयोग किया जाता है, इसलिए हमें इसकी गुणवत्ता के उच्चतम मानक प्रदान करने चाहिए, क्योंकि सॉफ़्टवेयर में किसी भी त्रुटि का मतलब बड़े मौद्रिक, प्रतिष्ठित और अन्य नुकसान हैं।

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

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

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

वर्णित संपत्तियाँ लगभग किसी भी वफादारी प्रणाली के लिए मानक हैं। आइए हमारे प्रोजेक्ट की विशेषताओं के बारे में बात करें।

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

स्पोर्टमास्टर में लॉयल्टी सिस्टम 7 वर्षों से अधिक समय से अस्तित्व में है और इसे एकल डेवलपर्स द्वारा बनाया गया था... इन 7 वर्षों के दौरान हमारे प्रोजेक्ट पर डेवलपर्स की औसत संख्या 3-4 लोग थे। लेकिन पिछले वर्ष में, हमारी टीम में काफी वृद्धि हुई है, और अब इस परियोजना पर 10 लोग काम कर रहे हैं। अर्थात्, ऐसे लोग परियोजना में आते हैं जो विशिष्ट कार्यों, प्रक्रियाओं और वास्तुकला से परिचित नहीं होते हैं। और यह जोखिम बढ़ गया है कि हम गलतियाँ करने से चूक जायेंगे।

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

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

utPLSQL बचाव के लिए आता है

क्या आप स्टीफन फ्यूरस्टीन के बारे में कुछ जानते हैं?

यह एक चतुर व्यक्ति है जिसने अपने करियर का एक लंबा हिस्सा ओरेकल और पीएल/एसक्यूएल के साथ काम करने के लिए समर्पित किया है, और इस विषय पर काफी बड़ी संख्या में काम लिखा है। उनकी प्रसिद्ध पुस्तकों में से एक का नाम है: “Oracle PL/SQL. पेशेवरों के लिए।" यह स्टीफन ही थे जिन्होंने utPLSQL समाधान विकसित किया, या, जैसा कि इसका अर्थ है, Oracle PL/SQL के लिए यूनिट टेस्टिंग फ्रेमवर्क। utPLSQL समाधान 2016 में बनाया गया था, लेकिन इस पर सक्रिय रूप से काम किया जा रहा है और नए संस्करण जारी किए गए हैं। रिपोर्टिंग के समय, नवीनतम संस्करण 24 मार्च, 2019 का है।
यह क्या है। यह एक अलग ओपन सोर्स प्रोजेक्ट है। उदाहरण और दस्तावेज़ीकरण सहित इसका वजन कुछ मेगाबाइट है। भौतिक रूप से, यह ORACLE डेटाबेस में यूनिट परीक्षण के आयोजन के लिए पैकेज और तालिकाओं के एक सेट के साथ एक अलग स्कीमा है। इंस्टालेशन में कुछ सेकंड लगते हैं. utPLSQL की एक विशिष्ट विशेषता इसके उपयोग में आसानी है।
विश्व स्तर पर, utPLSQL यूनिट परीक्षण चलाने के लिए एक तंत्र है, जहां एक यूनिट परीक्षण को सामान्य Oracle बैच प्रक्रियाओं के रूप में समझा जाता है, जिसका संगठन कुछ नियमों का पालन करता है। लॉन्च करने के अलावा, utPLSQL आपके सभी परीक्षण रनों का एक लॉग संग्रहीत करता है, और इसमें एक आंतरिक रिपोर्टिंग प्रणाली भी है।

आइए एक उदाहरण देखें कि इस तकनीक का उपयोग करके कार्यान्वित इकाई परीक्षण कोड कैसा दिखता है।

तो, स्क्रीन यूनिट परीक्षणों के साथ एक विशिष्ट पैकेज विनिर्देश के लिए कोड दिखाती है। अनिवार्य आवश्यकताएँ क्या हैं? पैकेट के पहले "utp_" लगा होना चाहिए। परीक्षण वाली सभी प्रक्रियाओं में बिल्कुल समान उपसर्ग होना चाहिए। पैकेज में दो मानक प्रक्रियाएँ होनी चाहिए: "utp_setup" और "utp_teardown"। पहली प्रक्रिया को प्रत्येक इकाई परीक्षण को पुनरारंभ करके बुलाया जाता है, दूसरा - लॉन्च के बाद।

"utp_setup", एक नियम के रूप में, हमारे सिस्टम को यूनिट परीक्षण चलाने के लिए तैयार करता है, उदाहरण के लिए, परीक्षण डेटा बनाना। "utp_teardown" - इसके विपरीत, सब कुछ मूल सेटिंग्स पर वापस आ जाता है और लॉन्च परिणामों को रीसेट कर देता है।

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

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

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

इस प्रकार यूनिट परीक्षण चलाए जाते हैं। दो संभावित लॉन्च विकल्प हैं: एक विशिष्ट पैकेज से सभी यूनिट परीक्षण चलाना या एक विशिष्ट पैकेज में एक विशिष्ट यूनिट परीक्षण चलाना।

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

ऑटोटेस्ट के 6 नियम

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

1. ऑटोटेस्ट प्रभावी होना चाहिए और उपयोगी होना चाहिए। हमारे पास अद्भुत डेवलपर्स हैं, जिनका उल्लेख निश्चित रूप से आवश्यक है, क्योंकि उनमें से कुछ शायद इस रिपोर्ट को देखेंगे, और वे अद्भुत कोड लिखते हैं। लेकिन उनका अद्भुत कोड भी सही नहीं है और उसमें त्रुटियां हैं, हैं और रहेंगी। इन त्रुटियों को खोजने के लिए ऑटोटेस्ट की आवश्यकता होती है। यदि यह मामला नहीं है, तो या तो हम खराब ऑटोटेस्ट लिख रहे हैं, या हम एक मृत क्षेत्र में आ गए हैं, जो सिद्धांत रूप में विकसित नहीं हो रहा है। दोनों ही मामलों में, हम कुछ गलत कर रहे हैं, और हमारा दृष्टिकोण बिल्कुल भी समझ में नहीं आता है।
2. ऑटोटेस्ट का उपयोग किया जाना चाहिए। किसी सॉफ़्टवेयर उत्पाद को लिखने में बहुत अधिक समय और प्रयास खर्च करने, उसे भंडार में रखने और भूल जाने का कोई मतलब नहीं है। परीक्षण चलाए जाने चाहिए और यथासंभव नियमित रूप से चलाए जाने चाहिए।
3. ऑटोटेस्ट को स्थिर रूप से काम करना चाहिए। दिन के समय, लॉन्च स्टैंड और अन्य सिस्टम सेटिंग्स के बावजूद, परीक्षण रन का परिणाम समान होना चाहिए। एक नियम के रूप में, यह इस तथ्य से सुनिश्चित होता है कि ऑटोटेस्ट निश्चित सिस्टम सेटिंग्स के साथ विशेष परीक्षण डेटा के साथ काम करते हैं।
4. ऑटोटेस्ट को आपके प्रोजेक्ट के लिए स्वीकार्य गति से काम करना चाहिए। यह समय प्रत्येक सिस्टम के लिए अलग-अलग निर्धारित किया जाता है। कुछ लोग पूरे दिन काम कर सकते हैं, जबकि अन्य इसे सेकंडों में करना महत्वपूर्ण समझते हैं। मैं आपको थोड़ी देर बाद बताऊंगा कि हमने अपने प्रोजेक्ट में कौन से गति मानक हासिल किए हैं।
5. ऑटोटेस्ट विकास लचीला होना चाहिए। किसी भी कार्यक्षमता का परीक्षण करने से केवल इसलिए इनकार करना उचित नहीं है क्योंकि हमने इसे पहले नहीं किया है या किसी अन्य कारण से। utPLSQL विकास पर कोई प्रतिबंध नहीं लगाता है, और Oracle, सिद्धांत रूप में, आपको विभिन्न प्रकार की चीजों को लागू करने की अनुमति देता है। अधिकांश समस्याओं का समाधान होता है, यह केवल समय और प्रयास की बात है।
6. तैनाती. हमारे पास कई स्टैंड हैं जहां हमें परीक्षण चलाने की आवश्यकता है। प्रत्येक स्टैंड पर, डेटा डंप को किसी भी समय अपडेट किया जा सकता है। किसी प्रोजेक्ट को स्वचालित परीक्षणों के साथ इस तरह से संचालित करना आवश्यक है कि आप दर्द रहित तरीके से इसकी पूर्ण या आंशिक स्थापना कर सकें।

और कुछ दिनों में दूसरी पोस्ट में मैं आपको बताऊंगा कि हमने क्या किया और क्या परिणाम हासिल किए।

स्रोत: www.habr.com