اگر امروز از هوش مصنوعی برای نوشتن تست‌کیس‌ها استفاده می‌کنید، احتمالاً خروجی‌هایی دریافت می‌کنید که برای هر تستر تازه‌کاری هم بدیهی است. خروجی یک پرامپت کلی مانند «تست‌کیس‌های یک صفحه لاگین را بنویس»، معمولاً روان اما بی‌فایده است؛ چرا که تنها سناریوهای واضحی مثل لاگین موفق، رمز عبور اشتباه و فیلدهای خالی را پوشش می‌دهد که هر تستر جونیوری می‌تواند در چند دقیقه آن‌ها را بنویسد. برای عبور از این بن‌بست، شرکت CloudQA در ۱۴ اکتبر ۲۰۲۶ چارچوبی ساختاریافته را معرفی کرد تا تست‌های تولیدشده توسط مدل‌ها را از فهرست‌های کلی به دارایی‌های آمادهٔ استقرار تبدیل کند.
بیشتر تست‌های تولیدشده توسط هوش مصنوعی به این دلیل شکست می‌خورند که از قوانین خاص محصول و تعاریف دقیق «شکست» بی‌بهره‌اند. همان‌طور که در تحلیل قبلی ما درباره‌ی گیت‌وی‌های سازگار مانند Consus و باز کردن دسترسی مدل‌ها در محیط‌های امنیتی اشاره کردیم، چالش فعلی از «دسترسی» به «کاربرد» تغییر یافته است. برای یک توسعه‌دهنده، یک مدل زبانی بزرگ (LLM) — مثل کتابخانه‌داری که میلیاردها صفحه را خوانده و حالا با همان لحن کتاب‌ها جواب می‌دهد — یک پیش‌خوان برای پیش‌نویس است، نه پیشگویی که منطق کسب‌وکار شما را می‌داند. یک LLM تنها با داده‌هایی که به آن می‌دهید کار می‌کند؛ بدون قوانین صریح درباره اینکه چه چیزی «شکست» محسوب می‌شود، مدل فقط حدس می‌زند.
چهار ستون یک پرامپت کاربردی
به نقل از راهنمای CloudQA، هر پرامپت با بازدهی بالا باید شامل چهار عنصر باشد:
- نقش (Role): تعیین شخصیتی مثل «مهندس ارشد QA» واژگان تخصصی و سخت‌گیری مورد انتظار را تعیین می‌کند. این یک اهرم کوچک است، اما به طور موثری سطح پاسخ را تغییر می‌دهد.
- بستر واقعی (Real Context): قرار دادن استوری‌های کاربر، مشخصات API، معیارهای پذیرش (Acceptance Criteria) یا قطعات کد، حیاتی‌ترین گام است. مدلی که نیازمندی‌های واقعی را می‌خواند، می‌تواند شکاف‌های واقعی را بیابد، در حالی که مدلی که فقط عبارت «یک فرم لاگین» را می‌خواند، تنها قادر به حدس زدن است.
- وظایف مشخص (Specific Tasks): استفاده از افعال مستقیم مثل «تولید کن»، «لیست کن» یا «شناسایی کن» مانع از حالت بیش از حد گفتاری مدل می‌شود. این راهنما توصیه می‌کند از عبارات مبهمی مثل «فکر کن درباره...» یا «در نظر بگیر...» پرهیز کنید.
- قالب خروجی (Output Format): درخواست جدول با ستون‌های نام‌گذاری شده، سینتکس Gherkin یا JSON باعث می‌شود خروجی مستقیماً در ابزارهای مدیریت تست جای بگیرد.
۵ چارچوب عملیاتی برای مهندسی پرامپت
این راهنما پنج نوع پرامپت متمایز را برای نیازهای مختلف تست شناسایی کرده است.
۱. پوشش عملکردی از استوری‌های کاربر
اولین چارچوب بر پوشش عملکردی متمرکز است. در این حالت، یک پرامپت نمونه از مدل می‌خواهد در نقش مهندس ارشد QA عمل کرده و جدولی شامل ستون‌های «شناسه تست»، «سناریو»، «پیش‌نیازها»، «گام‌ها» و «نتیجه مورد انتظار» ایجاد کند که موارد مثبت، منفی و مرزی (Boundary) را پوشش دهد.
طبق گزارش CloudQA، اگر از مدل بخواهید پیش‌فرض‌های خود را در یک بخش جداگانه به نام «Assumptions» بنویسد، به جای اینکه مدل در سکوت یک تفسیر را انتخاب کند، تسترها می‌توانند شکاف‌های موجود در نیازمندی‌های اصلی را پیدا کنند؛ جایی که معمولاً باگ‌های واقعی پنهان شده‌اند. برای مثال، اگر یک استوری کاربر «افزودن محصول به سبد خرید» را توصیف کند، مدل ممکن است مواردی را شناسایی کند که در معیارهای پذیرش ذکر نشده‌اند، مانند «افزودن محصول ناموجود» یا «مدیریت کلیک‌های سریع و مکرر» برای اطمینان از اینکه آیتم‌های تکراری در سبد ایجاد نمی‌شوند.
۲. موارد خاص (Edge Cases) و سناریوهای منفی
برای موارد خاص، شخصیت «تستر QA وسواسی» پیشنهاد می‌شود. این رویکرد بر ورودی‌های نامعتبر، شرایط مرزی و رفتارهای غیرمعمول کاربر تمرکز دارد. برای فرمی که نیاز به فرمت ایمیل معتبر و رمز عبور حداقل ۸ رقمی دارد، پرامپت باید به طور خاص دسته‌های زیر را درخواست کند:
- اعتبارسنجی ورودی (Input Validation)
- رفتار نشست (Session Behavior)
- محدودیت نرخ درخواست (Rate Limiting)
- دسترسی‌پذیری (Accessibility)
دسته‌بندی بر اساس این محورها مانع از آن می‌شود که مدل به سمت سناریوهای بدیهی منحرف شود و باعث می‌شود طوفان فکری جامع‌تری برای ورودی‌های غیرمعمول صورت گیرد.
۳. ایده‌های تست با محوریت امنیت
تست امنیت به لنز متفاوتی نیاز دارد. با ایفای نقش «تستر امنیت اپلیکیشن»، هوش مصنوعی می‌تواند چک‌لیست‌هایی برای آسیب‌پذیری‌های رایج در مدیریت ورودی، مانند SQL Injection و Cross-Site Scripting (XSS)، برای فرم‌هایی که نام کاربری، ایمیل و رمز عبور می‌گیرند، تولید کند. پرامپت باید «ورودی خاص»، «فیلد هدف» و «رفتار امن مورد انتظار» را درخواست کند.
با این حال، این راهنما هشدار می‌دهد که این خروجی‌ها باید به عنوان نقطه شروع یا چک‌لیست دیده شوند، نه جایگزینی برای ابزارهای تخصصی امنیت یا ارزیابی‌های رسمی امنیتی. این تست‌ها تنها باید روی سیستم‌هایی اجرا شوند که مالک آن‌ها هستید یا صراحتاً اجازه تست آن‌ها را دارید.
۴. سناریوهای BDD با سینتکس Gherkin
برای تیم‌هایی که از توسعه رفتار-محور (BDD) استفاده می‌کنند، این چارچوب پیشنهاد می‌کند از شخصیت «متخصص BDD» برای پیش‌نویس فایل‌های ویژگی Gherkin استفاده شود. این شامل استفاده از «Scenario Outline» به همراه «Examples» برای مدیریت بهینه ورودی‌های متنوع است. برای یک قابلیت جست‌وجوی محصول، AI می‌تواند بلوک‌های متمایزی برای نام‌های محصول منطبق (مثلاً "wireless mouse") و سناریوهای بدون نتیجه (مثلاً "zzzzqqq") ایجاد کند تا اطمینان حاصل شود پیام «نتیجه‌ای یافت نشد» به درستی نمایش داده می‌شود.
۵. نقدِ خود (Self-Critique)
پرکاربردترین تکنیک نادیده گرفته شده، نقدِ خود است. پس از تولید یک مجموعه تست، باید پرامپت دومی ارسال شود تا مدل موارد زیر را در برابر نیازمندی‌ها بازبینی کند:
۱. کدام نیازمندی‌ها هیچ پوشش تستی ندارند؟
۲. کدام تست‌کیس‌ها تکراری یا تقریباً تکراری هستند؟
۳. کدام تست‌کیس‌ها رفتاری را فرض کرده‌اند که در نیازمندی‌ها ذکر نشده است؟
۴. پنج سناریوی پرریسک که حذف شده‌اند کدام‌اند؟
مورد سوم حیاتی است، زیرا لحظاتی را افشا می‌کند که مدل دچار توهم (Hallucination) — مثل دوستی که خاطره‌ای را اشتباه تعریف می‌کند — شده و رفتاری را از خودش اختراع کرده است؛ این رایج‌ترین دلیل شکست در تست‌های تولیدشده توسط AI است. در واقع، اعمال محدودیت‌های سخت‌گیرانه در ساختار پرامپت‌ها می‌تواند به طور مستقیم نرخ این توهمات را کاهش داده و دقت خروجی‌ها را بالا ببرد.
ریسک‌های تست‌های تولیدشده توسط هوش مصنوعی
مدل‌های زبانی وقتی نیازمندی‌ها ساکت باشند، رفتارهای محتمل اما غلط می‌سازند. مدل نمی‌داند قوانین خاص کسب‌وکار شما چیست؛ مثلاً اینکه آیا استرداد وجه بالای مبلغی خاص نیاز به تایید مدیر دارد یا اینکه آیا سطوح خاصی از مشتریان قیمت‌های ویژه‌ای دریافت می‌کنند یا خیر. این موضوع منجر به تست‌هایی می‌شود که به دلایل غلط «پاس» می‌شوند یا بر اساس توهمات شکست می‌خورند.
علاوه بر این، کدهای اتوماسیون تولیدشده — مانند اسکریپت‌های Playwright یا WebdriverIO — اغلب شامل انتخابگرهای (Selectors) حدسی هستند که باید دستی تایید شوند. راهنمای CloudQA اشاره می‌کند که AI «حجم» تولید می‌کند، نه «اولویت»؛ سی تست‌کیس بهتر از ده تست‌کیس نیست اگر تستر نتواند شناسایی کند که کدام پنج مورد حیاتی‌ترین‌ها هستند.
حریم خصوصی داده‌ها یک نگرانی اصلی است. این راهنما تاکید می‌کند که کدهای اختصاصی، داده‌های مشتریان یا نیازمندی‌های محرمانه هرگز نباید در رابط‌های عمومی مدل‌ها قرار گیرند و در عوض، استفاده از نسخه‌های سازمانی (Enterprise) با تضمین‌های سخت‌گیرانه داده‌ای توصیه می‌شود.
چک‌لیست بازبینی
هر تست‌کیس قبل از ورود به مجموعه نهایی باید این فیلترهای سخت‌گیرانه را رد کند:
- آیا به یک نیازمندی واقعی بازمی‌گردد؟
- آیا نتایج مورد انتظار صریح هستند یا فقط به طور ضمنی اشاره شده‌اند؟
- آیا رفتاری فرض شده که شما تایید نکرده‌اید؟
- آیا تکراریِ چیزی است که از قبل دارید؟
- اگر تست شکست بخورد، آیا می‌دانید دلیلش چیست؟
- آیا ارزش اتوماسیون دارد یا بهتر است به عنوان یک بررسی اکتشافی (Exploratory) باقی بماند؟
اگر موردی در این فیلترها شکست بخورد، باید بازنویسی یا حذف شود.
از پرامپت تا اتوماسیون
گردش کار ایده‌آل از «تولید» به «بازبینی»، سپس «انتخاب» و در نهایت «اسکریپت‌نویسی» می‌رسد. هنگام تبدیل یک تست به کد، راهنما پیشنهاد می‌کند از مدل بخواهید از لوکیتورهای مبتنی بر نقش (Role-based locators) استفاده کند، از تایم‌اوت‌های ثابت (Fixed timeouts) بپرهیزد و صراحتاً روی هر انتخابگری که در موردش تردید دارد، کامنت بگذارد. این کار یک لیست تایید داخلی برای مهندس انسان ایجاد می‌کند.
برای کسانی که ترجیح می‌دهند پرامپت‌ها را دستی ننویسند، تولیدکننده تست‌کیس AI شرکت CloudQA می‌تواند این موارد را مستقیماً از توصیف قابلیت در مرورگر تولید کند. این تغییر در رویکرد، نقش QA را از «نویسنده تست‌کیس» به «داور پیش‌نویس‌های AI» تغییر می‌دهد. ارزش دیگر در حجم تست‌های تولیدشده نیست، بلکه در دقت ورودی‌هایی است که به مدل داده می‌شود.
گام بعدی شما
- یکی از ۵ چارچوب بالا را روی یک فیچر کوچک در پروژه فعلی‌تان تست کنید.
- پرامپت «نقدِ خود» را به انتهای هر زنجیره تولید تست اضافه کنید تا نرخ توهم مدل را بسنجید.
- برای اتوماسیون، از مدل بخواهید دلیل انتخاب هر Selector را توضیح دهد تا زمان بازبینی کاهش یابد.
اما تبدیل این تست‌ها به کدهای اجرایی بدون خطا، نیازمند استراتژی‌های پیشرفته‌تری در مدیریت توکن‌هاست — به تحلیل ما درباره بهینه‌سازی پنجره متنی مراجعه کنید.
گفتگو