मेन्यू

सेलेनियम स्वचालन परियोजना के परीक्षण के अनुमान को प्रभावित करने वाले 7 कारक - सेलेनियम ट्यूटोरियल # 32

7 factors affecting test estimation selenium automation project selenium tutorial 32

समस्याओं को खत्म करने के लिए हमारे साधन का प्रयास करें

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

इस ट्यूटोरियल में, हम अलग-अलग चर्चा करेंगे सेलेनियम स्वचालन के प्रयास के आकलन को प्रभावित करने वाले कारक ।

विंडोज़ 10 वाईफाई डिफ़ॉल्ट गेटवे उपलब्ध नहीं है

योजना और अनुमान एक सॉफ्टवेयर विकास जीवनचक्र के दो सबसे महत्वपूर्ण पहलू हैं।

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

सेलेनियम स्वचालन

इससे पहले कि आप किसी भी परियोजना का आकलन करना शुरू कर दें, आपके प्रोजेक्ट के प्रत्येक चरण को समझना अनिवार्य है, जिससे आप एक सही और उचित अनुमान दे सकते हैं।

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

चलो शुरू करते हैं!!

मैं मान रहा हूं कि हम स्क्रैच से ऑटोमेशन की पहल शुरू कर रहे हैं और हमारे पास कोई तैयार ढांचा उपलब्ध नहीं है।

आप क्या सीखेंगे:

सेलेनियम स्वचालन के आकलन को प्रभावित करने वाले कारक

'सेलेनियम' विशिष्ट परियोजना के आकलन के लिए आपको कौन से प्रभाव और जिन पर विचार करना चाहिए, वे नीचे दिए गए हैं:

# 1 परियोजना का दायरा

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

शामिल कदम हैं:

  1. विभिन्न कारकों की पहचान करें जो उम्मीदवार परीक्षण मामलों की पहचान करने का आधार बनेंगे।
  2. छोटे मॉड्यूल में एप्लिकेशन को तोड़ें
  3. उम्मीदवार परीक्षा मामलों की पहचान करने के लिए प्रत्येक मॉड्यूल का विश्लेषण करें
  4. ROI की गणना करें

सही परीक्षण मामले की पहचान करने के बारे में अधिक जानकारी के लिए, कृपया मेरा पिछला पेपर देखें: स्वचालन के लिए सही परीक्षण मामलों का चयन

# 2 आवेदन की जटिलता

यहाँ शामिल कदम हैं:

  1. स्वचालित रूप से परीक्षण किए जाने वाले परीक्षण मामलों की संख्या के आधार पर अनुप्रयोग का आकार निर्धारित करें।
  2. फाइबोनैचि श्रृंखला के माध्यम से आकार की जटिलता।
  3. प्रत्येक परीक्षण मामले के सत्यापन बिंदु और चौकी की पहचान करें

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

उदाहरण के लिए:

यदि आपके आवेदन में स्वचालित होने के लिए 300 - 500 परीक्षण मामले हैं, तो आप इसे छोटे आकार के अनुप्रयोग के रूप में मान सकते हैं। यदि परीक्षण के मामले 1500 से अधिक हैं, तो इसे जटिल के रूप में वर्गीकृत किया जा सकता है। यह कारक अलग-अलग एप्लिकेशन के लिए अलग-अलग हो सकता है। कुछ के लिए, स्वचालित करने के लिए 1500 परीक्षण मामलों को छोटा / मध्यम आकार का माना जा सकता है। तो एक बार जब आप परीक्षण के मामलों की सही संख्या की पहचान कर लेते हैं, तो इसे छोटे / मध्यम या बड़े पैमाने पर करें। प्रयास का आकलन करने की दिशा में आपकी रणनीति इन मानदंडों पर बहुत हद तक निर्भर करेगी।

आपको अपने परीक्षण मामले के लिए विभिन्न चौकियों और सत्यापन बिंदुओं पर भी विचार करना होगा। एक परीक्षण मामले में 1 से अधिक चौकी हो सकती हैं

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

# 3 सहायक उपकरणों / प्रौद्योगिकियों का उपयोग

