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

पहिलो भाग - यहाँ.

अवस्था कल्पना गर्नुहोस्। तपाईं नयाँ कार्यक्षमता विकास गर्ने कार्यको सामना गर्दै हुनुहुन्छ। तपाईंका पूर्ववर्तीहरूबाट विकासहरू छन्। यदि हामीले मान्यौं कि तपाईको कुनै नैतिक दायित्व छैन भने तपाईले के गर्नुहुन्छ?

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

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

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

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

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

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

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

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

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

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

त्यसोभए, हाम्रो एकाइ परीक्षण प्रणाली प्रयोग गर्ने नतिजाहरूको बारेमा कुरा गरौं।

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

अब के

स्वचालित परीक्षण परियोजनाको लागि विकास योजनाहरूको बारेमा कुरा गरौं।

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

अटोटेस्टहरूको संख्या बढ्दै जाँदा, तिनीहरूको कुल सञ्चालन समय लगातार बढ्दै जानेछ, र हामीले फेरि प्रदर्शनको मुद्दामा फर्कनु पर्छ। सम्भवतः, समाधान समानान्तर थ्रेडहरूको संख्या बढाउनु हुनेछ।

तर यी विकासका स्पष्ट उपाय हुन् । यदि हामी थप गैर-तुच्छ कुराको बारेमा कुरा गर्छौं भने, हामी निम्न हाइलाइट गर्छौं:

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

   हाम्रो स्वत: परीक्षण प्रणाली एक वर्ष भन्दा पुरानो छ र सायद अब हाम्रो कभरेज मूल्याङ्कन गर्ने समय हो। मेरो अन्तिम परियोजनामा ​​(स्पोर्टमास्टर परियोजना होइन) यो के भयो। अटोटेस्टमा काम गरेको एक वर्ष पछि, व्यवस्थापनले हामीले कभर गर्ने कोडको कति प्रतिशत मूल्याङ्कन गर्ने कार्य सेट गर्‍यो। १% भन्दा बढीको कभरेजको साथ, व्यवस्थापन खुसी हुनेछ। हामी, विकासकर्ताहरूले लगभग 1% को नतिजाको अपेक्षा गरेका थियौं। हामीले कोड कभरेज स्थापना गर्यौं, यसलाई मापन गर्यौं, र 10% पायौं। उत्सव मनाउन, हामी पुरस्कार लिन गएका थियौं, तर हामी कसरी यो प्राप्त गर्न गयौं र हामी पछि कहाँ गयौं त्यो बिल्कुल फरक कथा हो।

3. स्वत: परीक्षणहरूले खुला वेब सेवाहरू जाँच गर्न सक्छन्। ओरेकलले हामीलाई यो राम्रोसँग गर्न अनुमति दिन्छ, र हामीले अब धेरै समस्याहरूको सामना गर्ने छैनौं।
4. र, निस्सन्देह, हाम्रो स्वचालित परीक्षण प्रणाली अर्को परियोजनामा ​​लागू गर्न सकिन्छ। हामीले प्राप्त गरेको समाधान विश्वव्यापी छ र Oracle को प्रयोग मात्र आवश्यक छ। मैले सुनें कि अन्य स्पोर्टमास्टर परियोजनाहरू स्वचालित परीक्षणमा रुचि राख्छन् र सायद हामी तिनीहरूमा जानेछौं।

निष्कर्ष

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

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

यदि भविष्यमा जोड दिनु पर्ने बिन्दुहरू छन्, वा खुलासा आवश्यक पर्ने प्रश्नहरू छन् भने टिप्पणीहरू लेख्नुहोस्।

दर्ता भएका प्रयोगकर्ताहरूले मात्र सर्वेक्षणमा भाग लिन सक्छन्। साइन इन गर्नुहोस्कृपया

यसबारे थप लेख्ने ?

• हो अवश्य

• धन्यबाद

12 प्रयोगकर्ताहरूले मतदान गरे। २ प्रयोगकर्ताहरू रोकिए।

स्रोत: www.habr.com