فائدہ:
- مصنوعی ذہانت کے ساتھ مضبوط UI ٹیسٹ کوڈ تیار کرنے کی صلاحیت، بشمول ڈیٹا ٹیسٹڈ، کھلا انتظار، اور اس بات پر زور دینا کہ صارف کے حقیقی نتائج کی تصدیق ہوتی ہے۔
- نازک ٹیسٹوں (خراب سلیکٹر، اندھا انتظار) سے بچنے اور پیج آبجیکٹ ماڈل کے ڈھانچے میں ٹیسٹوں کو برقرار رکھنے کے لیے آسان بنانے کی صلاحیت
- کوڈ کو توڑ کر تیار کردہ ہر UI ٹیسٹ کو جانچنے اور جعلی پاس کیے گئے ٹیسٹوں کا پتہ لگانے اور ٹھیک کرنے کی اہلیت
ہر کلک، ہر فارم بھرنا، ہر صفحہ کی منتقلی جو صارف کسی براؤزر میں کرتا ہے اسے بار بار ہاتھ سے ٹیسٹ نہیں کیا جا سکتا — اسی لیے UI ٹیسٹ آٹومیشن (یوزر انٹرفیس؛ یہ ٹیسٹ پروگرام کے ذریعے حقیقی براؤزر چلا کر صارف کے رویے کی نقل کرتے ہیں) موجود ہے۔ سیلینیم، پلے رائٹ اور سائپرس اس کام کے لیے سب سے عام ٹول ہیں۔ مصنوعی ذہانت (AI) ان ٹولز کے لیے کوڈ لکھنے میں انتہائی ماہر ہے: آپ ٹیسٹ کیس کی وضاحت کرتے ہیں، AI آپ کو قابل عمل آٹومیشن اسکرپٹ کا مسودہ فراہم کرتا ہے۔ لیکن یہاں اس ماڈیول کی مرکزی انتباہ ایک بار پھر عمل میں آتی ہے: UI ٹیسٹ کوڈ جو AI تیار کرتا ہے اکثر نازک ٹیسٹ ہو سکتے ہیں جو "سبز روشنی لیکن غلط چیز کی تصدیق کرتے ہیں" یا ہوا میں پھڑپھڑاتے ہیں۔ آپ کا کام اس کوڈ کو چلانا نہیں ہے، بلکہ یہ یقینی بنانا ہے کہ یہ صحیح چیز کی مضبوطی سے تصدیق کرتا ہے۔
اس یونٹ میں، ہمارا مقصد AI کے ساتھ مضبوط، برقرار رکھنے کے قابل اور صحیح معنوں میں توثیق کرنے والے UI ٹیسٹ تیار کرنا ہے۔ آپ نازک ٹیسٹوں سے بچنا سیکھیں گے۔
ٹھوس UI ٹیسٹنگ کے تین ستون
1. درست عنصر لوکیٹر۔ ایک ٹیسٹ صفحہ پر عنصر کو تلاش کرنے کے لیے سلیکٹر کا استعمال کرتا ہے۔ AI اکثر ٹوٹنے والے سلیکٹرز تیار کرتا ہے: لمبے XPath راستے (پتہ حد سے زیادہ صفحہ کے ڈھانچے پر منحصر ہے)، CSS کلاس کے ناموں پر مبنی سلیکٹرز (ڈیزائن تبدیل ہونے پر ٹوٹ جاتا ہے)۔ مضبوط طریقہ ڈیٹا ٹیسٹڈ جیسی مستحکم صفات ہے جسے ڈویلپر نے جانچ کے لیے شامل کیا ہے۔ واضح طور پر اسے AI پر مسلط کریں۔
2. واضح انتظار۔ UI ٹیسٹنگ میں خطرے کا نمبر ایک ذریعہ وقت ہے۔ مستقل نیند (3) (اندھا انتظار) بری مشق ہے: بعض اوقات یہ کافی نہیں ہوتا ہے، بعض اوقات یہ وقت ضائع کرتا ہے۔ صحیح طریقہ یہ ہے کہ واضح انتظار کا استعمال کیا جائے، جو کہتا ہے کہ "اس عنصر کے ظاہر ہونے تک انتظار کریں"۔ ڈرامہ نگار یہ بڑی حد تک خود بخود کرتا ہے۔ سیلینیم میں آپ کو واضح طور پر اس کی درخواست کرنی ہوگی۔
3. معنی خیز دعویٰ۔ ٹیسٹ کو اس نتیجے کی تصدیق کرنی چاہیے جو صارف کو درحقیقت نظر آئے گا — جیسے "اسکرین پر آرڈر نمبر ظاہر ہوا،" نہ صرف "صفحہ لوڈ ہوا۔" اگر AI کے ذریعہ تیار کردہ ٹیسٹ میں کوئی دعویٰ نہیں ہے یا وہ غیر اہم ہے، تو وہ ٹیسٹ ایک چھدم پاس (پہلا یونٹ) پیدا کرتا ہے۔
احتیاط: جب آپ پہلی بار AI سے تیار کردہ UI ٹیسٹ دیکھیں، تو زیادہ سے زیادہ تین چیزوں کو چیک کریں: کیا سلیکٹرز پرعزم ہیں (ڈیٹا ٹیسٹڈ)، انتظار کر رہے ہیں (کوئی اندھی نیند نہیں)، اور کیا دعویٰ صارف کے حقیقی نتیجے کی تصدیق کرتا ہے؟ اگر یہ تینوں ٹھیک ہیں تو، ٹیسٹ شاید ٹھوس ہے۔
صفحہ آبجیکٹ ماڈل
جیسے جیسے ٹیسٹ بڑے ہوتے جاتے ہیں، ہر ٹیسٹ کے اندر سلیکٹرز لکھنا دیکھ بھال کا ڈراؤنا خواب بن جاتا ہے۔ صفحہ آبجیکٹ ماڈل (POM — ڈیزائن پیٹرن جو ہر صفحہ/اسکرین کے لیے سلیکٹرز اور ایکشنز کو ایک کلاس میں جمع کرتا ہے) سلیکٹر کو ایک جگہ پر رکھتا ہے۔ جب انٹرفیس تبدیل ہوتا ہے، تو آپ اسے ایک فائل میں اپ ڈیٹ کرتے ہیں۔ AI کو براہ راست کے بجائے POM ڈھانچے میں ٹیسٹ تیار کرنے کو کہیں۔ یہ دیکھ بھال کو یکسر آسان بنا دیتا ہے۔
کمزور فوری / مضبوط اشارہ
کمزور: "لاگ ان پیج کے لیے سیلینیم ٹیسٹ لکھیں۔"
مضبوط: "Playwright (TypeScript) کے ساتھ لاگ ان فلو ٹیسٹ لکھیں۔ سلیکٹرز صرف ڈیٹا ٹیسٹڈ استعمال کرتے ہیں؛ صارف جو کچھ دیکھتا ہے اسے کنٹرول کا استعمال نہ کریں، صفحہ کا عنوان نہیں۔"
طاقتور فوری؛ یہ ٹول زبان، سلیکٹر پالیسی، انتظار کی حکمت عملی، فن تعمیر (POM) اور اظہار خیال کی توقع فراہم کرتا ہے۔
ٹیسٹ ڈیٹا اور ماحول کی آزادی
ایک ٹھوس UI ٹیسٹ نہ صرف صحیح لکھا جاتا ہے، بلکہ اپنے ٹیسٹ ڈیٹا کو بھی بناتا اور صاف کرتا ہے۔ AI سے تیار کردہ ٹیسٹ اکثر ایسے صارف یا ریکارڈ سے منسلک ہوتے ہیں جو ماحول میں پہلے سے موجود سمجھا جاتا ہے ("ایڈمن صارف کے طور پر لاگ ان")۔ یہ مفروضہ ٹوٹ جاتا ہے جب ٹیسٹ کسی دوسرے ماحول میں چلتا ہے یا دوسرے ٹیسٹ کے بعد (یونٹ 9 میں آرڈر پر انحصار کا مسئلہ)۔ سچ یہ ہے کہ ہر ٹیسٹ ٹیسٹ کے آغاز میں مطلوبہ ڈیٹا بناتا ہے (یا اسے API کال کے ساتھ تیار کرتا ہے) اور آخر میں اسے صاف کرتا ہے۔ AI کو واضح طور پر ہدایت کریں کہ "کسی بھی ڈیٹا کو ترتیب دیں جس پر یہ ٹیسٹ ٹیسٹ کے اندر منحصر ہے؛ باہر سے تیار کردہ ڈیٹا کو فرض نہ کریں۔"
ایک اور اہم نکتہ یہ ہے کہ صارف کے حقیقی ڈیٹا کے ساتھ UI ٹیسٹنگ نہ کریں۔ اگر جانچ کے ماحول میں پروڈکشن ڈیٹا بیس کی کاپی استعمال کی جاتی ہے، تو یہ ریکارڈ حقیقی افراد کا ڈیٹا ہوتا ہے۔ اسکرین شاٹس اور ٹیسٹ ریکارڈنگ اس ڈیٹا کو ظاہر کر سکتے ہیں۔ مصنوعی (افسانہ) ٹیسٹ اکاؤنٹس کا استعمال کریں؛ یہ دونوں رازداری کی حفاظت کرتا ہے اور ٹیسٹوں کو دوبارہ پیدا کرنے کے قابل بناتا ہے۔ حقیقی کسٹمر اکاؤنٹ کے ساتھ "آرڈر کینسلیشن" ٹیسٹ کروانا ایک اخلاقی اور آپریشنل غلطی ہے۔
مشورہ: UI ٹیسٹ کم سے کم رکھیں۔ اصل تصدیق کو API اور یونٹ ٹیسٹوں پر چھوڑ دیں، جو تیز اور مستحکم ہیں۔ UI ٹیسٹنگ مہنگی اور ٹوٹ پھوٹ کا شکار ہے — اسے صرف صحیح معنوں میں صارف کے بہاؤ کی توثیق کرنے کے لیے استعمال کریں (ٹیسٹ پرامڈ منطق)۔
گاڑی کا موازنہ
خصوصیت
سیلینیم
ڈرامہ نگار
صنوبر
زبانیں
Java, C#, Python, JS
JS/TS، Python، .NET، Java
JavaScript/TypeScript
آٹو اسٹینڈ بائی
نہیں (ہاتھ سے)
ہاں (مضبوط)
جی ہاں
ملٹی براؤزر
چوڑا
Chromium/Firefox/WebKit
کرومیم غالب
ٹوٹ پھوٹ کا رجحان
ہائی (دستی اسٹینڈ بائی)
کم
کم
سیکھنے میں آسانی
درمیانہ
آسان
آسان
متوازی آپریشن
گرڈ کی ضرورت ہے۔
بلٹ میں
رہائشی / ادا شدہ
AI سے کوڈ کی درخواست کرتے وقت، واضح طور پر بتائیں کہ اس کا تعلق کس گاڑی سے ہے۔ بصورت دیگر، یہ مبہم، غیر کام کرنے والا کوڈ پیدا کر سکتا ہے۔
چار کاپی کرنے کے قابل ٹیمپلیٹس
1) ٹھوس UI ٹیسٹ جنریشن:
آپ کا کردار: سینئر ٹیسٹ آٹومیشن انجینئر۔ درج ذیل بہاؤ کے لیے [ٹول + لینگویج] کے ساتھ ٹیسٹ لکھیں: [بہاؤ]۔ قواعد: - صرف انتخاب کنندگان ڈیٹا ٹیسٹڈ؛ XPath/CSS کلاس کا استعمال۔ - کوئی اندھی نیند نہیں؛ واضح/خودکار انتظار کا استعمال کریں۔ - پیج آبجیکٹ ماڈل کا اطلاق کریں۔ - ہر ایک دعوی کو صارف کے حقیقی نتائج کی تصدیق کرنے دیں۔ ہر ٹیسٹ کے شروع میں تبصرہ کریں کہ آپ کس قبولیت کے معیار کی توثیق کر رہے ہیں۔
2) نزاکت کنٹرول:
ٹوٹ پھوٹ کے لیے درج ذیل UI ٹیسٹ کی جانچ کریں:- کیا کوئی غیر مستحکم سلیکٹر ہے (لمبا
3) صفحہ آبجیکٹ میں تبدیلی:
درج ذیل سادہ ٹیسٹ کوڈ کو پیج آبجیکٹ ماڈل ڈھانچے میں تبدیل کریں۔ سلیکٹرز اور اعمال کو صفحہ کی کلاسوں میں منتقل کریں؛ ٹیسٹ فائل کو صرف منظر نامے کے بہاؤ کو پڑھنے دیں۔ [ٹول/زبان]۔کوڈ: [کوڈ پیسٹ کریں]
4) چھدم منتقلی کا ثبوت:
ثابت کریں کہ یہ UI ٹیسٹ حقیقت میں توثیق کرتا ہے: میں ایپلیکیشن کوڈ میں کون سی واحد تبدیلی کروں جو اس ٹیسٹ کو RED کر دے؟ اگر آپ کوئی ایسی تبدیلی نہیں ڈھونڈ سکتے جو ٹیسٹ کو توڑ دے، تو ٹیسٹ ناکافی ہے۔ گمشدہ دعوے شامل کریں۔ ٹیسٹ: [ٹیسٹ پیسٹ کریں]
تین چھوٹے مقدمات
کیس 1 - نازک سلیکٹر سے آزادی۔ 40 ٹیسٹوں میں سے ایک ٹیم نے AI کے ساتھ تیار کیا، 70% انٹرفیس اپ ڈیٹ کے بعد ٹوٹ گئے۔ ان میں سے کوئی بھی اصل کیڑے نہیں تھے، وہ تمام نازک XPath سلیکٹرز تھے۔ ٹیم نے ٹیسٹوں کو "نزاکت چیک" ٹیمپلیٹ کے ساتھ ڈیٹا ٹیسٹڈ بیس میں تبدیل کیا۔ اگلے تین انٹرفیس اپڈیٹس میں، جھوٹے وقفوں کی تعداد صفر ہو گئی۔ دیکھ بھال کا وقت 6 گھنٹے سے گھٹ کر 30 منٹ فی ہفتہ رہ گیا۔
کیس 2 — جعلی پاس کرنے والا UI ٹیسٹ۔ AI نے "Add to cart" ٹیسٹ تیار کیا۔ ٹیسٹ سبز تھا. جب "جعلی پروف آف پاسیج" ٹیمپلیٹ چلایا گیا تو، ٹیسٹ صرف بٹن کے کلک اور صفحہ کے عنوان کو چیک کرنے کے لیے ظاہر ہوا، کبھی بھی اس بات کی تصدیق نہیں کی گئی کہ آیا کارٹ کاؤنٹر میں اضافہ ہوا ہے یا نہیں۔ یہاں تک کہ اگر ٹوکری کی منطق مکمل طور پر ٹوٹ گئی تھی، امتحان پاس ہوا. سچا دعوی شامل کیا گیا (کارٹ بیج "1" ہے)۔
کیس 3 - اندھا انتظار کا جال۔ AI کے ذریعہ تیار کردہ سیلینیم ٹیسٹ میں، ہر قدم کے بعد نیند (2) تھی۔ 60 ٹیسٹوں میں 14 منٹ لگے اور پھر بھی کبھی کبھار ٹوٹ گئے۔ کھلے انتظار میں سوئچ کرنے کے بعد (عنصر کے کلک کے قابل ہونے کا انتظار کریں) وقت 5 منٹ تک کم ہو گیا اور ٹوٹ پھوٹ ختم ہو گئی۔ اندھا انتظار سست اور ناقابل اعتبار تھا۔
عام غلطیاں
- نازک سلیکٹرز سے اتفاق۔ AI کے ذریعہ تیار کردہ طویل XPaths کا استعمال کرنا جیسا کہ ہے؛ پہلے انٹرفیس کی تبدیلی پر ٹیسٹ کریش ہو جاتے ہیں۔
- اندھے کو 'نیند' چھوڑنا۔ ایک مقررہ انتظار کے ساتھ وقت کو "حل کرنا"؛ سست اور غیر فیصلہ کن دونوں.
- معمولی دعویٰ۔ بس تصدیق کریں کہ صفحہ لوڈ ہو گیا ہے۔ صارف کے حقیقی نتائج (جعلی پاس) کی جانچ نہیں کرنا۔
- POM کے بغیر بڑھیں۔ ہر ٹیسٹ میں سلیکٹرز کو تقسیم کریں۔ انٹرفیس تبدیل ہونے پر درجنوں فائلوں کو دستی طور پر اپ ڈیٹ کرنا۔
- ٹول کی وضاحت نہیں کرنا۔ اے آئی کو یہ نہ بتانا کہ آپ کون سا ٹول/زبان چاہتے ہیں؛ گندا، غیر کام کرنے والا کوڈ۔
- جب آپ تیار کردہ کوڈ چلاتے ہیں اور پاس کرتے ہیں تو بھروسہ کرنا۔ کوڈ کو توڑ کر جانچ نہیں کرنا۔
خلاصہ میں
UI ٹیسٹنگ آٹومیشن پروگرام کے ساتھ اصل براؤزر چلا کر صارف کے رویے کی تصدیق کرتی ہے۔ AI اس کوڈ کو تیزی سے تیار کرتا ہے، لیکن اس میں دو بڑے نقصانات ہیں: ٹوٹنے والے ٹیسٹ (خراب سلیکٹر، اندھا انتظار) اور جعلی پاس کرنے والے ٹیسٹ (نامکمل/معمولی دعویٰ)۔ ٹھوس UI ٹیسٹنگ کے تین ستون کمٹ سلیکٹر (ڈیٹا ٹیسٹڈ) ہیں، واضح انتظار کریں، اور اس بات پر زور دیں کہ صارف کے حقیقی نتائج کی تصدیق کریں۔ پیج آبجیکٹ ماڈل میں ٹیسٹ تیار کرنا دیکھ بھال کو یکسر آسان بنا دیتا ہے۔ ہر تیار کردہ ٹیسٹ کو اس سوال کے ساتھ جانچیں کہ "کونسی تبدیلی اسے توڑ دے گی؟"
درخواست کا کام
اپنے پروجیکٹ سے صارف کا بہاؤ منتخب کریں (جیسے لاگ ان یا تلاش)۔ "مضبوط UI ٹیسٹ جنریشن" ٹیمپلیٹ کے ساتھ AI تحریری ٹیسٹ کروائیں۔ پھر: (1) سلیکٹرز کو چیک کریں اور ٹھیک کریں اور "نزاکت کی جانچ" کے ساتھ انتظار کریں، (2) ثابت کریں کہ ہر ٹیسٹ دراصل "سیڈو پاس پروف" کے ساتھ توثیق کرتا ہے، (3) کوڈ کو توڑیں اور دیکھیں کہ ٹیسٹ سرخ ہو جاتا ہے۔ تیار کردہ اور درست کیے گئے ٹیسٹوں کی تعداد، اور آپ کو پائے جانے والے خطرات اور سیوڈو پاسز کی تعداد کی اطلاع دیں۔
چیک لسٹ
- میں نے AI کو ٹول، زبان، سلیکٹر پالیسی اور فن تعمیر (POM) واضح طور پر دیا۔
- میں نے تصدیق کی کہ سلیکٹرز ڈیٹا ٹیسٹڈ ہیں۔
- میں نے اندھی نیند کے بجائے واضح/خودکار انتظار کا استعمال یقینی بنایا۔
- [ ] میں نے چیک کیا کہ ہر دعوی اصل صارف کے نتائج کی تصدیق کرتا ہے۔
- میں نے کوڈ کو توڑ کر ہر ٹیسٹ کا تجربہ کیا۔ میں نے اسے سرخ ہوتے دیکھا۔
- میں نے پیج آبجیکٹ ماڈل ڈھانچے میں ٹیسٹ جمع کیے ہیں۔