यहाँ शामिल कदम हैं:

  1. फ्रेमवर्क और स्वचालन आवश्यकताओं की पहचान करें
  2. जरूरतों के आधार पर, उपयोग किए जाने वाले उपकरणों का विश्लेषण और पहचान करें।
  3. उपकरण का उपयोग करने की निर्भरता / निहितार्थ को पहचानें।

अकेले सेलेनियम एक ढांचा बनाने या स्वचालन को पूरा करने के लिए पर्याप्त नहीं है। सेलेनियम (वेब ​​ड्राइवर) केवल टेस्ट केस को स्क्रिप्ट करेगा, लेकिन साथ ही अन्य कार्य भी हैं, जैसे कि परिणाम की रिपोर्ट करना, लॉग्स को ट्रैक करना, स्क्रीनशॉट लेना आदि।

इन्हें प्राप्त करने के लिए आपको अलग-अलग टूल की आवश्यकता होती है जो आपके ढांचे के साथ एकीकृत होंगे इसलिए इन सहायक संस्थाओं की पहचान करना यहां महत्वपूर्ण है जो आपकी आवश्यकता के अनुरूप होगा और सकारात्मक आरओआई प्राप्त करने में मदद करेगा

# 4 फ्रेमवर्क लागू करना

यहाँ मुश्किल हिस्सा जे कदम शामिल हैं आता है !!

  1. इनपुट को पहचानें (पैटर्न जिसमें डेटा स्क्रिप्ट में फीड किया गया है) और आपके ऑटोमेशन सूट का आउटपुट (रिपोर्ट / परीक्षण परिणाम)।
  2. अपनी इनपुट फ़ाइलों को डिज़ाइन करें। यह एक साधारण पाठ फ़ाइल से लेकर जटिल एक्सेल फ़ाइल तक हो सकती है। यह मूल रूप से फाइल है जिसमें आपका परीक्षण डेटा होगा।
  3. अपने इनपुट मापदंडों के आधार पर फ़ोल्डर संरचना डिज़ाइन करें और
  4. रिपोर्टिंग सुविधा लागू करें (या तो किसी एक्सेल फ़ाइल में या ReportNG जैसे किसी उपकरण का उपयोग करके)
  5. अपने ढाँचे में लकड़हारा निर्धारित / लागू करें
  6. अपने ढांचे में बिल्ड टूल को लागू करें
  7. यूनिट टेस्ट फ्रेमवर्क लागू करें (Junit या TestNG)

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

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

हमें यहां यह याद रखना होगा कि सेलेनियम में 'रेडी-मेड' कुछ भी नहीं है। सब कुछ के लिए, हमें कोड करना होगा, इसलिए त्रुटियों के निवारण और समस्या निवारण के लिए अनुमान में प्रावधान होने चाहिए।

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

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

# 5 सीखना और प्रशिक्षण

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

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

जावा सीखने के साथ-साथ, अन्य तकनीकों जैसे ANT / Maven (भवन निर्माण के लिए), TestNG / jUnit (यूनिट टेस्ट फ्रेमवर्क), Log4J (लॉगिंग के लिए), रिपोर्टिंग (रिपोर्टिंग के लिए) आदि की सूची के आधार पर विकसित हो सकते हैं। ढांचे का स्तर। यह सूची जितनी अधिक बढ़ती जाएगी, उतना ही अधिक समय लगेगा।

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

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

# 6 पर्यावरण सेटअप

पर्यावरण के साथ सौदों की स्थापना (तक सीमित नहीं): -

  • परीक्षण वातावरण में कोड सेट करना
  • उत्पादन वातावरण में कोड सेट करना
  • स्वचालित परीक्षणों को ट्रिगर करने के लिए स्क्रिप्ट लिखना।
  • रिपोर्टिंग के लिए तर्क विकसित करना
  • स्क्रिप्ट चलाने की आवृत्ति की स्थापना और इसके कार्यान्वयन के लिए तर्क विकसित करना
  • परीक्षण डेटा और परीक्षण मामलों में प्रवेश करने के लिए पाठ / एक्सेल फाइल बनाना
  • वातावरण और साख पर नज़र रखने के लिए संपत्ति फ़ाइलें बनाना

# 7 कोडिंग / स्क्रिप्टिंग और समीक्षा

