पेज ऑब्जेक्ट मॉडल + वेबड्राइवर। एक परीक्षण कार्यान्वयन उदाहरण

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

कोड उदाहरण C # + NUnit में होंगे।

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

यह इतना प्रभावी क्यों है?

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

संरचना

एक उदाहरण एक सरल परीक्षण है - एक फेसबुक लॉगिन (हम पृष्ठ के ऊपरी दाएं कोने में दिखाई देने वाले लॉगिन पर विचार करेंगे)।

इस परियोजना का एक उदाहरण कार्यान्वयन github.com/DmitryRoss/Page-Object-Model-Article पर डाउनलोड किया जा सकता है।

- पूरी परियोजना के प्रमुख में NUnit परीक्षण वाली कक्षाएं हैं। हमारे परीक्षण के लिए, हम इस तरह की एक कक्षा बनाएंगे और उसे लॉगिनटैस्ट कहेंगे। इसमें, AssertLogin () नामक एक परीक्षण विधि बनाएं।

[TestFixture] public class LoginTests : BaseTests { static LoginHelper loginHelper = new LoginHelper(); [Test] public static void AssertLogin(){...} } 

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

  loginHelper. DoLogin(userName, password). AssertUserName(displayedUserName); 

हमारे उदाहरण में, हम एक ऐसी कक्षा बनाएंगे और उसे लॉगिनहेलपर कहेंगे।
इसमें हम 2 तरीके बनाएंगे।
1. DoLogin (स्ट्रिंग उपयोगकर्ता नाम, स्ट्रिंग पासवर्ड)
2. AsserUserName (स्ट्रिंग उपयोगकर्ता नाम)

 public class LoginHelper :TestFramework { public LoginHelper DoLogin(string userName, string password){...} public LoginHelper AssertUserName(string userName){...} } 

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

 loginPage. TypeUserName(userName). TypePassword(password). ClickLoginButton(); 

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

 public class LoginPage : TestFramework { [FindsBy(How = How.XPath, Using = USER_NAME_TEXT_FIELD)] public IWebElement userNameTextField; [FindsBy(How = How.XPath, Using = PASSWORD_TEXT_FIELD)] public IWebElement passwordTextField; [FindsBy(How = How.XPath, Using = LOGIN_BUTTON)] public IWebElement loginButton; public static LoginPage GetLoginPage(){...} public LoginPage TypeUserName(string userName){...} public LoginPage TypePassword(string password){...} public LandingPage ClickLoginButton(){...} public const string USER_NAME_TEXT_FIELD = "//input[@id='email']"; public const string PASSWORD_TEXT_FIELD = "//input[@id='pass']"; public const string LOGIN_BUTTON = "//label[@id='loginbutton']/input"; } 

उपरोक्त उदाहरण में, GetLoginPage () विधि है। यह आरंभिक तत्वों के साथ इस पृष्ठ के वर्ग का एक उदाहरण देता है।

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

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

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

सेवा के बारे में थोड़ा और।

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

बिल्कुल सही संरचना।

अपने लिए, मैंने ऐसी परियोजना की आदर्श संरचना को घटा दिया, लेकिन, मैं स्वीकार करता हूं, मैं इसका पालन नहीं कर सकता, मैं केवल इसके लिए प्रयास कर सकता था।

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

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

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