تیم برنامه را در یک اسپرینت کامل تست می‌کند، نسخه را منتشر می‌کند و یک هفته بعد شکایت‌ها به پشتیبانی می‌رسد: «در شهر من قیمت متفاوت است»، «نوتیفیکیشن نیامد»، «نمی‌توانم با کارت پرداخت کنم». دلیل تقریباً همیشه یکسان است: تمام تست‌ها از یک IP شرکتی انجام شده است، در حالی که کاربران واقعی از مناطق، شبکه‌ها و اپراتورهای دیگر وارد می‌شوند. در این مقاله 7 سناریو خاص QA را بررسی خواهیم کرد که به‌طور فیزیکی بدون تغییر IP آدرس قابل بررسی نیستند و نشان خواهیم داد که چگونه زیرساخت تست را با پروکسی تنظیم کنیم.
چرا IP اداری یک منطقه کور برای QA است
بیشتر برنامه‌های موبایل امروزه تصمیمات را بر اساس IP آدرس می‌گیرند: کشور کاربر، زبان رابط، ارز، روش‌های پرداخت موجود، مجموعه ویژگی‌ها و حتی قیمت اشتراک را تعیین می‌کنند. وقتی تمام بخش QA از یک دفتر با یک IP ثابت از مرکز داده یا شبکه شرکتی تست می‌کند، برنامه همیشه یک پاسخ یکسان از backend دریافت می‌کند — انگار تمام تست‌کنندگان در یک نقطه از جهان هستند.
در نتیجه، باگ‌هایی که به موقعیت جغرافیایی، ساعت در منطقه، اپراتور ارتباطی یا نوع اتصال وابسته هستند، به سادگی در ایستگاه تست بازتولید نمی‌شوند. آنها فقط در تولید ظاهر می‌شوند — زمانی که کاربر از قزاقستان قیمت‌ها را به روبل می‌بیند، کاربر آلمانی به دلیل مسدودسازی GCM در شبکه‌اش نوتیفیکیشن دریافت نمی‌کند و مشتری اندونزیایی نمی‌تواند با کارت پرداخت کند زیرا ارائه‌دهنده پرداخت برای منطقه‌اش متصل نیست. اصلاح چنین باگی پس از انتشار هزینه‌ای چند برابر بیشتر از شناسایی آن در مرحله QA دارد.
راه‌حل — شبیه‌سازی تنوع جغرافیایی و شبکه‌ای واقعی کاربران قبل از انتشار. برای این کار، مهندسان QA به‌طور فزاینده‌ای از سرورهای پروکسی استفاده می‌کنند: آنها اجازه می‌دهند که دستگاه تست یا شبیه‌ساز را به هر کشور، شهر یا حتی اپراتور ارتباطی منتقل کنند بدون اینکه نیاز به سفر فیزیکی به آنجا یا خرید ده‌ها سیم‌کارت باشد.
سناریو 1: محتوای جغرافیایی و قیمت‌های منطقه‌ای
بیشتر برنامه‌های دارای اشتراک (استریمینگ، تناسب اندام، آموزش) قیمت‌های متفاوتی را در کشورهای مختلف نشان می‌دهند — این به عنوان قیمت‌گذاری جغرافیایی شناخته می‌شود. اگر QA فقط با IP محلی فرآیند اشتراک را بررسی کند، نمی‌توان اطمینان حاصل کرد که قیمت برای کاربر از ترکیه، برزیل یا هند به درستی نمایش داده می‌شود، در ارز صحیح و با گرد کردن صحیح.
مشکل مشابهی با کاتالوگ‌های محتوایی وجود دارد: کتابخانه فیلم‌ها، محصولات یا پیشنهادات اغلب منطقه‌ای است. برای دیدن همان صفحه‌ای که کاربر واقعی می‌بیند، باید به‌طور فیزیکی در کشور مورد نظر «حضور» داشته باشید. برای چنین بررسی‌هایی، استفاده از پروکسی‌های مسکونی مناسب است — آنها IP کاربران واقعی خانگی در کشور خاصی را ارائه می‌دهند و backend برنامه درخواست را به عنوان ترافیک ارگانیک معمولی در نظر می‌گیرد، نه به عنوان درخواست از مرکز داده.
چک‌لیست عملی: سناریو اشتراک را در 8-10 بازار کلیدی (ایالات متحده، آلمان، برزیل، هند، ترکیه، ژاپن، نیجریه، امارات) اجرا می‌کنیم، اسکرین‌شات‌های قیمت و ارز را ثبت می‌کنیم و با لیست قیمت محصول مقایسه می‌کنیم. این بخش بزرگی از شکایات «چرا قیمت من متفاوت است» را پوشش می‌دهد.
سناریو 2: مسدودسازی جغرافیایی و محدودیت‌های دسترسی
برنامه‌های فین‌تک، خدمات استریمینگ و برخی بازی‌ها به دلایل قانونی یا مجوزی دسترسی از کشورهای خاص را مسدود می‌کنند. QA باید اطمینان حاصل کند که نه تنها برنامه در جایی که باید کار می‌کند، بلکه به درستی (و نه با خطا) در جایی که نباید، دسترسی را رد می‌کند.
باگ معمول: به جای صفحه مرتب «سرویس در منطقه شما در دسترس نیست»، کاربر صفحه سفید یا بارگذاری بی‌پایان می‌بیند — زیرا توسعه‌دهندگان فقط مسیر خوشحال را از کشور مجاز تست کرده‌اند. بررسی مسدودسازی‌های جغرافیایی نیاز به اتصال پیوسته از چندین حوزه ممنوعه دارد، که در سیم‌کارت‌های زنده و سفرهای کاری غیرواقعی است، اما از طریق پروکسی 10-15 دقیقه برای هر کشور طول می‌کشد.
برای این سناریو، پروکسی‌هایی با موقعیت جغرافیایی دقیق در سطح شهر، نه فقط کشور، مناسب هستند — مهم است که نه فقط «آلمان به طور کلی»، بلکه زمین‌های خاص را بررسی کنیم، اگر مجوز محدود به منطقه‌ای درون کشور باشد.
سناریو 3: A/B و رول‌اوت‌های مرحله‌ای در کشورهای مختلف
پرچم‌های ویژگی و رول‌اوت‌های تدریجی تقریباً همیشه با توجه به موقعیت جغرافیایی تنظیم می‌شوند: ویژگی جدید ابتدا در کانادا فعال می‌شود، یک هفته بعد در استرالیا، سپس در همه جا. اگر تیم QA به‌طور فیزیکی در یک کشور باشد، اصولاً نمی‌تواند نسخه جدید را قبل از سایر مناطق ببیند، تا زمانی که پرچم به او نرسد.
برای تست ویژگی قبل از انتشار جهانی، باید موقعیت جغرافیایی را به کشور اولین موج رول‌اوت تغییر دهیم. این یکی از رایج‌ترین وظایفی است که پروکسی‌ها در ترکیب با مرورگرهای ضد شناسایی یا شبیه‌سازهای دستگاه‌ها حل می‌کنند — IP را به کشور مورد نظر تغییر می‌دهیم، جلسه برنامه را دوباره راه‌اندازی می‌کنیم، ویژگی را زودتر از سایر کاربران می‌بینیم و قبل از اینکه پرچم به 100% مخاطب برسد، باگ‌ها را پیدا می‌کنیم.
نکته مهم: برای تست‌های A/B به «ثبت‌نام» پایدار IP در طول کل دوره تست نیاز است — جلسه نباید بین درخواست‌ها بین کشورها پرش کند، در غیر این صورت backend شرایط آزمایش را گیج می‌کند و گاهی گروه کنترل و گاهی گروه تست را نشان می‌دهد.
سناریو 4: محلی‌سازی و نوتیفیکیشن‌های فشاری
متن نوتیفیکیشن فشاری، زمان ارسال آن و حتی خود واقعیت تحویل اغلب به موقعیت جغرافیایی دستگاه بستگی دارد. در برخی کشورها، ارائه‌دهندگان نوتیفیکیشن (Firebase، APNs، دروازه‌های SMS محلی) با تأخیر یا از طریق مسیرهای جایگزین کار می‌کنند — و آنچه که به‌خوبی در محیط تست از دفتر در مسکو تحویل داده می‌شود، ممکن است به کاربر در اندونزی به دلیل مسدودسازی سرورهای نوتیفیکیشن خاص توسط ارائه‌دهنده محلی نرسد.
همچنین، محلی‌سازی رابط اغلب به IP وابسته است، نه فقط زبان سیستم: کاربری با زبان انگلیسی در تلفن، اما IP از فرانسه، ممکن است رابط مختلطی را ببیند — عناوین به زبان فرانسوی، دکمه‌ها به زبان انگلیسی. چنین باگ‌هایی 100% نامرئی هستند، اگر تمام QA از یک منطقه جغرافیایی تست کنند.
فرآیند پیشنهادی: 5-7 زبان محلی از بازارهای اولویت‌دار محصول را انتخاب می‌کنیم، از طریق پروکسی با IP مربوطه متصل می‌شویم، زبان سیستم را در دستگاه/شبیه‌ساز تغییر می‌دهیم و ثبت می‌کنیم که چه متنی و چه فرمت تاریخ/عدد را برنامه نشان می‌دهد. عدم تطابق IP کشور و زبان سیستم — یک مورد ضروری جداگانه است که اغلب فراموش می‌شود.
سناریو 5: روش‌های پرداخت و سیستم‌های ضد تقلب
مجموعه روش‌های پرداخت موجود در یک برنامه موبایل تقریباً همیشه به کشور بستگی دارد: در یک منطقه پرداخت با کارت و Apple Pay در دسترس است، در دیگری فقط کیف پول‌های محلی (Mercado Pago، Boleto، UPI، QIWI)، و در سومی — پرداخت از طریق اپراتور ارتباطی. اگر QA نتواند از کشور مورد نظر متصل شود، نیمی از سناریوهای پرداخت تا تولید بدون بررسی باقی می‌ماند، جایی که هزینه خطا — از دست دادن درآمد و شکایات به پشتیبانی است.
درد جداگانه — سیستم‌های ضد تقلب ارائه‌دهندگان پرداخت. آنها ریسک تراکنش را تا حدی بر اساس IP ارزیابی می‌کنند: درخواست با IP مرکز داده تقریباً مطمئناً رد خواهد شد یا نیاز به بررسی اضافی 3D-Secure خواهد داشت، حتی اگر کارت کاملاً معتبر باشد. این نتایج تست را تحریف می‌کند: QA رد پرداخت را می‌بیند و باگ را به توسعه‌دهندگان گزارش می‌دهد، در حالی که مشکل در کد نیست، بلکه در این است که IP تست به‌طور مشکوکی برای ارزیابی ضد تقلب به نظر می‌رسد.
برای سناریوهای پرداخت بهتر است از پروکسی‌های مسکونی یا پروکسی‌های موبایل استفاده کنید — آنها مانند ترافیک معمولی یک کاربر واقعی به نظر می‌رسند و باعث ایجاد هشدارهای اضافی در سیستم‌های ضد تقلب نمی‌شوند، که تصویر دقیق‌تری از رفتار جریان پرداخت ارائه می‌دهد.
سناریو 6: رفتار در شبکه‌های موبایل اپراتورها
برنامه‌ای که در Wi-Fi اداری با سرعت 200 مگابیت بر ثانیه به‌خوبی کار می‌کند، ممکن است در شبکه موبایل 3G/4G با اتصال ناپایدار، پروکسی NAT اپراتور و تأخیر بالا رفتار کاملاً متفاوتی داشته باشد. زمان‌های پاسخ، تلاش‌های مجدد، کاهش کیفیت ویدئو/صوت، کارکرد حالت آفلاین — همه اینها باید به‌طور دقیق در شرایط نزدیک به اینترنت موبایل، نه در شبکه پایدار اداری بررسی شوند.
پیچیدگی اضافی: برخی از اپراتورهای ارتباطی از پروکسی‌ها و CGNATهای خود استفاده می‌کنند، که باعث می‌شود سرور IP واقعی کاربر را نبیند، بلکه IP مشترک اپراتور را ببیند که هزاران مشترک به‌طور همزمان از آن عبور می‌کنند. این بر محدودیت نرخ و موقعیت جغرافیایی بر اساس IP تأثیر می‌گذارد — برنامه ممکن است «فکر کند» که کاربر در شهر دیگری است، در حالی که او واقعاً در آنجا نیست.
برای بازتولید چنین رفتاری، به پروکسی‌های موبایل نیاز داریم که از طریق سیم‌کارت‌های واقعی اپراتورهای کشور مورد نظر به اینترنت متصل می‌شوند — این تصویر دقیقی از NAT، تأخیرها و سرعتی را که نمی‌توان با IP معمولی مرکز داده به دست آورد، ارائه می‌دهد.
سناریو 7: محدودیت نرخ و حفاظت در برابر ربات‌ها
بسیاری از APIهای backend برنامه‌های موبایل تعداد درخواست‌ها از یک IP را محدود می‌کنند (محدودیت نرخ) و از حفاظت در برابر ربات‌ها استفاده می‌کنند، مشابه کپچا یا تحلیل رفتاری. اگر تیم QA تست‌های خودکار را با یک IP شرکتی اجرا کند، پس از مدتی سرور شروع به پاسخ دادن با خطاهای 429 یا مسدود کردن درخواست‌ها به‌طور کامل می‌کند — و تست‌ها به دلیل باگ در برنامه نمی‌افتند، بلکه به این دلیل که backend ترافیک تست را به عنوان حمله در نظر می‌گیرد.
این موضوع به‌ویژه برای تست بار و تست‌های رگرسیونی مهم است، زمانی که در مدت زمان کوتاهی باید صدها درخواست مشابه (ثبت‌نام، ورود، افزودن به سبد خرید) انجام شود. توزیع درخواست‌ها بین IPهای مختلف از طریق استخر پروکسی به‌طور منصفانه API را بارگذاری می‌کند بدون اینکه نتایج به دلیل فعال شدن حفاظت ضد تقلب تحریف شود.
برای چنین تست‌های خودکار انبوه، معمولاً بهتر است از پروکسی‌های مرکز داده استفاده کنید — آنها سریع‌تر و ارزان‌تر در حجم بالای درخواست‌ها هستند و موقعیت جغرافیایی در این سناریو به اندازه سرعت و ثبات اتصال بحرانی نیست.
ابزارها و تنظیمات پروکسی برای QA
برای QA دستی در شبیه‌سازها (شبیه‌ساز Android Studio، شبیه‌ساز Xcode) پروکسی از طریق تنظیمات شبکه سیستم شبیه‌ساز تنظیم می‌شود: IP و پورت سرور پروکسی، نام کاربری و رمز عبور را مشخص می‌کنید، اگر احراز هویت استفاده شود. برای دستگاه‌های واقعی، تنظیمات مشابه در اتصال Wi-Fi از طریق «تنظیمات پیشرفته → پروکسی → به‌صورت دستی» در دسترس است.
برای ضبط و تحلیل ترافیک بین برنامه و backend، مهندسان QA از Charles Proxy یا Proxyman استفاده می‌کنند — هر دو ابزار اجازه می‌دهند که ترافیک برنامه از طریق پروکسی خارجی عبور کند و همزمان تمام درخواست‌های HTTP/HTTPS، هدرهای موقعیت جغرافیایی و پاسخ‌های سرور را ببینند. این برای تشخیص مناسب است: بلافاصله مشخص است که کدام IP و کدام کشور «درخواست» را backend می‌بیند.
برای تست خودکار از طریق Appium یا Espresso، پروکسی در قابلیت‌های مورد نظر جلسه یا از طریق تنظیمات سیستم دستگاه قبل از اجرای مجموعه تست مشخص می‌شود. پلتفرم‌های ابری برای تست برنامه‌های موبایل (BrowserStack، Sauce Labs) همچنین از اتصال پروکسی‌های سفارشی پشتیبانی می‌کنند، که این امکان را می‌دهد که همان سناریوی تست خودکار را از کشورهای مختلف بدون دستگاه‌های فیزیکی در هر نقطه از جهان اجرا کنید.
اگر در تیم نسخه وب برنامه وجود دارد یا نیاز به تست همزمان چند حساب با موقعیت جغرافیایی متفاوت است، استفاده از مرورگرهای ضد شناسایی (Dolphin Anty، AdsPower، Multilogin) مناسب است — هر پروفایل به یک پروکسی جداگانه متصل می‌شود و مهندس QA می‌تواند 5-10 جلسه از کشورهای مختلف را به‌طور همزمان بدون سردرگمی در کوکی‌ها و کش نگه دارد.
کدام نوع پروکسی برای هر سناریو انتخاب کنیم
| سناریو QA | نوع پروکسی پیشنهادی | چرا |
|---|---|---|
| قیمت‌های جغرافیایی و محتوا | مسکونی | به عنوان ترافیک کاربر عادی به نظر می‌رسند، سیستم‌های ضد ربات را فعال نمی‌کنند |
| مسدودسازی‌های جغرافیایی | مسکونی | موقعیت جغرافیایی دقیق تا سطح شهر/منطقه |
| A/B و رول‌اوت‌ها | مسکونی / مرکز داده | جلسه پایدار در طول کل دوره تست |
| نوتیفیکیشن‌های فشاری و محلی‌سازی | موبایل | شرایط واقعی تحویل از طریق اپراتورها را شبیه‌سازی می‌کند |
| پرداخت‌ها و ضد تقلب | مسکونی / موبایل | ریسک پایین برای فعال شدن نادرست سیستم‌های ضد تقلب |
| شبکه‌های موبایل اپراتورها | موبایل | سیم‌کارت‌های واقعی اپراتورها، شبیه‌سازی دقیق NAT و تأخیرها |
| محدودیت نرخ / تست‌های بار | مرکز داده | سرعت بالا و هزینه پایین در حجم بالای درخواست‌ها |
چک‌لیست قبل از انتشار
قبل از اینکه نسخه را به تولید بفرستید، از روی یک لیست کوتاه از بررسی‌های مربوط به موقعیت جغرافیایی و شبکه عبور کنید — این بیشتر باگ‌های ذکر شده در بالا را پوشش می‌دهد:
- قیمت‌ها و ارز اشتراک حداقل در 5 بازار کلیدی محصول بررسی شده‌اند
- نمایش صحیح صفحه مسدودسازی جغرافیایی در کشورهای ممنوع بررسی شده است
- پرچم ویژگی در کشور اولین موج رول‌اوت قبل از انتشار جهانی تست شده است
- نوتیفیکیشن‌های فشاری با IP و زبان سیستم از ترکیب کشورهای مختلف بررسی شده‌اند
- روش‌های پرداخت موجود به‌طور جداگانه برای هر منطقه کلیدی بررسی شده‌اند
- جریان پرداخت بدون فعال شدن نادرست سیستم‌های ضد تقلب تست شده است
- برنامه در شرایط شبکه موبایل (3G/4G) و نه فقط Wi-Fi تست شده است
- تست‌های خودکار به دلیل محدودیت نرخ در هنگام اجرای همزمان از یک IP نمی‌افتند
نتیجه‌گیری
برنامه موبایل در ده‌ها کشور، شبکه و اکوسیستم پرداخت به‌طور همزمان زندگی می‌کند، در حالی که تیم QA به‌طور فیزیکی در یک دفتر با یک IP نشسته است. این شکاف بین مخاطب واقعی و شرایط تست، بیشتر «باگ‌های غیرقابل توضیح» را ایجاد می‌کند که به تولید می‌رسند. هفت سناریوی بالا — قیمت‌های جغرافیایی، مسدودسازی‌های جغرافیایی، رول‌اوت‌های A/B، نوتیفیکیشن‌های فشاری و محلی‌سازی، پرداخت‌ها، شبکه‌های موبایل اپراتورها و محدودیت نرخ — بخش عمده‌ای از این خطرات را پوشش می‌دهند.
اگر تیم شما برنامه‌ای را تست می‌کند که با محتوای منطقه‌ای، قیمت‌ها یا پرداخت‌ها کار می‌کند، منطقی است که پروکسی‌های مسکونی را برای شبیه‌سازی کاربران واقعی به استک تست متصل کنید و برای سناریوهای مربوط به ارتباطات موبایل و تحویل نوتیفیکیشن‌ها — پروکسی‌های موبایل با اتصال به اپراتورهای خاص. این امکان را می‌دهد که باگ‌های بحرانی را در مرحله QA پیدا کنید، نه پس از شکایات کاربران در فروشگاه‌ها.