इससे पहले कि आप वास्तव में अपने परीक्षण लिखना शुरू करें, 2 शर्तें हैं:

  1. अभ्यर्थी के परीक्षण के मामले आसान हों
  2. ढांचा तैयार है

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

समीक्षा के लिए भी प्रावधान होना चाहिए। समीक्षा बस कोड की समीक्षा है जो एक सहकर्मी या एक डेवलपर द्वारा किया जा सकता है। जोड़ी प्रोग्रामिंग सबसे अच्छा विकल्प है जो त्वरित है, लेकिन यदि यह संभव नहीं है, तो उपलब्ध संसाधनों या संगठनों की समीक्षा की रणनीति के आधार पर, इसके लिए घंटे आवंटित किए जाने चाहिए।

आकलन को प्रभावित करने वाले प्रत्येक कारक के बारे में अधिक जानकारी:

कारक # 1: स्कोप

जिसका अर्थ है : ROI के माध्यम से स्वचालन के लिए उम्मीदवार परीक्षण मामलों की पहचान करना

शामिल कदम:

  1. विभिन्न कारकों की पहचान करें जो उम्मीदवार परीक्षण मामलों की पहचान करने का आधार बनेंगे।
  2. छोटे मॉड्यूल में एप्लिकेशन को तोड़ें
  3. उम्मीदवार परीक्षा मामलों की पहचान करने के लिए प्रत्येक मॉड्यूल का विश्लेषण करें
  4. आरओआई की गणना करें

वितरित: स्वचालित करने के लिए आवश्यक परीक्षण मामलों की सूची।

टिप्पणियों: आकलन के अन्य चरणों के साथ आगे बढ़ने से पहले अपने दायरे को फ्रीज करना महत्वपूर्ण है।

कारक # 2: जटिलता

अर्थ: सीधे और छोटे आकार के आवेदन की परिभाषा स्थापित करें।

शामिल कदम:

  1. स्वचालित रूप से परीक्षण किए जाने वाले परीक्षण मामलों की संख्या के आधार पर एप्लिकेशन को आकार दें।
  2. फाइबोनैचि श्रृंखला के माध्यम से आकार की जटिलता।
  3. प्रत्येक परीक्षण मामले के सत्यापन बिंदु और चौकी की पहचान करें।

वितरित: आवेदन का आकार - छोटा, मध्यम या बड़ा।

परीक्षण मामलों की एक संख्या और उनके संबंधित चेकपॉइंट और सत्यापन बिंदु।

टिप्पणियों : अनुशंसित - एक परीक्षण मामले में कई जांच बिंदु हो सकते हैं लेकिन केवल 1 सत्यापन बिंदु। यदि किसी परीक्षण मामले में 1 से अधिक सत्यापन बिंदु हैं, तो इसे एक अलग परीक्षण मामले में विभाजित किया जाना चाहिए।

कारक # 3: सहायक उपकरण

अर्थ: सेलेनियम स्वयं एक मजबूत ढांचा बनाने के लिए पर्याप्त नहीं है। इसके लिए फ्रेमवर्क बनाने के लिए फ्रेमवर्क टूल की सूची की आवश्यकता होती है।

शामिल कदम:

  1. अंतिम रूप से आई.डी.ई.
  2. अंतिम इकाई परीक्षण उपकरण
  3. अंतिम रूप से लकड़हारा
  4. अंतिम रूप देने वाला रिपोर्टिंग टूल
  5. अंतिम रूप से निर्मित उपकरण

वितरित: फ्रेमवर्क बनाने के लिए आवश्यक उपकरणों की सूची।

टिप्पणियों:

उदाहरण:

  • ग्रहण / राड - आईडीई के रूप में
  • चींटी / मावेन - निर्माण उपकरण के रूप में
  • jUnit / TestNG - इकाई परीक्षण ढांचे के रूप में
  • Log4j - लकड़हारा के रूप में
  • ReportiNG - रिपोर्टिंग टूल के रूप में
  • पाठ फ़ाइलें - वातावरण / साख पर नज़र रखने के लिए
  • एक्सेल फाइलें - परीक्षण डेटा पर नज़र रखने के लिए
  • पर्ल / पायथन - एक वातावरण स्थापित करने और परीक्षण स्क्रिप्ट को ट्रिगर करने के लिए।

