Trang này trình bày các nguyên lý cốt lõi của việc kiểm thử ứng dụng Android, bao gồm phương pháp hay nhất tập trung và lợi ích của chúng.
Lợi ích của việc kiểm thử
Kiểm thử là một phần quan trọng trong quá trình phát triển ứng dụng. Chạy thử nghiệm dựa trên ứng dụng của bạn một cách nhất quán, bạn có thể xác minh độ chính xác, chức năng của ứng dụng và khả năng hữu dụng trước khi phát hành công khai.
Bạn có thể kiểm thử ứng dụng theo cách thủ công bằng cách duyệt qua ứng dụng đó. Bạn có thể dùng các thiết bị và trình mô phỏng khác nhau, thay đổi ngôn ngữ hệ thống cũng như cố gắng tạo mọi lỗi của người dùng hoặc truyền tải mọi luồng người dùng.
Tuy nhiên, thử nghiệm thủ công có quy mô kém và có thể dễ bị bỏ qua sự hồi quy trong hành vi của ứng dụng. Kiểm thử tự động bao gồm cả việc sử dụng các công cụ giúp thực hiện thử nghiệm cho bạn, nhanh hơn, lặp lại nhiều hơn và nhìn chung cung cấp cho bạn thông tin phản hồi hữu ích hơn về ứng dụng của bạn trong quá trình phát triển của chúng tôi.
Các loại kiểm thử trong Android
Ứng dụng dành cho thiết bị di động rất phức tạp và phải hoạt động tốt trong nhiều môi trường. Như có nhiều loại thử nghiệm.
Tiêu đề
Ví dụ: có nhiều loại bài kiểm tra tuỳ thuộc vào chủ đề:
- Kiểm thử chức năng: ứng dụng của tôi có thực hiện những gì được yêu cầu không?
- Thử nghiệm hiệu suất: thử nghiệm có nhanh chóng và hiệu quả không?
- Kiểm thử khả năng hỗ trợ tiếp cận: công cụ này có hoạt động tốt với các dịch vụ hỗ trợ tiếp cận không?
- Kiểm thử khả năng tương thích: có hoạt động tốt trên mọi thiết bị và cấp độ API không?
Phạm vi
Các thử nghiệm cũng khác nhau tuỳ thuộc vào kích thước hoặc mức độ tách biệt:
- Kiểm thử đơn vị hoặc kiểm thử nhỏ chỉ xác minh một phần rất nhỏ của ứng dụng, chẳng hạn như phương thức hoặc lớp.
- Kiểm thử toàn diện hoặc kiểm thử lớn sẽ xác minh các phần lớn hơn của ứng dụng ở cùng một lúc, chẳng hạn như toàn bộ màn hình hoặc luồng người dùng.
- Kiểm thử trung bình nằm ở giữa và kiểm tra việc tích hợp giữa hai hoặc đơn vị khác.
Có nhiều cách để phân loại bài kiểm tra. Tuy nhiên, điểm khác biệt quan trọng nhất đối với nhà phát triển ứng dụng là nơi chạy bài kiểm thử.
Kiểm thử đo lường so với kiểm thử cục bộ
Bạn có thể chạy thử nghiệm trên một thiết bị Android hoặc trên một máy tính khác:
- Kiểm thử đo lường chạy trên thiết bị Android, cả thiết bị thực hoặc mô phỏng. Ứng dụng được xây dựng và cài đặt cùng với một ứng dụng kiểm thử chèn các lệnh và đọc trạng thái. Kiểm thử đo lường thường là kiểm thử giao diện người dùng, khởi chạy ứng dụng và sau đó tương tác với nội dung đó.
- Bài kiểm thử cục bộ thực thi trên máy phát triển hoặc máy chủ của bạn, vì vậy, chúng còn được gọi là kiểm thử phía máy chủ. Chúng thường nhỏ và nhanh, cô lập đối tượng kiểm thử từ phần còn lại của ứng dụng.
Không phải kiểm thử đơn vị nào cũng cục bộ và không phải kiểm thử toàn diện nào cũng chạy trên thiết bị. Ví dụ:
- Thử nghiệm cục bộ quy mô lớn: Bạn có thể sử dụng trình mô phỏng Android chạy cục bộ, chẳng hạn như dưới dạng Robolectric.
- Kiểm thử đo lường nhỏ: Bạn có thể xác minh rằng mã của mình hoạt động tốt với tính năng khung, chẳng hạn như cơ sở dữ liệu SQLite. Bạn có thể chạy bài kiểm tra này trên nhiều thiết bị để kiểm tra việc tích hợp với nhiều phiên bản SQLite.
Ví dụ
Các đoạn mã sau đây minh hoạ cách tương tác với giao diện người dùng trong kiểm thử giao diện người dùng được đo lường nhấp vào một phần tử và xác minh rằng một phần tử khác sẽ được hiển thị.
Espresso
// When the Continue button is clicked
onView(withText("Continue"))
.perform(click())
// Then the Welcome screen is displayed
onView(withText("Welcome"))
.check(matches(isDisplayed()))
Giao diện người dùng Compose
// When the Continue button is clicked
composeTestRule.onNodeWithText("Continue").performClick()
// Then the Welcome screen is displayed
composeTestRule.onNodeWithText("Welcome").assertIsDisplayed()
Đoạn mã này cho thấy một phần của kiểm thử đơn vị cho ViewModel (cục bộ, phía máy chủ) thử nghiệm):
// Given an instance of MyViewModel
val viewModel = MyViewModel(myFakeDataRepository)
// When data is loaded
viewModel.loadData()
// Then it should be exposing data
assertTrue(viewModel.data != null)
Xác định chiến lược thử nghiệm
Tốt nhất là bạn nên kiểm thử mọi dòng mã trong ứng dụng của mình trên mọi thiết bị tương thích với ứng dụng của bạn. Thật không may, phương pháp này quá chậm và đắt đỏ để thiết thực.
Một chiến lược kiểm thử hiệu quả sẽ cân bằng hợp lý giữa độ trung thực của kiểm thử, tốc độ và độ tin cậy. Sự tương đồng của môi trường kiểm thử với một thiết bị thực sẽ quyết định độ trung thực của thử nghiệm. Các bài kiểm thử có độ chân thực cao hơn sẽ chạy trên thiết bị được mô phỏng hoặc chính thiết bị thực tế. Có thể chạy các thử nghiệm có độ chân thực thấp hơn trên máy trạm JVM địa phương. Quá trình kiểm thử có độ chân thực cao thường chậm hơn và đòi hỏi nhiều tài nguyên hơn, vì vậy không phải kiểm thử nào cũng đều có độ trung thực cao.
Kiểm thử không ổn định
Lỗi xảy ra ngay cả khi chạy kiểm thử được thiết kế và triển khai chính xác. Ví dụ: khi chạy kiểm thử trên một thiết bị thực, quá trình cập nhật tự động có thể bắt đầu sau giữa quá trình kiểm thử và khiến kiểm thử không thành công. Các điều kiện tranh đấu tinh vi trong mã của bạn có thể chỉ xảy ra một tỷ lệ nhỏ thời gian. Các bài kiểm thử không vượt qua 100% đều không ổn định.
Cấu trúc có thể kiểm thử
Với cấu trúc ứng dụng có thể kiểm thử, mã sẽ tuân theo cấu trúc cho phép bạn để dễ dàng kiểm thử từng phần của ứng dụng đó một cách riêng biệt. Kiến trúc có thể kiểm thử có những lợi thế khác như dễ đọc hơn, dễ bảo trì hơn, có thể mở rộng và khả năng tái sử dụng.
Một cấu trúc không thể kiểm thử tạo ra kết quả sau:
- Quy trình kiểm thử lớn hơn, chậm hơn, không ổn định hơn. Các lớp không thể kiểm thử đơn vị có thể có được hỗ trợ bằng các thử nghiệm tích hợp hoặc thử nghiệm giao diện người dùng quy mô lớn hơn.
- Có ít cơ hội hơn để thử nghiệm nhiều tình huống. Các thử nghiệm lớn hơn sẽ chậm hơn, vì vậy việc thử nghiệm tất cả các trạng thái có thể xảy ra của ứng dụng có thể không thực tế.
Để tìm hiểu thêm về các nguyên tắc về cấu trúc, hãy xem hướng dẫn về cách triển khai ứng dụng .
Các phương pháp tách
Nếu bạn có thể trích xuất một phần của hàm, lớp hoặc mô-đun từ phần còn lại, hãy kiểm thử dễ dàng và hiệu quả hơn. Phương pháp này được gọi là phân tách và là khái niệm quan trọng nhất đối với kiến trúc có thể kiểm thử.
Sau đây là các kỹ thuật tách rời phổ biến:
- Chia một ứng dụng thành các lớp như Bản trình bày, Miền và Dữ liệu. Bạn có thể hãy chia một ứng dụng thành các mô-đun, mỗi mô-đun cho một tính năng.
- Tránh thêm logic vào các thực thể có phần phụ thuộc lớn, chẳng hạn như hoạt động và mảnh. Hãy dùng các lớp này làm điểm truy cập vào khung và di chuyển giao diện người dùng và logic nghiệp vụ sang nơi khác, chẳng hạn như sang một Thành phần kết hợp, ViewModel hoặc lớp miền.
- Tránh các phần phụ thuộc khung trực tiếp trong các lớp chứa logic nghiệp vụ. Ví dụ: không sử dụng Ngữ cảnh Android trong ViewModels.
- Giúp dễ dàng thay thế các phần phụ thuộc. Ví dụ: hãy sử dụng giao diện thay vì triển khai cụ thể. Sử dụng Chèn phần phụ thuộc ngay cả khi bạn không sử dụng khung DI.
Các bước tiếp theo
Bây giờ, bạn đã biết lý do nên kiểm thử và hai loại kiểm thử chính, bạn có thể đọc phần Nội dung cần kiểm thử.
Ngoài ra, nếu bạn muốn tạo thử nghiệm đầu tiên và học hỏi bằng cách thực hiện, hãy chọn các lớp học lập trình kiểm thử.