हम कैनवास पर परीक्षण अनुप्रयोगों को कैसे स्वचालित करते हैं

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


मेरे जीवन के अंतिम 8 महीने, मेरे सहयोगियों और मैंने HTML5 में लिखे एक पूरी तरह से नए दस्तावेज़ संपादक का परीक्षण करने में बिताया। नवीन उत्पादों का परीक्षण करना मुश्किल है, यदि केवल इसलिए कि इससे पहले किसी ने ऐसा नहीं किया है।

हमारे सभी विचारों को लागू करने के लिए, हमें तीसरे पक्ष के उपकरणों की आवश्यकता थी:

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

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

1. सत्यापन

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

1. एप्लिकेशन के एपीआई का उपयोग करना।

2. अपने स्वयं के दस्तावेज़ पार्सर का उपयोग करना।

एपीआई

सकारात्मक पहलू:

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

नकारात्मक पक्ष:

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

डाउनलोड किए गए दस्तावेज़ को पार्स करना

सकारात्मक पहलू:

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

नकारात्मक पक्ष:

• कार्यान्वयन में कठिनाई।

अंतिम सत्यापन

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

DOCX को पार्सिंग के प्रारूप के रूप में चुना गया था। यह इस तथ्य के कारण है कि:

• संपादक में ही, DOCX प्रारूप के लिए समर्थन को सर्वोत्तम रूप से लागू किया गया था, अधिकतम संख्या में कार्यों का समर्थन किया गया था, और इसे बचाने के लिए सबसे अधिक गुणात्मक और मज़बूती से किया गया था।
• DOC के विपरीत, स्वयं DOCX प्रारूप अधिक खुला है और इसमें एक सरल संरचना है। संक्षेप में, यह XML फ़ाइलों के साथ एक ज़िप संग्रह है।

हमें DOCX को पार्स करने के लिए एक तृतीय-पक्ष लाइब्रेरी नहीं मिली, जो हमें आवश्यक फ़ंक्शन के सेट का समर्थन करेगी। इसके बाद, इसी तरह की स्थिति एक अलग प्रारूप के साथ विकसित हुई, जब टेबल संपादक का परीक्षण करने के लिए हमें XLSX पार्सर की आवश्यकता थी।

पार्सर के लिए केवल एक विशेषज्ञ जिम्मेदार है। कार्यात्मक की मुख्य रीढ़ लगभग एक महीने में लागू की गई थी, लेकिन अभी भी लगातार समर्थित है - कीड़े तय हो गए हैं (जो, वैसे, मौजूदा कार्यात्मक के लिए लगभग कोई बग नहीं हैं), और दस्तावेज़ संपादक में शुरू की गई नई कार्यक्षमता के लिए समर्थन जोड़ा जाता है।

एक उदाहरण:

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



दस्तावेज़ में तत्वों (तत्वों) का एक सेट होता है - ये पाठ, चित्र, तालिकाओं के पैराग्राफ हो सकते हैं।

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

अंदर character_style सभी आवश्यक पाठ गुण हैं, जैसे आकार = 20 - फ़ॉन्ट आकार, फ़ॉन्ट = "टाइम्स न्यू रोमन" - फ़ॉन्ट प्रकार, font_style - फ़ॉन्ट शैली गुणों के साथ एक वर्ग (बोल्ड, इटैलिक, रेखांकित, स्ट्राइक), साथ ही साथ अन्य सभी गुण। दस्तावेज़।

परिणामस्वरूप, इस दस्तावेज़ को सत्यापित करने के लिए, हमें यह कोड लिखना चाहिए:

doc.elements.first.character_styles_array.first.size.should = 2 20
doc.elements.first.character_styles_array.first.font.should == "टाइम्स रोमन":
doc.elements.first.character_styles_array.first.font_style.should == FontStyle.new (सत्य, सत्य, असत्य, असत्य)

2. दस्तावेज़ जनरेटर

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

इसके विकास के आधार पर, निम्नलिखित निष्कर्ष किए गए:

