4.8 KiB
4.8 KiB
ارزیابی نام واریزکننده و پیامک رد فیش
تاریخ ارزیابی: ۱۹ مهر ۱۴۰۵ (۲۰۲۶-۱۰-۱۱)
رفتار پیاده‌شده
- تمام فرم‌های ثبت و اصلاح فیش، نام واریزکننده اجباری و قابل ویرایش دارند. نام از پروفایل مشتری یا نام حساب پر می‌شود؛ POST بدون نام حتی با وجود نام در پروفایل رد می‌شود.
- نام روی نسخه فیش ذخیره می‌شود و اصلاح آن، نام نسخه قبلی و پروفایل مشتری را تغییر نمی‌دهد. نام مشتری و نام واریزکننده در میزکار و جزئیات کارکنان نمایش داده می‌شوند.
- اعلان ثبت فیش در پیامک مدیران و بله هر دو نام متفاوت را نمایش می‌دهد؛ نام یکسان پس از یکسان‌سازی حروف و فاصله‌ها فقط یک بار می‌آید. اطلاعات اعلان snapshot زمان ثبت نسخه است.
- رد فیش با دلیل و تأیید صریح کارشناس انجام می‌شود. انصراف از دیالوگ، فرم و دکمه‌ها را قابل استفاده نگه می‌دارد. کنترل مجوز پیش از کنترل تأیید انجام می‌شود.
- پیامک رد در تراکنش تصمیم و با کلید یکتای چرخه بررسی ساخته می‌شود؛ ارسال از Worker موجود انجام می‌شود. دلیل کامل حتی در قالب سفارشی بدون تگ دلیل به مشتری می‌رسد.
- هشدار قرمز بانک شناسه‌دار، نام بانک و شناسه اختصاصی تولیدشده با الگوریتم موجود را نمایش می‌دهد و با تغییر حساب مقصد به‌روز می‌شود. الزام واردکردن شناسه در خود عملیات بانکی توضیح داده می‌شود؛ فیلد اختیاری شناسه درج‌شده روی فیش مطابق قرارداد فعلی حفظ شده است.
نتایج بررسی
- کل تست‌های سمت سرور: ۵۱۴ موفق، ۷ ردشده از اجرا به علت نیاز به PostgreSQL؛ محیط فعلی SQLite است.
- تست‌های مرورگری پرداخت: ۴۱ سناریوی متمایز موفق، شامل تست نسخه‌گذاری PWA. یک خطای واقعی قفل شدن دکمه پس از انصراف کشف، اصلاح و دوباره تست شد.
- ۱۶ تست جدید سمت سرور و ۶ سناریوی جدید مرورگری برای نام، هشدار بانک و تأیید رد اضافه شدند.
- تست‌های ارسال، درگاه پیامک و بله را mock می‌کنند و پیامی به مشتری یا گروه واقعی نمی‌فرستند.
manage.py checkبدون اشکال؛makemigrations --check --dry-runبدون تغییر جامانده؛ بررسی whitespace فایل‌های این تغییر بدون خطا.PROJECT_TREE.txt، تست‌های موجود و مستندات اعلان بررسی شدند. Graphify برای ارتباط مستندات و بخش‌ها و Ripwire برای impact، uses، قرارداد و دروازه تست به کار رفتند.- Ripwire پس از بازخوانی بدون کش یک هشدار عمده باقی‌مانده دارد: افزایش تعداد پارامترهای
decide_receiptبه دلیل پارامتر اختیاری تأیید رد. این تغییر عمدی است؛ بررسی قرارداد هیچ فراخوان ناسازگاری گزارش نکرد و تست‌های مجوز و تصمیم موفق بودند. یافته‌های عدم پوشش AST، جایگزین نتایج اجرای تست نیستند. - محتوای واقعی
/chaharsu/payment-receipt/و/staff/payments/و فایل‌های JavaScript سرو‌شده روی سرور محلی بررسی شدند. دقیقاً یک شنونده روی0.0.0.0:8000وجود دارد. UUIDهای نمونه درخواست در دیتابیس محلی نبودند؛ صفحات جزئیات با داده مستقل در live_server تست شدند.
انتشار
روی دیتابیس توسعه، پس از backup، migrationهای payments.0008، notifications.0019 و notifications.0020 اجرا شدند. برای محیط اصلی نیز migrationها باید اجرا و Worker process_notifications با کد جدید بازراه‌اندازی شود. migrationهای قبلی و تغییرات موجود کاربر حفظ شدند. برای فیش‌های قدیمی نام واقعی واریزکننده جعل یا از پروفایل بازسازی نمی‌شود؛ وضعیت ثبت نشدن نام در پنل مشخص است.