🎫 🍴 🐑 ऑटो टेस्ट कवरेज विज़ुअलाइज़ेशन 📕 👩🏻‍🔬 🏢

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

सम्मेलन से क्यूमेटा सॉफ्टवेयर से आर्टेम इरशेंको की एक रिपोर्ट के कट - वीडियो और ट्रांसक्रिप्ट के तहत । उन्होंने कई विकसित सरल और सुरुचिपूर्ण समाधान पेश किए जो कि Yandex.Verticals टीम को टेस्ट ऑटोमेशन इंजीनियरों द्वारा लिखित परीक्षणों के कवरेज का मूल्यांकन करने में मदद करते हैं। आर्टेम आपको बताएगा कि कैसे जल्दी से पता लगाया जाए कि क्या कवर किया गया है, कैसे कवर किया गया है, क्या परीक्षण पास हुए हैं, और तुरंत दृश्य रिपोर्ट देखें।

मेरा नाम एर्टोम इरोसेंको है eroshenkoam, मैं 10 वर्षों से परीक्षण स्वचालन कर रहा हूं। मैं एक परीक्षण स्वचालन प्रबंधक, एक टूल डेवलपमेंट टीम मैनेजर, एक टूल डेवलपर था।

फिलहाल मैं परीक्षण स्वचालन के क्षेत्र में एक सलाहकार हूं, मैं कई कंपनियों के साथ काम करता हूं जिनके साथ हम प्रक्रियाओं का निर्माण करते हैं।
मैं एल्योर रिपोर्ट का डेवलपर और गुप्त प्रबंधक भी हूं। हमने हाल ही में एक अच्छी बात तय की है : अब JUnit 5 में जुड़नार हैं।

एटलस फ्रेमवर्क

मेरा विकास एटलस फ्रेमवर्क है । अगर किसी ने 2012 में जावा वेब ड्राइवर को शुरू करना शुरू कर दिया था, तो उस समय मैंने एचटीएमएल एलिमेंट्स नामक एक ओपन सोर्स लाइब्रेरी बनाई थी ।

एचटीएमएल एलिमेंट्स की एटलस लाइब्रेरी में इसकी निरंतरता और पुनर्विचार है, जो इंटरफेस पर बनाया गया है: इस तरह के कोई वर्ग नहीं हैं, कोई फ़ील्ड नहीं, बहुत सुविधाजनक, हल्के और आसानी से एक्स्टेंसिबल लाइब्रेरी। यदि आपको इसे समझने की इच्छा है, तो आप लेख पढ़ सकते हैं या रिपोर्ट देख सकते हैं ।

मेरी रिपोर्ट परीक्षण स्वचालन और मुख्य रूप से कोटिंग्स की समस्या के लिए समर्पित है। एक पृष्ठभूमि के रूप में, मैं यह बताना चाहूंगा कि परीक्षण प्रक्रियाओं का आयोजन Yandex.Verticals में कैसे किया जाता है।

ऑटोमेशन वर्टिकल में कैसे काम करता है?

Yandex.Verticals परीक्षण स्वचालन टीम में केवल चार लोग हैं जो चार सेवाओं को स्वचालित करते हैं: Yandex.Avto, कार्य, रियल एस्टेट और पार्ट्स। यही है, यह वाहन चालकों की एक छोटी टीम है जो बहुत कुछ करते हैं। हम एपीआई, वेब इंटरफेस, मोबाइल एप्लिकेशन और इतने पर स्वचालित करते हैं। कुल मिलाकर, हमारे पास लगभग 15.5 हजार परीक्षण हैं जो विभिन्न स्तरों पर किए जाते हैं।

टीम में परीक्षणों की स्थिरता लगभग 97% है, हालांकि मेरे कुछ सहयोगी 99% के बारे में कहते हैं। इस तरह की उच्च स्थिरता बहुत ही देशी प्रौद्योगिकियों पर लघु परीक्षणों के लिए सटीक धन्यवाद प्राप्त की जाती है। एक नियम के रूप में, हमारे परीक्षणों में लगभग 15 मिनट लगते हैं, जो बहुत अधिक क्षमता वाला है, और हम उन्हें लगभग 800 थ्रेड्स में चलाते हैं। यही है, हमारे पास 800 ब्राउज़र एक ही समय में शुरू हो रहे हैं - हमारे परीक्षण का ऐसा तनाव परीक्षण। लोहे के रूप में हम सेलेनॉइड (एरोकोब) का उपयोग करते हैं। आप मेरी 2017 की रिपोर्ट देखकर Yandex.Verticals में स्वचालन के बारे में अधिक जान सकते हैं, जो अभी भी प्रासंगिक है।

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

