Chiến lược test cho ứng dụng di động

Nguyên tắc phân tầng

Lỗi càng bị phát hiện muộn thì càng đắt. Một lỗi bắt được lúc viết code tốn vài phút; cũng lỗi đó lọt ra bản release có thể tốn cả một sprint vá lỗi và mất uy tín với người dùng.

Vì vậy: nhiều test nhanh ở tầng dưới, ít test chậm ở tầng trên.

Tầng	Kiểm cái gì	Tốc độ	Tỷ trọng
Unit	Logic thuần, tính toán, chuyển đổi dữ liệu	Mili giây	Khoảng 70%
Integration	Kết nối giữa các thành phần, gọi mạng, lưu trữ cục bộ	Giây	Khoảng 20%
E2E	Vài luồng sống còn trên máy thật	Phút	Khoảng 10%

Tỷ lệ là định hướng, không phải chỉ tiêu phải đạt.

Luồng bắt buộc phải có E2E test

Chọn ít, giữ cho chúng luôn xanh. Đề xuất:

1. Mở ứng dụng lần đầu tới màn hình chính
2. Đăng nhập và đăng xuất
3. Luồng nghiệp vụ chính tạo ra giá trị của sản phẩm
4. Hành vi khi mất mạng giữa chừng

E2E test hay chập chờn. Một bài test lúc xanh lúc đỏ còn tệ hơn không có, vì nó dạy cả đội thói quen bỏ qua tín hiệu đỏ. Chập chờn thì sửa ngay hoặc gỡ ra, không để lửng lơ.

Những thứ dễ bị bỏ sót trên di động

• Xoay ngang màn hình và thay đổi kích thước cửa sổ
• Hệ điều hành thu hồi ứng dụng đang chạy nền rồi khôi phục lại
• Quyền truy cập bị từ chối, hoặc bị thu hồi sau khi đã cấp
• Cỡ chữ hệ thống đặt ở mức rất lớn
• Pin yếu, chế độ tiết kiệm pin bật
• Mạng chậm chứ không đứt hẳn — trường hợp khó chịu hơn mất mạng hoàn toàn
• Nâng cấp từ phiên bản cũ với dữ liệu cũ còn nằm trên máy

Mục cuối là nguồn lỗi bị xem nhẹ nhiều nhất. Luôn thử kịch bản nâng cấp, đừng chỉ thử cài mới.

Đo coverage cho đúng

Coverage là tín hiệu, không phải mục tiêu. Coverage thấp ở phần logic quan trọng là đáng lo thật. Nhưng ép coverage lên 90% bằng những bài test không khẳng định điều gì thì chỉ tạo ra ảo giác an toàn kèm chi phí bảo trì.