اتوماسیون تست رابط کاربری: تولید کد سلنیوم، نمایشنامه نویس و سرو با هوش مصنوعی

سود:

• امکان تولید کد تست رابط کاربری قوی با هوش مصنوعی، از جمله داده تست، انتظار باز، و ادعایی که نتیجه واقعی کاربر را تایید می‌کند.
• امکان اجتناب از تست های شکننده (انتخاب کننده بد، انتظار کور) و آسان نگه داشتن تست ها در ساختار مدل شیء صفحه
• امکان تست هر تست UI تولید شده با شکستن کد و شناسایی و رفع تست های پاس جعلی

هر کلیک، پر کردن فرم، هر انتقال صفحه ای که کاربر در مرورگر انجام می دهد را نمی توان بارها و بارها با دست آزمایش کرد - به همین دلیل است که اتوماسیون تست UI (رابط کاربری؛ این تست ها رفتار کاربر را با هدایت برنامه ای یک مرورگر واقعی تقلید می کنند) وجود دارد. سلنیوم، نمایشنامه نویس و سرو رایج ترین ابزار برای این کار هستند. هوش مصنوعی (AI) در نوشتن کد این ابزارها مهارت بالایی دارد: شما یک مورد آزمایشی را توصیف می کنید، هوش مصنوعی پیش نویس یک اسکریپت اتوماسیون قابل اجرا را در اختیار شما قرار می دهد. اما در اینجا هشدار اصلی این ماژول دوباره به میان می آید: کد تست UI که هوش مصنوعی تولید می کند اغلب می تواند تست های شکننده ای باشد که "سبز روشن می شود اما چیز اشتباه را تأیید می کند" یا در باد می چرخد. وظیفه شما اجرای این کد نیست، بلکه این است که مطمئن شوید که واقعاً درست را تأیید می کند.

در این واحد، هدف ما تولید تست‌های رابط کاربری قوی، قابل نگهداری و معتبر با هوش مصنوعی است. شما یاد خواهید گرفت که از آزمایشات شکننده اجتناب کنید.

سه ستون تست UI جامد

1. مکان یاب عنصر را درست کنید. یک تست از یک انتخابگر برای یافتن عنصر موجود در صفحه استفاده می کند. هوش مصنوعی اغلب انتخابگرهای شکننده تولید می کند: مسیرهای طولانی XPath (آدرس بیش از حد به ساختار صفحه وابسته است)، انتخابگرهای مبتنی بر نام کلاس CSS (وقتی طراحی تغییر می کند خراب می شود). راه قوی، ویژگی های پایداری مانند data-testid است که توسعه دهنده برای آزمایش اضافه کرده است. صراحتاً این را به هوش مصنوعی تحمیل کنید.

2. انتظار صریح. منبع شماره یک آسیب پذیری در تست UI زمان بندی است. خواب مداوم (3) (انتظار کور) تمرین بدی است: گاهی کافی نیست، گاهی وقت را تلف می کند. راه صحیح استفاده از انتظار صریح است که می گوید "صبر کنید تا این عنصر ظاهر شود". نمایشنامه نویس این کار را تا حد زیادی به صورت خودکار انجام می دهد. در سلنیوم باید صریحاً آن را درخواست کنید.

3. ادعای معنادار. آزمایش باید نتیجه ای را که کاربر واقعاً می بیند تأیید کند - مانند "شماره سفارش روی صفحه ظاهر شد"، نه فقط "صفحه بارگذاری شده". اگر تست تولید شده توسط هوش مصنوعی ادعایی نداشته باشد یا بی اهمیت باشد، آن تست یک پاس شبه (واحد اول) ایجاد می کند.

احتیاط: هنگامی که برای اولین بار یک آزمایش UI تولید شده توسط هوش مصنوعی را مشاهده می کنید، حداکثر سه چیز را بررسی کنید: آیا انتخابگرها متعهد هستند (تست داده شده)، منتظر ماندن هستند (بدون خواب کور)، و آیا اظهار نظر نتیجه واقعی کاربر را تأیید می کند؟ اگر این سه مورد خوب باشند، احتمالاً تست محکم است.

مدل شی صفحه

با بزرگتر شدن تست ها، نوشتن انتخابگرها در داخل هر آزمون به یک کابوس تعمیر و نگهداری تبدیل می شود. مدل شی صفحه (POM - الگوی طراحی که انتخابگرها و اقدامات را برای هر صفحه/صفحه در یک کلاس جمع می کند) انتخابگر را در یک مکان نگه می دارد. وقتی رابط تغییر می کند، آن را در یک فایل به روز می کنید. از هوش مصنوعی بخواهید که آزمایش ها را در یک ساختار POM به جای مستقیم تولید کند. این امر تعمیر و نگهداری را بسیار آسان تر می کند.

اعلان ضعیف / اعلان قوی

ضعیف: "یک تست سلنیوم برای صفحه ورود بنویسید."

