DBMS मधील युनिट चाचण्या - स्पोर्टमास्टरमध्ये आम्ही ते कसे करतो, भाग दोन

पहिला भाग - येथे.

परिस्थितीची कल्पना करा. नवीन कार्यक्षमता विकसित करण्याचे कार्य तुमच्यासमोर आहे. आपल्याकडे आपल्या पूर्वसुरींच्या घडामोडी आहेत. जर आम्ही असे गृहीत धरले की तुमची कोणतीही नैतिक जबाबदारी नाही, तर तुम्ही काय कराल?

बर्याचदा, सर्व जुन्या घडामोडी विसरल्या जातात आणि सर्वकाही पुन्हा सुरू होते. कुणालाही दुसर्‍याच्या कोडमध्ये खोदायला आवडत नाही, पण जर तुमच्याकडे वेळ असेल तर तुमची स्वतःची सिस्टीम का तयार करू नये? हा एक नमुनेदार दृष्टीकोन आहे आणि तो बऱ्याच अंशी बरोबर आहे. पण आमच्या प्रकल्पात आम्ही ते चुकीचे केले. आम्ही आमच्या पूर्ववर्तींच्या utPLSQL वरील युनिट चाचण्यांमधील घडामोडींवर भविष्यातील स्वयंचलित चाचणी प्रणाली आधारित केली आणि नंतर अनेक समांतर दिशानिर्देशांमध्ये काम केले.

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

   लाँचरला एका मजकूर इनपुट पॅरामीटरसह एक सार्वत्रिक प्रक्रिया म्हणून प्रस्तुत केले जाते. पॅरामीटर म्हणून, तुम्ही ऑटोटेस्ट नेमोनिक कोड, पॅकेज नाव, चाचणी नाव, ऑटोटेस्ट सेटिंग किंवा आरक्षित कीवर्ड पास करू शकता. प्रक्रिया अटी पूर्ण करणार्‍या सर्व ऑटोटेस्ट्स निवडते आणि चालवते.

   डेटा जनरेशन मॉड्यूल एका पॅकेजच्या स्वरूपात सादर केले जाते ज्यामध्ये चाचणी अंतर्गत सिस्टमच्या प्रत्येक ऑब्जेक्टसाठी (डेटाबेसमधील एक टेबल), एक विशेष प्रक्रिया तयार केली गेली आहे जी तेथे डेटा समाविष्ट करते. या प्रक्रियेमध्ये, डीफॉल्ट मूल्ये शक्य तितकी भरली जातात, जे बोटाच्या एका क्लिकवर अक्षरशः वस्तूंची निर्मिती सुनिश्चित करते. आणि वापर सुलभतेसाठी, व्युत्पन्न केलेल्या डेटासाठी टेम्पलेट्स तयार केले गेले. उदाहरणार्थ, चाचणी फोन आणि पूर्ण खरेदीसह विशिष्ट वयाचा क्लायंट तयार करा.

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

   पण कामाचा वेग अनुकूल करण्यावर काम करायचं होतं. उत्पादनातील निष्ठा प्रणाली रात्री अद्यतनित केली जाते. एका प्रकाशनाचा भाग म्हणून, आम्हाला रात्री तातडीचे बदल करावे लागले. सकाळी तीन वाजता ऑटोटेस्टच्या निकालासाठी अर्धा तास प्रतीक्षा केल्याने रिलीझसाठी जबाबदार असलेल्या व्यक्तीला आनंद झाला नाही (अलेक्सी वास्युकोव्हला उत्कट अभिवादन!), आणि दुसऱ्या दिवशी सकाळी आमच्या सिस्टमबद्दल अनेक दयाळू शब्द बोलले गेले. परंतु परिणामी, कामासाठी 5-मिनिटांचे मानक स्थापित केले गेले.

   कार्यप्रदर्शन वेगवान करण्यासाठी, आम्ही दोन पद्धती वापरल्या: ऑटोटेस्ट तीन समांतर थ्रेड्समध्ये चालू लागल्या, सुदैवाने आमच्या निष्ठा प्रणालीच्या आर्किटेक्चरमुळे हे खूप सोयीचे आहे. आणि आम्ही हा दृष्टीकोन सोडला आहे जिथे ऑटोटेस्ट स्वतःसाठी चाचणी डेटा तयार करत नाही, परंतु सिस्टममध्ये काहीतरी योग्य शोधण्याचा प्रयत्न करतो. बदल केल्यानंतर, एकूण ऑपरेटिंग वेळ 3-4 मिनिटांपर्यंत कमी करण्यात आला.

7. स्वयंचलित चाचण्यांसह प्रकल्प विविध स्टँडवर तैनात करण्यात सक्षम असावा. आमच्या प्रवासाच्या सुरुवातीस, आमच्या स्वत: च्या बॅच फाइल्स लिहिण्याचा प्रयत्न झाला, परंतु हे स्पष्ट झाले की स्वयं-लिखित स्वयंचलित स्थापना संपूर्ण भयपट आहे, आणि आम्ही औद्योगिक उपायांकडे वळलो. प्रोजेक्टमध्ये बरेच डायरेक्ट कोड आहेत (सर्वप्रथम, आम्ही ऑटोटेस्ट कोड संग्रहित करतो) आणि फारच कमी डेटा (मुख्य डेटा ऑटोटेस्ट्सबद्दल मेटाडेटा आहे), लिक्विबेस प्रोजेक्टमध्ये अंमलबजावणी अगदी सोपी झाली.

   हे डेटाबेस स्कीमा बदलांचा मागोवा घेण्यासाठी, व्यवस्थापित करण्यासाठी आणि अंमलबजावणीसाठी एक मुक्त-स्रोत, डेटाबेस-स्वतंत्र लायब्ररी आहे. कमांड लाइन किंवा Apache Maven सारख्या फ्रेमवर्कद्वारे व्यवस्थापित. Liquibase च्या ऑपरेशनचे सिद्धांत अगदी सोपे आहे. आमच्याकडे एक विशिष्ट प्रकारे आयोजित केलेला प्रकल्प आहे, ज्यामध्ये बदल किंवा स्क्रिप्ट असतात ज्यांना लक्ष्य सर्व्हरवर रोल आउट करणे आवश्यक आहे आणि हे बदल कोणत्या क्रमाने आणि कोणत्या पॅरामीटर्ससह स्थापित केले जावेत हे निर्धारित करणार्‍या फायली नियंत्रित करतात.

   DBMS स्तरावर, एक विशेष सारणी तयार केली जाते ज्यामध्ये Liquibase रोलओव्हर लॉग संग्रहित करते. प्रत्येक बदलामध्ये गणना केलेला हॅश असतो, ज्याची डेटाबेसमधील प्रकल्प आणि राज्य यांच्यामध्ये प्रत्येक वेळी तुलना केली जाते. लिक्विबेसचे आभार, आम्ही आमच्या सिस्टममधील बदल कोणत्याही सर्किटमध्ये सहज आणू शकतो. ऑटोटेस्ट्स आता चाचणी आणि रिलीझ सर्किट्सवर तसेच कंटेनरवर (विकासकांच्या वैयक्तिक सर्किट्स) लाँच केल्या जातात.

तर, आमच्या युनिट चाचणी प्रणाली वापरण्याच्या परिणामांबद्दल बोलूया.

