AutoCar में परीक्षण कैसे करें: माइंडपावर, स्टैटिक कोड विश्लेषण और मॉकसेवर

नमस्ते! मैं आपको बताना चाहता हूं कि वीआईएन द्वारा कार निरीक्षण सेवा ऑटोटेक परियोजना में परीक्षण कैसे काम करता है। कटौती के तहत - हम अपनी आवश्यकताओं को परखने के लिए किस उपकरण का उपयोग करते हैं, स्प्रिंट प्लानिंग, हमारी परियोजना में परीक्षण प्रक्रिया कैसे काम करती है।

कार्य को तैयार करने के लिए माइंडपॉइंट

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

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

नतीजतन, मैंने माइंडमैप पर आधारित एक समाधान का प्रस्ताव रखा, जिसमें लगभग सभी निर्भरताएं दिखाई गईं जो DoD, DoR और कार्य मूल्यांकन को प्रभावित कर सकती हैं।



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

लाइन्टी और स्टेटिक कोड एनालिसिस फॉर गो

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



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

MockServer और सेवाओं को प्राप्त करने के लिए कि उन्हें क्या चाहिए

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

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

मुझे अपना स्वयं का मॉक लिखने का विचार था और इस तरह से ऑटोटेक के स्रोतों को प्रतिस्थापित किया गया। लेकिन अंत में, एक सरल समाधान मिला - रेडी-मेड मॉकस्वर , जावा में ओपन-सोर्स विकास।

इसके काम का सिद्धांत:

• उम्मीदें बनाना
• आने वाले अनुरोधों का मिलान करें,
• यदि एक मैच पाया जाता है - एक प्रतिक्रिया भेजें।

जावा क्लाइंट का उपयोग करके प्रतीक्षा करने का एक उदाहरण:

new MockServerClient("localhost", 1080) .when( request() .withMethod("POST") .withPath("/login") .withBody("{username: 'foo', password: 'bar'}") ) .respond( response() .withStatusCode(302) .withCookie( "sessionId", "2By8LOhBmaW5nZXJwcmludCIlMDAzMW" ) .withHeader( "Location", "https://www.mock-server.com" ) ); 

जैसा कि आप उदाहरण से देख सकते हैं, हम उस अनुरोध का वर्णन करते हैं जिसे हम भेजेंगे और जो प्रतिक्रिया हम प्राप्त करना चाहते हैं। MockServer अनुरोध प्राप्त करता है, इसे उन लोगों के साथ तुलना करने की कोशिश करता है जो बनाए गए थे, और यदि मैच हैं, तो यह एक प्रतिक्रिया देता है। यदि अनुरोध विफल नहीं होता है, तो हमें 404 मिलते हैं।

MockServer के लिए जावा और जावास्क्रिप्ट, उत्कृष्ट प्रलेखन और उपयोग के उदाहरण के लिए ग्राहक हैं। RegExp पर मेल के अनुरोध, सर्वर पर विस्तृत लॉगिंग और चिप्स का एक पूरा गुच्छा होने की संभावना है। हमारी जरूरतों के लिए, यह एक आदर्श उम्मीदवार था। लॉन्च प्रक्रिया को साइट पर विस्तार से वर्णित किया गया है, इसलिए इसे यहां वापस लेने से बिंदु नहीं दिखता है। एकमात्र क्षण, नवीनतम संस्करण बहुत मेमोरी लीक था, इसलिए हम 5.2.3 संस्करण का उपयोग करते हैं। सावधान रहें। एक और माइनस यह है कि मॉकसेवर के पास बॉक्स से SOAP सपोर्ट नहीं है।

फिलहाल, MockServer हमारे साथ लगभग तीन महीने से काम कर रहा है। नतीजतन, परीक्षणों की स्थिरता, उनके निष्पादन की गति और देव-पर्यावरण पर किसी भी डेटा को प्राप्त करने की क्षमता में वृद्धि हुई है। और तदनुसार, परीक्षण के लिए अधिक अवसर हैं।

उपसंहार

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

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