⛅️ 🎣 🏨 वेब एप्लिकेशन टेस्ट स्वचालन 🎉 👩🏼‍💼 🌭

टेस्ट ऑटोमेशन दो विषयों का मिलन स्थल है: विकास और परीक्षण। शायद इसलिए, मैं इस अभ्यास को कठिन, लेकिन दिलचस्प मानता हूं।

परीक्षण और त्रुटि के माध्यम से, हम निम्नलिखित तकनीकी स्टैक में आए:

SpecFlow (वैकल्पिक): डीएसएल
NUnit: परीक्षण रूपरेखा
PageObject + PageElements: UI अमूर्तता
परीक्षण संदर्भ (लक्ष्य पर्यावरण, सिस्टम उपयोगकर्ताओं के बारे में जानकारी)
Selenium.WebDriver

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

इतनी मेहनत क्यों?

जाहिर है, टेस्ट ऑटोमेशन के कई फायदे हैं। ऑटो समाधान:

समय बचाता है
परीक्षण करते समय मानव कारक को हटा देता है
नियमित प्रतिगमन परीक्षण के बोझ से राहत देता है

हर कोई जिसने कभी भी स्वचालित परीक्षण किया है, वह सिक्के के फ्लिप पक्ष के बारे में जानता है। स्वचालित परीक्षण हो सकते हैं:

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

उदाहरण के लिए, निम्नलिखित कोड पर विचार करें। नाम से यह देखा जा सकता है कि हम इस तथ्य का परीक्षण कर रहे हैं कि "गैंगनाम शैली" के अनुरोध पर Google कोरियाई लोकप्रिय कलाकार PSY के YouTube चैनल को पहला परिणाम देगा।

[Test] public void Google_SearchGangnamStyle_PsyYouTubeChanelIsOnTop() { var wd = new OpenQA.Selenium.Firefox.FirefoxDriver {Url = "http://google.com"}; try { wd.Navigate(); wd.FindElement(By.Id("gbqfq")).SendKeys("gangnam style"); wd.FindElement(By.Id("gbqfb")).Click(); var firstResult = new WebDriverWait(wd, TimeSpan.FromSeconds(10)).Until( w => w.FindElement(By.CssSelector("h3.r>a"))); Assert.AreEqual("PSY - YouTube", firstResult.Text); Assert.AreEqual("http://www.youtube.com/user/officialpsy", firstResult.GetAttribute("href")); } finally { wd.Quit(); } }

इस परीक्षण में बहुत सारी समस्याएं हैं:

हैरान आवेदन परतें (ड्राइवर, लोकेटर, परिणाम)
परीक्षण में लाइनों को सीवन किया जाता है
वेब ड्राइवर को बदलने के लिए, उदाहरण के लिए IE पर सभी परीक्षणों को बदलना आवश्यक है
लोकेटर को परीक्षण में तार दिया गया है और प्रत्येक परीक्षण में फिर से दोहराया जाएगा
वेब ड्राइवर निर्माण कोड दोहराव
त्रुटि संदेश के साथ नहीं
यदि पहला जोर "गिरता" है, तो दूसरी स्थिति की जांच बिल्कुल नहीं की जाएगी
परीक्षण पर पहली नज़र में, यह स्पष्ट नहीं है कि इसमें क्या हो रहा है, आपको इसे पढ़ना होगा और कोड को समझने में समय बिताना होगा

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

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

आपके परीक्षण भी कोड हैं। उन्हें आवेदन में कोड के रूप में व्यवहार करें। व्यावसायिक अनुप्रयोग परतों का विषय पहले से ही अच्छी तरह से कवर किया गया है। परीक्षणों में किन परतों को उजागर किया जा सकता है?

तकनीकी ड्राइवर (वेबड्राइवर, सेलेनियम आरसी, आदि)
परीक्षण संदर्भ (लक्ष्य वातावरण, उपयोगकर्ता, डेटा)
UI अमूर्तता - पृष्ठ, विजेट, पृष्ठ घटक (PageObject पैटर्न)
टेस्ट (परीक्षण ढांचा: NUnit, xUnit, MSTest)
डीएसएल