कार्यक्षेत्रों में, परीक्षण डेवलपर्स परीक्षण लिखते हैं, और वे परीक्षण विकास के लिए इतने उत्सुक हैं कि वे हमारे साथ प्रतिस्पर्धा करते हैं। आप इस प्रक्रिया के बारे में रिपोर्ट "परीक्षण प्रतिक्रियाओं के परीक्षण का पूरा चक्र" से जान सकते हैं, जहां अलेक्सी एंड्रोसोव और नताल्या स्टस बात करते हैं कि वे हमारे जावा एंड-टू-एंड परीक्षणों के समानांतर पुप्तेर पर यूनिट परीक्षण कैसे लिखते हैं।

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

डेवलपर्स भी हमारी मदद करते हैं, और यह अच्छा है।

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

क्या परीक्षण किया है और क्या नहीं है?

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

प्रभावी ढंग से कवरेज को मापने के तरीके।
एपीआई परीक्षणों के लिए कवरेज।
वेब परीक्षणों के लिए कवरेज।

सबसे पहले, यह निर्धारित करें कि कवर करने के दो तरीके हैं: आवश्यकताओं को कवर करना और उत्पाद कोड को कवर करना।

कैसे कवरेज की आवश्यकताओं को मापा जाता है

उदाहरण के रूप में auto.ru का उपयोग करके आवश्यकताओं के कवरेज पर विचार करें। Auto.ru परीक्षक के स्थान पर, मैं निम्नलिखित कार्य करूंगा। सबसे पहले, मैं गूगल करूँगा और तुरंत एक विशेष आवश्यकता तालिका खोजूंगा। यह आवश्यकताओं के कवरेज का आधार है।

इस तालिका में, बाईं ओर आवश्यकताओं के नाम लिखे गए हैं। इस स्थिति में: खाता, विज्ञापन, सत्यापन और भुगतान, यानी घोषणा का सत्यापन। सामान्य तौर पर, यह कवरेज है। बाएं हिस्से का विस्तार परीक्षक के स्तर पर निर्भर करता है। उदाहरण के लिए, Google के इंजीनियरों के पास 49 प्रकार के कोटिंग्स हैं जो विभिन्न स्तरों पर परीक्षण किए जाते हैं।

तालिका का दाईं ओर आवश्यकताएँ विशेषताएँ हैं। हम विशेषताओं के रूप में कुछ भी उपयोग कर सकते हैं, उदाहरण के लिए: प्राथमिकता, कवरेज और राज्य। यह अंतिम रिलीज की तारीख हो सकती है।

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

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

इस दृष्टिकोण के पेशेवरों और विपक्ष क्या हैं? प्लस यह है कि यह दृष्टिकोण हमारे सवालों का जवाब देता है। यदि प्रबंधक पूछता है कि हमने क्या कवर किया है, तो मैं टैबलेट खोलूंगा और दिखाऊंगा कि क्या विशेषताएं शामिल हैं। दूसरी ओर, इन आवश्यकताओं को हमेशा अद्यतित रखना चाहिए, और वे बहुत जल्दी अप्रचलित हो जाते हैं।
जब आपके पास 15 हजार परीक्षण होते हैं, तो TestRail को देखना अंतरिक्ष में एक तारे की तरह लग रहा है: यह लंबे समय तक फट गया, और प्रकाश अभी आप तक पहुंचा है। आप वर्तमान परीक्षण के मामले को देखते हैं, और यह पहले से ही एक पुराना समय है और अपरिवर्तनीय रूप से पुराना है।

इस समस्या को हल करना मुश्किल है। हमारे लिए, ये आम तौर पर दो अलग-अलग जगहें हैं: स्वचालन की एक दुनिया है जो अपने स्वयं के कानूनों के अनुसार घूमती है, जहां हर परीक्षण जो विफल रहता है, वह तुरंत तय हो जाता है, और मैन्युअल परीक्षण और आवश्यकताओं के कार्ड की एक दुनिया है। जब तक आप एल्योर सर्वर का उपयोग नहीं करते, उनके बीच की दीवार अभेद्य है। हम अब उनके लिए इस समस्या को हल करते हैं।

