هوش مصنوعی برای تست نرمافزار: سناریو، داده و گزارش باگ
بخش سخت تست، فکر کردن به حالتهایی است که کسی به آنها فکر نکرده. بخش کند، نوشتن همان چیزهاست. این دو را از هم جدا کنید تا بفهمید کجا کمک میگیرید.
یک تیم سهنفره، یک سبد خرید، و انتشاری که فردا صبح است. کسی باید بنشیند و برای فرم ثبت سفارش پنجاه حالت بنویسد: کد تخفیف منقضی، موجودی صفر وسط پرداخت، شمارهی موبایل با صفر اضافه، آدرسی که کاربر با «ی» عربی نوشته. همه هم میدانند لازم است و هیچکس حوصلهاش را ندارد.
اینجا یک تفکیک مهم هست. بخش سختِ تست، فکر کردن به حالتهایی است که هیچکس به آنها فکر نکرده. بخش کندِ تست، نوشتن همان حالتهاست. مدلهای زبانی در بخش دوم خوباند و در بخش اول فقط تا حدی که شما اطلاعات داده باشید.
سناریوی تست از روی نیازمندی
ورودی هرچه دقیقتر، خروجی هرچه مفیدتر. اگر فقط بنویسید «برای فرم ثبتنام تست بنویس»، بیست مورد بدیهی میگیرید. اگر قواعد واقعی را بدهید، مواردی میگیرید که خودتان هم جا انداخته بودید.
این قابلیت را تست کن:
شرح: [توضیح دقیق قابلیت]
قواعد اعتبارسنجی: [فهرست هر قاعده]
نقشهای کاربری: [مهمان / کاربر عادی / ادمین]
وابستگیهای بیرونی: [درگاه پرداخت، پیامک، ...]
موارد تست را در چهار دسته بده:
۱) مسیر موفق
۲) اعتبارسنجی ورودی (شامل مقادیر مرزی)
۳) خطای سرویس بیرونی (تایماوت، پاسخ ناقص)
۴) همزمانی و وضعیت (دو تب باز، دکمهی دوبار)
قالب هر مورد: عنوان | پیششرط | گامها | نتیجهی انتظاری
موارد تکراری را حذف کن.دستهی سوم و چهارم همانهایی هستند که در عمل بیشتر باگ میدهند و کمتر نوشته میشوند. تایماوت درگاه پرداخت وسط تراکنش، یا کاربری که دکمهی «پرداخت» را دوبار میزند، دو سناریوی کلاسیکیاند که تقریباً همیشه از قلم میافتند.
به انتهای پرامپت اضافه کنید: «سه فرضی را که در شرح بالا صریح نگفتهام ولی برای تست لازم است، فهرست کن و از من بپرس.» مدل معمولاً دقیقاً همان ابهامهایی را پیدا میکند که بعداً در محیط عملیاتی به باگ تبدیل میشوند.
دادهی تست فارسی
این یکی از معدود جاهایی است که خروجی تقریباً بدون ویرایش قابل استفاده است — به شرطی که صریح بخواهید دادهی بد هم بسازد. مدل بهطور پیشفرض دادهی تمیز میسازد و دادهی تمیز چیزی را نمیشکند.
۳۰ ردیف دادهی تست برای جدول کاربران بساز.
ستونها: نام | موبایل | ایمیل | تاریخ تولد | آدرس
نیمی معتبر و نیمی مسئلهدار باشد. حتماً اینها را بیاور:
- نام با نیمفاصله و نام با «ي» و «ك» عربی
- نام تکحرفی و نام ۸۰ کاراکتری
- موبایل با +۹۸، با ۰۰۹۸، بدون صفر، با فاصله وسط
- تاریخ شمسی، میلادی، و ۳۰ اسفند سال غیرکبیسه
- آدرس با اعداد فارسی و آدرس با ایموجی
- ایمیل با حروف بزرگ و با نقطهی اضافه
خروجی: CSV با جداکنندهی ویرگول، بدون توضیح.«۳۰ اسفند سال غیرکبیسه» را حتماً نگه دارید. تبدیل تاریخ شمسی، منبع دائمی باگ در نرمافزارهای ایرانی است و این یک ردیف، بیشتر از بیست ردیف سالم ارزش دارد.
گزارش باگ که برنامهنویس بتواند بازتولید کند
گزارشهای ضعیف دو مشکل مشترک دارند: توصیف احساس بهجای مشاهده («صفحه قاطی میکند») و نبود گامهای دقیق. مدل در تبدیل یادداشت خام به گزارش ساختاریافته خوب عمل میکند.
از این یادداشت خام، گزارش باگ بساز:
[یادداشت من]
قالب:
عنوان (یک خط، شامل کجا و چه)
محیط (مرورگر، نسخه، نقش کاربر)
گامهای بازتولید (شمارهدار، بدون گام اضافه)
نتیجهی فعلی / نتیجهی انتظاری
شدت با یک جمله دلیل
اگر اطلاعاتی برای بازتولید کم است، اول فهرستش کن.تست خودکار: تا کجا بسپاریم
نوشتن تست واحد برای تابعی که کدش را میدهید، معمولاً خوب جواب میدهد. تست یکپارچگی و end-to-end نتیجهی متغیرتری دارد، چون مدل ساختار پروژه و شناسههای عناصر صفحه را نمیبیند.
| کار | کیفیت خروجی | چه چیزی باید بدهید |
|---|---|---|
| تست واحد یک تابع خالص | خوب | کد کامل تابع |
| تست واحد با وابستگی | متوسط | امضای وابستگیها و ابزار mock |
| تست API | خوب | نمونهی درخواست و پاسخ واقعی |
| تست رابط کاربری | ضعیف تا متوسط | HTML یا شناسههای دقیق عناصر |
| تست کارایی و بار | ضعیف | فقط برای طرح سناریو مفید است |
| ساخت دادهی تست | خیلی خوب | ساختار جدول و قواعد |
شایعترین اشکال کد تست تولیدشده این است که چیزی را میسنجد که همیشه درست است — مثلاً بررسی میکند خروجی null نیست، بهجای اینکه مقدار درست را چک کند. قبل از پذیرفتن هر تست، عمداً کد را خراب کنید و ببینید تست قرمز میشود یا نه. اگر نشد، آن تست ارزشی ندارد.
مرز امنیتی: چه چیزی را نچسبانید
وسوسهی کپیکردن لاگ کامل خطا زیاد است، ولی لاگ محیط عملیاتی معمولاً پر از چیزهایی است که نباید بیرون برود: توکن نشست، شماره تماس کاربر، رشتهی اتصال دیتابیس. ردیابی پشته و پیام خطا را نگه دارید، مقادیر متغیرها را جایگزین کنید. تفصیل این بحث در مقالهی امنیت اطلاعات آمده است.
کاری که نمیکند
- باگهای ناشی از فرضهای نانوشته را پیدا نمیکند. مدل فقط چیزی را میبیند که نوشتهاید؛ باگ واقعی معمولاً همانجایی است که کسی چیزی را ننوشته چون بدیهی میدانست.
- اولویت نمیدهد. پنجاه مورد تست به شما میدهد بدون اینکه بداند کدامشان برای کسبوکار شما حیاتی است.
- جای تست دستی اکتشافی را نمیگیرد. نشستن پای محصول و بازیکردن با آن، هنوز بهترین راه پیدا کردن مشکلات عجیب است.
الگوی کلی همان چیزی است که در مقالهی اشتباهات رایج هم دیده میشود: خروجی را پیشنویس بدانید، نه نتیجه. و اگر با پرامپتها راحت نیستید، راهنمای پرامپتنویسی نقطهی شروع بهتری است.
جمعبندی
سپردن نوشتن به ابزار و نگهداشتن فکر کردن برای خودتان — این خلاصهی کل ماجراست. سناریو، داده و گزارش باگ، سه کار پرحجم و کمفکرند که ساعتها وقت میگیرند و کسی از انجام دادنشان لذت نمیبرد.
یک عادت هم بسازید: هر تستی که تولید شد، یک بار عمداً بشکنیدش. تستی که با کد خرابِ عمدی هم سبز میماند، فقط عدد پوشش را بالا برده. برای شروع میتوانید همین حالا در نارنگی یکی از این پرامپتها را روی یک تابع واقعی امتحان کنید. برای فهرست کاملتر موارد امنیتی، راهنمای تست امنیتی OWASP مرجع خوبی است.
مطالب مرتبط:
