DBMS मा एकाइ परीक्षणहरू - हामी यसलाई Sportmaster मा कसरी गर्छौं, भाग एक

हे हाबर!

मेरो नाम Maxim Ponomarenko हो र म Sportmaster मा एक विकासकर्ता हुँ। मसँग IT क्षेत्रमा 10 वर्षको अनुभव छ। उनले म्यानुअल परीक्षणमा आफ्नो क्यारियर सुरु गरे, त्यसपछि डाटाबेस विकासमा स्विच गरे। विगत ४ वर्षदेखि, परीक्षण र विकासमा प्राप्त ज्ञान सङ्कलन गर्दै, म DBMS स्तरमा स्वचालित परीक्षण गर्दै आएको छु।

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

पहिलो, थोरै बोरिंग सिद्धान्त। स्वचालित परीक्षण भनेको के हो? यो परीक्षण हो जुन सफ्टवेयर प्रयोग गरी गरिन्छ, र आधुनिक IT मा यो बढ्दो सफ्टवेयर विकास मा प्रयोग गरिन्छ। यो तथ्यको कारण हो कि कम्पनीहरू बढ्दै छन्, तिनीहरूको सूचना प्रणालीहरू बढ्दै छन् र, तदनुसार, परीक्षण गर्न आवश्यक कार्यक्षमताको मात्रा बढ्दै छ। म्यानुअल परीक्षण सञ्चालन गर्नु झन् महँगो हुँदै गइरहेको छ।

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

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

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

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

पहिले, हामी परियोजनाको बारेमा कुरा गरौं जहाँ हामीले स्वचालित परीक्षण प्रणाली प्रयोग गर्यौं। हाम्रो परियोजना Sportmaster वफादारी प्रणाली हो (वैसे, हामीले पहिले नै यसको बारेमा लेखेका छौं यो पोस्ट).

यदि तपाईंको कम्पनी पर्याप्त ठूलो छ भने, तपाईंको वफादारी प्रणालीमा तीन मानक गुणहरू हुनेछन्:

• तपाईंको प्रणाली अत्यधिक लोड हुनेछ
• तपाईंको प्रणालीमा जटिल कम्प्युटिङ् प्रक्रियाहरू समावेश हुनेछन्
• तपाईंको प्रणाली सक्रिय रूपमा सुधार गरिनेछ।

क्रमशः जाऔं... कुल मिलाएर, यदि हामी सबै स्पोर्टमास्टर ब्रान्डहरू विचार गर्छौं भने, हामीसँग रूस, युक्रेन, चीन, काजाकिस्तान र बेलारुसमा १००० भन्दा बढी स्टोरहरू छन्। यी स्टोरहरूमा हरेक दिन लगभग 1000 खरिदहरू गरिन्छ। त्यो हो, प्रत्येक सेकेन्ड 300-000 चेकहरू हाम्रो प्रणालीमा प्रवेश गर्छन्। स्वाभाविक रूपमा, हाम्रो वफादारी प्रणाली अत्यधिक लोड छ। र यो सक्रिय रूपमा प्रयोग भएकोले, हामीले यसको गुणस्तरको उच्चतम मापदण्डहरू प्रदान गर्नुपर्छ, किनभने सफ्टवेयरमा कुनै त्रुटिको अर्थ ठूलो वित्तीय, प्रतिष्ठा र अन्य हानि हो।

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

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

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

वर्णित गुणहरू लगभग कुनै पनि वफादारी प्रणालीको लागि मानक हो। हाम्रो परियोजना को विशेषताहरु को बारे मा कुरा गरौं।

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

Sportmaster मा वफादारी प्रणाली 7 वर्ष भन्दा बढीको लागि अवस्थित छ र एकल विकासकर्ताहरू द्वारा सिर्जना गरिएको थियो... यी 7 वर्षहरूमा हाम्रो परियोजनामा ​​विकासकर्ताहरूको औसत संख्या 3-4 व्यक्तिहरू थिए। तर गत वर्षमा, हाम्रो टोली उल्लेखनीय रूपमा बढेको छ, र अहिले त्यहाँ 10 जना व्यक्तिहरू परियोजनामा ​​​​काम गरिरहेका छन्। त्यो हो, मानिसहरू परियोजनामा ​​आउँछन् जो विशिष्ट कार्यहरू, प्रक्रियाहरू, र वास्तुकलासँग परिचित छैनन्। र त्यहाँ बढ्दो जोखिम छ कि हामीले गल्तीहरू गुमाउनेछौं।

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

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

utPLSQL उद्धारमा आउँछ

के तपाई स्टीफन फ्युरस्टेनको बारेमा केहि जान्नुहुन्छ?

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

यो प्रविधि प्रयोग गरेर लागू गरिएको एकाइ परीक्षण कोड कस्तो देखिन्छ भन्ने उदाहरण हेरौं।

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

"utp_setup", एक नियमको रूपमा, हाम्रो प्रणालीलाई एकाइ परीक्षण चलाउनको लागि तयार गर्दछ, उदाहरणका लागि, परीक्षण डेटा सिर्जना गर्नुहोस्। "utp_teardown" - यसको विपरित, सबै कुरा मूल सेटिङहरूमा फर्कन्छ र सुरुवात परिणामहरू रिसेट गर्दछ।

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

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

