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

अहो हाब्र!

माझे नाव मॅक्सिम पोनोमारेन्को आहे आणि मी स्पोर्टमास्टरचा विकासक आहे. मला आयटी क्षेत्रात 10 वर्षांचा अनुभव आहे. त्याने मॅन्युअल टेस्टिंगमध्ये आपल्या कारकिर्दीची सुरुवात केली, त्यानंतर डेटाबेस डेव्हलपमेंटवर स्विच केले. गेल्या 4 वर्षांपासून, चाचणी आणि विकासामध्ये मिळवलेले ज्ञान जमा करून, मी डीबीएमएस स्तरावर स्वयंचलित चाचणी करत आहे.

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

प्रथम, थोडा कंटाळवाणा सिद्धांत. स्वयंचलित चाचणी म्हणजे काय? ही चाचणी आहे जी सॉफ्टवेअर वापरून केली जाते आणि आधुनिक आयटीमध्ये ते सॉफ्टवेअर डेव्हलपमेंटमध्ये वाढत्या प्रमाणात वापरले जाते. हे या वस्तुस्थितीमुळे आहे की कंपन्या वाढत आहेत, त्यांची माहिती प्रणाली वाढत आहे आणि त्यानुसार, चाचणी करणे आवश्यक असलेल्या कार्यक्षमतेचे प्रमाण वाढत आहे. मॅन्युअल चाचणी आयोजित करणे अधिकाधिक महाग होत आहे.

मी एका मोठ्या कंपनीसाठी काम केले ज्याचे प्रकाशन दर दोन महिन्यांनी बाहेर येते. त्याच वेळी, डझनभर परीक्षकांनी स्वतः कार्यक्षमता तपासण्यासाठी संपूर्ण महिना खर्च केला. डेव्हलपरच्या छोट्या टीमद्वारे ऑटोमेशन लागू केल्याबद्दल धन्यवाद, आम्ही दीड वर्षात चाचणी वेळ 2 आठवड्यांपर्यंत कमी करू शकलो. आम्ही केवळ चाचणीचा वेग वाढवला नाही तर त्याची गुणवत्ताही सुधारली आहे. स्वयंचलित चाचण्या नियमितपणे सुरू केल्या जातात आणि त्या नेहमी त्यामध्ये समाविष्ट केलेल्या तपासण्यांचा संपूर्ण अभ्यासक्रम पार पाडतात, म्हणजेच आम्ही मानवी घटक वगळतो.

आधुनिक आयटीचे वैशिष्ट्य असे आहे की विकसकाला केवळ उत्पादन कोड लिहिणे आवश्यक नाही, तर हा कोड तपासणाऱ्या युनिट चाचण्या देखील लिहिणे आवश्यक आहे.

पण तुमची प्रणाली प्रामुख्याने सर्व्हर लॉजिकवर आधारित असेल तर? बाजारात कोणतेही सार्वत्रिक उपाय किंवा सर्वोत्तम पद्धती नाहीत. नियमानुसार, कंपन्या त्यांची स्वतःची स्वयं-लिखित चाचणी प्रणाली तयार करून ही समस्या सोडवतात. ही आमची स्वतःची स्वयं-लिखित स्वयंचलित चाचणी प्रणाली आहे जी आमच्या प्रकल्पावर तयार केली गेली आहे आणि मी माझ्या अहवालात याबद्दल बोलेन.

निष्ठा चाचणी

प्रथम, त्या प्रकल्पाबद्दल बोलूया जिथे आम्ही स्वयंचलित चाचणी प्रणाली तैनात केली आहे. आमचा प्रकल्प स्पोर्टमास्टर लॉयल्टी सिस्टम आहे (तसे, आम्ही याबद्दल आधीच लिहिले आहे हे पोस्ट).

तुमची कंपनी पुरेशी मोठी असल्यास, तुमच्या लॉयल्टी सिस्टममध्ये तीन मानक गुणधर्म असतील:

• तुमची प्रणाली खूप लोड केली जाईल
• तुमच्या सिस्टममध्ये जटिल संगणकीय प्रक्रिया असतील
• तुमची प्रणाली सक्रियपणे सुधारली जाईल.