हम विकासवादी सुधार को आगे बढ़ाएंगे और अपने परीक्षण को ठीक करेंगे।

तकनीकी ड्राइवर

हमारे मामले में, यह सेलेनियम है। WeDriver। WebDriver अपने आप में एक परीक्षण स्वचालन उपकरण नहीं है, लेकिन सिर्फ एक ब्राउज़र प्रबंधन उपकरण है। हम HTTP अनुरोधों के स्तर पर परीक्षण को स्वचालित कर सकते हैं और बहुत समय बचा सकते हैं। वेब सेवाओं का परीक्षण करने के लिए, हमें एक वेब ड्राइवर की आवश्यकता नहीं है: एक प्रॉक्सी पर्याप्त है।
वेब ड्राइवर का उपयोग करना एक अच्छा विचार है क्योंकि:

आधुनिक अनुप्रयोग केवल एक अनुरोध-प्रतिक्रिया से अधिक हैं। सत्र, कुकीज़, जावा-स्क्रिप्ट, वेब सॉकेट। यह सब प्रोग्रामेटिक रूप से दोहराने के लिए कठिन हो सकता है।
ऐसा परीक्षण उपयोगकर्ता के व्यवहार के जितना संभव हो उतना करीब है।
कोड लिखने की जटिलता बहुत कम है।

तकनीकी ड्राइवर परत में शामिल हैं:

सभी वेब ड्राइवर सेटिंग्स
वेब ड्राइवर बनाने और नष्ट करने के पीछे तर्क
त्रुटि नियंत्रण

आरंभ करने के लिए, हम विन्यास में सेटिंग्स करेंगे। यह हमारे लिए इस तरह दिखता है:

 <driverConfiguration targetDriver="Firefox" width="1366" height="768" isRemote="false" screenshotDir="C:\Screenshots" takeScreenshots="true" remoteUrl="…"/>

चलो एक अलग वर्ग बनाते हैं जो वेब ड्राइवर को कॉन्फ़िगर करने, बनाने और नष्ट करने के तर्क को ले जाएगा।

 [Test] public void WebDriverContextGoogle_SearchGangnamStyle_PsyYouTubeChanelIsOnTop() { var wdc = WebDriverContext.GetInstance(); try { var wd = wdc.WebDriver; wd.Url = "http://google.com"; wd.Navigate(); wd.FindElement(By.Id("gbqfq")).SendKeys("gangnam style"); wd.FindElement(By.Id("gbqfb")).Click(); var firstResult = new WebDriverWait(wd, TimeSpan.FromSeconds(10)).Until( w => w.FindElement(By.CssSelector("h3.r>a"))); var expected = new KeyValuePair<string, string>( "PSY - YouTube", "http://www.youtube.com/user/officialpsy"); var actual = new KeyValuePair<string, string>( firstResult.Text, firstResult.GetAttribute("href")); Assert.AreEqual(expected, actual); } finally { wdc.Dispose(); } }

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

परीक्षण संदर्भ

एप्लिकेशन के ब्लैक-बॉक्स परीक्षण के लिए हमें एक निश्चित मात्रा में इनपुट की आवश्यकता होती है:

लक्षित वातावरण - url, परीक्षण किए गए अनुप्रयोगों के पोर्ट
एक अलग भूमिका सेट के साथ उपयोगकर्ता

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

 <environmentsConfiguration targetEnvironment="Google"> <environments> <environment name="Google" app="GoogleWebSite"> <apps> <app name="GoogleWebSite" url="http://google.com/" /> </apps> <users> <user name="Default" login="user" password="user" /> </users> </environment> </environmentsConfiguration>

इसके बजाय wd.Url = " google.com "; बन गया wd.Url = एन्वायरनमेंटकॉन्फिगरेशन। CurrentEnvironmentBaseUrl;