र यदि हामी नयाँ क्लाइन्ट सिर्जना गर्ने विधि प्रयोग गरेर एकाइ परीक्षणहरू लेख्छौं, त्यसपछि प्रत्येक परीक्षण पछि प्रणालीमा नयाँ ग्राहक सिर्जना हुनेछ, जसले परीक्षणको पछिको सुरुवातलाई असर गर्न सक्छ।

यसरी एकाइ परीक्षणहरू सञ्चालन गरिन्छ। त्यहाँ दुई सम्भावित प्रक्षेपण विकल्पहरू छन्: एक विशेष प्याकेजबाट सबै एकाइ परीक्षणहरू चलाउन वा एक विशेष प्याकेजमा एक विशेष इकाई परीक्षण चलाउन।

आन्तरिक रिपोर्टिङ प्रणालीको उदाहरण यस्तो देखिन्छ। एकाइ परीक्षणको नतिजाको आधारमा, utPLSQL ले एउटा सानो रिपोर्ट बनाउँछ। यसमा हामी प्रत्येक विशिष्ट जाँचको नतिजा र एकाइ परीक्षणको समग्र नतिजा देख्छौं।

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

वफादारी प्रणालीको स्वचालित परीक्षणको लागि नयाँ प्रणाली सिर्जना गर्न सुरु गर्नु अघि, व्यवस्थापनसँगै, हामीले हाम्रा भविष्यका स्वचालित परीक्षणहरूले पालना गर्नुपर्ने सिद्धान्तहरू निर्धारण गर्यौं।

1. Autotests प्रभावकारी हुनुपर्छ र उपयोगी हुनुपर्छ। हामीसँग अद्भुत विकासकर्ताहरू छन्, जसलाई निश्चित रूपमा उल्लेख गर्न आवश्यक छ, किनकि तिनीहरूमध्ये केहीले यो रिपोर्ट देख्नेछन्, र तिनीहरूले अद्भुत कोड लेख्छन्। तर तिनीहरूको अद्भुत कोड पनि सही छैन र त्रुटिहरू समावेश गर्दछ, छ, र जारी रहनेछ। यी त्रुटिहरू फेला पार्न Autotests आवश्यक छ। यदि यो मामला होइन भने, या त हामी खराब अटोटेस्टहरू लेखिरहेका छौं, वा हामी एक मृत क्षेत्रमा आएका छौं, जुन, सिद्धान्तमा, विकसित भइरहेको छैन। दुबै अवस्थामा, हामी केहि गलत गर्दैछौं, र हाम्रो दृष्टिकोणले कुनै अर्थ राख्दैन।
2. अटोटेस्ट प्रयोग गर्नुपर्छ। सफ्टवेयर उत्पादन लेख्न धेरै समय र प्रयास खर्च गर्न, यसलाई भण्डारमा राख्नुहोस् र बिर्सनुको कुनै अर्थ छैन। परीक्षणहरू चलाउनुपर्दछ, र सकेसम्म नियमित रूपमा चलाउनुपर्दछ।
3. स्वत: परीक्षणहरू स्थिर रूपमा काम गर्नुपर्छ। दिनको समय, लन्च स्ट्यान्ड र अन्य प्रणाली सेटिङहरूको बावजुद, परीक्षण रनले समान परिणाम ल्याउनुपर्दछ। एक नियमको रूपमा, यो तथ्य द्वारा सुनिश्चित गरिएको छ कि स्वत: परीक्षणहरू निश्चित प्रणाली सेटिङहरूसँग विशेष परीक्षण डेटासँग काम गर्दछ।
4. अटोटेस्टहरूले तपाईंको परियोजनाको लागि स्वीकार्य गतिमा काम गर्नुपर्छ। यो समय प्रत्येक प्रणालीको लागि व्यक्तिगत रूपमा निर्धारण गरिन्छ। केही व्यक्तिहरू दिनभर काम गर्न खर्च गर्न सक्छन्, जबकि अरूले यसलाई सेकेन्डमा गर्न महत्त्वपूर्ण पाउँछन्। म तपाइँलाई केहि समय पछि बताउनेछु कि हामीले हाम्रो परियोजना मा हासिल गरेको गति मापदण्डहरु।
5. Autotest विकास लचिलो हुनुपर्छ। कुनै पनि प्रकार्यता परीक्षण गर्न अस्वीकार गर्नु उचित हुँदैन किनभने हामीले यो पहिले वा कुनै अन्य कारणले गरेका छैनौं। utPLSQL ले विकासमा कुनै प्रतिबन्ध लगाउँदैन, र Oracle, सिद्धान्तमा, तपाईंलाई विभिन्न चीजहरू लागू गर्न अनुमति दिन्छ। धेरैजसो समस्याहरूको समाधान हुन्छ, यो केवल समय र प्रयासको कुरा हो।
6. डिप्लोयबिलिटी। हामीसँग धेरै स्ट्यान्डहरू छन् जहाँ हामीले परीक्षणहरू चलाउन आवश्यक छ। प्रत्येक स्ट्यान्डमा, डाटा डम्प कुनै पनि समयमा अद्यावधिक गर्न सकिन्छ। यो स्वचालित परीक्षण संग एक परियोजना सञ्चालन गर्न को लागी आवश्यक छ कि तपाइँ पीडा बिना यसको पूर्ण वा आंशिक स्थापना गर्न सक्नुहुन्छ।

र केही दिनमा दोस्रो पोष्टमा हामीले के गर्यौं र हामीले के नतिजा हासिल गर्यौं भन्ने कुरा बताउनेछु।

स्रोत: www.habr.com