Nguyên tắc cơ bản về việc kiểm thử ứng dụng Android

Trang này trình bày các nguyên tắc cốt lõi của việc kiểm thử ứng dụng Android, bao gồm cả các phương pháp hay nhất chính 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 không thể thiếu trong quá trình phát triển ứng dụng. Bằng cách chạy các quy trình kiểm thử cho ứng dụng một cách nhất quán, bạn có thể xác minh độ chính xác, hành vi chức năng và khả năng hữu dụng của ứng dụng trước khi xuất bản chính thức.

Bạn có thể kiểm thử ứng dụng của mình theo cách thủ công bằng cách di chuyển qua ứng dụng đó. Bạn có thể sử dụng nhiều thiết bị và trình mô phỏng, thay đổi ngôn ngữ hệ thống và cố gắng tạo mọi lỗi của người dùng hoặc đi qua mọi luồng người dùng.

Tuy nhiên, việc kiểm thử thủ công không hiệu quả và bạn có thể dễ dàng bỏ qua các lỗi hồi quy trong hành vi của ứng dụng. Kiểm thử tự động liên quan đến việc sử dụng các công cụ thực hiện quy trình kiểm thử cho bạn, nhanh hơn, có thể lặp lại nhiều lần và thường 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 ở giai đoạn đầu của quá trình phát triển.

Các loại quy trình kiểm thử trong Android

Ứng dụng di động rất phức tạp và phải hoạt động tốt trong nhiều môi trường. Do đó, có nhiều loại quy trình kiểm thử.

Chủ đề

Ví dụ: có nhiều loại quy trình kiểm thử tuỳ thuộc vào chủ đề:

  • Kiểm tra về mặt hoạt động: ứng dụng của tôi có hoạt động đúng như dự kiến không?
  • Kiểm thử hiệu suất: ứng dụng có hoạt động nhanh chóng và hiệu quả không?
  • Kiểm thử khả năng hỗ trợ tiếp cận: ứng dụng 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: ứng dụng có hoạt động tốt trên mọi thiết bị và cấp độ API không?

Phạm vi

Quy trình kiểm thử cũng khác nhau tuỳ thuộc vào kích thước hoặc mức độ cô lập:

  • 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ư một phương thức hoặc lớp.
  • Quy trình kiểm thử từ đầu đến cuối hoặc kiểm thử lớn 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 quá trình tích hợp giữa 2 hoặc nhiều đơn vị.
Các thử nghiệm có thể có quy mô nhỏ, trung bình hoặc lớn.
Hình 1: Phạm vi kiểm thử trong một ứng dụng thông thường.

Có nhiều cách để phân loại quy trình kiểm thử. 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 quy trình kiểm thử.

Kiểm thử đo lường so với kiểm thử cục bộ

Bạn có thể chạy quy trình kiểm thử trên 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, thiết bị thực hoặc thiết bị mô phỏng. Ứng dụng được tạo 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. Quy trình kiểm thử đo lường thường là quy trình kiểm thử giao diện người dùng, khởi chạy một ứng dụng rồi tương tác với ứng dụng đó.
  • Kiểm thử cục bộ thực thi trên máy phát triển hoặc máy chủ, 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 đang kiểm thử khỏi phần còn lại của ứng dụng.
Các chương trình kiểm thử có thể chạy dưới dạng kiểm thử đo lường trên một thiết bị hoặc kiểm thử cục bộ trên máy phát triển.
Hình 2: Các loại quy trình kiểm thử khác nhau tuỳ thuộc vào nơi chạy quy trình kiểm thử.

Không phải tất cả quy trình kiểm thử đơn vị đều là quy trình kiểm thử cục bộ và không phải tất cả quy trình kiểm thử từ đầu đến cuối đều chạy trên thiết bị. Ví dụ:

  • Kiểm thử cục bộ 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ư 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 một tính năng của khung, chẳng hạn như cơ sở dữ liệu SQLite. Bạn có thể chạy quy trình kiểm thử này trên nhiều thiết bị để kiểm tra quá trình 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 một quy trình kiểm thử giao diện người dùng đ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 đượ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 quy trình kiểm thử đơn vị cho ViewModel (quy trình kiểm thử cục bộ, phía máy chủ):

// 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)

Kiến trúc có thể kiểm thử

Với kiến trúc ứng dụng có thể kiểm thử, mã sẽ tuân theo một cấu trúc cho phép bạn dễ dàng kiểm thử các phần khác nhau của mã đó một cách riêng biệt. Kiến trúc có thể kiểm thử có những ưu điểm khác, chẳng hạn như khả năng đọc, khả năng bảo trì, khả năng có thể mở rộng và khả năng sử dụng lại tốt hơn.

Kiến trúc không thể kiểm thử sẽ tạo ra những điều sau:

  • Quy trình kiểm thử lớn hơn, chậm hơn và không ổn định hơn. Các lớp không thể kiểm thử đơn vị có thể phải được bao gồm trong các quy trình kiểm thử tích hợp hoặc quy trình kiểm thử giao diện người dùng lớn hơn.
  • Ít cơ hội hơn để kiểm thử các tình huống khác nhau. Quy trình kiểm thử lớn hơn sẽ chậm hơn, vì vậy, việc kiểm thử tất cả các trạng thái có thể có của một ứng dụng có thể không thực tế.

Để tìm hiểu thêm về nguyên tắc kiến trúc, hãy xem hướng dẫn về kiến trúc ứng dụng.

Các phương pháp tách rời

Nếu bạn có thể trích xuất một phần của hàm, lớp hoặc mô-đun khỏi phần còn lại, thì việc kiểm thử sẽ dễ dàng và hiệu quả hơn. Phương pháp này được gọi là tách rời và đây là khái niệm quan trọng nhất đối với kiến trúc có thể kiểm thử.

Các kỹ thuật tách rời phổ biến bao gồm:

  • Chia ứng dụng thành các lớp như Trình bày, Miền và Dữ liệu. Bạn cũng có thể chia ứ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ó nhiều phần phụ thuộc, chẳng hạn như hoạt động và mảnh. Sử 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 kinh doanh sang nơi khác, chẳng hạn như sang một lớp Composable, ViewModel hoặc miền.
  • Tránh các phần phụ thuộc khung trực tiếp trong các lớp chứa logic kinh doanh. Ví dụ: không sử dụng Ngữ cảnh Android trong ViewModel.
  • Giúp các phần phụ thuộc dễ dàng thay thế. Ví dụ: sử dụng giao diện thay vì các phương thức triển khai cụ thể. Sử dụng tính nă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à 2 loại quy trình kiểm thử chính, bạn có thể đọc Nội dung cần kiểm thử hoặc tìm hiểu về Chiến lược kiểm thử

Ngoài ra, nếu bạn muốn tạo quy trình kiểm thử đầu tiên và học bằng cách thực hành, hãy xem Lớp học lập trình về kiểm thử.