हमें अब सभी परीक्षणों में URL की नकल नहीं करनी चाहिए
किसी अन्य वातावरण का परीक्षण करने के लिए, एक परियोजना को एक अलग कॉन्फ़िगरेशन के साथ इकट्ठा करना और एक परिवर्तन जोड़ना पर्याप्त है

 <environmentsConfiguration targetEnvironment="Google-Test" xdt:Transform="SetAttributes">

पेज ऑब्जेक्ट्स

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

पृष्ठ वस्तुओं के मुख्य लाभ:

शक्तियों का पृथक्करण: पृष्ठ के सभी "व्यावसायिक तर्क" को पृष्ठ ऑब्जेक्ट में रखा जाना चाहिए, परीक्षण कक्षाएं केवल सार्वजनिक विधियों को कॉल करें और परिणाम की जांच करें
DRY - सभी लोकेटरों को एक स्थान पर रखा गया है। ~~यदि~~ UI बदल जाता है, तो हम केवल एक स्थान पर लोकेटर को बदल देंगे
तकनीकी चालक परत को छिपाना। आपके परीक्षण उच्च-स्तरीय अमूर्तता के साथ काम करेंगे। भविष्य में, आप ड्राइवर को बदलना चाह सकते हैं: उदाहरण के लिए, PhantomJS का उपयोग करें, या आमतौर पर प्रदर्शन में सुधार करने के लिए कुछ क्षेत्रों के लिए WebDriver का उपयोग करने से इनकार करते हैं। इस स्थिति में, आपको केवल पृष्ठ ऑब्जेक्ट कोड बदलना होगा। टेस्ट अपरिवर्तित रहेंगे
पृष्ठ ऑब्जेक्ट आपको स्थानीय लोगों को एक घोषणात्मक शैली में लिखने की अनुमति देता है

पेज ऑब्जेक्ट्स में क्या गायब है

विहित पैटर्न में आपके आवेदन के प्रति पृष्ठ एक वर्ग बनाना शामिल है। यह कुछ मामलों में असुविधाजनक हो सकता है:

अनुकूलन और / या गतिशील रूप से अस्थिर लेआउट
कई पृष्ठों पर मौजूद विजेट या अन्य तत्व

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

 [FindsBy(How = How.Id, Using = "gbqfq")] public IWebElement SearchTextBox { get; set; } [FindsBy(How = How.Id, Using = "gbqfb")] public IWebElement SubmitButton { get; set; } public GoogleSearchResults ResultsBlock { get; set; } public void EnterSearchQuery(string query) { SearchTextBox.SendKeys(query); } public void Search() { SubmitButton.Click(); }

और परिणामों के साथ एक "विजेट"

 public class GoogleSearchResults : PageElement { [FindsBy(How = How.CssSelector, Using = "h3.r>a")] public IWebElement FirstLink { get; set; } public KeyValuePair<string, string> FirstResult { get { var firstLink = PageHelper.WaitFor<GoogleSearchResults>(w => w.FirstLink); return new KeyValuePair<string, string>(firstLink.Text, firstLink.GetAttribute("href")); } } }

NuGet का WebDriver.Support पैकेज उत्कृष्ट PageFactory.InitElements विधि के साथ है ।
विधि अच्छी है, लेकिन इसके दुष्प्रभाव हैं। WebDriver.Support पैकेज से PageFactory एक प्रॉक्सी देता है और लोड होने के लिए तत्व की प्रतीक्षा नहीं करता है। इसके अलावा, यदि सभी तुल्यकालन विधियाँ By वर्ग के साथ काम करती हैं, जो अभी तक नहीं जानती है कि FindsBy विशेषता के साथ कैसे काम किया जाए ।
बेस क्लास पेज बनाकर इस समस्या को हल किया जाता है।

 /// <summary> /// Get Page element instance by type /// </summary> /// <typeparam name="T">Page element type</typeparam> /// <param name="waitUntilLoaded">Wait for element to be loaded or not. Default value is true</param> /// <param name="timeout">Timeout in seconds. Default value=PageHelper.Timeout</param> /// <returns>Page element instance</returns> public T GetElement<T>(bool waitUntilLoaded = true, int timeout = PageHelper.Timeout) where T : PageElement /// <summary> /// Wait for all IWebElement properies of page instance to be loaded. /// </summary> /// <param name="withElements">Wait all page elements to be loaded or just load page IWebElement properties</param> /// <returns>this</returns> public Page WaitUntilLoaded(bool withElements = true)

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

 var positionsWidget = Page.GetElement<GoogleSearchResults>();

