Tự động hoá quy trình kiểm thử giao diện người dùng

Việc kiểm thử hoạt động tương tác của người dùng giúp đảm bảo người dùng không gặp phải các kết quả không mong muốn hoặc có trải nghiệm không tốt khi tương tác với ứng dụng. Bạn nên hình thành thói quen tạo các bài kiểm thử giao diện người dùng (UI) nếu cần xác minh rằng giao diện người dùng của ứng dụng đang hoạt động chính xác.

Một phương pháp kiểm thử giao diện người dùng đơn giản là yêu cầu nhân viên kiểm thử thực hiện một nhóm thao tác của người dùng trên ứng dụng mục tiêu và xác minh rằng ứng dụng đó đang hoạt động chính xác. Tuy nhiên, phương pháp thủ công này có thể tốn thời gian và dễ xảy ra lỗi. Một phương pháp hiệu quả hơn là viết các bài kiểm thử giao diện người dùng sao cho các hành động của người dùng được thực hiện theo cách tự động. Phương pháp tự động này cho phép bạn chạy kiểm thử một cách nhanh chóng và đáng tin cậy theo cách có thể lặp lại.

Các bài kiểm thử giao diện người dùng khởi chạy một ứng dụng (hoặc một phần ứng dụng), sau đó mô phỏng các hoạt động tương tác của người dùng và cuối cùng là kiểm tra để đảm bảo ứng dụng đó đã phản ứng đúng cách. Đây là các chương trình kiểm thử tích hợp, có thể từ việc xác minh hành vi của một thành phần nhỏ đến kiểm thử điều hướng lớn truyền tải toàn bộ luồng người dùng. Các tệp này rất hữu ích trong việc kiểm tra mức hồi quy cũng như xác minh khả năng tương thích với nhiều cấp độ API và thiết bị thực.

Kiểm thử giao diện người dùng được đo lường trong Android Studio

Để chạy kiểm thử giao diện người dùng được đo lường bằng Android Studio, bạn cần triển khai mã kiểm thử trong một thư mục kiểm thử Android riêng – src/androidTest/java. Trình bổ trợ Android cho Gradle sẽ tạo một ứng dụng kiểm thử dựa trên mã kiểm thử của bạn, sau đó tải ứng dụng kiểm thử đó trên cùng một thiết bị với ứng dụng mục tiêu. Trong mã kiểm thử, bạn có thể sử dụng khung kiểm thử giao diện người dùng để mô phỏng hoạt động tương tác của người dùng trên ứng dụng mục tiêu, nhằm thực hiện các tác vụ kiểm thử bao gồm những tình huống sử dụng cụ thể.

Khung Jetpack

Jetpack có nhiều khung cung cấp API để viết kiểm thử giao diện người dùng:

  • Khung kiểm thử Espresso (Android 4.0.1, API cấp 14 trở lên) cung cấp các API để viết quy trình kiểm thử giao diện người dùng nhằm mô phỏng hoạt động tương tác của người dùng với Khung hiển thị trong một ứng dụng đích duy nhất. Lợi ích chính khi sử dụng Espresso là tự động đồng bộ hoá các thao tác kiểm thử với giao diện người dùng của ứng dụng mà bạn đang kiểm thử. Espresso phát hiện thời điểm luồng chính ở trạng thái rảnh, nhờ đó, Espresso có thể chạy các lệnh kiểm thử vào thời điểm thích hợp, từ đó cải thiện độ tin cậy của hoạt động kiểm thử.
  • Jetpack Compose (Android 5.0, API cấp 21 trở lên) cung cấp một tập hợp API kiểm thử để khởi chạy và tương tác với các màn hình cũng như thành phần Compose. Các hoạt động tương tác với các phần tử Compose được đồng bộ hoá với các bài kiểm thử và có toàn quyền kiểm soát thời gian, các ảnh động và các thành phần kết hợp lại.
  • UI Automator (Android 4.3, API cấp 18 trở lên) là một khung kiểm thử giao diện người dùng phù hợp để kiểm thử chức năng giao diện người dùng trên nhiều ứng dụng trên hệ thống và các ứng dụng cần cài đặt. API Automator của giao diện người dùng cho phép bạn thực hiện các thao tác như mở trình đơn Cài đặt hoặc trình chạy ứng dụng trên thiết bị kiểm thử.
  • Robolectric (Android 4.1, API cấp 16 trở lên) cho phép bạn tạo chương trình kiểm thử cục bộ chạy trên máy trạm hoặc môi trường tích hợp liên tục trong JVM thông thường, thay vì trên trình mô phỏng hoặc thiết bị. Có thể sử dụng các API kiểm thử Espresso hoặc Compose để tương tác với các thành phần giao diện người dùng.

Tính linh hoạt và tính đồng bộ

