परतदार परीक्षणों के चार घुड़सवार

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

1. अंतर्निहित प्रतीक्षा विधियों से बचें

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

 textField.fill('Some text') waitForTime(5000) confirmationButton.click()

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

 button.click() waitFor(textField.isVisible()) textField.fill()

निःसंदेह, ऐसे मामले भी होते हैं जहां आपको किसी ऐसी चीज के लिए इंतजार करना पड़ता है जिसे आप स्मार्ट तरीके से जांच नहीं सकते। मैं ऐसी जगहों पर टिप्पणियाँ जोड़ने या यहां तक कि आपके प्रतीक्षा तरीकों में एक पैरामीटर के रूप में कारण स्पष्टीकरण जोड़ने या ऐसा कुछ करने का सुझाव देता हूं:

 waitForTime(5000, {reason: "For unstable server processed something..."}

इसका उपयोग करने का एक अतिरिक्त लाभ परीक्षण रिपोर्ट है जहां आप ऐसे स्पष्टीकरणों को संग्रहीत कर सकते हैं ताकि यह किसी और के लिए या भविष्य में आपके लिए भी स्पष्ट हो जाए कि यहां पांच सेकंड का इंतजार क्या और क्यों है।

 waitForTime(5000, {reason: "For unstable server processed something..."} button.click() waitFor(textField.isVisible()) textField.fill()

2. तत्वों का चयन करने के लिए मजबूत और विश्वसनीय लोकेटर का उपयोग करें

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

 //*[@id="editor_7"]/section/div[2]/div/h3[2]

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

3. परीक्षणों को एक दूसरे से स्वतंत्र बनाएं

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

उदाहरण के लिए, Playwright में, आप इसे प्राप्त करने के लिए beforeAll(), beforeEach(), AfterAll(), और AfterEach() एनोटेशन का उपयोग कर सकते हैं।

कुछ परीक्षणों के साथ अगले परीक्षण सूट की जाँच करें। पहला है उपयोगकर्ता की उपस्थिति सेटिंग्स को बदलना, और दूसरा है डिफ़ॉल्ट उपस्थिति की जाँच करना।

 test.describe('Test suite', () => { test('TC101 - update appearance settings to dark', async ({page}) => { await user.goTo(views.settings); await user.setAppearance(scheme.dark); }); test('TC102 - check if default appearance is light', async ({page}) => { await user.goTo(views.settings); await user.checkAppearance(scheme.light); }); });

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

ऐसी समस्या को हल करने के लिए, मैंने प्रत्येक परीक्षण के बाद निष्पादित AfterEach() हुक जोड़ा है। इस स्थिति में, यह डिफ़ॉल्ट दृश्य पर नेविगेट करेगा और उपयोगकर्ता की उपस्थिति को स्थानीय संग्रहण से हटाकर साफ़ कर देगा।

 test.afterEach(async ({ page }) => { await user.localStorage(appearanceSettings).clear() await user.goTo(views.home) }); test.describe('Test suite', () => { test('TC101 - update appearance settings to dark', async ({page}) => { await user.goto(views.settings); await user.setAppearance(scheme.dark); }); test('TC102 - check if default appearance is light', async ({page}) => { await user.goTo(views.settings); await user.checkAppearance(scheme.light); }); });

इस दृष्टिकोण का उपयोग करते हुए, इस सुइट में प्रत्येक परीक्षण स्वतंत्र होगा।

4. स्वचालित पुनर्प्रयास का बुद्धिमानी से उपयोग करें

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

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

उदाहरण के लिए, दिखावा करें कि आपके पास एक परीक्षण मामला है जहां आपको 'फ़ाइल चयनकर्ता' ईवेंट का उपयोग करके कुछ फ़ाइलें अपलोड करनी होंगी। आपको <टाइमआउट 'फ़ाइलचूसर' इवेंट की प्रतीक्षा करते समय पार हो गया> त्रुटि मिलती है, जो इंगित करती है कि प्लेराइट परीक्षण 'फ़ाइलचूज़र' इवेंट के घटित होने की प्रतीक्षा कर रहा है, लेकिन इसमें अधिक समय लग रहा है।

 async function uploadFile(page: Page, file) { const fileChooserPromise = page.waitForEvent('filechooser'); await clickOnElement(page, uploadButton); const fileChooser = await fileChooserPromise; await fileChooser.setFiles(file); }

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

ऐसा करने के लिए, आप मानक प्रयास...कैच कथन का उपयोग कर सकते हैं।

 async function uploadFile(page: Page, file) { const maxRetries = 3; let retryCount = 0; while (retryCount < maxRetries) { try { const fileChooserPromise = page.waitForEvent('filechooser'); await clickOnElement(page, uploadButton); const fileChooser = await fileChooserPromise; await fileChooser.setFiles(file); break; // Success, exit the loop } catch (error) { console.error(`Attempt ${retryCount + 1} failed: ${error}`); retryCount++; } } }

इस तरह के दृष्टिकोण से अतिरिक्त समय की बचत होगी और आपका परीक्षण कम परतदार हो जाएगा।

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