आखिरी असुविधाजनक मामला था। कुछ विजेट हैं जो राज्य के आधार पर कुछ तत्वों को छिपाते हैं / दिखाते हैं। इस तरह के एक विजेट को एक संपत्ति के साथ कई में विभाजित करना अव्यावहारिक है।
एक समाधान भी मिला।

 public static IWebElement WaitFor<TPage>( Expression<Func<TPage, IWebElement>> expression, int timeout = Timeout) var firstLink = PageHelper.WaitFor<GoogleSearchResults>(w => w.FirstLink);

मैं इन विधियों के तकनीकी कार्यान्वयन को बोर नहीं करूंगा। आइए देखें कि रीफैक्टरिंग के बाद कोड कैसा दिखेगा।

 [Test] public void Google_SearchGangnamStyle_PsyYouTubeChanelIsOnTop() { try { var page = WebDriverContext.CreatePage<GooglePage>(EnvironmentsConfiguration.CurrentEnvironmentBaseUrl); page.EnterSearchQuery("gangnam style"); page.Search(); var expected = new KeyValuePair<string, string>( "PSY - YouTube", "http://www.youtube.com/user/officialpsy"); var actual = page.GetElement<GoogleSearchResults>().FirstResult; Assert.AreEqual(expected, actual); } finally { WebDriverContext.GetInstance().Dispose(); } }

इस स्तर पर, यह बहुत बेहतर हो गया:

परीक्षण वर्ग ने चालक नियंत्रण को त्याग दिया और इन जिम्मेदारियों को पृष्ठ वर्ग में सौंप दिया।
हमें स्थानीय लोगों के दोहराव से छुटकारा मिला
टेस्ट पठनीयता में सुधार हुआ

परीक्षण

जब हमने पेज ऑब्जेक्ट में लोकेटर और लॉजिक निकाला, तो परीक्षण कोड अधिक संक्षिप्त और साफ हो गया। हालांकि, कुछ चीजें अभी भी बहुत अच्छी नहीं हैं:

वेब ड्राइवर बनाने के तर्क को परीक्षण से परीक्षण तक दोहराया गया है
प्रत्येक विधि में एक पेज बनाने का तर्क भी बेमानी है
जादुई रेखाएँ, "गंगनम स्टाइल", "PSY - YouTube", "http://www.youtube.com/user/officialpsy"
परीक्षण स्क्रिप्ट अपने आप में पर्याप्त नाजुक है: अनुक्रमण परिणाम बदल सकते हैं और हमें कोड बदलना होगा

