डेस्कटॉप एप्लिकेशन का स्वचालित परीक्षण:समीचीनता और रूपरेखा अवलोकन

परिचय

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

आरओआई

स्वचालित UI परीक्षण लिखने से पहले, हमें यह आकलन करना होगा कि हमारे निवेश कितने लाभदायक हैं। हमने ROI (रिटर्न ऑन इन्वेस्टमेंट https://en.wikipedia.org/wiki/Return_on_investment) की मदद से ऐसा किया
यूआई परीक्षण के आरओआई की गणना करना भी कई अज्ञात चरों के साथ एक दिलचस्प काम बन गया:

ROI =लाभ / व्यय
या
ROI =(लाभ - व्यय) / व्यय

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

• नए क्यूए विशेषज्ञों को परीक्षण मामलों में वर्णित चरणों की सीमित समझ हो सकती है। जब ऐसा होता है, तो स्थिति को बेहतर ढंग से समझने में मदद करने के लिए कुछ लोग स्वीकृति परीक्षण में शामिल होंगे। यहां, हमें इस सवाल को भी ध्यान में रखना चाहिए कि हमारे पास पर्यावरण सेटिंग्स और आवश्यकताओं के बारे में जानकारी कितनी प्रासंगिक है।
• कभी-कभी स्वीकृति परीक्षण में शामिल लोग तकनीकी दस्तावेज सीखने में समय व्यतीत करते हैं।
• ऐप स्वयं सेवाओं के एक विशिष्ट सेट के साथ इंटरैक्ट करता है। यदि उनमें से एक उपलब्ध नहीं है, तो कम अनुभवी क्यूए विशेषज्ञ बग का वर्णन करने में समय व्यतीत करेंगे, जो कि डेवलपर्स अपनी बारी में जांच करेंगे। परिणामस्वरूप, समय बर्बाद होता है क्योंकि ब्लैकआउट/हार्डवेयर अपडेट/कंप्यूटर रीबूट के बाद आवश्यक सेवा ठीक से नहीं चलती है।
• QA परीक्षकों के कंप्यूटर बहुत शक्तिशाली नहीं होते हैं। यदि कोई SSD नहीं है, तो आप इसे स्थापना के दौरान पहले ही नोटिस कर लेंगे। साथ ही, यदि ऐप भारी लोड के तहत काम कर रहा है, तो संभव है कि धीमी पेजिंग फ़ाइल का उपयोग किया जाएगा।
• सच कहूं तो, हम बहक गए और भूल गए कि हम स्वचालन के साथ काम कर रहे हैं। वैसे, क्या आपने अपने ब्राउज़र में Youtube टैब बंद कर दिया है?

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

लाभ =(X - Y) * N =(60 - 1) * 8 =472 दिन

X - मैन्युअल परीक्षण पर बिताया गया समय (60 दिन)
Y - स्वचालित परीक्षण करने में लगने वाला समय (1 दिन)
N - स्वीकृति में लगने वाला समय

इसके बाद, हम खर्चों को देखेंगे:

व्यय =ए + बी + सी + डी + ई + एफ =0 + 10 + 5 + 50 + 7 + 8 =80

ए - स्वचालन उपकरण लाइसेंस की लागत। हमारे मामले में, एक मुफ़्त टूल का इस्तेमाल किया गया था।
B - एक क्यूए विशेषज्ञ का प्रशिक्षण (10 दिन)
C - बुनियादी ढाँचा तैयार करना (5 दिन)
D - परीक्षण विकसित करना (50 दिन)
E - परीक्षण चलाना और प्रक्रिया में खोजे गए बग का वर्णन करना (7 दिन)
F - परीक्षण रखरखाव (8 दिन)

कुल:

ROI =लाभ / व्यय =472/80 =5,9

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

मौजूदा फ़्रेमवर्क

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

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

परीक्षण पूर्ण

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

--no-sandbox
program files (x86)\smartbear\testcomplete12\x64\bin\Extensions\tcCrExtension\tcCEFHost.dll;application/x-testcomplete12-0-chrome-browser-agent

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

यदि आप इसे काफी देर तक देखते हैं, तो आप इसे सुन सकते हैं। Microsoft इस "चमत्कार" को पॉवरशेल स्क्रिप्ट में बदलने का सुझाव देता है। एक विकल्प के रूप में, जावास्क्रिप्ट और पायथन का उपयोग किया जा सकता है, जो स्थिति में मदद करता है।

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

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

अब तक का सबसे खराब ट्रेड डील, चलिए आगे बढ़ते हैं।

कोडित UI

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

परीक्षण लिखने का दृष्टिकोण काफी सुखद था:शेल में एकीकृत कमांड ने एक रिकॉर्डर को जल्दी से लॉन्च करने की अनुमति दी जो एक इकाई परीक्षण और यूआई का वर्णन करने वाला एक "मानचित्र" वर्ग उत्पन्न करता है। वीएस में एकीकृत अतिरिक्त उपकरण कोड को कॉल किए बिना अलग परीक्षण वर्ग बनाने की क्षमता प्रदान करते हैं।
हमने जो एकमात्र विशेषता देखी वह आंशिक वर्ग थी जिसमें नियंत्रण का विवरण था और इसे दो भागों में विभाजित किया गया था। कई अन्य बातों के साथ, यह दस्तावेज़ीकरण में वर्णित है। यह दस्तावेज़ीकरण एक आरामदायक कार्य प्रक्रिया के लिए पर्याप्त है:कोड उदाहरण और स्क्रीनशॉट सभी तकनीकी जानकारी को आसानी से सुलभ और समझने में आसान बनाते हैं। सीधे शब्दों में कहें तो, जब रिकॉर्डर UI का वर्णन करता है, तो एक "Designer.cs" फ़ाइल उत्पन्न होती है। यह फ़ाइल उपयोगकर्ता इंटरफ़ेस का वर्णन करने वाले कोड का पुन:उपयोग करने के लिए ज़िम्मेदार है। रिकॉर्डर जो कुछ भी संभाल नहीं सका, उसे मैन्युअल रूप से लिखा जाना चाहिए और कक्षा के स्वत:उत्पन्न भाग के बाहर कहीं सहेजा जाना चाहिए। यह नियंत्रण बनाते समय वीएस डिग्नर्स द्वारा लिखी गई आंशिक कक्षाओं के समान ही है। नियंत्रणों और उनके राज्य जांचों पर किए गए संचालन की प्राथमिकता को एक ऐसी विधि में वर्णित किया गया है जिसमें रिकॉर्डर सहायक रूप से एक मानक TestMethod विशेषता जोड़ता है। . सबसे पहले, इसने एप्लिकेशन के कुछ मुद्दों को अस्पष्ट कर दिया:कुछ नियंत्रणों की नाम संपत्ति निर्दिष्ट नहीं की गई थी, और रिकॉर्डर ने नियम उल्लंघन के इस हास्यास्पद उदाहरण को पाठ के माध्यम से स्वीकार्य और खोजे गए नियंत्रणों को कॉल करना समझा। साथ ही, इसने जटिल नियंत्रणों को बहुत ही अक्षमता से संभाला। उदाहरण के लिए, ट्री व्यू नोड्स को नोड इंडेक्स द्वारा खोजा गया था जिसने इंटरफ़ेस विस्तार के मामले में बनाए गए "मैप" वर्ग को अनुपयोगी बना दिया था। और रिकॉर्डर का मूल्य हमारी दृष्टि में काफी गिर गया - यदि आपको बाद में इसकी जांच करने की आवश्यकता हो तो कोड को ऑटोजेनरेट करने का क्या मतलब है?
हम इन सभी चीजों के साथ शांति बना सकते हैं और एक सराहनीय समाधान ढूंढ सकते हैं, लेकिन अचानक, गड़गड़ाहट हुई:Microsoft कहा कि यह तकनीक अब अप्रचलित हो चुकी है। इसके साथ ही वीएस 2019 कोडेड यूआई को सपोर्ट करने वाले विजुअल स्टूडियो का आखिरी वर्जन बन गया। वीएस 2019 पर अभी और कुछ साल पहले निर्भर होने की संभावना वास्तव में उतनी डरावनी नहीं थी, लेकिन हमारी परियोजना काफी बड़ी है, इसलिए कहीं न कहीं मुश्किलें शुरू हो सकती हैं (उदाहरण के लिए 2025)।
आइए संक्षेप करते हैं। कोडित UI के साथ, हमारे पास होगा:

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

अंतिम बिंदु को छोड़कर सब कुछ अच्छा लग रहा था। यही कारण है कि हमें अपनी खोज जारी रखने की आवश्यकता है।

टेस्टस्टैक.व्हाइट

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

var appPath = @"C:\Program files\UiAutomatedTestApplication\TestApplication.exe";
var app = TestStack.White.Application.Launch(appPath);

var windowSearchCriteria = SearchCriteria.ByAutomationId("MainForm");
var window = app.GetWindow(windowSearchCriteria, InitializeOption.NoCache);

var execute = window.GetElement(SearchCriteria.ByText("Execute"));
var invokePattern = (InvokePattern)execute.GetCurrentPattern(InvokePattern.Pattern);
invokePattern.Invoke();

app.WaitWhileBusy();

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

public class InitializeOption {
//
// Summary:
//     This option should not be used as this is only for internal white purposes
public static InitializeOption WithCache { get; }
public static InitializeOption NoCache { get; }
public virtual bool Cached { get; }
public virtual string Identifier { get; }
public virtual bool NoIdentification { get; }

//
// Summary:
//     Specify the unique identification for your window. White remembers the location
//     of UIItems inside a window as you find them. Next time when items inside the
//     same window is found they are located first based on position which is faster.
//
// Parameters:
//   identifier:
public virtual InitializeOption AndIdentifiedBy(string identifier);
public virtual void NonCached();
public override string ToString();
}

इस तरह के अजीब फैसले हर जगह होते हैं, और क्यूए के लिए ढांचा बहुत ही सारगर्भित होता है।

प्रलेखन अच्छी गुणवत्ता का है और इसने एक अच्छा सामान्य प्रभाव छोड़ा है। प्रोजेक्ट का सोर्स कोड जीथब पर होस्ट किया गया था, लेकिन नवीनतम कमिटमेंट 8 जनवरी, 2016 को किया गया था।
व्हाइट के बारे में जानकारी को सारांशित करते हुए, हमारे पास:

• सभ्य दस्तावेज़ीकरण
• स्रोत कोड तक पहुंच
• एक छोटा समुदाय
• सभी क्यूए विशेषज्ञों को यह समझाने की आवश्यकता है कि नियंत्रण का व्यवहार पैटर्न वर्ग के माध्यम से कार्यान्वित किया जाता है
• एक पुराना भंडार जिससे हमें निश्चित रूप से फोर्क करने की आवश्यकता होगी

सबसे अप्रिय हिस्सा अपने स्वयं के ढांचे को विकसित करने की आवश्यकता थी, जिससे हम बचना चाहेंगे। इसलिए हमें आगे बढ़ना पड़ा।

एपियम

हमने पहले अपनी खोज में एपियम का सामना किया है, लेकिन माइक्रोसॉफ्ट द्वारा कोडित यूआई का उपयोग बंद करने के बाद ही इस पर गंभीरता से विचार करना शुरू किया।
पहली नज़र में, एपियम की मदद से परीक्षण तीन रीलों के साथ एक स्लॉट मशीन की तरह दिखता है। पहला वह भाषा दिखाता है जिसके लिए एक एपीआई है जो ड्राइवर के साथ बातचीत की अनुमति देता है। यह किसी भी परिचित भाषा में परीक्षण लिखने की क्षमता प्रदान करता है:पायथन, सी #, जावा, आदि। दूसरी रील ड्राइवर ऐप दिखाती है जो परीक्षणों और हमारे द्वारा परीक्षण किए जा रहे उत्पाद के बीच एक मध्यवर्ती परत के रूप में कार्य करती है। जैसा कि प्रलेखन में वर्णित है, JSON वायर प्रोटोकॉल का उपयोग करके परीक्षणों के साथ बातचीत की जाती है - यह वास्तव में हमें किसी भी भाषा में परीक्षण लिखने की क्षमता देता है। और तीसरी रील उस वस्तु को दिखाती है जिसका हम परीक्षण कर रहे हैं। यह वास्तव में कोई फर्क नहीं पड़ता कि यह वेबसाइट, मोबाइल ऐप या डेस्कटॉप ऐप है, जब तक कि संबंधित ड्राइवर चल रहा हो। जैसा कि आप देख सकते हैं, घटक सुरुचिपूर्ण ढंग से विनिमेय हैं।
पैकेज की प्रासंगिकता का अनुमान संतोषजनक था - जीथब पेज पर, हम देख सकते थे कि रिपॉजिटरी में नए कमिट थे। WinAppDriver रिपॉजिटरी की जांच करते समय, हमने पाया कि इसमें एक रिकॉर्डर भी था।
हमने प्रोटोटाइप लिखते समय कुछ मुद्दों पर ध्यान देना शुरू किया। उदाहरण के लिए, क्योंकि ढांचा बहुत बहुउद्देश्यीय है, डेस्कटॉप नियंत्रण के लिए जिम्मेदार WindowsElement में FindElementByCssSelector विधि है जो निष्पादन पर निम्नलिखित अपवाद फेंकता है:"अप्रत्याशित त्रुटि। लागू नहीं किया गया आदेश:सीएसएस चयनकर्ता लोकेटर रणनीति समर्थित नहीं है"। अगले लेख में, हम इस ढांचे के साथ काम करते समय सामने आई समस्याओं के बारे में अधिक विस्तार से बात करेंगे, लेकिन अभी के लिए मैं यह कहना चाहता हूं कि हम उन सभी को संभालने में कामयाब रहे।

संक्षेप में, यहां बताया गया है कि एपियम का उपयोग करते समय हमारे पास क्या होगा:

• एक बुनियादी ढांचे और एक परीक्षण के दायरे में एक ब्राउज़र (प्रतिक्रिया पृष्ठ खोलना, ऑनलाइन सक्रियण, ईमेल वितरण की जांच) के साथ बातचीत की आवश्यकता वाले एप्लिकेशन कार्यक्षमता का परीक्षण करने की क्षमता
• विजुअल स्टूडियो के किसी भी संस्करण के साथ काम करने की क्षमता
• यूआई रेंडर करने के लिए ब्राउज़र का उपयोग करने वाले डेस्कटॉप एप्लिकेशन का परीक्षण करने की क्षमता। इसका एक अच्छा उदाहरण Azure डेटा स्टूडियो होगा
• कोडित UI से हमें मिलने वाले सभी लाभ
• एक निःशुल्क ढांचा जिसका उपयोग करने की Microsoft अनुशंसा करता है
• इन्फ्रास्ट्रक्चर जो सेलेनियम के साथ काम करने वाले क्यूए विशेषज्ञों से परिचित है
• ताज़ा कमिट के साथ अपडेट किया गया एक संग्रह
• एक शालीनता से बड़ा समुदाय, हालांकि, कोडित UI के समुदाय जितना बड़ा नहीं है
• सीमित कार्यक्षमता वाला रिकॉर्डर
• परीक्षण के लिए ड्राइवर एप्लिकेशन चलाने की आवश्यकता। बहुत सुविधाजनक नहीं है, लेकिन इसकी अपनी लॉगिंग कार्यक्षमता है
• AppiumWebElement से WindowsElement की दुर्भाग्यपूर्ण विरासत के कारण अपने आप को पैर में गोली मारने के बहुत सारे अवसर

फ़्रेमवर्क की ज़रूरतों के साथ सभी बिंदुओं को देखते हुए और उनमें से प्रत्येक फ्रेमवर्क में पाए जाने वाले सभी मुद्दों की तुलना करते हुए, हमने आखिरकार एपियम को चुना।

निष्कर्ष

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