قوی: "یک تست جریان ورود به سیستم با Playwright (TypeScript) بنویسید. انتخابگرها فقط از data-testid استفاده می کنند؛ از کنترل آنچه کاربر می بیند استفاده نمی کنند، نه عنوان صفحه."

اعلان قدرتمند؛ این ابزار به زبان، خط مشی انتخابگر، استراتژی انتظار، معماری (POM) و انتظارات بیانی بیان می کند.

داده های تست و استقلال محیط

یک تست UI جامد نه تنها به درستی نوشته می‌شود، بلکه داده‌های آزمایشی خود را نیز می‌سازد و پاک می‌کند. آزمایش‌های ایجاد شده توسط هوش مصنوعی اغلب به کاربر یا رکوردی پیوند می‌خورند که فرض می‌شود از قبل در محیط وجود داشته است ("ورود به عنوان کاربر سرپرست"). این فرض زمانی که آزمون در محیط دیگری یا پس از آزمایش دیگری اجرا می شود (مسئله وابستگی سفارش در واحد 9) از بین می رود. حقیقت این است که هر تست در ابتدای تست داده های مورد نیاز خود را ایجاد می کند (یا با یک فراخوانی API آماده می کند) و در پایان آن را پاک می کند. صراحتاً به هوش مصنوعی دستور دهید که "هر داده ای را که این آزمایش به آن وابسته است در داخل آزمایش تنظیم کند؛ داده های آماده از خارج را فرض نکنید."

نکته مهم دیگر این است که آزمایش UI را با داده های واقعی کاربر انجام ندهید. اگر یک نسخه از پایگاه داده تولید در محیط آزمایش استفاده شود، این سوابق داده های افراد واقعی هستند. اسکرین شات ها و ضبط های آزمایشی ممکن است این داده ها را آشکار کنند. از حساب های آزمایشی مصنوعی (تخیلی) استفاده کنید. هم از محرمانگی محافظت می‌کند و هم آزمایش‌ها را قابل تکرار می‌کند. انجام تست "لغو سفارش" با حساب مشتری واقعی هم یک اشتباه اخلاقی و هم عملیاتی است.

نکته: تست های UI را تا حد امکان کم نگه دارید. تایید واقعی را به API و تست های واحد بسپارید که سریع و پایدار هستند. تست UI گران و شکننده است - فقط از آن برای اعتبارسنجی جریان کاربر انتها به انتها (منطق هرم تست) استفاده کنید.

مقایسه خودرو

ویژگی

سلنیوم

نمایشنامه نویس

سرو

زبان ها

جاوا، سی شارپ، پایتون، جی اس

JS/TS، پایتون، دات نت، جاوا

جاوا اسکریپت/تایپ اسکریپت

آماده به کار خودکار

خیر (با دست)

بله (قوی)

بله

چند مرورگر

گسترده

Chromium/Firefox/WebKit

کروم غالب است

تمایل به شکنندگی

بالا (آماده به کار دستی)

پایین

پایین

سهولت یادگیری

متوسط

آسان

آسان

عملیات موازی

شبکه مورد نیاز است

ساخته شده است

مقیم/پرداخت

هنگام درخواست کد از هوش مصنوعی، به وضوح مشخص کنید که متعلق به کدام وسیله نقلیه است. در غیر این صورت، ممکن است کد گیج کننده و غیر کاربردی تولید کند.

چهار قالب قابل کپی

1) تولید تست رابط کاربری جامد:

نقش شما: مهندس ارشد اتوماسیون تست. تست ها را با [ابزار + زبان] برای جریان زیر بنویسید: [flow]. قوانین: - Selectors data-testid only. با استفاده از XPath/CSS-class. - بدون خواب کور; از انتظار صریح/خودکار استفاده کنید. - مدل شیء صفحه را اعمال کنید. - اجازه دهید هر ادعای نتیجه واقعی کاربر را تأیید کند. در ابتدای هر آزمون نظر دهید که کدام معیارهای پذیرش را تأیید می کنید.

2) کنترل شکنندگی:

تست UI زیر را برای شکنندگی بررسی کنید: - آیا انتخابگر ناپایدار (طولانی

3) تبدیل به شی صفحه:

کد آزمایشی ساده زیر را به ساختار Page Object Model تبدیل کنید. انتخابگرها و اقدامات را به کلاس های صفحه منتقل کنید. اجازه دهید فایل آزمایشی فقط جریان سناریو را بخواند. [ابزار/زبان]. کد: [پیست کد]

4) اثبات انتقال شبه:

ثابت کنید که این تست UI واقعاً اعتبار می‌دهد: چه تغییری در کد برنامه ایجاد کنم که این تست را قرمز کند؟ اگر نتوانستید تغییری پیدا کنید که باعث شکست آزمون شود، آزمون ناکافی است. افزودن اظهارات گمشده. تست: [تست چسباندن]

سه کیف کوچک

