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

पहला भाग - यहां.

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

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

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

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

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

6. ऑटोटेस्ट ऐसे समय में शुरू और चलना चाहिए जो आपके सिस्टम के लिए स्वीकार्य हो। इसलिए, एक दैनिक रात्रि लॉन्च का आयोजन किया गया, जिसके परिणामों के आधार पर परिणामों पर एक रिपोर्ट तैयार की जाती है और कॉर्पोरेट मेल के माध्यम से संपूर्ण विकास टीम को भेजी जाती है। पुराने ऑटोटेस्ट को पुनर्स्थापित करने और नए बनाने के बाद, कुल परिचालन समय 30 मिनट था। यह प्रदर्शन सभी के अनुकूल था, क्योंकि लॉन्च कार्य घंटों के बाहर हुआ था।

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

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

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

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

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

तो, आइए हमारी इकाई परीक्षण प्रणाली के उपयोग के परिणामों के बारे में बात करें।

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

आगे क्या है

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

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

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

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

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

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

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

निष्कर्ष

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

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

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

केवल पंजीकृत उपयोगकर्ता ही सर्वेक्षण में भाग ले सकते हैं। साइन इन करेंकृपया।

क्या हम इसके बारे में आगे लिखेंगे?

• हां बिल्कुल

• जी नहीं, धन्यवाद

12 उपयोगकर्ताओं ने मतदान किया। 4 उपयोगकर्ता अनुपस्थित रहे।

स्रोत: www.habr.com