رفتن به محتوا
AI Forwardپیشرفت سازمان با هوش مصنوعی
خانهپروژه‌های بهبودتوسعه و نگهداری

آزمون مسیرهای مهم کاربر و پیدا کردن علت خطا

P20

فنیطراحیتیم محصول

برنامه شروع

شکست ورود، دسترسی و خرید پیش از انتشار با شاهد قابل بازپخش پیدا شود.

قدم اول

محیط تست و حساب‌ها را مشخص کنید؛ ماتریس یک جریان را از نتیجه مورد انتظار کاربر تا وضعیت سمت سرور بنویسید.

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

ورودی‌های لازم

  • محیط تست و حساب دو نقش
  • نتیجه مورد انتظار رابط و سرور
  • سناریوی موفق، ناموفق و تکراری

کمک هوش مصنوعی: سناریو و خلاصه شکست را از شاهد آزمون پیشنهاد کند؛ قبولی با بررسی صریح نتیجه و مرجع مستقل تعیین شود.

روش آزمون و ابزارها

مقایسه با روش فعلی

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

نمونه آزمون

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

  • سهم سناریوهای بحرانی دارای assertion و شاهد قابل بازتولید؛ نه فقط تعداد تست
  • نقص معلوم کشف‌شده و خطای ازقلم‌افتاده، به تفکیک رابط، سفارش، پرداخت و مجوز
  • شکست ناپایدار در اجرای تکراری و زمان بازتولید و تشخیص
  • دقت خلاصه شکست و دقیقه اصلاح آن؛ نتیجه دستی صفحه‌کلید، RTL و موارد axe-core

معیار پیشنهادی پذیرش

پیشنهاد: هر نقص معلوم در ماتریس کشف شود، هیچ اختلاط حساب یا پرداخت تکراری نادیده نماند و قبولی روی داده بازنشانی‌شده بازتولیدپذیر باشد؛ خطای ناپایدار حل یا صریحاً از پوشش معتبر کنار گذاشته شود. AI فقط با کاهش زمان تشخیص بدون پنهان کردن شکست اضافه شود.

ابزارهای مرتبط

  • Playwright — تست مرورگر و trace
  • axe-core — آزمون خودکار بخشی از دسترس‌پذیری

منابع فنی

منابع این پیشنهاد: RS03 · RS11 · RS14 · RS32 · RS33

جزئیات پروژه و منابع
محصول / سامانه هدف

پنل، SSO، IRShop، Flow Meet، ریبکس

زمان کاری برآوردشده برای آزمون اولیه

۲–۴ هفته کار یک نفر

نقش پاسخ‌گو

مسئول QA یا بازبین مستقل فنی

پیش‌نویس کار

این پروژه چه کمکی به کار روزانه می‌کند؟

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

برای شروع، چه چیزی آماده می‌شود؟

گزارش شامل مراحل تکرار، تصویر سبد پس از پرداخت و انتظار درست است: «سفارش ثبت شود و سبد خالی نمایش داده شود.»

در مرحله بعد، چه می‌توان اضافه کرد؟

این مسیر پس از هر تغییر مهم دوباره آزمایش می‌شود تا خطا برنگردد.

موفق‌بودن پیام درگاه کافی نیست؛ وضعیت سفارش و چیزی که مشتری می‌بیند هم باید درست باشد.

مراحل پیشنهادی کار

  1. مرحله ۱

    سناریو و داده آزمون

    یک مسیر واقعی کاربر، مثل خرید، را با حساب و داده آزمایشی مشخص می‌کنیم.

  2. مرحله ۲

    آزمایش مراحل کار با نتیجه مشخص

    ورود، حساب، پرداخت و فرم را با آزمون‌های مشخص بررسی می‌کنیم.

  3. مرحله ۳

    ثبت نتیجه آزمون بدون اطلاعات خصوصی

    تصویر و گزارش خطا را پس از حذف اطلاعات محرمانه نگه می‌داریم.

  4. مرحله ۴

    کمک هوش مصنوعی به توضیح علت خطا

    هوش مصنوعی خطا را خلاصه و علت احتمالی را پیشنهاد می‌کند.

  5. مرحله ۵

    تشخیص نهایی علت توسط تیم فنی

    تیم فنی علت و نتیجه آزمون را بررسی می‌کند؛ مدل به‌تنهایی موفقیت را اعلام نمی‌کند.