1. अर्थात, सर्वप्रथम, आम्हाला खात्री आहे की आम्ही अधिक चांगले सॉफ्टवेअर विकसित करण्यास सुरुवात केली आहे. ऑटोटेस्ट्स रोज लाँच केल्या जातात आणि प्रत्येक रिलीझमध्ये डझनभर त्रुटी आढळतात. शिवाय, यातील काही त्रुटी केवळ अप्रत्यक्षपणे त्या कार्यक्षमतेशी संबंधित आहेत जी आम्हाला खरोखर बदलायची होती. मॅन्युअल चाचणीत या त्रुटी आढळल्या असल्याच्या गंभीर शंका आहेत.
2. संघाला आता विश्वास आहे की विशिष्ट कार्यक्षमता योग्यरित्या कार्य करत आहे... सर्व प्रथम, हे आमच्या गंभीर प्रक्रियेशी संबंधित आहे. उदाहरणार्थ, गेल्या सहा महिन्यांत आम्हाला रिलीझमध्ये बदल करूनही, पावत्यांवरील सूट आणि बोनसच्या वितरणात कोणतीही समस्या आली नाही, जरी मागील कालावधीत काही वारंवारतेसह त्रुटी आल्या.
3. आम्ही चाचणी पुनरावृत्तीची संख्या कमी करण्यात व्यवस्थापित केले. नवीन कार्यक्षमतेसाठी ऑटोटेस्ट्स लिहिल्या जातात या वस्तुस्थितीमुळे, विश्लेषक आणि अर्धवेळ परीक्षकांना उच्च गुणवत्तेचा कोड प्राप्त होतो, कारण ते आधीच तपासले गेले आहे.
4. स्वयंचलित चाचणीमधील काही विकास विकासक वापरतात. उदाहरणार्थ, ऑब्जेक्ट जनरेशन मॉड्यूल वापरून कंटेनरवरील चाचणी डेटा तयार केला जातो.
5. आम्ही विकसकांच्या बाजूने स्वयंचलित चाचणी प्रणालीची "स्वीकृती" विकसित केली आहे हे महत्त्वाचे आहे. एक समज आहे की हे महत्वाचे आणि उपयुक्त आहे. परंतु माझ्या स्वत: च्या अनुभवावरून मी असे म्हणू शकतो की हे प्रकरण खूप दूर आहे. ऑटोटेस्ट्स लिहिणे आवश्यक आहे, त्यांना समर्थित आणि विकसित करणे आवश्यक आहे, परिणामांचे विश्लेषण केले जाणे आवश्यक आहे आणि बहुतेकदा या वेळेच्या खर्चाची किंमत नसते. उत्पादनात जाणे आणि तेथील समस्यांना सामोरे जाणे खूप सोपे आहे. येथे, विकासक रांगेत उभे राहतात आणि आम्हाला त्यांची कार्यक्षमता ऑटोटेस्टसह कव्हर करण्यास सांगतात.

पुढे काय

चला स्वयंचलित चाचणी प्रकल्पाच्या विकास योजनांबद्दल बोलूया.

अर्थात, जोपर्यंत स्पोर्टमास्टरची निष्ठा प्रणाली जिवंत आहे आणि विकसित होत आहे, तोपर्यंत ऑटोटेस्ट्स जवळजवळ अंतहीन विकसित करणे देखील शक्य आहे. म्हणून, विकासाची मुख्य दिशा कव्हरेज क्षेत्राचा विस्तार करणे आहे.

ऑटोटेस्ट्सची संख्या जसजशी वाढत जाईल, तसतसा त्यांचा एकूण ऑपरेटिंग वेळ सतत वाढत जाईल आणि आम्हाला पुन्हा कामगिरीच्या समस्येकडे परत यावे लागेल. बहुधा, समांतर थ्रेड्सची संख्या वाढवणे हा उपाय असेल.

परंतु हे विकासाचे स्पष्ट मार्ग आहेत. जर आपण अधिक क्षुल्लक गोष्टींबद्दल बोललो तर, आम्ही खालील हायलाइट करतो:

1. सध्या, ऑटोटेस्ट व्यवस्थापन डीबीएमएस स्तरावर केले जाते, म्हणजे. यशस्वी कामासाठी PL/SQL चे ज्ञान आवश्यक आहे. आवश्यक असल्यास, सिस्टम व्यवस्थापन (उदाहरणार्थ, मेटाडेटा लॉन्च करणे किंवा तयार करणे), आपण जेनकिन्स किंवा तत्सम काहीतरी वापरून काही प्रकारचे प्रशासक पॅनेल तयार करू शकता.
2. प्रत्येकाला परिमाणवाचक आणि गुणात्मक निर्देशक आवडतात. स्वयंचलित चाचणीसाठी, असा सार्वत्रिक निर्देशक म्हणजे कोड कव्हरेज किंवा कोड कव्हरेज मेट्रिक. या निर्देशकाचा वापर करून, आम्ही हे निर्धारित करू शकतो की चाचणी अंतर्गत आमच्या सिस्टमच्या कोडची किती टक्केवारी ऑटोटेस्ट्सद्वारे संरक्षित आहे. आवृत्ती 12.2 पासून, Oracle हे मेट्रिक मोजण्याची क्षमता प्रदान करते आणि मानक DBMS_PLSQL_CODE_COVERAGE पॅकेज वापरण्याची ऑफर देते.

   आमची ऑटोटेस्ट सिस्टम फक्त एक वर्षापेक्षा जुनी आहे आणि कदाचित आता आमच्या कव्हरेजचे मूल्यांकन करण्याची वेळ आली आहे. माझ्या शेवटच्या प्रकल्पात (स्पोर्टमास्टर प्रकल्प नाही) असेच घडले. ऑटोटेस्ट्सवर काम केल्यानंतर एक वर्षानंतर, व्यवस्थापनाने आम्ही किती टक्के कोड कव्हर करतो याचे मूल्यांकन करण्याचे कार्य सेट केले. 1% पेक्षा जास्त कव्हरेजसह, व्यवस्थापन आनंदी होईल. आम्ही, विकासकांना, सुमारे 10% निकाल अपेक्षित आहे. आम्ही कोड कव्हरेज स्थापित केले, ते मोजले आणि 20% मिळाले. उत्सव साजरा करण्यासाठी, आम्ही बक्षीस घेण्यासाठी गेलो, परंतु आम्ही ते मिळवण्यासाठी कसे गेलो आणि नंतर आम्ही कुठे गेलो ही पूर्णपणे वेगळी कहाणी आहे.