फैक्टर # 4: फ्रेमवर्क को लागू करना

अर्थ: संरचना का निर्माण

शामिल कदम:

  1. अपनी इनपुट फ़ाइलों को डिज़ाइन करें।
  2. फ़ोल्डर संरचना डिज़ाइन करें
  3. अपने फ्रेम वर्क में लकड़हारा निर्धारित / लागू करें
  4. अपने ढांचे में बिल्ड टूल को लागू करें
  5. इकाई परीक्षण ढांचे को लागू करें

वितरित:

  • आईडीई में निर्मित फ्रेमवर्क और फोल्डर संरचना।
  • एक्सेल शीट जिसमें आपका इनपुट डेटा है
  • पर्यावरण-संबंधी डेटा और क्रेडेंशियल्स वाली संपत्ति फ़ाइलें।

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

कारक # 5: पर्यावरण की स्थापना

अर्थ: कोड परिनियोजन और कोड तैनाती के लिए डाउनलोडिंग / तैयारी के साथ सौदा

शामिल कदम:

  1. इनपुट फ़ाइल और रिपोर्टिंग तैयार करें
  2. ट्रिगरिंग स्क्रिप्ट बनाएं

वितरित: पर्यावरण तैयार

टिप्पणियों: हमें अपने ढांचे को इस तरह से बनाने की कोशिश करनी चाहिए कि कम से कम परेशानी के साथ, हमारे कोड को उक्त वातावरण / बॉक्स में तैनात किया जाए।

मुझे गलत नहीं होना चाहिए अगर मैं कहता हूं कि हमारी पाठ फ़ाइलों (जिसमें URL और क्रेडेंशियल्स हैं) में न्यूनतम प्रविष्टियों के साथ हमारा कोड चलाने और रॉक करने के लिए तैयार होना चाहिए!

कारक # 6: सीखना और प्रशिक्षण

अर्थ: एक प्रोग्रामिंग भाषा और अन्य सहायक तकनीकों को सीखना

शामिल कदम: अपनी स्वचालन आवश्यकताओं के अनुसार एक योजना तैयार करें और इसे टीम के साथ साझा करें और उन्हें सीखने और पाठ्यक्रम के अनुसार आगे बढ़ने के लिए प्रोत्साहित करें।

वितरित: प्रशिक्षण योजना और उसका ट्रैकर जो टीम की प्रगति को ट्रैक करेगा।

टिप्पणियों: सिंटैक्स सीखने के बजाय लॉजिक्स बनाने पर जोर दिया जाना चाहिए।

कारक # 7: कोडिंग / स्क्रिप्टिंग और समीक्षा

अर्थ: वास्तविक परीक्षण स्क्रिप्ट लिखना और उनकी समीक्षा करना

शामिल कदम:

  1. परीक्षण के मामले और रूपरेखा तैयार है।
  2. परीक्षण मामलों को ले जाएं / विभाजित करें और इसे स्वचालित स्क्रिप्ट में परिवर्तित करें और अपनी प्रगति को ट्रैक करें

वितरित: स्वचालित परीक्षण स्क्रिप्ट

टिप्पणी: पूरी टीम को लागू ढांचे का उपयोग करके परीक्षण स्क्रिप्ट लिखने में भाग लेना चाहिए। इसलिए आकलन करते समय, पूरी टीम के प्रयासों को ध्यान में रखा जाना चाहिए।

निष्कर्ष :

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

ऊपर वर्णित कारक मेरे अनुभव के आधार पर हैं, लेकिन अन्य संस्थाएं भी हो सकती हैं जो रणनीति को प्रभावित कर सकती हैं।

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

अगला ट्यूटोरियल # 33 : हम अपना समापन करेंगे सबसे व्यापक सेलेनियम ऑनलाइन प्रशिक्षण मुक्त ट्यूटोरियल श्रृंखला अंतिम ट्यूटोरियल के साथ अर्थात् सेलेनियम परीक्षण साक्षात्कार सवालों के जवाब के साथ ”।

यदि आप सेलेनियम परियोजनाओं के प्रयास के आकलन के लिए कोई अन्य सुझाव हैं, तो हमें बताएं।

अनुशंसित पाठ

^