Tính chất không đồng bộ của các ứng dụng và khung dành cho thiết bị di động thường khiến việc viết các chương trình kiểm thử đáng tin cậy và có thể lặp lại trở nên khó khăn. Khi một sự kiện người dùng được chèn, khung kiểm thử phải đợi ứng dụng phản ứng xong với sự kiện đó, có thể từ việc thay đổi một số văn bản trên màn hình đến việc tái tạo hoàn toàn một hoạt động. Khi không có hành vi xác định, kiểm thử sẽ không ổn định.

Các khung hiện đại như Compose hoặc Espresso được thiết kế có lưu ý đến việc kiểm thử, vì vậy, việc đảm bảo rằng giao diện người dùng sẽ ở trạng thái rảnh trước khi hành động kiểm thử hoặc câu nhận định tiếp theo diễn ra. Đây là quá trình đồng bộ hoá.

Kiểm thử quá trình đồng bộ hoá

Các vấn đề vẫn có thể phát sinh khi bạn chạy các hoạt động không đồng bộ hoặc chạy ở chế độ nền mà chương trình kiểm thử không xác định được, chẳng hạn như tải dữ liệu từ một cơ sở dữ liệu hoặc hiển thị ảnh động vô hạn.

sơ đồ quy trình cho thấy một vòng lặp kiểm tra xem ứng dụng có đang rảnh hay không trước khi vượt qua bài kiểm thử
Hình 1: Đồng bộ hoá kiểm thử.

Để tăng độ tin cậy của bộ kiểm thử, bạn có thể cài đặt một cách theo dõi hoạt động ở chế độ nền, chẳng hạn như Espresso Idling Resources (Tài nguyên idling Espresso). Ngoài ra, bạn có thể thay thế mô-đun cho các phiên bản kiểm thử mà bạn có thể truy vấn để kiểm tra trạng thái rảnh hoặc cải thiện tính năng đồng bộ hoá, chẳng hạn như TestDispatcher cho coroutine hoặc RxIdler cho RxJava.

Sơ đồ cho thấy một lần kiểm thử không thành công khi quá trình đồng bộ hoá dựa trên việc chờ một thời gian cố định
Hình 2: Việc sử dụng giấc ngủ trong kiểm thử sẽ dẫn đến việc kiểm thử chậm hoặc không ổn định.

Cấu trúc và thiết lập kiểm thử

Cấu trúc của ứng dụng phải cho phép hoạt động kiểm thử thay thế các phần của ứng dụng để kiểm thử gấp đôi. Bạn nên sử dụng các thư viện cung cấp tiện ích để hỗ trợ kiểm thử. Ví dụ: bạn có thể thay thế mô-đun kho lưu trữ dữ liệu bằng một phiên bản trong bộ nhớ của mô-đun đó, phiên bản đó cung cấp dữ liệu giả, tất định cho kiểm thử.

Sơ đồ cấu trúc sản xuất và kiểm thử. Sơ đồ sản xuất cho thấy các nguồn dữ liệu cục bộ và từ xa cung cấp dữ liệu cho kho lưu trữ, sau đó cung cấp dữ liệu không đồng bộ cho giao diện người dùng. Sơ đồ kiểm thử cho thấy một kho lưu trữ giả mạo cung cấp dữ liệu đồng bộ cho giao diện người dùng.
Hình 3: Kiểm thử giao diện người dùng bằng cách thay thế các phần phụ thuộc của giao diện đó bằng các phần phụ thuộc giả mạo.

Phương pháp đề xuất để bật chức năng này là sử dụng tính năng chèn phần phụ thuộc. Bạn có thể tạo hệ thống của riêng mình theo cách thủ công nhưng bạn nên sử dụng khung DI như Hilt để khắc phục vấn đề này.

Tại sao bạn nên thử nghiệm tự động?

Một ứng dụng Android có thể nhắm đến hàng nghìn thiết bị ở nhiều cấp độ API và kiểu dáng. Đồng thời, mức độ tuỳ chỉnh cao mà hệ điều hành mang lại cho người dùng có nghĩa là ứng dụng của bạn có thể hiển thị không chính xác hoặc thậm chí gặp sự cố trên một số thiết bị.

Việc kiểm thử giao diện người dùng cho phép bạn thực hiện kiểm thử khả năng tương thích, xác minh hành vi của một ứng dụng trong nhiều ngữ cảnh. Bạn nên chạy kiểm thử giao diện người dùng trên các thiết bị có sự khác biệt theo những cách sau:

  • Cấp độ API: 21, 25 và 30.
  • Ngôn ngữ: Tiếng Anh, tiếng Ả Rập và tiếng Trung.
  • Hướng: Dọc, ngang.

Hơn nữa, ứng dụng nên kiểm tra hành vi ngoài điện thoại. Bạn nên kiểm thử trên máy tính bảng, thiết bị có thể gập lại và các thiết bị khác.

Tài nguyên khác

Để biết thêm thông tin về cách tạo kiểm thử giao diện người dùng, hãy tham khảo các tài nguyên sau.

Tài liệu

Lớp học lập trình