परीक्षण बनाते या स्वचालित करते समय, एक बार में सभी संभव प्रारूप कार्यक्षमता को कवर करने का प्रयास न करें। यह अतिरिक्त कठिनाइयों का निर्माण करेगा, विशेष रूप से परीक्षण के तहत आवेदन के विकास के प्रारंभिक चरण में।

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

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

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

3. परीक्षण चलाने के लिए रूपरेखा

सेलेनियम के साथ बातचीत

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

इस ढांचे के विकास से पहले, वेब अनुप्रयोगों का परीक्षण जावा में बनाया गया था, और सभी XPath तत्वों और अन्य ऑब्जेक्ट पहचानकर्ताओं को एक अलग xml फ़ाइल में स्थानांतरित किया गया था ताकि XPath को बदलते समय संपूर्ण परियोजना को फिर से स्थापित करना आवश्यक न हो।

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

सेलेनियम वेबड्राइवर में कार्य ओवरलोड थे क्योंकि आपको 1200 xPath तत्वों वाली फ़ाइल के साथ काम करना था। हमने उन्हें फिर से काम किया:

यह था

get_attribute(xpath, attribute) @driver.find_element(:xpath, xpath_value) attribute_value = element.attribute(attribute) return attribute_value end get_attribute('//div/div/div[5]/span/div[3]', 'name') 

बन गया है

 get_attribute(xpath_name, attribute) xpath_value =@@xpaths.get_value(xpath_name) elementl = @driver.find_element(:xpath, xpath_value) attribute_value = element.attribute(attribute) return attribute_value end get_attribute('admin_user_name_xpath', 'name') 

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

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

मेनू बातचीत

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

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

इन कार्यों को लिखने की प्रक्रिया में, स्मोक परीक्षणों की पहली श्रेणी बनाई गई थी, जिसकी स्क्रिप्ट सभी कार्यों के लिए इस तरह दिखती है:

1. एक नया दस्तावेज़ बनाया गया है।

2. एक (सिर्फ एक) लिखित फ़ंक्शन को कहा जाता है, जो कुछ विशिष्ट सही मान (यादृच्छिक नहीं, लेकिन विशिष्ट और सही है, इस चरण में त्यागने के लिए एक कार्यात्मक है जो केवल संभावित मूल्यों के एक भाग पर सही ढंग से काम करता है) पारित किया जाता है

3. दस्तावेज़ डाउनलोड करें

4. हम सत्यापित करते हैं

5. रिपोर्टिंग सिस्टम में परिणाम दर्ज करें

6. लाभ!

4. टेस्ट

इसलिए, संक्षेप में, आइए उन परीक्षणों की श्रेणियों को देखें जो हमारी परियोजना में मौजूद हैं।

1. धुआँ परीक्षण
उनका लक्ष्य कुछ छोटी मात्रा में इनपुट डेटा पर उत्पाद का परीक्षण करना है और, सबसे महत्वपूर्ण बात यह सत्यापित करने के लिए कि फ़्रेमवर्क स्वयं नए बिल्ड पर सही तरीके से काम करता है (xPath तत्व बदल गए हैं, अनुप्रयोग इंटरफ़ेस मेनू बदल गया निर्माण का तर्क है)।


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

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


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

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


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


5. जोड़ी
पैरामीटर बंडलों की जाँच के लिए टेस्ट। उदाहरण के लिए, सभी शैलियों और आकारों (मापदंडों के साथ दो या अधिक फ़ंक्शन) के साथ फ़ॉन्ट हेडसेट की पूरी जांच। स्वतः उत्पन्न होते हैं। उनकी अवधि (कम से कम 4-5 घंटे, कुछ अधिक समय तक) के कारण उन्हें बहुत कम लॉन्च किया जाता है।


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

5. रिपोर्टिंग

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

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

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

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



निष्कर्ष में, कुछ आँकड़े:

प्रोजेक्ट आयु - 1 वर्ष

परीक्षणों की संख्या - लगभग 2000

पूर्ण किए गए मामलों की संख्या - लगभग 350 000

टीम - 3 लोग

पाए जाने वाले कीड़ों की संख्या लगभग 300 है