Kiểm thử ứng dụng di động chuyên sâu (Mobile Testing nâng cao) cho Tester — dự án ShopEasy Mobile

1. Tóm tắt nhanh & ma trận yếu tố cần kiểm thử

Ở cấp nâng cao, bạn không còn dừng lại ở việc test chức năng đúng-sai như thông thường. Kiểm thử ứng dụng di động chuyên sâu đòi hỏi bạn nghĩ như một người dùng thật đang cầm điện thoại giữa đời sống: họ nhận cuộc gọi lúc đang thanh toán, họ đi từ vùng có wifi sang vùng chỉ có 4G, họ để app chạy nền rồi quên mất, điện thoại họ hết pin dở chừng, họ xoay ngang màn hình để đọc thông tin dễ hơn. Mỗi tình huống đó đều là một 'điểm gãy' tiềm ẩn nếu đội phát triển chỉ test trên emulator ổn định trong văn phòng.

2. Gián đoạn hệ thống: cuộc gọi, thông báo, báo thức

Điện thoại là thiết bị 'đa nhiệm bắt buộc': tại bất kỳ thời điểm nào, một cuộc gọi đến, một thông báo tin nhắn, một báo thức, hay một popup xin quyền của app khác đều có thể đè lên màn hình ShopEasy Mobile mà người dùng không hề chủ động. Với kiểm thử ứng dụng di động, đây là nhóm ca kiểm thử bắt buộc phải có, vì tần suất xảy ra trong đời thực rất cao — đặc biệt ở đúng lúc người dùng đang thao tác quan trọng nhất: thanh toán.

Bộ ca kiểm thử cần bao phủ ít nhất: (1) nhận cuộc gọi khi đang điền form, (2) nhận cuộc gọi ngay lúc bấm nút gửi yêu cầu, (3) nhận thông báo đẩy (push notification) của chính app hoặc app khác khi đang xem giỏ hàng, (4) báo thức hoặc lịch nhắc kích hoạt giữa lúc thanh toán. Với mỗi ca, kỳ vọng luôn là: app chuyển sang nền đúng cách (không crash), giữ nguyên toàn bộ dữ liệu người dùng đã nhập, và khi quay lại foreground phải hiển thị đúng bước đang dang dở — không tự động tiến hoặc lùi bước.

3. Chuyển mạng: wifi ↔ 4G ↔ mất mạng

Người dùng ShopEasy Mobile không đứng yên một chỗ: họ mở app ở nhà (wifi), ra đường (4G), vào thang máy hoặc hầm gửi xe (mất mạng hoàn toàn), rồi lại có mạng khi ra ngoài. Mỗi lần chuyển đổi loại kết nối là một cơ hội để lộ ra lỗi mà kiểm thử chỉ trên wifi ổn định của văn phòng không bao giờ bắt được: request bị gửi trùng, phản hồi bị mất khiến giao diện treo ở trạng thái 'đang xử lý' vô thời hạn, hoặc dữ liệu giỏ hàng bị đồng bộ sai.

Điểm mấu chốt khi thiết kế ca kiểm thử chuyển mạng là tính IDEMPOTENT — nghĩa là dù request bị gửi lại nhiều lần do mạng chập chờn, kết quả cuối cùng phải giống hệt như chỉ gửi đúng một lần. Với đơn hàng, điều này có nghĩa: bấm 'Đặt hàng' 2 lần vì tưởng lần đầu chưa thành công (do màn hình không phản hồi khi mất mạng) không được tạo ra 2 đơn hàng riêng biệt. Ngoài ra, cần test cả trường hợp mất mạng NGAY SAU khi server đã xử lý xong nhưng phản hồi chưa kịp về máy khách — client phải có cơ chế kiểm tra lại trạng thái thay vì mặc định coi là thất bại.

4. Vòng đời app: chạy nền, bị hệ điều hành kill, pin yếu

Trên di động, một app không bao giờ 'tắt hẳn' theo cách người dùng nghĩ. Khi bạn chuyển sang app khác, ShopEasy Mobile chỉ chuyển xuống 'nền' (background) và hệ điều hành có toàn quyền quyết định: giữ nguyên trong bộ nhớ, tạm dừng tiến trình, hoặc thẳng tay 'kill' tiến trình để giải phóng RAM cho app đang mở phía trước — đặc biệt phổ biến trên các máy Android tầm trung/RAM thấp. Kiểm thử ứng dụng di động nâng cao bắt buộc phải mô phỏng đủ 3 trạng thái này, không chỉ dừng ở 'mở app rồi đóng app' như kiểm thử cơ bản.

Trường hợp nguy hiểm nhất là app bị kill khi người dùng đang ở giữa luồng thanh toán, vì lúc đó dữ liệu giỏ hàng và tiến trình thanh toán thường chỉ tồn tại tạm thời trong bộ nhớ (in-memory state) nếu đội phát triển chưa lưu đúng cách xuống local storage hoặc đồng bộ server. Thêm vào đó, khi điện thoại vào 'chế độ tiết kiệm pin' (low power mode/battery saver), hệ điều hành thường giới hạn mạnh tay hoạt động nền: tắt refresh tự động, hạn chế đồng bộ, làm chậm animation — những hành vi này cần được test riêng vì chúng thay đổi cách app hoạt động một cách âm thầm mà người dùng không hề chủ động bật lên trong app.