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

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

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 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 các thiết bị và trình mô phỏng khác nhau, thay đổi ngôn ngữ hệ thống và cố gắng tạo mọi lỗi người dùng hoặc đi qua mọi quy trình người dùng.

Tuy nhiên, 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 là quá trình sử dụng các công cụ thực hiện kiểm thử cho bạn. Quá trình này diễn ra nhanh hơn, có tính lặp lại cao 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 ngay từ giai đoạn đầu của quy trình phát triển.

Các loại kiểm thử trong Android

Các ứ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 thử nghiệm.

Tiêu đề

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

  • Kiểm thử chức năng: ứng dụng của tôi có hoạt động như mong đợi không?
  • Kiểm thử hiệu suất: 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 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.
  • Thử nghiệm đầu cuối hoặc thử nghiệm 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 quy trình của người dùng.
  • Kiểm thử trung bình nằm ở giữa và kiểm tra quy trình tích hợp giữa hai hoặc nhiều đơn vị.
Các bài kiểm tra có thể có quy mô nhỏ, trung bình hoặc lớn.
Hình 1: Các 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 các 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 các 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 một thiết bị Android hoặc trên một máy tính khác:

  • Các kiểm thử đo lường chạy trên một thiết bị Android, có thể là thiết bị thực hoặc thiết bị được 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. Kiểm thử đo lường thường là 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ủ của bạn, vì vậy, các kiểm thử này còn được gọi là kiểm thử phía máy chủ. Chúng thường nhỏ và nhanh, tách biệt đối tượng đang 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 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 kiểm thử tuỳ thuộc vào vị trí chạy.

Không phải tất cả kiểm thử đơn vị đều là kiểm thử cục bộ và không phải tất cả kiểm thử toàn diện đều chạy trên thiết bị. Ví dụ:

  • Kiểm thử cục bộ quy mô lớn: Bạn có thể sử dụng một 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 việc tích hợp với nhiều phiên bản của 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 thử nghiệm 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 sẽ xuất hiện.

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 một ViewModel (kiểm thử cục bộ phía máy chủ lưu trữ):

// 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 một 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ác cấu trúc có thể kiểm thử có những ưu điểm khác, chẳng hạn như khả năng dễ đọc, dễ duy trì, khả năng mở rộng và khả năng sử dụng lại tốt hơn.

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

  • Các kiểm thử lớn hơn, chậm hơn và dễ bị lỗi 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 hơn để thử nghiệm các tình huống khác nhau. Các 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ể là điều 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ấu trúc ứng dụng.

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

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à tách rời 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 tách rời 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ó 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 cũng như 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 trực tiếp vào khung trong các lớp chứa logic nghiệp vụ. Ví dụ: không dùng Ngữ cảnh Android trong ViewModel.
  • Dễ dàng thay thế các phần phụ thuộc. Ví dụ: sử dụng giao diện thay vì cá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 dùng khung DI.

Các bước tiếp theo

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