Chiến lược kiểm thử

Kiểm thử tự động giúp bạn cải thiện chất lượng ứng dụng theo nhiều cách. Ví dụ: việc này giúp bạn thực hiện quy trình xác thực, phát hiện các lỗi hồi quy và xác minh khả năng tương thích. Một chiến lược kiểm thử hiệu quả sẽ giúp bạn tận dụng tính năng kiểm thử tự động để tập trung vào một lợi ích quan trọng: năng suất của nhà phát triển.

Các nhóm đạt được năng suất cao hơn khi sử dụng phương pháp kiểm thử có hệ thống kết hợp với các điểm cải tiến về cơ sở hạ tầng. Việc này giúp bạn nhận được ý kiến phản hồi kịp thời về cách hoạt động của mã. Một chiến lược kiểm thử hiệu quả sẽ:

• Phát hiện vấn đề càng sớm càng tốt.
• Thực thi nhanh chóng.
• Đưa ra chỉ báo rõ ràng khi cần sửa chữa một vấn đề.

Trang này sẽ giúp bạn quyết định loại thử nghiệm cần triển khai, nơi chạy thử nghiệm và tần suất chạy thử nghiệm.

android skills add testing-setup

Kim tự tháp kiểm thử

Bạn có thể phân loại các bài kiểm thử trong các ứng dụng hiện đại theo kích thước. Các bài kiểm thử nhỏ chỉ tập trung vào một phần nhỏ của mã, giúp chúng hoạt động nhanh chóng và đáng tin cậy. Các kiểm thử lớn có phạm vi rộng và yêu cầu các chế độ thiết lập phức tạp hơn, khó duy trì. Tuy nhiên, các bài kiểm thử lớn có độ trung thực cao hơn* và có thể phát hiện nhiều vấn đề hơn cùng một lúc.

*Độ trung thực đề cập đến mức độ tương đồng của môi trường thời gian chạy thử nghiệm với môi trường thực tế.

Hầu hết các ứng dụng nên có nhiều thử nghiệm nhỏ và tương đối ít thử nghiệm lớn. Việc phân phối các kiểm thử trong mỗi danh mục phải tạo thành một kim tự tháp, trong đó các kiểm thử nhỏ có số lượng lớn hơn tạo thành phần đáy và các kiểm thử lớn có số lượng ít hơn tạo thành phần đỉnh.

Giảm thiểu chi phí của một lỗi

Một chiến lược kiểm thử hiệu quả sẽ tối đa hoá năng suất của nhà phát triển trong khi giảm thiểu chi phí tìm lỗi.

Hãy xem xét ví dụ về một chiến lược có thể không hiệu quả. Ở đây, số lượng kiểm thử theo kích thước không được sắp xếp thành hình kim tự tháp. Có quá nhiều kiểm thử toàn diện quy mô lớn và quá ít kiểm thử giao diện người dùng thành phần:

Điều này có nghĩa là có quá ít thử nghiệm được chạy trước khi hợp nhất. Nếu có lỗi, các quy trình kiểm thử có thể không phát hiện được lỗi đó cho đến khi chạy quy trình kiểm thử toàn diện hằng đêm hoặc hằng tuần.

Điều quan trọng là bạn phải xem xét những tác động của việc này đối với chi phí xác định và sửa lỗi, cũng như lý do tại sao bạn cần tập trung nỗ lực kiểm thử vào các hoạt động kiểm thử nhỏ hơn và thường xuyên hơn:

• Khi lỗi được phát hiện bằng một kiểm thử đơn vị, lỗi đó thường được khắc phục trong vài phút, vì vậy chi phí thấp.
• Một quy trình kiểm thử toàn diện có thể mất nhiều ngày để phát hiện ra lỗi tương tự. Việc này có thể thu hút nhiều thành viên trong nhóm, làm giảm năng suất tổng thể và có thể trì hoãn việc phát hành. Chi phí của lỗi này cao hơn.

Tuy nhiên, một chiến lược kiểm thử không hiệu quả vẫn tốt hơn là không có chiến lược nào. Khi một lỗi xuất hiện trong bản phát hành chính thức, bản sửa lỗi sẽ mất nhiều thời gian để xuất hiện trên thiết bị của người dùng, đôi khi là hàng tuần, vì vậy, vòng hồi tiếp là dài nhất và tốn kém nhất.

Chiến lược kiểm thử có thể mở rộng

Theo truyền thống, tháp kiểm thử được chia thành 3 danh mục:

• Kiểm thử đơn vị
• Thử nghiệm tích hợp
• Kiểm thử toàn diện.

Tuy nhiên, những khái niệm này không có định nghĩa chính xác, vì vậy, các nhóm có thể muốn xác định các danh mục theo cách khác, chẳng hạn như sử dụng 5 lớp:

• Một đơn vị kiểm thử được chạy trên máy chủ và xác minh một đơn vị logic chức năng duy nhất mà không phụ thuộc vào khung Android.
  • Ví dụ: xác minh lỗi sai lệch một đơn vị trong một hàm toán học.