बेस टेस्ट क्लास बनाएं

 public class WebDriverTestsBase<T> : TestsBase where T:Page, new() { /// <summary> /// Page object instance /// </summary> protected T Page { get; set; } /// <summary> /// Relative Url to target Page Object /// </summary> protected abstract string Url { get; } [SetUp] public virtual void SetUp() { WebDriverContext = WebDriverContext.GetInstance(); Page = Framework.Page.Create<T>( WebDriverContext.WebDriver, EnvironmentsConfiguration.CurrentEnvironmentBaseUrl, Url, PageElements); } [TearDown] public virtual void TearDown() { if (WebDriverContext.HasInstance) { var instance = WebDriverContext.GetInstance(); instance.Dispose(); } } }

फिर से परीक्षा को पुन: लिखें

 public class GoogleExampleTest : WebDriverTestsBase<GooglePage> { [Test] public void Google_SearchGangnamStyle_PsyYouTubeChanelIsOnTop() { Page.EnterSearchQuery("gangnam style"); Page.Search(); var expected = new KeyValuePair<string, string>( "PSY - YouTube", "http://www.youtube.com/user/officialpsy"); var actual = Page.GetElement<GoogleSearchResults>().FirstResult; Assert.AreEqual(expected, actual); } }

पहले से ही लगभग सही। TestCase विशेषता में जादू की लाइनें डालें और Assert में एक टिप्पणी जोड़ें

 [TestCase("gangnam style", "PSY - YouTube", "http://www.youtube.com/user/officialpsy")] public void Google_SearchGoogle_FirstResult(string query, string firstTitle, string firstLink) { Page.EnterSearchQuery(query); Page.Search(); var expected = new KeyValuePair<string, string>(firstTitle, firstLink); var actual = Page.ResultsBlock.FirstResult; Assert.AreEqual(expected, actual, string.Format( "{1} ({2}) is not top result for query \"{0}\"", firstTitle, firstLink, query)); }

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

डीएसएल

इस कोड में समस्याएं हैं:

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

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

 Feature: Google Search As a user I want to search in google So that I can find relevent information Scenario Outline: Search Given I have opened Google main page And I have entered <searchQuery> When I press search button Then the result is <title>, <url> Examples: |searchQuery |title |url |gangnam style |PSY - YouTube |http://www.youtube.com/user/officialpsy [Binding] public class GoogleSearchSteps : WebDriverTestsBase<GooglePage> { [Given("I have opened Google main page")] public void OpenGooglePage() { // Page is already created on SetUp, so that's ok } [Given(@"I have entered (.*)")] public void EnterQuery(string searchQuery) { Page.EnterSearchQuery(searchQuery); } [When("I press search button")] public void PressSearchButton() { Page.Search(); } [Then("the result is (.*), (.*)")] public void CheckResults(string title, string href) { var expected = new KeyValuePair<string, string>(title, href); var actual = Page.GetElement<GoogleSearchResults>().FirstResult; Assert.AreEqual(expected, actual); } }

इस तरह से:

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

आप इस लेख में जब दिए गए तब के साथ SpecFlow और आवश्यकताओं के प्रबंधन के बारे में अधिक पढ़ सकते हैं।

दिशानिर्देश स्वचालन

नाजुक और जटिल लोकेटर से बचें
सही नहीं है:
```
 [FindsBy(How = How.XPath, Using = "((//div[@class='dragContainer']/div[@class='dragHeader']" + "/div[@class='dragContainerTitle'])[text()=\"Account Info\"])" + "/../div[@class='dragContainerSettings']")] public IWebElement SettingsButton { get; set; } 
```
सही:
```
 [FindsBy(How = How.Id, Using = "gbqfb")] public IWebElement SubmitButton { get; set; } 
```
आईडी का उपयोग करने के लिए सबसे अच्छा। जावा-स्क्रिप्ट आईडी पर निर्भर हो सकती है और फ्रंट-एंड डेवलपर्स इसे कम संभावना के साथ बदल देंगे। यदि आप आईडी (डायनेमिक मार्कअप) का उपयोग नहीं कर सकते हैं, तो डेटा-सहायता (ऑटोमेशन-आईडी), या इसी तरह की विशेषता का उपयोग करें
पेज क्लास में अपने एप्लिकेशन लॉजिक को इनकैप्सुलेट करें, जैसे कि लॉगऑनपेज, रेजिस्ट्रेशनपेज, होमपेज, ऑर्डरपेज, आदि।
"विगेट्स" (पेज एलिमेंट्स) में विजेट्स और रिपीटिंग ब्लॉक का चयन करें, उदाहरण के लिए: हेडर, फुटर, लॉगऑनॉगऑफ
उनके प्रदर्शन के आधार पर विजेट में समूह तत्व, उदाहरण के लिए: पुष्टिकरणPopup, EditPopup, AddPopup
परीक्षण कोड में जादू की रेखाओं से बचें, उन्हें पेज और विजेट के गुणों में या सहायकों में रखें, उदाहरण के लिए ऑर्डरसुअस मेसेजेज, रेजिस्ट्रेशनसुअसमैसेज, इनवैलिडपासवर्डमेज़ेज। यह तत्वों के लोडिंग / उपस्थिति के लिए अनावश्यक कोड से बचना होगा
आधार परीक्षण कक्षाओं के लिए दोहराए जाने वाले संचालन को बाहर निकालें, सेटअप, टियरडाउन का उपयोग करें: ड्राइवर बनाएं और नष्ट करें, त्रुटियों, प्रमाणीकरण के साथ स्क्रीनशॉट बनाएं, परीक्षण की पठनीयता में सुधार करें
पेज असेंबली को एक अलग असेंबली में निकालें, इससे विजेट / पेज के डुप्लिकेट से बचने में मदद मिलेगी परीक्षणों के साथ कई विधानसभाएं हो सकती हैं
केवल परीक्षण कोड में Assert का उपयोग करें; पृष्ठ और विजेट्स में Asserts शामिल नहीं होने चाहिए
उन असेरेज़ का उपयोग करें, जो आपके द्वारा परीक्षण किए जा रहे हैं का सर्वोत्तम वर्णन करते हैं। इससे परीक्षण की पठनीयता में सुधार होगा।
सही नहीं है:
```
 var actual = Page.Text == “Success” Assert.IsTrue(actual); 
```
सही:
```
 Assert.AreEqual(MessageHelper.Success, Page.Text) 
```

त्रुटि संदेश का उपयोग करें

 Assert.AreEqual(MessageHelper.Success, Page.Text, “Registration process is not successfull”);

आइटम लोड करने के टाइमआउट के रूप में Thread.Sleep का उपयोग करने से बचें। उदाहरण के लिए, आवश्यक DOM तत्वों को लोड करने की गारंटी देने वाले उच्च-स्तरीय अमूर्तनों का उपयोग करें:
```
 Page.GetElement<GoogleSearchResults>(); var firstLink = PageHelper.WaitFor<GoogleSearchResults>(w => w.FirstLink); 
```
यदि आप डीएसएल का उपयोग नहीं करते हैं, तो प्रारूप में परीक्षणों का नाम लिखें [Page_] Script_Expected Behaviour । इससे लोगों को यह समझने में मदद मिलेगी कि किस तरह के व्यवहार का परीक्षण किया जा रहा है। आवश्यकताओं को बदलते समय यह विशेष रूप से महत्वपूर्ण हो सकता है।
डीएसएल में, समूह सीमांत रूप से और इस तरह से कदमों का पुन: उपयोग अधिकतम करने के लिए करता है
सही नहीं है:
```
 I have logged as a user with empty cart 
```
सही:
```
 I have logged in And my cart is empty 
```
DSL में, एक चरण में ट्यूपल्स की तुलना करें, इससे आप अधिक संक्षिप्त कोड लिख पाएंगे और टेस्ट क्रैश होने पर अधिक जानकारी प्राप्त कर सकेंगे
सही नहीं है:
```
 When I open Profile page I can see first name is “Patrick” And I can see last name is “Jane” And I can see phone is “+123 45-67-89” 
```
सही ढंग से
```
 When I open Profile page I can see profile info: Patrick Jane +123 45-67-89 
```
ब्लैक-बॉक्स परीक्षण का उपयोग करें, परीक्षण कोड से परीक्षण डेटा के आरंभीकरण को बाहर निकालें। इसके लिए उपयुक्त है, उदाहरण के लिए, एक एसएसडीटी परियोजना
नियमित रूप से परीक्षण चलाने के लिए CI का उपयोग करें, अपने परीक्षा परिणामों को सार्वजनिक और स्पष्ट करें

परीक्षण स्वचालन पर ईबे से एक बहुत अच्छी रिपोर्ट यहाँ मिल सकती है: www.youtube.com/watch?v=tJ0O8p5PajQ

वेब एप्लिकेशन टेस्ट स्वचालन