3. ऑटोटेस्ट्स उघड झालेल्या वेब सेवा तपासू शकतात. ओरॅकल आम्हाला हे चांगल्या प्रकारे करू देते आणि आम्हाला यापुढे अनेक समस्यांना सामोरे जावे लागणार नाही.
4. आणि, अर्थातच, आमची स्वयंचलित चाचणी प्रणाली दुसर्‍या प्रकल्पावर लागू केली जाऊ शकते. आम्हाला मिळालेले समाधान सार्वत्रिक आहे आणि फक्त ओरॅकल वापरणे आवश्यक आहे. मी ऐकले की इतर स्पोर्टमास्टर प्रकल्पांना स्वयंचलित चाचणीमध्ये स्वारस्य आहे आणि कदाचित आम्ही त्यांच्याकडे जाऊ.

निष्कर्ष

चला सारांश द्या. स्पोर्टमास्टरमधील लॉयल्टी सिस्टम प्रकल्पावर, आम्ही स्वयंचलित चाचणी प्रणाली लागू करण्यात व्यवस्थापित केले. हे स्टीफन फ्युअरस्टीनच्या utPLSQL सोल्यूशनवर आधारित आहे. utPLSQL च्या आसपास ऑटोटेस्ट कोड आणि सहाय्यक स्व-लिखित मॉड्यूल्स आहेत: लॉन्च मॉड्यूल, डेटा जनरेशन मॉड्यूल आणि इतर. ऑटोटेस्ट्स रोज लाँच केल्या जातात आणि सर्वात महत्त्वाचे म्हणजे ते कार्य करतात आणि उपयुक्त आहेत. आम्हाला खात्री आहे की आम्ही उच्च दर्जाचे सॉफ्टवेअर सोडण्यास सुरुवात केली आहे. त्याच वेळी, परिणामी समाधान सार्वत्रिक आहे आणि कोणत्याही प्रकल्पावर मुक्तपणे लागू केले जाऊ शकते जेथे Oracle DBMS वर स्वयंचलित चाचणी आयोजित करणे आवश्यक आहे.

P.S. हा लेख फार विशिष्ट नाही: भरपूर मजकूर आहे आणि व्यावहारिकदृष्ट्या कोणतीही तांत्रिक उदाहरणे नाहीत. जर विषय सामान्यतः मनोरंजक असेल, तर आम्ही ते सुरू ठेवण्यास तयार आहोत आणि सातत्यांसह परत येऊ, जेथे आम्ही तुम्हाला गेल्या सहा महिन्यांत काय बदलले आहे ते सांगू आणि कोड उदाहरणे देऊ.

भविष्यात ज्या मुद्द्यांवर जोर द्यायचा असेल किंवा ज्या प्रश्नांना प्रकटीकरण आवश्यक असेल तर टिप्पण्या लिहा.

केवळ नोंदणीकृत वापरकर्तेच सर्वेक्षणात भाग घेऊ शकतात. साइन इन करा, आपले स्वागत आहे.

याबद्दल पुढे लिहू का?

• होय नक्कीच

• नको धन्यवाद

12 वापरकर्त्यांनी मतदान केले. 4 वापरकर्ते दूर राहिले.

स्त्रोत: www.habr.com