"पेशेवरों और विपक्ष" का तीसरा बिंदु मैनुअल काम की आवश्यकता है। एक नई परियोजना में, आपको एक आवश्यकताओं के नक्शे को फिर से बनाना होगा, सभी परीक्षण मामलों को लिखना होगा, और इसी तरह। इसे हमेशा मैनुअल काम की आवश्यकता होती है, और यह वास्तव में बहुत दुखद है।

कोड कवरेज कैसे मापा जाता है

इस दृष्टिकोण का एक विकल्प कोड कवरेज है। यह हमारी समस्या का समाधान प्रतीत होता है। यह उत्पाद कोड का कवरेज कैसा दिखता है:

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

1963 में कोड कवरेज का पहला उल्लेख वापस आ गया था, लेकिन इस दिशा में गंभीर प्रगति केवल अब दिखाई देती है।

तो, हमारे पास एक परीक्षण है जो सिस्टम के साथ बातचीत करता है। इससे कोई फर्क नहीं पड़ता कि वह उसके साथ कैसे बातचीत करता है: फ्रंट-एंड के माध्यम से, एपीआई या सीधे बैक-एंड में रेंगता है - हम केवल यह मानेंगे कि हमारे पास यह है।

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

जब आपके परीक्षण यह जांचते हैं कि कौन सी कोड की लाइन हिट हुई और कौन सी हिट नहीं हुई, तो वे फाइलों को सहेजते हैं कि कौन सी लाइनें कवर हैं। इस जानकारी के आधार पर, आपके पास डेटा है।

कोड कवरेज के पेशेवरों और विपक्ष क्या हैं?

कोड कवरेज मैं तुरंत एक ऋण कहूंगा । आप प्रबंधक के पास नहीं आएंगे, आप इस प्लेट को नहीं दिखाएंगे और आप यह नहीं कहेंगे कि हर कोई स्वचालित है, क्योंकि यह डेटा पढ़ा नहीं जा सकता, वह आपसे स्पष्ट डेटा वापस करने के लिए कहेगा जिसे आप जल्दी से देख सकते हैं और सब कुछ समझ सकते हैं।

कोड कवरेज रिपोर्ट विकास के करीब है। यह एक सामान्य दृष्टिकोण के रूप में एक टीम को सभी डेटा प्रदान करने के लिए इस्तेमाल नहीं किया जा सकता है अगर हम चाहते हैं कि पूरी टीम देखने में सक्षम हो।

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

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

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

टेस्ट कवरेज एपीआई

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

अनुरोधों की सूची।
अनुरोध पैरामीटर: डेवलपर को खींचने और यह पूछने की कोई आवश्यकता नहीं है कि पैरामीटर क्या हैं।
उत्तर कोड

स्वैगर के संचालन का सिद्धांत पीढ़ी है। इससे कोई फर्क नहीं पड़ता कि आप किस फ्रेमवर्क का उपयोग करते हैं। मान लीजिए कि स्प्रिंग या गो सर्वर, आप Swagger Codegen घटक का उपयोग करते हैं और swagger.json उत्पन्न करते हैं । यह कुछ विनिर्देश है, जिसके आधार पर फिर एक सुंदर यूआई तैयार किया जाता है।
यह हमारे लिए महत्वपूर्ण है कि swagger.json का उपयोग किया जाता है : इसका समर्थन सभी व्यापक रूप से उपयोग की जाने वाली भाषाओं के लिए उपलब्ध है।
हमारे पास Open API विनिर्देशन swagger.json है । यह इस तरह दिखता है:

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

उत्तर कोड हैं, वे भी सभी प्रलेखित हैं:

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

लेकिन क्या होगा अगर आप एक अंतर का निर्माण करते हैं?

हमने स्वैगर डिफरेंट लाइब्रेरी की ओर रुख किया , जो हमें इसके लिए जरूरी है। इसके संचालन का सिद्धांत कुछ इस तरह है: आपके पास संस्करण 1.0 है, एपीआई संस्करण 1.1 के साथ, वे दोनों swagger.json उत्पन्न करते हैं , फिर आप उन्हें स्वैगर अंतर पर फेंकते हैं और परिणाम देखते हैं।
परिणाम कुछ इस तरह दिखता है:

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

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

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

