लाभ:
- कृत्रिम बुद्धिमत्ता के साथ मजबूत यूआई परीक्षण कोड तैयार करने की क्षमता, जिसमें डेटा-टेस्टिड, ओपन वेट और एस्टर शामिल है जो वास्तविक उपयोगकर्ता परिणाम की पुष्टि करता है
- नाजुक परीक्षणों (खराब चयनकर्ता, अंधी प्रतीक्षा) से बचने और पेज ऑब्जेक्ट मॉडल संरचना में परीक्षणों को बनाए रखना आसान बनाने की क्षमता
- कोड को तोड़कर उत्पादित प्रत्येक यूआई परीक्षण का परीक्षण करने और नकली-पारित परीक्षणों का पता लगाने और उन्हें ठीक करने की क्षमता
उपयोगकर्ता द्वारा ब्राउज़र में किए गए प्रत्येक क्लिक, प्रत्येक फ़ॉर्म भरने, प्रत्येक पृष्ठ संक्रमण को बार-बार हाथ से परीक्षण नहीं किया जा सकता है - यही कारण है कि यूआई परीक्षण स्वचालन (उपयोगकर्ता इंटरफ़ेस; ये परीक्षण वास्तविक ब्राउज़र को प्रोग्रामेटिक रूप से चलाकर उपयोगकर्ता के व्यवहार की नकल करते हैं) मौजूद हैं। सेलेनियम, प्लेराइट और साइप्रस इस कार्य के लिए सबसे आम उपकरण हैं। आर्टिफिशियल इंटेलिजेंस (एआई) इन उपकरणों के लिए कोड लिखने में अत्यधिक कुशल है: आप एक परीक्षण मामले का वर्णन करते हैं, एआई आपको एक व्यावहारिक स्वचालन स्क्रिप्ट का मसौदा देता है। लेकिन यहां इस मॉड्यूल की केंद्रीय चेतावनी फिर से लागू होती है: एआई द्वारा उत्पादित यूआई परीक्षण कोड अक्सर नाजुक परीक्षण हो सकते हैं जो "हरे रंग की रोशनी करते हैं लेकिन गलत चीज़ को सत्यापित करते हैं" या हवा में फ़्लैप करते हैं। आपका काम इस कोड को चलाना नहीं है, बल्कि यह सुनिश्चित करना है कि यह वास्तव में सही चीज़ को मजबूती से सत्यापित करता है।
इस इकाई में, हमारा लक्ष्य एआई के साथ मजबूत, रखरखाव योग्य और सही मायने में मान्य यूआई परीक्षण तैयार करना है; आप नाजुक परीक्षाओं से बचना सीखेंगे।
ठोस यूआई परीक्षण के तीन स्तंभ
1. सही तत्व लोकेटर. एक परीक्षण पृष्ठ पर तत्व ढूंढने के लिए एक चयनकर्ता का उपयोग करता है। एआई अक्सर भंगुर चयनकर्ता उत्पन्न करता है: लंबे XPath पथ (पता पृष्ठ संरचना पर अत्यधिक निर्भर), सीएसएस वर्ग नामों पर आधारित चयनकर्ता (डिज़ाइन बदलने पर टूट जाते हैं)। मजबूत तरीका डेटा-टेस्टिड जैसी स्थिर विशेषताएँ हैं जिन्हें डेवलपर ने परीक्षण के लिए जोड़ा है। इसे एआई पर स्पष्ट रूप से थोपें।
2. स्पष्ट प्रतीक्षा. यूआई परीक्षण में भेद्यता का नंबर एक स्रोत समय है। निरंतर नींद(3) (अंध प्रतीक्षा) बुरा अभ्यास है: कभी-कभी यह पर्याप्त नहीं होता है, कभी-कभी यह समय बर्बाद करता है। सही तरीका स्पष्ट प्रतीक्षा का उपयोग करना है, जो कहता है "इस तत्व के प्रकट होने तक प्रतीक्षा करें"। नाटककार यह काम काफी हद तक स्वचालित रूप से करता है; सेलेनियम में आपको स्पष्ट रूप से इसका अनुरोध करना होगा।
3. सार्थक कथन। परीक्षण को उस परिणाम को सत्यापित करना चाहिए जो उपयोगकर्ता वास्तव में देखेगा - जैसे "ऑर्डर नंबर स्क्रीन पर दिखाई दिया," न कि केवल "पेज लोड किया गया।" यदि एआई द्वारा निर्मित परीक्षण में कोई दावा नहीं है या महत्वहीन है, तो वह परीक्षण एक छद्म-पास (पहली इकाई) उत्पन्न करता है।
सावधानी: जब आप पहली बार एआई-जनरेटेड यूआई परीक्षण देखते हैं, तो अधिकतम तीन चीजों की जांच करें: क्या चयनकर्ता प्रतिबद्ध हैं (डेटा-टेस्टिड), क्या प्रतीक्षा की जा रही है (कोई ब्लाइंड स्लीप नहीं), और क्या एस्टर वास्तविक उपयोगकर्ता परिणाम को सत्यापित करता है? यदि ये तीनों ठीक हैं, तो परीक्षण संभवतः ठोस है।
पेज ऑब्जेक्ट मॉडल
जैसे-जैसे परीक्षण बड़े होते जाते हैं, प्रत्येक परीक्षण के अंदर चयनकर्ता लिखना एक रखरखाव दुःस्वप्न बन जाता है। पृष्ठ ऑब्जेक्ट मॉडल (POM - डिज़ाइन पैटर्न जो प्रत्येक पृष्ठ/स्क्रीन के लिए चयनकर्ताओं और क्रियाओं को एक ही वर्ग में एकत्रित करता है) चयनकर्ता को एक स्थान पर रखता है; जब इंटरफ़ेस बदलता है, तो आप इसे एक फ़ाइल में अपडेट करते हैं। क्या AI सीधे के बजाय POM संरचना में परीक्षण तैयार करता है; इससे रखरखाव बिल्कुल आसान हो जाता है।
कमजोर संकेत/मजबूत संकेत
कमज़ोर: "लॉगिन पेज के लिए सेलेनियम परीक्षण लिखें।"
मजबूत: "प्लेराइट (टाइपस्क्रिप्ट) के साथ एक लॉगिन प्रवाह परीक्षण लिखें। चयनकर्ता केवल डेटा-टेस्टिड का उपयोग करते हैं; उपयोगकर्ता जो देखता है उसे नियंत्रित करने का उपयोग न करें, पृष्ठ शीर्षक का नहीं।"
शक्तिशाली संकेत; उपकरण भाषा, चयनकर्ता नीति, प्रतीक्षा रणनीति, वास्तुकला (पीओएम) और अभिव्यंजक मुखर अपेक्षा देता है।
परीक्षण डेटा और पर्यावरण स्वतंत्रता
एक ठोस यूआई परीक्षण न केवल सही ढंग से लिखा जाता है, बल्कि अपना स्वयं का परीक्षण डेटा भी बनाता और साफ करता है। एआई-जनरेटेड परीक्षण अक्सर किसी उपयोगकर्ता या रिकॉर्ड से लिंक होते हैं जो पहले से ही पर्यावरण में मौजूद माना जाता है ("व्यवस्थापक उपयोगकर्ता के रूप में लॉग इन करें")। यह धारणा तब टूटती है जब परीक्षण किसी अन्य वातावरण में या किसी अन्य परीक्षण के बाद चलता है (इकाई 9 में ऑर्डर निर्भरता समस्या)। सच्चाई यह है कि प्रत्येक परीक्षण परीक्षण की शुरुआत में आवश्यक डेटा बनाता है (या इसे एपीआई कॉल के साथ तैयार करता है) और अंत में इसे साफ़ करता है। एआई को स्पष्ट रूप से निर्देश दें कि "यह परीक्षण जिस भी डेटा पर निर्भर करता है उसे परीक्षण के भीतर सेट करें; बाहर से तैयार किए गए डेटा को न मानें।"
एक अन्य महत्वपूर्ण बिंदु वास्तविक उपयोगकर्ता डेटा के साथ यूआई परीक्षण नहीं करना है। यदि परीक्षण वातावरण में उत्पादन डेटाबेस प्रतिलिपि का उपयोग किया जाता है, तो ये रिकॉर्ड वास्तविक व्यक्तियों का डेटा हैं; स्क्रीनशॉट और परीक्षण रिकॉर्डिंग से यह डेटा सामने आ सकता है। सिंथेटिक (काल्पनिक) परीक्षण खातों का उपयोग करें; यह गोपनीयता की रक्षा करता है और परीक्षणों को पुन: प्रस्तुत करने योग्य बनाता है। वास्तविक ग्राहक खाते के साथ "ऑर्डर रद्दीकरण" परीक्षण आयोजित करना एक नैतिक और परिचालन संबंधी गलती है।
युक्ति: यूआई परीक्षण यथासंभव कम रखें; वास्तविक सत्यापन को एपीआई और यूनिट परीक्षणों पर छोड़ दें, जो तेज़ और स्थिर हैं। यूआई परीक्षण महंगा और भंगुर है - इसका उपयोग केवल वास्तव में एंड-टू-एंड उपयोगकर्ता प्रवाह (पिरामिड तर्क का परीक्षण) को मान्य करने के लिए करें।
वाहन तुलना
सुविधा
सेलेनियम
नाटककार
सरू
भाषाएँ
जावा, सी#, पायथन, जेएस
जेएस/टीएस, पायथन, .NET, जावा
जावास्क्रिप्ट/टाइपस्क्रिप्ट
ऑटो स्टैंडबाय
नहीं (हाथ से)
हाँ (मजबूत)
हाँ
मल्टी ब्राउज़र
विस्तृत
क्रोमियम/फ़ायरफ़ॉक्स/वेबकिट
क्रोमियम-प्रमुख
भंगुरता की प्रवृत्ति
उच्च (मैन्युअल स्टैंडबाय)
कम
कम
सीखने में आसानी
मध्यम
आसान
आसान
समानांतर संचालन
ग्रिड की आवश्यकता है
अंतर्निहित
निवासी/भुगतान किया हुआ
एआई से कोड का अनुरोध करते समय, स्पष्ट रूप से बताएं कि यह किस वाहन का है; अन्यथा, यह भ्रामक, गैर-कार्यशील कोड उत्पन्न कर सकता है।
चार प्रतिलिपि योग्य टेम्पलेट
1) ठोस यूआई परीक्षण पीढ़ी:
आपकी भूमिका: वरिष्ठ परीक्षण स्वचालन इंजीनियर। निम्नलिखित प्रवाह के लिए [टूल + भाषा] के साथ परीक्षण लिखें: [प्रवाह]। नियम: - चयनकर्ता केवल डेटा-टेस्टिड; XPath/CSS-क्लास का उपयोग करना। - कोई अंधी नींद नहीं; स्पष्ट/स्वचालित प्रतीक्षा का प्रयोग करें। - पेज ऑब्जेक्ट मॉडल लागू करें। - प्रत्येक दावे को वास्तविक उपयोगकर्ता परिणाम सत्यापित करने दें। प्रत्येक परीक्षण की शुरुआत में टिप्पणी करें कि आप किस स्वीकृति मानदंड को मान्य कर रहे हैं।
2) नाजुकता नियंत्रण:
भंगुरता के लिए निम्नलिखित यूआई परीक्षण की जांच करें: - क्या कोई अस्थिर चयनकर्ता (लंबा) है
3) पेज ऑब्जेक्ट में रूपांतरण:
निम्नलिखित सादे परीक्षण कोड को पेज ऑब्जेक्ट मॉडल संरचना में बदलें। चयनकर्ताओं और क्रियाओं को पृष्ठ कक्षाओं में ले जाएँ; परीक्षण फ़ाइल को केवल परिदृश्य प्रवाह पढ़ने दें। [उपकरण/भाषा].कोड: [कोड चिपकाएँ]
4) छद्म संक्रमण प्रमाण:
साबित करें कि यह यूआई परीक्षण वास्तव में मान्य है: मैं एप्लिकेशन कोड में कौन सा एकल परिवर्तन करूं जो इस परीक्षण को लाल कर देगा? यदि आपको कोई ऐसा परिवर्तन नहीं मिलता जो परीक्षण को विफल कर दे, तो परीक्षण अपर्याप्त है; लुप्त दावे जोड़ें। परीक्षण: [परीक्षण चिपकाएँ]
तीन मिनी मामले
केस 1 - नाजुक चयनकर्ता से मुक्ति। एक टीम द्वारा एआई के साथ किए गए 40 परीक्षणों में से 70% इंटरफ़ेस अपडेट के बाद विफल हो गए; उनमें से कोई भी वास्तविक बग नहीं था, वे सभी नाजुक XPath चयनकर्ता थे। टीम ने परीक्षणों को "नाज़ुकता जांच" टेम्पलेट के साथ डेटा-टेस्टिड बेस में बदल दिया। अगले तीन इंटरफ़ेस अपडेट में, गलत ब्रेक की संख्या शून्य हो गई; रखरखाव का समय प्रति सप्ताह 6 घंटे से घटकर 30 मिनट हो गया।
केस 2 - फर्जी-पासिंग यूआई परीक्षण। एआई ने "कार्ट में जोड़ें" परीक्षण तैयार किया; परीक्षण हरा था. जब "फर्जी-प्रूफ-ऑफ-पैसेज" टेम्प्लेट चलाया गया, तो परीक्षण में केवल बटन क्लिक और पेज शीर्षक की जांच की गई, कभी भी यह सत्यापित नहीं किया गया कि कार्ट काउंटर में वृद्धि हुई है या नहीं। भले ही कार्ट लॉजिक पूरी तरह से टूट गया हो, परीक्षण पास हो गया। सच्चा दावा जोड़ा गया (कार्ट बैज "1" है)।
केस 3 - अंध प्रतीक्षा जाल। एआई द्वारा निर्मित सेलेनियम परीक्षण में, प्रत्येक चरण के बाद नींद(2) थी; 60 परीक्षणों में 14 मिनट लगे और फिर भी कभी-कभी टूट गया। ओपन वेट (तत्व के क्लिक करने योग्य होने की प्रतीक्षा करें) पर स्विच करने के बाद समय 5 मिनट तक कम हो गया और भंगुरता गायब हो गई। अंधी प्रतीक्षा धीमी और अविश्वसनीय दोनों थी।
सामान्य गलतियाँ
- नाजुक चयनकर्ताओं से सहमत होना. एआई द्वारा उत्पन्न लंबे XPaths का उपयोग करना; पहले इंटरफ़ेस परिवर्तन पर परीक्षण क्रैश हो जाते हैं।
- अंधी `नींद` छोड़कर. एक निश्चित प्रतीक्षा के साथ समय का "समाधान" करना; धीमा और अनिर्णायक दोनों।
- तुच्छ दावा. बस सत्यापित करें कि पृष्ठ लोड हो गया है; वास्तविक उपयोगकर्ता परिणाम (नकली-पास) की जाँच नहीं करना।
- पोम के बिना बढ़ें. प्रत्येक परीक्षण के लिए चयनकर्ताओं को वितरित करें; इंटरफ़ेस बदलने पर दर्जनों फ़ाइलों को मैन्युअल रूप से अपडेट करना।
- उपकरण निर्दिष्ट नहीं कर रहा. एआई को यह नहीं बताना कि आपको कौन सा टूल/भाषा चाहिए; कोड गड़बड़ हो रहा है, काम नहीं कर रहा है।
- जब आप जेनरेट कोड चलाते हैं और पास करते हैं तो भरोसा करते हैं। कोड तोड़कर परीक्षण नहीं।
सारांश
यूआई परीक्षण स्वचालन प्रोग्राम के साथ वास्तविक ब्राउज़र चलाकर उपयोगकर्ता के व्यवहार की पुष्टि करता है। एआई इस कोड को तुरंत उत्पन्न करता है, लेकिन दो बड़े नुकसान हैं: भंगुर परीक्षण (खराब चयनकर्ता, अंधा इंतजार) और नकली-पासिंग परीक्षण (अपूर्ण/तुच्छ दावा)। ठोस यूआई परीक्षण के तीन स्तंभ हैं प्रतिबद्ध चयनकर्ता (डेटा-टेस्टिड), स्पष्ट प्रतीक्षा, और जोर जो वास्तविक उपयोगकर्ता परिणाम को सत्यापित करता है। पेज ऑब्जेक्ट मॉडल में परीक्षण उत्पन्न होने से रखरखाव मौलिक रूप से सरल हो जाता है। प्रत्येक उत्पन्न परीक्षण का परीक्षण इस प्रश्न के साथ करें कि "कौन सा परिवर्तन इसे तोड़ देगा?"
आवेदन कार्य
अपने स्वयं के प्रोजेक्ट से उपयोगकर्ता प्रवाह का चयन करें (जैसे लॉगिन या खोज)। "मजबूत यूआई परीक्षण पीढ़ी" टेम्पलेट के साथ एआई लेखन परीक्षण करें। फिर: (1) चयनकर्ताओं को जांचें और ठीक करें और "नाजुकता जांच" के साथ प्रतीक्षा करें, (2) साबित करें कि प्रत्येक परीक्षण वास्तव में "छद्म-पास प्रमाण" के साथ मान्य है, (3) कोड को तोड़ें और देखें कि परीक्षण लाल हो गया है। किए गए और सुधारे गए परीक्षणों की संख्या और आपके द्वारा पाई गई कमजोरियों और छद्म-पास की संख्या की रिपोर्ट करें।
चेकलिस्ट
- [ ] मैंने एआई को उपकरण, भाषा, चयनकर्ता नीति और वास्तुकला (पीओएम) स्पष्ट रूप से दी।
- [ ] मैंने सत्यापित किया कि चयनकर्ता डेटा-टेस्टिड हैं।
- [ ] मैंने अंधी नींद के बजाय स्पष्ट/स्वचालित प्रतीक्षा का उपयोग करना सुनिश्चित किया।
- [ ] मैंने जाँच की कि प्रत्येक दावा वास्तविक उपयोगकर्ता परिणाम की पुष्टि करता है।
- [ ] मैंने कोड को तोड़कर प्रत्येक परीक्षण का परीक्षण किया; मैंने उसे लाल होते देखा.
- [ ] मैंने पेज ऑब्जेक्ट मॉडल संरचना में परीक्षण एकत्र किए।