• Thử nghiệm thành phần xác minh chức năng hoặc giao diện của một mô-đun hoặc thành phần độc lập với các thành phần khác trong hệ thống. Không giống như kiểm thử đơn vị, phạm vi của kiểm thử thành phần mở rộng đến các lớp trừu tượng cao hơn so với các phương thức và lớp riêng lẻ.
  • Ví dụ: Kiểm thử ảnh chụp màn hình cho một nút tuỳ chỉnh
• Thử nghiệm tính năng xác minh hoạt động tương tác của hai hoặc nhiều thành phần hoặc mô-đun độc lập. Kiểm thử tính năng có quy mô lớn hơn và phức tạp hơn, thường hoạt động ở cấp tính năng.
  • Ví dụ: Các kiểm thử hành vi giao diện người dùng xác minh việc quản lý trạng thái trên màn hình
• Một kiểm thử ứng dụng xác minh chức năng của toàn bộ ứng dụng dưới dạng một tệp nhị phân có thể triển khai. Đây là các kiểm thử tích hợp quy mô lớn sử dụng một tệp nhị phân có thể gỡ lỗi, chẳng hạn như bản dựng dành cho nhà phát triển có thể chứa các lệnh gọi kiểm thử, làm hệ thống đang được kiểm thử.
  • Ví dụ: Kiểm thử hành vi của giao diện người dùng để xác minh các thay đổi về cấu hình trong thiết bị có thể gập lại, kiểm thử khả năng hỗ trợ tiếp cận và bản địa hoá
• Thử nghiệm bản phát hành dùng thử xác minh chức năng của một bản phát hành. Các thử nghiệm này tương tự như thử nghiệm ứng dụng, ngoại trừ việc tệp nhị phân ứng dụng được giảm kích thước và tối ưu hoá. Đây là các kiểm thử tích hợp toàn diện quy mô lớn chạy trong một môi trường gần với môi trường phát hành chính thức nhất có thể mà không để lộ ứng dụng cho tài khoản người dùng công khai hoặc các phần phụ trợ công khai.
  • Ví dụ: Hành trình trọng yếu của người dùng, kiểm thử hiệu suất

Việc phân loại này có tính đến độ chân thực, thời gian, phạm vi và mức độ cô lập. Bạn có thể có nhiều loại kiểm thử trên nhiều lớp. Ví dụ: Lớp kiểm thử ứng dụng có thể chứa các kiểm thử về hành vi, ảnh chụp màn hình và hiệu suất.

Quyết định danh mục kiểm thử

Theo nguyên tắc chung, bạn nên xem xét lớp thấp nhất của kim tự tháp có thể cung cấp cho nhóm mức độ phản hồi phù hợp.

Ví dụ: hãy xem xét cách kiểm thử việc triển khai tính năng này: giao diện người dùng của một quy trình đăng nhập. Tuỳ thuộc vào nội dung cần kiểm thử, bạn sẽ chọn các danh mục khác nhau:

Trong một số trường hợp, việc xác định một nội dung thuộc danh mục này hay danh mục khác có thể mang tính chủ quan. Có thể có những lý do khác khiến một bài kiểm thử được chuyển lên hoặc xuống, chẳng hạn như chi phí cơ sở hạ tầng, tính không ổn định và thời gian kiểm thử dài.

Xin lưu ý rằng danh mục kiểm thử không quyết định loại kiểm thử và không phải tính năng nào cũng phải được kiểm thử trong mọi danh mục.

Kiểm thử thủ công cũng có thể là một phần trong chiến lược kiểm thử của bạn. Thông thường, các nhóm đảm bảo chất lượng sẽ thực hiện kiểm thử Phiên bản phát hành nhưng họ cũng có thể tham gia vào các giai đoạn khác. Ví dụ: kiểm thử khám phá để tìm lỗi trong một tính năng mà không có tập lệnh.

Cơ sở hạ tầng kiểm thử

Chiến lược kiểm thử phải được hỗ trợ bởi cơ sở hạ tầng và các công cụ để giúp nhà phát triển liên tục chạy các kiểm thử và thực thi các quy tắc đảm bảo rằng tất cả các kiểm thử đều vượt qua.

Bạn có thể phân loại các kiểm thử theo phạm vi để xác định thời điểm và vị trí chạy kiểm thử nào. Ví dụ: theo mô hình 5 lớp:

• Các bài kiểm thử Đơn vị và Thành phần chạy trên hệ thống Tích hợp liên tục cho mọi cam kết mới, nhưng chỉ dành cho các mô-đun bị ảnh hưởng.
• Tất cả các bài kiểm thử Đơn vị, Thành phần và Tính năng đều chạy trước khi hợp nhất hoặc gửi một thay đổi.
• Các kiểm thử ứng dụng chạy sau khi hợp nhất.
• Các bài kiểm thử Bản phát hành đề xuất chạy hằng đêm trên điện thoại, thiết bị có thể gập lại và máy tính bảng.
• Trước khi phát hành, các kiểm thử Bản phát hành đề xuất sẽ chạy trên nhiều thiết bị.

Các quy tắc này có thể thay đổi theo thời gian khi số lượng bài kiểm thử ảnh hưởng đến năng suất. Ví dụ: nếu chuyển các kiểm thử sang nhịp độ hằng đêm, bạn có thể giảm thời gian kiểm thử và tạo bản dựng CI, nhưng cũng có thể kéo dài vòng lặp phản hồi.