मजेदार बात यह है कि हमने स्वैगर के लिए मूल ग्राहक का इस्तेमाल किया, वहीं लिखा। हमें अपनी बायनेरिज़ बनाने की भी आवश्यकता नहीं है, हमने केवल स्वैगर विनिर्देश भर दिया है।

हमें बहुत सी .json फाइलें मिलीं, जिनके साथ हमें कुछ करना था - उन्होंने एक स्वैगर एग्रीगेटर लिखा। यह एक बहुत ही सरल प्रोग्राम है जो निम्नलिखित सिद्धांत के अनुसार काम करता है:

वह एक नए अनुरोध को पूरा करती है, अगर यह हमारे डेटाबेस में नहीं है, तो वह कहती है।
वह अनुरोध पूरा करती है, उसके पास एक नया पैरामीटर है - जोड़ता है।
स्टेटस कोड के साथ एक ही बात।

इस प्रकार, हम सभी पेन, पैरामीटर और स्टेटस कोड के बारे में जानकारी प्राप्त करते हैं जो हमने उपयोग किया था। इसके अलावा, यहां आप वे डेटा एकत्र कर सकते हैं जिनके साथ ये अनुरोध किए गए थे: उपयोगकर्ता नाम, लॉगिन और इसी तरह। हम अभी तक यह पता नहीं लगा पाए हैं कि इस जानकारी का उपयोग कैसे किया जाए, क्योंकि सब कुछ हमारे साथ उत्पन्न होता है, लेकिन आप समझ सकते हैं कि कुछ अनुरोधों को क्या पैरामीटर कहा जाता है।

इसलिए, हम जीत से लगभग एक पत्थर फेंक रहे थे, लेकिन परिणामस्वरूप हमने स्वैगर डिफ को मना कर दिया, क्योंकि यह थोड़ा अलग अवधारणा में काम करता है - अंतर की अवधारणा में।

स्वैगर डिफ कहता है कि क्या बदल गया है, न कि क्या कवर किया गया है, लेकिन हम कवरेज के परिणाम को प्रदर्शित करना चाहते थे। बहुत अधिक अतिरिक्त डेटा है, यह विवरण, सारांश और अन्य मेटा-जानकारी के बारे में जानकारी संग्रहीत करता है, लेकिन हमारे पास यह जानकारी नहीं है। और जब हम डिफ बनाते हैं, तो वे हमें लिखते हैं कि "इस पेन में विवरण नहीं है", लेकिन यह मौजूद नहीं था।

खुद की रिपोर्ट

हमने अपना कार्यान्वयन किया, और यह निम्नानुसार काम करता है: हमारे पास कई फाइलें हैं जो ऑटोटेस्ट्स से आई हैं, हमारे पास स्वैगर सेवा एपीआई है, और हम इसके आधार पर एक रिपोर्ट तैयार करते हैं।
एक साधारण रिपोर्ट इस तरह दिखती है: ऊपर आप कुल कितने पेन (349) के बारे में जानकारी देख सकते हैं, जिस पर जानकारी पूरी तरह से कवर की गई है (प्रत्येक पैरामीटर, स्थिति कोड, और इसी तरह)। आप अपने स्वयं के मानदंड चुन सकते हैं, उदाहरण के लिए, कई मापदंडों को कवर करें।

यहां यह भी जानकारी है कि 40% आंशिक रूप से कवर किया गया है - इसका मतलब है कि हमारे पास पहले से ही इन पेन के लिए परीक्षण हैं, लेकिन कुछ चीजें अभी तक कवर नहीं की गई हैं, और आपको वहां ध्यान से देखने की आवश्यकता है। खाली कवरेज भी परिलक्षित होता है।

टैब के माध्यम से चलते हैं। यह एक पूर्ण-कवरेज है , हमारे पास सभी पैरामीटर हैं जो हमारे पास हैं, जो कवर किए गए हैं, स्थिति कोड और इसी तरह।

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

यह उपकरण आपको हमेशा अच्छे आकार में रहने और समझने की अनुमति देता है कि हमारे पास आंशिक रूप से क्या कवर है, कौन सा पैरामीटर भूल गया है, और इसी तरह।

