در این مقاله
برای آماده‌شدن فروشگاه برای WooCommerce 11.3، قبل از نصب روی سایت اصلی یک ماتریس آزمون بسازید. در بررسی ۳۱ اکتبر ۲۰۲۶، نسخه پیشانتشار برای تست موجود است و انتشار اصلی برای هفته ۹ نوامبر برنامهریزی شده است. نسخه بتا ابزار بررسی سازگاری است، نه دعوت به تغییر فوری فروشگاهی که سفارش واقعی می‌گیرد.
تمرکز این راهنما روی نیاز فروشگاه ایرانی است: درگاه، ارسال، تخفیف، محصول متغیر، موجودی و برگشت کاربر از پرداخت. هیچ ادعایی درباره سازگاری همه افزونه‌های ایرانی یا اجرای تراکنش واقعی در این مقاله نداریم. هدف، تعریف آزمونی است که نتیجه‌اش برای نسخه دقیق فروشگاه شما قابل اتکا باشد و پیش از انتشار مسیر بازیابی داشته باشد.
خبر انتشار را به فهرست آزمون تبدیل کنید
اطلاعیه رسمی پیشانتشار WooCommerce 11.3 تغییرات و هشدارهای توسعه‌دهندگان را توضیح می‌دهد. تغییرات بلوک، Store API و رفتار بعضی فیلترها می‌توانند برای افزونه یا کد سفارشی مهم باشند. لازم نیست همه فروشگاه‌ها از همه این مسیرها استفاده کنند؛ فهرست قابلیت‌های واقعاً فعال خودتان را با اطلاعیه تطبیق دهید.
پیش از هر اقدام، وضعیت روز را در فهرست انتشارهای ووکامرس بررسی کنید. تاریخ برنامهریزی با انتشار قطعی یکی نیست. نسخه هسته وردپرس، ووکامرس، قالب، افزونه درگاه و نوع Checkout را در گزارش کنار هم بنویسید. «آخرین نسخه» عبارت کافی برای یک آزمون قابل تکرار نیست، چون ممکن است فردا به مجموعه دیگری اشاره کند.
فهرست وابستگی‌های فروشگاه را تهیه کنید
درگاه و ارسال تنها وابستگی‌ها نیستند. افزونه فاکتور، حسابداری، پیامک، جست‌وجو، تخفیف پویا و کد سفارشی قالب هم می‌توانند روی سفارش اثر بگذارند. برای هر جزء، مسئول، نسخه و مسیر کاربر مرتبط را بنویسید. اگر افزونه‌ای فقط در وضعیت خاص فعال می‌شود، همان وضعیت را به داده آزمون اضافه کنید؛ یک سبد ساده همه منطق فروشگاه را پوشش نمی‌دهد.
نوع تسویه‌حساب را مشخص کنید. Checkout بلوکی و مسیر کلاسیک ممکن است از قراردادهای یکسانی استفاده نکنند. وجود سازگاری اعلام‌شده برای یک حالت را به دیگری تعمیم ندهید. برای موضوع ذخیره سفارش نیز راهنمای HPOS را بخوانید؛ تغییر نسخه ووکامرس و تغییر شیوه ذخیره داده را بدون ضرورت در یک گام جمع نکنید.
محیط تست باید پیام و پرداخت واقعی نسازد
کپی سایت را از نظر دیتابیس، دامنه، کلید درگاه، ایمیل، پیامک و Webhook مستقل کنید. غیرفعال‌کردن یک دکمه در ظاهر کافی نیست؛ Cron یا Worker می‌تواند بیرون از مرورگر عملیات انجام دهد. داده ساختگی را ترجیح دهید و دسترسی محیط آزمایشی را محدود کنید. noindex جای احراز هویت یا محافظت از اطلاعات مشتری را نمی‌گیرد.
اگر درگاه Sandbox رسمی دارد، همان قرارداد را استفاده کنید. اگر ندارد، روش تست مجاز را از ارائه‌دهنده درگاه بپرسید؛ این مقاله پیشنهاد تراکنش واقعی بدون هماهنگی نمی‌دهد. شناسه سفارش آزمایشی، زمان و نتیجه مورد انتظار را قبل از اجرا ثبت کنید. هدف این است که شکست هم قابل تفسیر باشد، نه فقط موفقیت ظاهری صفحه پرداخت.
داده آزمون نماینده انتخاب کنید
یک محصول ساده، یک محصول متغیر، یک کالای ناموجود و یک سبد دارای کوپن بسازید. هزینه ارسال و محدودیت منطقه را هم وارد سناریو کنید. تعداد و قیمت‌ها باید ساختگی و قابل محاسبه باشند. اگر مالیات یا گردکردن مبلغ دارید، مقدار مرجع را مستقل حساب کنید تا پاسخ برنامه را بدون مرجع به‌عنوان درست نپذیرید.
سناریوی مهم دیگر، تغییر موجودی بین افزودن به سبد و نهایی‌کردن خرید است. رفتار مورد انتظار را مشخص کنید: پیام خطا، اصلاح تعداد یا توقف پرداخت. دو خرید هم‌زمان برای آخرین موجودی نیز آزمون جداست. قالب زیبا یا پاسخ سریع صفحه محصول نمی‌تواند اشتباه موجودی و مبلغ را جبران کند؛ صحت سفارش معیار اول پذیرش است.
نظرات کاربران (۰)
هنوز نظری ثبت نشده است. اولین نفر باشید.