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

पहला भाग यहाँ है ।



स्थिति की कल्पना करो। आप नई कार्यक्षमता विकसित करने के कार्य के साथ सामना कर रहे हैं। आप अपने पूर्ववर्तियों से घटनाक्रम है। यह मानते हुए कि आपके पास कोई नैतिक दायित्व नहीं है, आप क्या करेंगे?

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

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

तो, चलो हमारी इकाई परीक्षण प्रणाली को लागू करने के परिणामों के बारे में बात करते हैं।

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

आगे क्या है

चलो स्वचालित परीक्षण परियोजना के लिए विकास योजनाओं के बारे में बात करते हैं।

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

जैसे-जैसे ऑटोटेस्ट्स की संख्या बढ़ेगी, उनके काम का कुल समय लगातार बढ़ता जाएगा, और हमें फिर से उत्पादकता के मुद्दे पर लौटना होगा। सबसे अधिक संभावना है, समाधान समानांतर धागे की संख्या में वृद्धि होगी।

लेकिन ये स्पष्ट विकास पथ हैं। यदि हम कुछ और गैर-तुच्छ के बारे में बात करते हैं, तो हम निम्नलिखित पर प्रकाश डालते हैं:

1. वर्तमान में, ऑटोटेस्ट्स को डीबीएमएस स्तर पर प्रबंधित किया जाता है, अर्थात। आपको सफलतापूर्वक काम करने के लिए PL / SQL ज्ञान की आवश्यकता है। यदि आवश्यक हो, तो सिस्टम को नियंत्रित करें (उदाहरण के लिए, मेटाडेटा को लॉन्च करना या बनाना), आप जेनकिन्स या कुछ समान का उपयोग करके किसी प्रकार का व्यवस्थापक पैनल बना सकते हैं।
2. सभी को मात्रात्मक और गुणात्मक संकेतक पसंद हैं। स्वचालित परीक्षण के लिए, इस तरह का एक सार्वभौमिक मीट्रिक कोड कवरेज या कोड कवरेज मीट्रिक है। इस सूचक का उपयोग करके, हम यह निर्धारित कर सकते हैं कि हमारे परीक्षण प्रणाली के कोड का कितना प्रतिशत ऑटोटेस्ट द्वारा कवर किया गया है। संस्करण 12.2 से शुरू होकर, ओरेकल इस मीट्रिक की गणना करने की क्षमता प्रदान करता है और मानक पैकेज DBMS_PLSQL_CODE_COVERAGE का उपयोग करने का सुझाव देता है।
   
   हमारा ऑटोटेस्ट सिस्टम एक साल से थोड़ा अधिक पुराना है, और शायद अब कवरेज का मूल्यांकन करने का समय है। मेरे पिछले प्रोजेक्ट में (स्पोर्टमास्टर का नहीं) एक प्रोजेक्ट हुआ। ऑटोटेस्ट पर काम करने के एक साल बाद, प्रबंधन ने यह निर्धारित करने के लिए एक लक्ष्य निर्धारित किया कि हम कितने प्रतिशत कोड को कवर करते हैं। 1% से अधिक की कवरेज के साथ, प्रबंधन खुश होगा। हम, डेवलपर्स, लगभग 10% के परिणाम की उम्मीद करते हैं। खराब किए गए कोड कवरेज, 20% प्राप्त किए गए। जश्न मनाने के लिए, हम एक पुरस्कार के लिए गए, लेकिन हम इसके लिए कैसे गए और हम बाद में कहां गए यह पूरी तरह से अलग कहानी है।
3. ऑटो परीक्षण उजागर वेब सेवाओं की जांच कर सकते हैं। ओरेकल आपको ऐसा करने की अनुमति देता है, और हम अब कई समस्याओं का सामना नहीं करेंगे।
4. और, ज़ाहिर है, हमारे स्वचालित परीक्षण प्रणाली को किसी अन्य परियोजना पर लागू किया जा सकता है। हमारा समाधान सार्वभौमिक है और बस ओरेकल के उपयोग की आवश्यकता है। मैंने सुना है कि स्पोर्टमास्टर की अन्य परियोजनाओं पर स्वचालित परीक्षण में रुचि है और, शायद, हम उनके पास जाएंगे।

निष्कर्ष

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

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

टिप्पणी लिखें अगर वहाँ अंक हैं जिस पर यह भविष्य में ध्यान देने योग्य है, या प्रकटीकरण की आवश्यकता वाले प्रश्न हैं।