زمان، درستی خروجی و فایده کار را بسنجیم

۱. زمان و هزینه انجام کار

زمان بازتولید و تشخیص شکست

۲. کیفیت و اعتبار

پوشش مسیر بحرانی و خطای escaped پس از انتشار

۳. فایده و نتیجه اقتصادی

نرخ موفقیت ورود/پرداخت و خرید تکمیل شده

توضیحات بیشتر برای اجرا و بررسی نتیجه

این کار کجا ثبت می‌شود؟

تیمیک: باگ به جریان، نسخه و شاهد متصل؛ تست‌های محلی/اجرای دستی مجاز، بدون GitHub Actions

هر مرحله را چه کسی انجام می‌دهد و به چه کسی تحویل می‌دهد؟
هر فرد چه کاری انجام می‌دهد؟
  1. ۱

    تیم محصول، نتیجه مورد انتظار را مشخص می‌کند

  2. ۲

    تیم آزمون و فنی، مشکل را آزمایش می‌کنند

  3. ۳

    برنامه‌نویس، خطا را رفع می‌کند

  4. ۴

    بازبین، دوباره آزمایش و نتیجه را تأیید می‌کند.

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

از کجا بفهمیم آزمون اولیه موفق بوده است؟

ورود موفق/ناموفق، مجوز دو حساب، پرداخت موفق/ناموفق/تکراری و RTL در سه اندازه؛ برای هر آزمون، گزارش نتیجه ثبت شود.

چه زمانی باید کار را متوقف کنیم؟
شرط توقف در این پروژه

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

ابزارها و منابع 5 مورد توضیح مفاهیم این حوزه

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

جزئیات هر کار و معیار نمونه اول در همین پروژه قرار دارد.

آزمون مشترک ماشین‌حساب‌های مالیایران‌ریبیت و کدام بروکر

آزمون مشترک ماشین‌حساب‌های مالی

متداول
ورودی
فرمول تأییدشده، واحد پول و ورودی‌هایی مثل صفر، عدد منفی یا حد مجاز
خروجی و نقش هوش مصنوعی
بررسی عددها با برنامه و گزارش ساده خطا؛ مدل مسئول حساب کردن نتیجه مرجع نباشد.
مسئول تحویل
فنی + کارشناس مالی
نمونه اول و سنجش
۳۰ حالت برای یک ابزار در هر برند؛ ورودی صفر، اعشار و تغییر واحد پوشش داده شود.

منبع روش پیشنهادی: RS32

آزمون مسیرهای مهم فارسی و موبایلایران‌ریبیت و کدام بروکر

آزمون مسیرهای مهم فارسی و موبایل

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

منبع روش پیشنهادی: RS32

برای شروع چه لازم است و بعد چه می‌کنیم؟

چه چیزهایی باید آماده باشد؟

این موارد باید از پروژه‌های مرتبط آماده شوند؛ کامل‌شدن همه امکانات آن پروژه‌ها لازم نیست.

  • P03؛ دیدن پروژه مرتبط

    برای هر کار، مسئله، مسئول، موعد و نشانه تحویل درست نوشته شود؛ مثلاً «فرم با شماره آزمون ثبت‌نام را کامل کند».

مراحل پیشنهادی اجرا و توسعه

این مراحل برنامه پیشنهادی‌اند؛ انجام‌شدن آن‌ها هنوز تأیید نشده است.

  1. مرحله ۱آزمون مسیر اصلی

    ثبت‌نام یا خرید را با حساب آزمایشی تا نتیجه نهایی انجام دهید.

  2. مرحله ۲بررسی شکست

    مرحله خطا و شواهد مرورگر را ثبت کنید.

  3. مرحله ۳افزودن حالت خطا

    پرداخت ناموفق یا ورودی نامعتبر را هم آزمایش کنید؛ انتشار با تأیید مسئول باشد.