مورد 1 - رهایی از انتخابگر شکننده. از 40 آزمایشی که یک تیم با هوش مصنوعی تولید کرد، 70٪ پس از به‌روزرسانی رابط شکسته شدند. هیچ یک از آنها باگ واقعی نبودند، همه آنها انتخابگرهای XPath شکننده بودند. تیم آزمایش‌ها را با الگوی «بررسی شکنندگی» به پایگاه داده‌های آزمایشی تبدیل کرد. در طول سه به روز رسانی رابط بعدی، تعداد شکست های نادرست به صفر کاهش یافت. زمان نگهداری از 6 ساعت به 30 دقیقه در هفته کاهش یافت.

مورد 2 - تست UI با موفقیت جعلی. هوش مصنوعی آزمایش «افزودن به سبد خرید» را تولید کرد. تست سبز بود هنگامی که الگوی "جعلی اثبات عبور" اجرا شد، آزمایش به نظر می‌رسد که فقط کلیک دکمه و عنوان صفحه را بررسی می‌کند و هرگز تأیید نمی‌کند که شمارنده سبد خرید افزایش یافته است یا خیر. حتی اگر منطق سبد خرید به طور کامل شکسته شده بود، آزمون قبول شد. ادعای واقعی اضافه شد (نشان سبد خرید "1" است).

مورد 3 - تله انتظار کور. در آزمایش سلنیوم تولید شده توسط هوش مصنوعی، خواب (2) بعد از هر مرحله وجود داشت. 60 تست 14 دقیقه طول کشید و باز هم گاهی اوقات شکست می خورد. پس از تغییر حالت باز کردن صبر کنید (صبر کنید تا عنصر قابل کلیک باشد) زمان به 5 دقیقه کاهش یافت و شکنندگی ناپدید شد. انتظار کور هم کند بود و هم غیرقابل اعتماد.

اشتباهات رایج

• موافقت با انتخابگرهای شکننده. استفاده از XPath های طولانی تولید شده توسط هوش مصنوعی همانطور که هست؛ تست ها در اولین تغییر رابط خراب می شوند.
• ترک «خواب» کور. "حل" زمان بندی با یک انتظار ثابت؛ هم کند و هم بی تصمیم
• ادعای بی اهمیت فقط بررسی کنید که صفحه بارگیری شده است. بررسی نکردن نتیجه واقعی کاربر (عبور جعلی).
• بدون POM رشد کنید. انتخابگرها را برای هر آزمون توزیع کنید. به‌روزرسانی دستی ده‌ها فایل هنگام تغییر رابط.
• عدم تعیین ابزار به هوش مصنوعی نگفتن چه ابزار/زبانی را می خواهید؛ کدهای نامرتب و غیر کارآمد می شود.
• وقتی کد تولید شده را اجرا می کنید و پاس می دهید، اعتماد کنید. تست نشدن با شکستن کد.

به طور خلاصه

اتوماسیون تست UI رفتار کاربر را با هدایت مرورگر واقعی با برنامه تأیید می کند. هوش مصنوعی این کد را به سرعت تولید می‌کند، اما دو مشکل بزرگ وجود دارد: تست‌های شکننده (انتخاب‌کننده بد، انتظار کور) و تست‌های قبولی جعلی (اظهار ناقص/بی‌اهمیت). سه ستون تست UI جامد عبارتند از: انتخابگر تعهد (تست داده)، انتظار صریح و ادعایی که نتیجه واقعی کاربر را تأیید می کند. وجود آزمایش‌های تولید شده در مدل شیء صفحه، تعمیر و نگهداری را بسیار ساده می‌کند. هر تست تولید شده را با این سوال امتحان کنید "چه تغییری این را شکسته است؟"

وظیفه کاربردی

یک جریان کاربری را از پروژه خود انتخاب کنید (به عنوان مثال ورود یا جستجو). تست‌های نوشتن هوش مصنوعی را با الگوی «نسل تست رابط کاربری قوی» انجام دهید. سپس: (1) انتخابگرها را بررسی و تعمیر کنید و با "بررسی شکنندگی" منتظر بمانید، (2) ثابت کنید که هر تست در واقع با "اثبات شبه پاس" تایید می شود، (3) کد را بشکنید و مشاهده کنید که تست قرمز می شود. تعداد تست های تولید شده و تصحیح شده و تعداد آسیب پذیری ها و شبه پاس هایی که پیدا کردید را گزارش دهید.

چک لیست

• [ ] من ابزار، زبان، خط مشی انتخابگر و معماری (POM) را به وضوح به هوش مصنوعی دادم.
• [ ] من تأیید کردم که انتخابگرها آزمایش داده شده هستند.
• [ ] مطمئن شدم که به جای خواب کور از انتظار صریح/خودکار استفاده کردم.
• [ ] من بررسی کردم که هر ادعا نتیجه واقعی کاربر را تأیید می کند.
• [ ] من هر تست را با شکستن کد آزمایش کردم. دیدم قرمز شد
• [ ] من تست ها را در ساختار Page Object Model جمع آوری کردم.