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 và lợi ích của các phương pháp đó.

Lợi ích của việc thử nghiệm

Thử nghiệm 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 theo cách thủ công bằng cách thao tác trong ứ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 ra mọi lỗi người dùng hoặc duyệt qua mọi luồng người dùng.

Tuy nhiên, kiểm thử thủ công có khả năng mở rộng kém và 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 bao gồm việc sử dụng các công cụ thực hiện kiểm thử cho bạn. Cách này nhanh hơn, dễ lặp lại hơn và thường cung cấp cho bạn nhiều ý kiến 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ác loại 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 kiểm thử.

Chủ đề

Ví dụ: có nhiều loại kiểm thử tuỳ thuộc vào đối tượng:

  • Kiểm tra về mặt hoạt động: ứng dụng của tôi có hoạt động đúng như mong đợi không?
  • Kiểm thử hiệu suất: ứng dụng có thực hiện 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

Các chương trình kiểm thử 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ư một phương thức hoặc lớp.
  • 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 mức độ tích hợp giữa hai hoặc nhiều đơn vị.
Các bài kiểm thử có thể 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 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 kiểm thử.

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

Bạn có thể chạy 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, có thể là 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 thử nghiệm có chức năng chèn 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 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ủ, nên còn được gọi là kiểm thử phía máy chủ. Các kiểm thử này thường nhỏ và nhanh, tách biệt đối tượng được kiểm thử vớ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 thiết bị hoặc kiểm thử cục bộ trên máy phát triển của bạn.
Hình 2: Các loại kiểm thử khác nhau tuỳ thuộc vào nơi chạy.

Không phải kiểm thử đơn vị nào cũng là kiểm thử 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ụ:

  • 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 thử nghiệm này trên nhiều thiết bị để kiểm tra khả năng 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 bản kiểm thử giao diện người dùng được đo lường, trong đó 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 kiểm thử đơn vị cho ViewModel (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 cấu 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ử riêng biệt các phần khác nhau của mã. Cấu trúc có thể kiểm thử có các ưu điểm khác, chẳng hạn như khả năng đọc, khả năng bảo trì, khả năng mở rộng và khả năng tái sử dụng tốt hơn.

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

  • Các thử nghiệm 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ể phải được bao gồm trong các kiểm thử tích hợp hoặc kiểm thử giao diện người dùng lớn hơn.
  • Ít cơ hội thử nghiệm các trường hợp khác nhau. Các bài 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ề các nguyên tắc cấu trúc, hãy xem hướng dẫn về cấu trúc ứng dụng.

Các phương pháp phân tách

Nếu 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, 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à phân tách và đây là khái niệm quan trọng nhất đối với cấu trúc có thể kiểm thử.

Sau đây là các kỹ thuật phân tách phổ biến:

  • 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ó phần phụ thuộc lớn, 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 nghiệp vụ sang nơi khác, chẳng hạn như sang một composable, ViewModel hoặc lớp miền.
  • Tránh các phần phụ thuộc trực tiếp của khung trong các lớp chứa logic nghiệp vụ. Ví dụ: không sử dụng Ngữ cảnh Android trong ViewModel.
  • Giúp bạn dễ dàng thay thế các phần phụ thuộc. Ví dụ: sử dụng giao diện thay vì 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

Giờ đây, khi đã biết lý do nên kiểm thử và hai loại kiểm thử chính, bạn có thể đọc bài viết 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 kiểm thử đầu tiên và học hỏi thông qua thực hành, hãy xem Lớp học lập trình về kiểm thử.