Nhóm kiểm tra ứng dụng trong suốt một sprint, phát hành bản dựng — và sau một tuần, bộ phận hỗ trợ nhận được hàng loạt khiếu nại: “giá ở thành phố tôi khác”, “thông báo đẩy không đến”, “không thể thanh toán bằng thẻ”. Nguyên nhân gần như luôn giống nhau: tất cả các bài kiểm tra đều được thực hiện từ một IP doanh nghiệp, trong khi người dùng thực tế truy cập từ các khu vực, mạng và nhà mạng khác nhau. Trong bài viết này, chúng ta sẽ phân tích 7 kịch bản QA cụ thể mà về mặt vật lý không thể kiểm tra mà không thay đổi địa chỉ IP, và chỉ cho bạn cách thiết lập hạ tầng kiểm tra với proxy.
Tại sao IP văn phòng là vùng mù trong QA
Hầu hết các ứng dụng di động ngày nay đưa ra quyết định dựa trên địa chỉ IP: xác định quốc gia của người dùng, ngôn ngữ giao diện, tiền tệ, các phương thức thanh toán có sẵn, bộ tính năng và thậm chí là giá thuê bao. Khi toàn bộ bộ phận QA kiểm tra từ một văn phòng với một IP tĩnh từ trung tâm dữ liệu hoặc mạng doanh nghiệp, ứng dụng luôn nhận được cùng một phản hồi từ backend — như thể tất cả các tester đều ở cùng một điểm trên thế giới.
Kết quả là các lỗi phụ thuộc vào định vị địa lý, giờ trong múi giờ, nhà mạng hoặc loại kết nối, đơn giản là không được tái hiện trên môi trường kiểm tra. Chúng chỉ xuất hiện trong sản xuất — khi người dùng từ Kazakhstan thấy giá bằng rúp, người dùng Đức không nhận được thông báo đẩy do bị chặn GCM trong mạng của họ, và khách hàng Indonesia không thể thanh toán bằng thẻ vì nhà cung cấp thanh toán cho khu vực của họ chưa được kết nối. Việc sửa lỗi như vậy sau khi phát hành tốn kém gấp nhiều lần so với việc phát hiện nó ở giai đoạn QA.
Giải pháp là mô phỏng sự đa dạng địa lý và mạng thực tế của người dùng ngay cả trước khi phát hành. Để làm điều này, các kỹ sư QA ngày càng sử dụng các máy chủ proxy: chúng cho phép “di chuyển” thiết bị kiểm tra hoặc trình giả lập đến bất kỳ quốc gia, thành phố hoặc thậm chí nhà mạng nào mà không cần phải đến đó hoặc mua hàng chục SIM.
Kịch bản 1: Nội dung địa lý và giá cả khu vực
Hầu hết các ứng dụng có thuê bao (streaming, thể dục, giáo dục) hiển thị giá khác nhau ở các quốc gia khác nhau — điều này được gọi là định giá địa lý. Nếu QA kiểm tra việc đăng ký thuê bao chỉ từ IP địa phương, không thể đảm bảo rằng giá cho người dùng từ Thổ Nhĩ Kỳ, Brazil hoặc Ấn Độ được hiển thị chính xác, bằng tiền tệ đúng và với cách làm tròn đúng.
Vấn đề tương tự với các danh mục nội dung: thư viện phim, sản phẩm hoặc khuyến mãi thường mang tính khu vực. Cần phải “xuất hiện” vật lý tại quốc gia cần thiết để thấy cùng một màn hình mà người dùng thực tế nhìn thấy. Đối với những kiểm tra như vậy, việc sử dụng proxy dân cư là rất tiện lợi — chúng cung cấp IP của người dùng thực tế tại quốc gia cụ thể, và backend của ứng dụng coi yêu cầu như lưu lượng tự nhiên thông thường, chứ không phải như một yêu cầu từ trung tâm dữ liệu.
Kiểm tra thực tế: chạy kịch bản đăng ký thuê bao trên 8-10 thị trường chính (Mỹ, Đức, Brazil, Ấn Độ, Thổ Nhĩ Kỳ, Nhật Bản, Nigeria, UAE), ghi lại ảnh chụp màn hình giá và tiền tệ, đối chiếu với bảng giá sản phẩm. Điều này giải quyết phần lớn các khiếu nại kiểu “tại sao tôi có giá khác”.
Kịch bản 2: Khóa địa lý và hạn chế truy cập
Các ứng dụng fintech, dịch vụ streaming và một số trò chơi chặn truy cập từ một số quốc gia vì lý do pháp lý hoặc cấp phép. QA phải đảm bảo không chỉ rằng ứng dụng hoạt động ở nơi nó nên hoạt động, mà còn rằng nó từ chối truy cập một cách chính xác (và không bị lỗi) ở những nơi không nên.
Lỗi điển hình: thay vì màn hình gọn gàng “dịch vụ không khả dụng ở khu vực của bạn”, người dùng thấy màn hình trắng hoặc vòng tải vô tận — vì các nhà phát triển chỉ kiểm tra con đường hạnh phúc từ quốc gia được phép. Kiểm tra khóa địa lý yêu cầu kết nối liên tiếp từ một số khu vực bị cấm, điều này là không thực tế với SIM sống và các chuyến công tác, trong khi qua proxy chỉ mất 10-15 phút cho mỗi quốc gia.
Đối với kịch bản này, các proxy với định vị chính xác ở cấp độ thành phố, chứ không chỉ quốc gia — điều quan trọng là kiểm tra không phải “Đức nói chung”, mà là các bang cụ thể, nếu giấy phép bị hạn chế trong khu vực trong nước.
Kịch bản 3: A/B và triển khai từng bước theo quốc gia
Các cờ tính năng và triển khai từng bước gần như luôn được thiết lập với sự liên kết đến định vị địa lý: tính năng mới đầu tiên được bật ở Canada, sau một tuần — ở Úc, rồi — ở khắp mọi nơi. Nếu đội QA thực sự ở trong một quốc gia, họ về cơ bản không thể thấy phiên bản mới trước các khu vực khác, cho đến khi cờ đến được với họ.
Để kiểm tra tính năng trước khi phát hành toàn cầu, cần phải thay đổi định vị địa lý sang quốc gia của làn sóng triển khai đầu tiên. Đây là một trong những nhiệm vụ thường xuyên nhất mà proxy giải quyết kết hợp với trình duyệt chống phát hiện hoặc trình giả lập thiết bị — chúng ta thay đổi IP sang quốc gia cần thiết, khởi động lại phiên ứng dụng, thấy tính năng trước các người dùng khác và kịp thời tìm ra lỗi trước khi cờ đến 100% khán giả.
Một điểm quan trọng: đối với các thử nghiệm A/B, cần có “đăng ký” IP ổn định trong suốt chu kỳ kiểm tra — phiên không nên nhảy giữa các quốc gia giữa các yêu cầu, nếu không backend sẽ nhầm lẫn điều kiện của thí nghiệm và hiển thị nhóm kiểm soát hoặc nhóm thử nghiệm.
Kịch bản 4: Địa phương hóa và thông báo đẩy
Văn bản thông báo đẩy, thời gian gửi và thậm chí cả việc giao hàng thường phụ thuộc vào định vị địa lý của thiết bị. Ở một số quốc gia, các nhà cung cấp thông báo đẩy (Firebase, APNs, cổng SMS địa phương) hoạt động với độ trễ hoặc qua các tuyến đường thay thế — và điều mà hoàn toàn được giao trong môi trường kiểm tra từ văn phòng ở Moscow có thể không đến được người dùng ở Indonesia do bị chặn các máy chủ thông báo đẩy cụ thể bởi nhà cung cấp dịch vụ viễn thông địa phương.
Ngoài ra, việc địa phương hóa giao diện thường được kích hoạt chính xác qua IP, chứ không chỉ qua ngôn ngữ hệ thống: người dùng có ngôn ngữ tiếng Anh trên điện thoại nhưng IP từ Pháp có thể thấy giao diện hỗn hợp — tiêu đề bằng tiếng Pháp, nút bằng tiếng Anh. Những lỗi như vậy hoàn toàn không thể nhìn thấy nếu toàn bộ QA kiểm tra từ một khu vực địa lý.
Quy trình được khuyến nghị: lấy 5-7 ngôn ngữ từ các thị trường ưu tiên của sản phẩm, kết nối qua proxy với IP tương ứng, thay đổi ngôn ngữ hệ thống trên thiết bị/trình giả lập và ghi lại văn bản và định dạng ngày/số mà ứng dụng hiển thị. Sự không khớp giữa IP quốc gia và ngôn ngữ hệ thống là một trường hợp bắt buộc riêng biệt, thường bị bỏ qua.
Kịch bản 5: Phương thức thanh toán và hệ thống chống gian lận
Bộ phương thức thanh toán có sẵn trong ứng dụng di động gần như luôn phụ thuộc vào quốc gia: ở một khu vực, thanh toán bằng thẻ và Apple Pay có sẵn, ở khu vực khác — chỉ có ví địa phương (Mercado Pago, Boleto, UPI, QIWI), ở khu vực thứ ba — thanh toán qua nhà mạng. Nếu QA không thể kết nối từ quốc gia cần thiết, một nửa các kịch bản thanh toán sẽ không được kiểm tra cho đến khi sản xuất, nơi giá của lỗi — doanh thu bị mất và khiếu nại đến bộ phận hỗ trợ.
Một nỗi đau riêng biệt — các hệ thống chống gian lận của các nhà cung cấp thanh toán. Chúng đánh giá rủi ro giao dịch một phần dựa trên IP: yêu cầu từ IP trung tâm dữ liệu gần như chắc chắn sẽ bị từ chối hoặc yêu cầu kiểm tra 3D-Secure bổ sung, ngay cả khi thẻ hoàn toàn hợp lệ. Điều này làm sai lệch kết quả kiểm tra: QA thấy từ chối thanh toán và báo cáo lỗi cho các nhà phát triển, trong khi vấn đề không nằm ở mã mà ở việc IP kiểm tra trông nghi ngờ đối với việc đánh giá chống gian lận.
Đối với các kịch bản thanh toán, tốt hơn nên sử dụng proxy dân cư hoặc proxy di động — chúng trông giống như lưu lượng của người dùng thực tế và không kích hoạt các cảnh báo không cần thiết từ hệ thống chống gian lận, điều này mang lại bức tranh chính xác hơn về hành vi của luồng thanh toán.
Kịch bản 6: Hành vi trong mạng di động của nhà mạng
Ứng dụng hoạt động hoàn hảo trên Wi-Fi văn phòng với tốc độ 200 Mbit/s có thể hoạt động hoàn toàn khác trong mạng di động 3G/4G với kết nối không ổn định, proxy NAT của nhà mạng và độ trễ cao. Thời gian chờ yêu cầu, thử lại, suy giảm chất lượng video/audio, hoạt động chế độ ngoại tuyến — tất cả đều cần được kiểm tra chính xác trong điều kiện gần giống như internet di động, chứ không phải trong mạng văn phòng ổn định.
Sự phức tạp thêm: một số nhà mạng áp dụng các proxy và CGNAT riêng, khiến máy chủ không thấy IP thực của người dùng mà là IP chung của nhà mạng, qua đó hàng ngàn thuê bao đi qua cùng một lúc. Điều này ảnh hưởng đến giới hạn tỷ lệ và định vị địa lý qua IP — ứng dụng có thể “nghĩ” rằng người dùng đang ở một thành phố khác so với vị trí thực tế.
Để tái hiện hành vi như vậy, cần có các proxy di động, kết nối internet qua các SIM thực của các nhà mạng trong quốc gia cần thiết — điều này cung cấp bức tranh chính xác về NAT, độ trễ và tốc độ mà không thể đạt được trên IP trung tâm dữ liệu thông thường.
Kịch bản 7: Giới hạn tỷ lệ và bảo vệ chống bot
Nhiều API backend của ứng dụng di động giới hạn số lượng yêu cầu từ một IP (giới hạn tỷ lệ) và sử dụng bảo vệ chống bot, tương tự như captcha hoặc phân tích hành vi. Nếu đội QA chạy các bài kiểm tra tự động từ một IP doanh nghiệp, sau một thời gian, máy chủ bắt đầu phản hồi lỗi 429 hoặc chặn hoàn toàn các yêu cầu — và các bài kiểm tra không thất bại do lỗi trong ứng dụng, mà do backend coi lưu lượng kiểm tra là một cuộc tấn công.
Điều này đặc biệt quan trọng đối với kiểm tra tải và kiểm tra hồi quy, khi trong thời gian ngắn cần thực hiện hàng trăm yêu cầu giống nhau (đăng ký, đăng nhập, thêm vào giỏ hàng). Phân phối các yêu cầu giữa các IP khác nhau qua một nhóm proxy cho phép tải công bằng API mà không làm sai lệch kết quả do kích hoạt bảo vệ chống gian lận.
Đối với việc kiểm tra tự động hàng loạt như vậy, thường có lợi hơn khi sử dụng proxy trung tâm dữ liệu — chúng nhanh hơn và rẻ hơn khi có khối lượng yêu cầu lớn, và định vị địa lý trong kịch bản này không quan trọng bằng tốc độ và độ ổn định của kết nối.
Công cụ và cấu hình proxy cho QA
Đối với QA thủ công trên các trình giả lập (Android Studio Emulator, Xcode Simulator), proxy được cấu hình qua cài đặt mạng hệ thống của trình giả lập: chỉ định IP và cổng của máy chủ proxy, tên đăng nhập và mật khẩu, nếu có xác thực. Đối với các thiết bị thực, các cài đặt tương tự có sẵn trong kết nối Wi-Fi qua “Cài đặt nâng cao → Proxy → Thủ công”.
Để chặn và phân tích lưu lượng giữa ứng dụng và backend, các kỹ sư QA sử dụng Charles Proxy hoặc Proxyman — cả hai công cụ cho phép chuyển lưu lượng của ứng dụng qua proxy bên ngoài và đồng thời xem tất cả các yêu cầu HTTP/HTTPS, tiêu đề định vị địa lý và phản hồi từ máy chủ. Điều này rất tiện lợi cho việc chẩn đoán: ngay lập tức thấy được IP nào và quốc gia nào mà backend “thấy” vào thời điểm yêu cầu.
Đối với kiểm tra tự động qua Appium hoặc Espresso, proxy được chỉ định trong các khả năng mong muốn của phiên hoặc qua cài đặt hệ thống của thiết bị trước khi khởi động bộ kiểm tra. Các nền tảng đám mây để kiểm tra ứng dụng di động (BrowserStack, Sauce Labs) cũng hỗ trợ kết nối proxy tùy chỉnh, cho phép chạy cùng một kịch bản kiểm tra tự động từ nhiều quốc gia mà không cần thiết bị thực ở mỗi điểm trên thế giới.
Nếu trong đội có phiên bản web của ứng dụng hoặc cần kiểm tra song song nhiều tài khoản với định vị địa lý khác nhau, việc sử dụng các trình duyệt chống phát hiện (Dolphin Anty, AdsPower, Multilogin) là rất tiện lợi — mỗi hồ sơ được gán với một proxy riêng biệt, và kỹ sư QA có thể giữ mở 5-10 phiên từ các quốc gia khác nhau cùng một lúc mà không bị nhầm lẫn trong cookie và bộ nhớ cache.
Loại proxy nào nên chọn cho từng kịch bản
| Kịch bản QA | Loại proxy được khuyến nghị | Tại sao |
|---|---|---|
| Giá địa lý và nội dung | Dân cư | Trông giống như lưu lượng của người dùng thông thường, không kích hoạt bảo vệ chống bot |
| Khóa địa lý | Dân cư | Định vị chính xác đến thành phố/khu vực |
| A/B và triển khai | Dân cư / trung tâm dữ liệu | Phiên ổn định trong toàn bộ chu kỳ kiểm tra |
| Thông báo đẩy và địa phương hóa | Di động | Tái hiện điều kiện giao hàng thực tế qua các nhà mạng |
| Thanh toán và chống gian lận | Dân cư / di động | Rủi ro thấp về việc kích hoạt sai hệ thống chống gian lận |
| Mạng di động của nhà mạng | Di động | SIM thực của các nhà mạng, mô phỏng chính xác NAT và độ trễ |
| Giới hạn tỷ lệ / kiểm tra tải | Trung tâm dữ liệu | Tốc độ cao và chi phí thấp cho khối lượng yêu cầu lớn |
Danh sách kiểm tra trước khi phát hành
Trước khi phát hành bản dựng vào sản xuất, hãy kiểm tra qua danh sách ngắn các kiểm tra liên quan đến định vị địa lý và mạng — điều này giải quyết phần lớn các lỗi đã được mô tả ở trên:
- Đã kiểm tra giá và tiền tệ thuê bao tối thiểu ở 5 thị trường chính của sản phẩm
- Đã kiểm tra hiển thị chính xác của màn hình khóa địa lý ở các quốc gia bị cấm
- Cờ tính năng đã được kiểm tra ở quốc gia làn sóng triển khai đầu tiên trước khi phát hành toàn cầu
- Thông báo đẩy đã được kiểm tra với IP và ngôn ngữ hệ thống từ các kết hợp quốc gia khác nhau
- Các phương thức thanh toán có sẵn đã được kiểm tra cho từng khu vực chính riêng biệt
- Luồng thanh toán đã được kiểm tra mà không có kích hoạt sai hệ thống chống gian lận
- Ứng dụng đã được kiểm tra trong điều kiện mạng di động (3G/4G), chứ không chỉ Wi-Fi
- Các bài kiểm tra tự động không bị rớt do giới hạn tỷ lệ khi chạy song song từ một IP
Kết luận
Ứng dụng di động hoạt động ở hàng chục quốc gia, mạng và hệ sinh thái thanh toán cùng một lúc, trong khi đội QA thực sự ngồi trong một văn phòng với một IP. Chính sự ngắt quãng này giữa khán giả thực tế và điều kiện kiểm tra đã tạo ra phần lớn các lỗi “khó hiểu” mà đến sản xuất. Bảy kịch bản ở trên — giá địa lý, khóa địa lý, triển khai A/B, thông báo đẩy và địa phương hóa, thanh toán, mạng di động của nhà mạng và giới hạn tỷ lệ — giải quyết phần lớn các rủi ro như vậy.
Nếu đội của bạn kiểm tra một ứng dụng hoạt động với nội dung, giá cả hoặc thanh toán khu vực, hợp lý để kết nối vào ngăn xếp kiểm tra proxy dân cư để mô phỏng người dùng thực tế, và cho các kịch bản với mạng di động và giao hàng thông báo đẩy — proxy di động với liên kết đến các nhà mạng cụ thể. Điều này cho phép tìm ra các lỗi nghiêm trọng ở giai đoạn QA, chứ không phải sau khi nhận được khiếu nại từ người dùng trong các cửa hàng.