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

नमस्कार, हेब्र!

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

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



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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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



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

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

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

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

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



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



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

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

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

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

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