Chọn công cụ kiểm thử tự động Android theo ranh giới: Appium, UI Automator hay Espresso?

Câu hỏi “công cụ tự động hóa Android nào tốt nhất?” thường xuất hiện quá sớm. Trước khi so sánh Appium, UI Automator, Espresso hay Compose Testing, nhóm phát triển cần xác định một điều quan trọng hơn: bài kiểm thử phải chứng minh điều gì và phải đi qua ranh giới phần mềm nào?

Bài viết này trình bày một mô hình chọn công cụ theo bốn ranh giới thay vì cố tìm một “người thắng tuyệt đối”.

1. Giao diện thuộc ứng dụng: bắt đầu với Compose Testing hoặc Espresso

Khi nhóm sở hữu mã nguồn và yêu cầu nằm hoàn toàn trong ứng dụng, Compose Testing hoặc Espresso thường là điểm khởi đầu hợp lý nhất.

Ví dụ:

• nút Gửi chỉ được bật khi dữ liệu hợp lệ;
• thông báo lỗi xuất hiện sau khi người dùng nhập sai;
• tab được chọn có đúng trạng thái;
• thao tác nhấn chuyển đến đúng màn hình;
• một component hiển thị đúng dữ liệu giả lập đã kiểm soát.

Với Jetpack Compose, API kiểm thử có thể tìm node qua semantics, thực hiện hành động và xác minh thuộc tính. Với giao diện View, Espresso cung cấp matcher, action và assertion. Nhóm có thể dùng dữ liệu giả, cô lập component và nhận lỗi có nguyên nhân rõ ràng hơn việc chỉ nhìn vào pixel.

Không nên mở rộng một bài kiểm thử nội bộ thành luồng toàn thiết bị nếu yêu cầu chưa đi ra ngoài ứng dụng. Hộp thoại quyền, màn hình Settings, launcher hoặc thông báo thuộc một ranh giới khác.

2. Giao diện hệ thống và luồng liên ứng dụng: dùng UI Automator

UI Automator phù hợp khi chính thiết bị Android là một phần của kịch bản.

API UI Automator có thể khởi chạy ứng dụng, tìm phần tử bằng điều kiện, xử lý hộp thoại quyền, kiểm tra nhiều cửa sổ và chụp ảnh màn hình. Vì vậy, nó phù hợp cho:

• cấp hoặc từ chối quyền lúc chạy;
• mở Android Settings rồi quay lại ứng dụng;
• kiểm tra picture-in-picture hoặc chia đôi màn hình;
• chuyển giữa hai ứng dụng đã cài;
• luồng end-to-end có launcher hoặc giao diện hệ thống.

Nên giữ lớp này mỏng. Nếu 30 yêu cầu có thể được chứng minh bằng kiểm thử component và chỉ 2 yêu cầu thực sự đi qua giao diện hệ thống, chỉ 2 yêu cầu đó cần chi phí của UI Automator.

3. Lớp WebDriver cho mobile: chọn Appium khi kiến trúc driver có giá trị thật

Appium phù hợp khi tổ chức cần mô hình máy chủ tự động hóa cho cả Android và iOS, muốn sử dụng JavaScript, Java, Python, Ruby hoặc .NET, hoặc đã có hạ tầng và cách tổ chức test theo WebDriver.

Trên Android, Appium thường làm việc thông qua UiAutomator2 driver. Môi trường đầy đủ không chỉ có mã test. Nó còn gồm Appium server, driver nền tảng, Android SDK và platform tools, JDK tương thích, thiết bị hoặc emulator đã cấu hình, capability và thư viện client.

Nhóm phải sở hữu rõ phiên bản server và driver, cách reset thiết bị, dữ liệu kiểm thử, log và cấu hình CI. Chọn Appium khi client đa ngôn ngữ, kiến trúc driver hoặc tính nhất quán đa nền tảng chính là lợi ích cần thiết; không cần chuyển mọi bài test nội bộ sang lớp này.

4. Quy trình hộp đen trên điện thoại thật: thêm lớp flow trực quan

Có những yêu cầu không thuộc kiểm thử component và cũng không cần trở thành một bộ regression chặn build.

Nhân viên hỗ trợ có thể cần tái hiện lỗi trên điện thoại thật. QA có thể cần ảnh chụp và OCR sau khi triển khai, hoặc quy trình phải đi qua ứng dụng bên thứ ba không có mã nguồn.

Trong các tình huống đó, một flow trực quan có thể bổ sung cho các framework viết bằng mã.

Một flow tốt không chỉ phát lại tọa độ. Nó xác định trạng thái bằng cây UI, OCR hoặc template đã kiểm chứng, chỉ cho phép hành động đã xét duyệt và dừng kèm bằng chứng khi màn hình không xác định.

Ví dụ, LaiCai Flow cho tự động hóa Android có thể kết hợp phân tích UI, OCR, template matching, ảnh chụp màn hình, nhánh điều kiện, vòng lặp có giới hạn và hành vi dừng rõ ràng. Người không trực tiếp chỉnh sửa mã test vẫn có thể đọc và xem lại đường đi của quyết định.

Lớp này không thay thế unit test, Compose assertion hay Espresso. Giá trị của nó nằm ở trạng thái trực quan trên thiết bị thật và gói bằng chứng mà con người có thể đánh giá.

Một yêu cầu, một nơi chịu trách nhiệm assertion chính

Cách nhanh nhất để làm bộ test vừa chậm vừa khó bảo trì là sao chép cùng một hành trình vào mọi công cụ.

Thay vào đó, nên gán một nơi chịu trách nhiệm chính cho mỗi yêu cầu:

Các lớp có thể đề cập cùng một hành trình người dùng nhưng không cần lặp lại mọi assertion. Chẳng hạn, một luồng checkout có thể dùng component test cho validation, một test UI Automator cho hộp thoại quyền, một hợp đồng Appium nhỏ dùng chung với iOS và một kiểm tra trên điện thoại thật để lưu bằng chứng sau khi phát hành.

Checklist trước khi thêm framework mới

Hãy thử một kịch bản đại diện và ghi lại toàn bộ bề mặt bảo trì:

1. Trạng thái bắt đầu được đặt tên là gì?
2. Bằng chứng cần thiết là semantic, trực quan, cấp hệ thống hay đa nền tảng?
3. Bài test có cần truy cập mã nguồn ứng dụng không?
4. Phiên bản server, SDK, driver, thiết bị, asset và dữ liệu nào phải được kiểm soát?
5. Điều kiện nào thay thế việc chờ bằng thời gian cố định?
6. Khi màn hình không xác định, bài test dừng như thế nào?
7. Ảnh chụp, log, cây UI, kết quả OCR hoặc assertion nào giải thích lỗi?
8. Ai cập nhật bài test khi ứng dụng, Android hoặc thiết bị thay đổi?

Nếu framework mới không tạo ra bằng chứng cần thiết mà lớp hiện tại không thể tạo hiệu quả, không nên thêm nó.

Bạn có thể xem ma trận chi tiết trong bài so sánh công cụ kiểm thử tự động Android. Nếu nhu cầu chính là workflow quan sát được trên điện thoại thật, hãy xem thêm trang công cụ AI tự động hóa Android và hướng dẫn kiểm thử trực quan Android với OCR và hình ảnh.

Chiến lược tốt nhất không phải là chọn một công cụ cho mọi việc. Đó là phân chia trách nhiệm rõ ràng và dùng ranh giới nhỏ nhất có thể tạo ra bằng chứng đáng tin cậy cho từng yêu cầu.