चला क्रमाने जाऊया... एकूण, जर आपण सर्व स्पोर्टमास्टर ब्रँड्सचा विचार केला, तर रशिया, युक्रेन, चीन, कझाकस्तान आणि बेलारूसमध्ये आमचे 1000 हून अधिक स्टोअर्स आहेत. या स्टोअरमध्ये दररोज सुमारे 300 खरेदी केल्या जातात. म्हणजेच, प्रत्येक सेकंदाला 000-3 चेक आमच्या सिस्टममध्ये प्रवेश करतात. साहजिकच, आमची निष्ठा प्रणाली खूप भारलेली आहे. आणि ते सक्रियपणे वापरले जात असल्याने, आम्ही त्याच्या गुणवत्तेची सर्वोच्च मानके प्रदान करणे आवश्यक आहे, कारण सॉफ्टवेअरमधील कोणतीही त्रुटी म्हणजे मोठे आर्थिक, प्रतिष्ठा आणि इतर नुकसान.

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

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

आमची प्रणाली सक्रियपणे वापरली जात असल्याने, व्यवसायाला तुमच्याकडून काहीतरी नवीन हवे असेल, काळासोबत जगावे लागेल आणि ग्राहकाभिमुख व्हावे लागेल. आमच्या लॉयल्टी सिस्टममध्ये, दर दोन महिन्यांनी रिलीझ बाहेर येतात. याचा अर्थ असा की दर दोन महिन्यांनी आपल्याला संपूर्ण प्रणालीचे संपूर्ण प्रतिगमन करणे आवश्यक आहे. त्याच वेळी, नैसर्गिकरित्या, कोणत्याही आधुनिक IT प्रमाणे, विकास त्वरित विकसकाकडून उत्पादनाकडे जात नाही. हे विकसकाच्या सर्किटवर उद्भवते, नंतर चाचणी बेंच, प्रकाशन, स्वीकृती यामधून उत्तीर्ण होते आणि त्यानंतरच उत्पादनात समाप्त होते. कमीतकमी, चाचणी आणि रिलीझ सर्किट्सवर, आम्हाला संपूर्ण सिस्टमचे संपूर्ण प्रतिगमन करणे आवश्यक आहे.

वर्णित गुणधर्म जवळजवळ कोणत्याही निष्ठा प्रणालीसाठी मानक आहेत. चला आमच्या प्रकल्पाच्या वैशिष्ट्यांबद्दल बोलूया.

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

स्पोर्टमास्टर मधील लॉयल्टी सिस्टीम 7 वर्षांहून अधिक काळ अस्तित्वात आहे आणि ती एकल विकासकांद्वारे तयार करण्यात आली आहे... या 7 वर्षांमध्ये आमच्या प्रकल्पावरील विकासकांची सरासरी संख्या 3-4 लोक होती. परंतु गेल्या वर्षभरात, आमची टीम लक्षणीयरीत्या वाढली आहे आणि आता या प्रकल्पावर 10 लोक काम करत आहेत. म्हणजेच, लोक प्रकल्पात येतात ज्यांना ठराविक कार्ये, प्रक्रिया आणि वास्तुकलाची माहिती नसते. आणि आपल्या चुका चुकवण्याचा धोका वाढतो.

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

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

utPLSQL बचावासाठी येतो

तुम्हाला स्टीफन फ्युअरस्टीनबद्दल काही माहिती आहे का?

हा एक हुशार माणूस आहे ज्याने त्याच्या कारकिर्दीचा बराचसा भाग ओरॅकल आणि पीएल/एसक्यूएल सोबत काम करण्यासाठी समर्पित केला आणि या विषयावर मोठ्या संख्येने कामे लिहिली आहेत. त्यांच्या प्रसिद्ध पुस्तकांपैकी एक असे म्हटले जाते: “ओरेकल पीएल/एसक्यूएल. व्यावसायिकांसाठी." स्टीफननेच utPLSQL सोल्यूशन विकसित केले, किंवा त्याचा अर्थ, Oracle PL/SQL साठी युनिट टेस्टिंग फ्रेमवर्क. 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. तैनाती. आमच्याकडे अनेक स्टँड आहेत जिथे आम्हाला चाचण्या घ्यायच्या आहेत. प्रत्येक स्टँडवर, डेटा डंप कधीही अद्यतनित केला जाऊ शकतो. स्वयंचलित चाचण्यांसह प्रकल्प अशा प्रकारे आयोजित करणे आवश्यक आहे की आपण त्याची पूर्ण किंवा आंशिक स्थापना वेदनारहितपणे करू शकता.

आणि काही दिवसात दुसऱ्या पोस्टमध्ये मी तुम्हाला सांगेन की आम्ही काय केले आणि आम्ही काय परिणाम प्राप्त केले.

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