स्वचालित वेब अनुप्रयोग परीक्षण (MS Unit टेस्टिंग फ्रेमवर्क + सेलेनियम वेबड्राइवर C #)। भाग 1: परिचय

परिचय

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

• जितना संभव हो उतना सरल है ताकि मैन्युअल परीक्षण विशेषज्ञ भी परीक्षण लिख सकें
• लचीला और विस्तार योग्य है, क्योंकि हम इस स्तर पर काम की पूरी मात्रा का पर्याप्त मूल्यांकन नहीं कर सकते हैं
• क्रॉस-प्लेटफ़ॉर्म (सेलेनियम वेबड्राइवर सी # फ़ायरफ़ॉक्स, क्रोम और IE का समर्थन करता है)

मेरे उदाहरण में, मैं .NET (Microsoft यूनिट टेस्टिंग फ्रेमवर्क) और सेलेनियम वेबड्राइवर C # का उपयोग करूंगा।

संदर्भ

भाग 1: परिचय
भाग 2.1: सेलेनियम एपीआई आवरण - ब्राउज़र
भाग 2.2: सेलेनियम एपीआई आवरण - वेबइमेंट
भाग 3: वेबपेज - पृष्ठों का वर्णन करना
भाग 4: अंत में परीक्षण लिखना
एक रूपरेखा प्रकाशित करना

चलो चलते हैं

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



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

परीक्षण

हम तय करेंगे कि हमारे परीक्षण क्या होंगे। हम पहिया को सुदृढ़ नहीं करेंगे - आदर्श रूप से, परीक्षण में 4 भाग होते हैं:

• इनपुट (परीक्षण) डेटा
• पूर्व शर्त, अर्थात् सिस्टम की कुछ स्थिति जिसमें हम आवश्यक जांच कर सकते हैं
• वेब अनुप्रयोग के साथ बातचीत
• जाँच - परिणाम के साथ अपेक्षित परिणाम की तुलना। इसके लिए MS Unit टेस्टिंग फ्रेमवर्क में एक अलग वर्ग Assert है

परीक्षणों की परमाणुता सुनिश्चित करना महत्वपूर्ण है - परीक्षण को एक तार्किक ऑपरेशन की जांच करनी चाहिए और, आदर्श रूप से, एक एकल जांच होनी चाहिए। इस दृष्टिकोण के लाभ इस प्रकार हैं:

• परीक्षा परिणामों के विश्लेषण के लिए कम समय
• बड़े पैमाने पर लॉगिंग को लागू करने के लिए समय बर्बाद करने की आवश्यकता नहीं है (यह मत भूलो कि एमएस यूनिट टेस्टिंग फ्रेमवर्क परीक्षण के दौरान सभी प्रकार की नैदानिक ​​जानकारी एकत्र करने में सक्षम है, उदाहरण के लिए: कॉल स्टैक, इवेंट लॉग, इंटेलीट्रेस, रिकॉर्ड फोटो और वीडियो, कोड कवरेज विश्लेषण

परीक्षण के तहत उत्पाद के वेब पृष्ठों का विवरण

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

उपयोगिताएँ

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

निष्कर्ष और उदाहरण

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

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

[TestClass] public class LogOnTests : TestsBase { [TestMethod] public void LogOnWithEmptyLogin() { #region TestData const string login = null; const string password = "password"; const string error = "Empty login!"; #endregion Browser.Open(...); LogOnPage.LogOn(login, password); Assert.AreEqual(error, LogOnPage.Error, "Error expected."); } } public static class LogOnPage { private static readonly WebElement LoginEdit = new WebElement().ById("Login"); private static readonly WebElement PasswordEdit = new WebElement().ById("Password"); private static readonly WebElement LogOnButton = new WebElement().ById("LogOn"); private static readonly WebElement LogOnValidationError = new WebElement().ById("LogOnValidation"); public static void LogOn(string login, string password) { LoginEdit.Text = login; PasswordEdit.Text = password; LogOnButton.Click(); } public static string Error { get { return LogOnValidationError.Text; } } } 

पीएस मुझे एक पुरानी रूसी कहावत याद थी: जो जल्दी उठता है, वह परीक्षणों को डिबग करता है।