نوشتن تست کیس با هوش مصنوعی؛ نمونه عملی

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

تست کیس خوب چه اجزایی دارد؟#

«بررسی کن تخفیف کار کند» دستور آزمون کافی نیست. آزمایشگر باید بداند کدام کد، روی چه سبدی، در چه زمانی و با چه نتیجه‌ای اجرا می‌شود. اگر دو نفر همان تست را اجرا کنند، باید بتوانند درباره موفق یا ناموفق بودن آن توافق کنند. عبارت‌هایی مانند «ظاهر مناسب» و «سرعت خوب» بدون معیار، نتیجه را سلیقه‌ای می‌کنند.

برای هر تست شناسه یکتا، نیازمندی مرتبط، پیش‌شرط، ورودی، مراحل و نتیجه مورد انتظار ثبت کنید. وضعیت اجرا، محیط و شاهد را بعداً اضافه کنید. AI می‌تواند به طراحی این بخش‌ها کمک کند، ولی نوشتن «Passed» پیش از اجرا اطلاعات نادرست می‌سازد. وضعیت اولیه تست‌های این مقاله «طراحی‌شده، اجرا نشده» است.

قرارداد قابلیت آموزشی کد تخفیف#

فروشگاه فرضی فقط یک کد به نام DEMO10 دارد. تخفیف ده درصد مبلغ کالاهاست و ارسال مشمول آن نیست. حداقل مبلغ کالاها ۵۰۰ هزار تومان است. کد برای هر حساب فقط یک سفارش تکمیل‌شده قابل استفاده است و بعد از ساعت تعیین‌شده پایان اعتبار، پذیرفته نمی‌شود. این اعداد سیاست واقعی فروشگاه یا پیشنهاد قیمت‌گذاری نیستند.

بازه زمانی باید دقیق باشد: در این مثال زمان سرور مرجع است و لحظه پایان، خارج از اعتبار محسوب می‌شود. پیش از طراحی تست، درباره لغو سفارش، گرد کردن مبلغ و حالت کاربر مهمان سؤال کنید. اگر پاسخ ندارید، همان را «نیازمند تصمیم محصول» نگه دارید؛ مدل نباید سیاست فروشگاه را حدس بزند.

جدول تست کیس قابل استفاده#

آخرین رفتار TC07 باید در قرارداد واقعی محصول تصویب شود؛ اینجا برای کامل شدن مثال آن را صریح اضافه کرده‌ایم. همین ثبت تصمیم نشان می‌دهد طراحی تست می‌تواند ابهام نیازمندی را آشکار کند. مسئله فقط زیاد کردن تعداد ردیف‌ها نیست.

پرامپت آماده طراحی تست کیس#

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

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

پوشش نیازمندی را چگونه ببینیم؟#

نیازمندی‌ها را شماره‌گذاری کنید: R01 نرخ تخفیف، R02 حداقل مبلغ، R03 یک‌بار استفاده و R04 پایان اعتبار. کنار هر تست شناسه مربوط را بگذارید. اگر یک نیازمندی هیچ تستی ندارد، پوشش ناقص است. اگر چند تست یک رفتار ساده را تکرار می‌کنند، شاید یکی کافی باشد و وقت به حالت مرزی اختصاص پیدا کند.

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

اجرای تست و ثبت شاهد#

برای هر اجرا نسخه برنامه، محیط، زمان و شناسه داده آزمون را ثبت کنید. حساب آزمایشی باید وضعیت روشن داشته باشد؛ استفاده قبلی از تخفیف می‌تواند نتیجه تست تازه را تغییر دهد. پیش از اجرای دوباره، پیش‌شرط را بازسازی کنید. یک تست که به وضعیت نامعلوم محیط وابسته است، نتیجه قابل اعتماد نمی‌دهد.

انتظار و نتیجه واقعی را در دو ستون جدا بنویسید. اگر مبلغ ۵۹۰ هزار مورد انتظار بود ولی ۵۸۵ هزار نمایش داده شد، اختلاف را صریح ثبت کنید. اسکرین‌شات یا پاسخ سرویس را در صورت مناسب بودن اضافه کنید، اما اطلاعات مشتری واقعی را در شاهد عمومی قرار ندهید. ناموفق شدن تست، به‌تنهایی علت فنی خطا را تعیین نمی‌کند.

تست خودکار را چه زمانی اضافه کنیم؟#

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

برای طراحی نیازمندی کوچک، یوزر استوری و معیار پذیرش و برای فهم هدف قابلیت، نمونه سند PRD را بخوانید. در راهنمای داستان کاربر Atlassian نیز رابطه نیاز کاربر و معیار تکمیل مطرح شده است. می‌توانید همین قرارداد ساختگی را برای طراحی تست در GPT Plus تمرین کنید؛ نتیجه اجرای واقعی را جداگانه نگه دارید.