अंतिम - शर्म की महिमा, हमें अभी भी यह करना है। जब आप इस पृष्ठ को देखते हैं और वहां खाली देखते हैं: 172 - आपके हाथ गिरते हैं, और फिर आप हाथ परीक्षकों को पढ़ाना शुरू करते हैं कि ऑटोटैस्ट्स कैसे लिखना है, तो वह बिंदु है।

जब हमने अपना समाधान निकाला तो हमें क्या लाभ हुआ?

सबसे पहले, हमने परीक्षणों को अधिक सार्थक रूप से लिखना शुरू किया। हम समझते हैं कि हम परीक्षण कर रहे हैं, और एक ही समय में हमारी दो रणनीतियां हैं। सबसे पहले, हम उस चीज़ को स्वचालित करते हैं जो तब नहीं होती है जब मैनुअल परीक्षक आते हैं और कहते हैं कि किसी विशेष सेवा के लिए यह महत्वपूर्ण है कि एक अनुरोध कम से कम एक बार निष्पादित हो, और हम खाली खोलें।

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

विकास के विचार

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

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

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

तीसरा विकास विचार एल्योर रिपोर्ट के साथ एकीकरण है। मैं इसे इस तरह से देखता हूं:

एक नियम के रूप में, जब पैरामीटर "परीक्षण" होता है, तो यह हमेशा हमें यह नहीं बताता है कि यह कैसे परीक्षण किया जाता है। और मैं इस पैरामीटर को इंगित करना चाहता हूं और परीक्षण के विशिष्ट चरणों को देखना चाहता हूं।

वेब परीक्षण कवरेज

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

यदि आप अपनी साइट को देखते हैं - यह कुछ तत्वों और उनके साथ बातचीत करने के तरीके हैं। यह एक पूर्ण विवरण है: "एक तत्व इसके साथ बातचीत करने का एक तरीका है।" आप लिंक पर क्लिक कर सकते हैं, आप पाठ की प्रतिलिपि बना सकते हैं, आप इनपुट में कुछ चला सकते हैं। साइट में संपूर्ण तत्व और उनकी सहभागिता के तरीके शामिल हैं:

परीक्षण कैसे चलते हैं: वे किसी बिंदु से शुरू होते हैं, फिर, उदाहरण के लिए, कुछ फ़ॉर्म भरें, कहें, एक प्राधिकरण फ़ॉर्म, फिर अन्य पृष्ठों पर बिखरे, फिर दूसरे से दूसरे और अंत में। ।

यदि प्रबंधक पूछता है कि क्या किसी विशेष बटन का परीक्षण किया जा रहा है, लेकिन इस प्रश्न का उत्तर देना मुश्किल है: आपको कोड खोलने या TestRail पर जाने की आवश्यकता है, तो मैं इस समस्या का समाधान देखना

चाहता हूं : मैं इस तत्व को इंगित करना चाहता हूं और हमारे पास सभी परीक्षण देखना चाहते हैं। इस आइटम पर। अगर ऐसा कोई साधन होता, तो मुझे खुशी होती। जब हमने इस विचार के बारे में सोचना शुरू किया, तो हमने सबसे पहले Yandex.Metrica को देखा। वे वास्तव में लिंक मानचित्र के रूप में लगभग समान कार्यक्षमता रखते हैं। एक अच्छा विचार।

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

आप सभी प्रकार के रुझानों को आकर्षित कर सकते हैं, मेटा-जानकारी जोड़ सकते हैं, लेकिन क्या होगा यदि हम यह सब लेते हैं और परीक्षण के दृष्टिकोण से आकर्षित करते हैं? इसलिए, हमारे पास एक कार्य है: कुछ तत्व को इंगित करने के लिए और परीक्षणों की सूची के साथ एक नोट प्राप्त करें।

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

SearchPage.open ();
SearchPage.offersList().should(hasSizeGreaterThan(0));

हम चाहते हैं कि कम से कम एक परिणाम प्रदर्शित हो, अन्यथा हम इसका परीक्षण नहीं करेंगे। फिर हम कर्सर को तत्व में ले जाते हैं, फिर उस पर क्लिक करें।

searchPage.offer(FIRST).moveCursor();
searchPage.offer(FIRST).actionBar().note().click();

फिर हम User_Text इनपुट में सेव करते हैं और सबमिट करते हैं।

searchPage.offer(FIRST).addNoteInput().sendKeys(USER_TEXT);
searchPage.offer(FIRST).saveNote().click();

उसके बाद, हम जाँचते हैं कि पाठ ठीक वही है जो होना चाहिए था।

 searchPage.offer(FIRST).addNoteInput().should(hasValue(USER_TEXT));

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

फिर हम प्रत्येक परीक्षा के रूप में इस लॉग को लुभाना में संलग्न करते हैं, और जब हमारे पास बहुत सारे locators.json होते हैं , तो हम meta.json उत्पन्न करते हैं । योजना सभी तत्वों के लिए समान है।

हमारे पास Google Chrome के लिए एक प्लगइन है। हम एक प्लगइन के रूप में एक निर्णय करना चाहते थे। मैंने विशेष रूप से एक वक्र स्क्रीनशॉट बनाया ताकि एक महत्वपूर्ण विवरण स्लाइड पर दिखाई दे - locators.json को रास्ता ।

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

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

यदि आप किसी तत्व पर होवर करते हैं, तो यह डेटा लेगा और आपके tms, Allure Board इत्यादि से आपके वास्तविक परीक्षण प्रिंट करेगा। परिणाम पूरी जानकारी है कि क्या परीक्षण किया जा रहा है और कैसे।
कृपया ध्यान दें कि प्रत्येक परीक्षा से आप सीधे एल्योर रिपोर्ट में विफल हो सकते हैं।

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

लाभ क्या है?

जैसे ही हमने इस सरल दृष्टिकोण को लागू किया, तब, मुख्य रूप से, हम यह समझने लगे कि हमने परीक्षणों में क्या परीक्षण किया है।

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

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

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

इस दृष्टिकोण का एक और लाभ अक्सर उपयोग किए जाने वाले तत्व हैं। यदि हम इस ब्लॉक को ओवरराइड करते हैं, जिसमें 87 परीक्षण हैं, तो वे सभी गिर जाएंगे। आपको समझ में आने लगता है कि आपके टेस्ट कितने फ्लैक्स हैं।

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

आप और कैसे विकसित हो सकते हैं?

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

एक अन्य विचार वर्तमान परीक्षा परिणाम को प्रदर्शित करना है। उदाहरण के लिए, इस तरह की तस्वीर को मैन्युअल परीक्षक को तुरंत फेंकना सुविधाजनक है:

आपको यह नहीं सोचना चाहिए कि कौन से परीक्षण टूट गए, क्योंकि आप साइट पर जा सकते हैं, परीक्षण पर क्लिक करें और अन्य परीक्षणों की जांच किए बिना इसके माध्यम से जा सकते हैं। यह आसान है, आप एल्योर से इस जानकारी को उठा सकते हैं और इसे यहीं आकर्षित कर सकते हैं।

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

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

आप परतों द्वारा परीक्षणों के वितरण को भी जोड़ सकते हैं, क्योंकि आप न केवल यह देखना चाहते हैं कि हमारे पास ये परीक्षण हैं, बल्कि सभी प्रकार के परीक्षण जो इस पृष्ठ पर हैं, संभवतः मैन्युअल परीक्षण भी।

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

अंत में, सामान्य रणनीति के बारे में बात करते हैं। हमने पहले से ही इस बारे में बात की है कि किस प्रकार के कवरेज हैं, दो का नाम, तीसरे प्रकार की कोटिंग के साथ आया था, जिसका उपयोग हमने परिणामस्वरूप किया था। इसलिए हमने इस समस्या को एक अलग कोण से लिया और देखा।

एक ओर, कवरेज है जो 1963 के बाद से लात मारी गई है, दूसरी ओर, मैन्युअल परीक्षक हैं जो कोड की तुलना में अधिक वास्तविक दुनिया में रहने के अभ्यस्त हैं। यह केवल इन दो दृष्टिकोणों को संयोजित करने के लिए बनी हुई है।

रुचि रखने वाले हमेशा हमारे समुदाय में शामिल हो सकते हैं। हमारे दो लोगों की रिपॉजिटरी इस प्रकार है कि कवरेज समस्या से निपटने के लिए

ऑटो टेस्ट कवरेज विज़ुअलाइज़ेशन