برای ارزیابی اسکریپت طلای آبشده، دیدن نمودار قیمت و دکمه خرید کافی نیست. مسئله اصلی این است که وزن، قیمت ثبتشده، موجودی، پرداخت و سند مالی در تمام حالتها با یکدیگر سازگار بمانند. حتی اگر ظاهر دمو کامل باشد، خرید همزمان، قطع ارتباط و برگشت پرداخت میتوانند ضعفهایی را آشکار کنند که در نمایش معمولی دیده نمیشوند.
این مقاله یک برنامه پیشنهادی آزمون نرمافزار است، نه توصیه خرید طلا یا تأیید مجوز کسبوکار. درباره مسیر کلی راهاندازی و برآورد پروژه، راهنمای طراحی سایت طلای آبشده را ببینید؛ در اینجا تمرکز بر معیارهای فنی تحویل است.
واحد وزن و پول باید بدون ابهام باشد
در هر صفحه و API باید روشن باشد مبلغ به ریال است یا تومان و وزن با چه واحد و دقتی ثبت میشود. نمایش گردشده برای کاربر نباید باعث شود عدد ذخیرهشده تغییر کند. قواعد عیار مبنا، کارمزد و حداقل سفارش باید مستند و در محاسبات سمت سرور اعمال شوند.
برای آزمون، یک نرخ ساختگی ثابت و چند وزن با اعشار متفاوت تعریف کنید. مبلغ سفارش، سند مالی و گزارش مدیر را مقایسه کنید. سپس همان داده را خروجی بگیرید و بررسی کنید تبدیل رقم فارسی و لاتین یا ورود از فایل، دقت را تغییر نمیدهد. این دادهها صرفاً برای تست هستند و نباید با نرخ واقعی بازار مخلوط شوند.
نرخ هنگام سفارش چگونه تثبیت میشود؟
فرض کنید کاربر قیمت را میبیند، اما پیش از تأیید خرید نرخ تغییر میکند. سامانه باید سیاست روشنی داشته باشد: قیمت پیشنهادی تا زمان معین معتبر است یا پیش از ثبت نهایی دوباره تأیید میشود. آنچه پذیرفته شده باید با زمان، منبع نرخ و اجزای محاسبه در سفارش ثبت شود.
سه حالت را آزمایش کنید: نرخ بهروز، نرخ منقضی و قطع دریافت نرخ. در حالت سوم، استفاده خاموش از آخرین عدد میتواند برداشت نادرست ایجاد کند. پیام وضعیت و امکان توقف سفارش باید مطابق قواعد کسبوکار طراحی شود. اختلاف ساعت سرور و نمایش کاربر نیز در اعتبار زمانی پیشنهاد مهم است.
پرداخت تکراری نباید موجودی تکراری بسازد
اعلان درگاه ممکن است دوباره برسد یا کاربر صفحه بازگشت را چند بار باز کند. سیستم باید تشخیص دهد این رویدادها متعلق به یک پرداخت هستند. تغییر موجودی یا وضعیت سفارش باید فقط پس از تأیید معتبر سرویس پرداخت و طبق یک انتقال وضعیت مجاز انجام شود.
- اعلان موفق یک پرداخت آزمایشی را دوباره پردازش کنید؛ موجودی نباید دوبار افزایش یابد.
- پاسخ دیرهنگام را بعد از پایان مهلت سفارش بررسی کنید؛ مسیر رسیدگی باید روشن باشد.
- شناسه پرداخت متعلق به کاربر دیگر را ارسال کنید؛ درخواست باید رد شود.
- مبلغ متفاوت از مبلغ سفارش را آزمایش کنید؛ مغایرت نباید به موفقیت ظاهری تبدیل شود.
- قطع ارتباط بین تأیید پرداخت و ثبت سند را شبیهسازی کنید؛ عملیات باید قابل بازیابی و تطبیق باشد.
این آزمونها روی محیط آزمایشی و حسابهای تست انجام میشوند. هدف، بررسی ثبات داده است، نه ایجاد تراکنش واقعی برای امتحان کردن سایت.
موجودی آزاد و موجودی رزروشده را جدا بررسی کنید
دو درخواست همزمان نباید بتوانند از یک موجودی محدود دوبار استفاده کنند. هنگام ثبت سفارش، لغو، انقضا و تکمیل، وضعیت رزرو باید قابل مشاهده باشد. مدیر باید بتواند دلیل اختلاف بین موجودی کل و موجودی قابل استفاده را از روی سوابق بفهمد.
برای تست، موجودی محدود تعریف کنید و دو درخواست همزمان بفرستید که مجموع آنها از موجودی بیشتر است. نتیجه قابل قبول باید با سیاست کسبوکار همخوان باشد و هیچ حسابی بدون مجوز منفی نشود. همچنین لغو دوباره یک سفارش نباید اعتبار رزروشده را دوبار آزاد کند.
دسترسی مدیر و ردپای عملیات
اپراتور پشتیبانی معمولاً به همان اختیارات مدیر مالی نیاز ندارد. نمایش اطلاعات هویتی، اصلاح موجودی و تأیید برداشت باید بر اساس نقش و نیاز کاری کنترل شود. صرف مخفی کردن دکمه در رابط کافی نیست؛ درخواست مستقیم به سرور نیز باید مجوز را بررسی کند.
برای تغییر حساس، عامل انجامدهنده، زمان، دلیل و شناسه عملیات ثبت شود. اصلاح حساب نباید با حذف خاموش سابقه انجام گیرد. مرجع ASVS از OWASP برای تدوین الزامات کنترل دسترسی و آزمون امنیت کاربرد دارد؛ دامنه آزمون باید متناسب با معماری سامانه تعیین شود.
گزارش مالی و تحویل فیزیکی را با هم تطبیق دهید
اگر تحویل فیزیکی در دامنه پروژه است، رزرو کالا، آمادهسازی، تحویل و لغو باید با وزن و اسناد مرتبط باشند. گزارش روزانه باید امکان بررسی سفارش، دریافت وجه، بدهی یا طلب و موارد حلنشده را بدهد. عدد نهایی بدون امکان رسیدن به رویدادهای تشکیلدهنده، برای رسیدگی به مغایرت کافی نیست.
در محصول گلدمن امکانات و دامنه نسخه را بررسی کنید و برای درخواست دموی فنی، سناریوهای این مقاله را همراه داشته باشید. قابلیتهایی مانند کنترل دومرحلهای یا اتصال خاص باید در نسخه مورد سفارش صریحاً تأیید شوند.
دو سؤال رایج درباره امنیت اسکریپت طلا
آیا عبور از این چکلیست به معنی امنیت کامل است؟ خیر؛ این موارد نقطه شروع آزمون پذیرشاند و جای بررسی تخصصی امنیت، عملیات و الزامات جاری کسبوکار را نمیگیرند.
آیا گزارش بدون خطا در دمو کافی است؟ دمو معمولاً داده و ترافیک محدودی دارد. تحویل نهایی باید نسخه مشخص، محیط مشخص، سناریوهای ثبتشده و نتیجه قابل تکرار داشته باشد. کیفیت نرمافزار زمانی قابل قضاوت است که رفتار آن در حالت شکست نیز روشن باشد.
دیدگاهها(0)