Tính năng 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ụ: tính năng này giúp bạn xác thực, phát hiện 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ả cho phé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 mứ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 tính năng nâng cao về cơ sở hạ tầng. Việc này sẽ cung cấp 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ẽ làm được những việc sau:
- Phát hiện vấn đề sớm nhất có thể.
- Thực thi nhanh chóng.
- Cho biết rõ ràng khi cần khắc phục vấn đề.
Trang này sẽ giúp bạn quyết định loại kiểm thử cần triển khai, nơi chạy kiểm thử và tần suất chạy.
Kim tự tháp kiểm thử
Bạn có thể phân loại các chương trình 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ỏ mã, giúp các bài kiểm thử này 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 kiểm thử lớn có độ chân thực cao hơn* và có thể phát hiện nhiều vấn đề hơn cùng một lúc.
*Độ chân thực đề cập đến mức độ tương đồng của môi trường thời gian chạy kiểm thử với môi trường phát hành chính thức.
Hầu hết các ứng dụng đều nên có nhiều kiểm thử nhỏ và tương đối ít kiểm thử lớn. Việc phân phối các lượt kiểm thử trong mỗi danh mục nên tạo thành một kim tự tháp, trong đó số lượt kiểm thử nhỏ sẽ tạo thành cơ sở càng ít và số lượt kiểm thử lớn càng ít.
Giảm thiểu chi phí của lỗi
Một chiến lược kiểm thử hiệu quả sẽ giúp 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 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 chương trình kiểm thử được chạy trước khi hợp nhất. Nếu có lỗi, các bài kiểm thử có thể không phát hiện được cho đến khi chạy kiểm thử toàn diện hằng đêm hoặc hằng tuần.
Bạn cần cân nhắc những tác động của điều này đối với chi phí xác định và khắc phục lỗi, cũng như lý do tại sao bạn cần thiên về 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 kiểm thử đơn vị, lỗi đó thường được khắc phục trong vài phút, vì vậy chi phí sẽ thấp.
- Quy trình kiểm thử toàn diện có thể mất nhiều ngày để phát hiện ra cùng một lỗi. Điều 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 bản phát hành. Chi phí của lỗi này cao hơn.
Tuy nhiên, 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 để được đưa vào thiết bị của người dùng, đôi khi là vài tuần, vì vậy, vòng hồi tiếp là vòng dài nhất và tốn kém nhất.
Chiến lược kiểm thử có thể mở rộng
Kim tự tháp kiểm thử theo truyền thống được chia thành 3 loại:
- Kiểm thử đơn vị
- Thử nghiệm tích hợp
- Kiểm thử toàn diện.
Tuy nhiên, các 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:
- Quy trình kiểm thử đơn vị chạy trên máy chủ và xác minh một đơn vị logic chức năng duy nhất không có phần phụ thuộc trên khung Android.
- Ví dụ: xác minh lỗi riêng lẻ trong một hàm toán học.
- Kiểm thử 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 khái niệm trừu tượng cao hơn trên 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
- Kiểm thử 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. Việc kiểm thử tính năng có quy mô lớn và phức tạp hơn, thường hoạt động ở cấp tính năng.
- Ví dụ: kiểm thử hành vi trên giao diện người dùng xác minh việc quản lý trạng thái trong màn hình
- 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 tệp nhị phân có thể triển khai. Đây là các kiểm thử tích hợp lớn sử dụng 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 trình bổ trợ kiểm thử, như hệ thống đang được kiểm thử.
- Ví dụ: kiểm thử hành vi giao diện người dùng để xác minh các thay đổi về cấu hình trong kiểm thử thiết bị có thể gập lại, bản địa hoá và hỗ trợ tiếp cận
- Bài kiểm thử bản phát hành dùng thử sẽ xác minh chức năng của bản phát hành.
Các tệp này tương tự như kiểm thử ứng dụng, ngoại trừ việc tệp nhị phân của ứng dụng được giảm thiểu và tối ưu hoá. Đây là các kiểm thử tích hợp toàn diện lớn chạy trong môi trường gần với môi trường sản xuất nhất có thể mà không hiển thị ứng dụng cho tài khoản người dùng công khai hoặ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
Cách phân loại này tính đến độ chân thực, thời gian, phạm vi và mức độ tách biệt. 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ử hành vi, ảnh chụp màn hình và hiệu suất.
Phạm vi |
Quyền truy cập mạng |
Thực thi |
Loại phiên bản |
Vòng đời |
|
|---|---|---|---|---|---|
Đơn vị |
Một phương thức hoặc lớp có phần phụ thuộc tối thiểu. |
Không |
Địa phương |
Có thể gỡ lỗi |
Trước khi hợp nhất |
Thành phần |
Cấp mô-đun hoặc thành phần Nhiều lớp cùng nhau |
Không |
Cục bộ |
Có thể gỡ lỗi |
Trước khi hợp nhất |
Tính năng |
Cấp tính năng Tích hợp với các thành phần thuộc sở hữu của các nhóm khác |
Mô phỏng |
Local |
Có thể gỡ lỗi |
Trước khi hợp nhất |
Ứng dụng |
Cấp độ ứng dụng Tích hợp với các tính năng và/hoặc dịch vụ thuộc sở hữu của các nhóm khác |
Giả lập |
Thiết bị |
Có thể gỡ lỗi |
Hợp nhất trước |
Bản phát hành dùng thử |
Cấp độ ứng dụng Tích hợp với các tính năng và/hoặc dịch vụ do các nhóm khác sở hữu |
Máy chủ sản xuất |
Trình mô phỏng |
Bản phát hành rút gọn |
Sau khi hợp nhất |
Quyết định danh mục kiểm thử
Theo nguyên tắc chung, bạn nên cân nhắc 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 luồng đăng nhập. Tuỳ thuộc vào nội dung bạn cần kiểm thử, bạn sẽ chọn các danh mục khác nhau:
Đối tượng đang được kiểm tra |
Nội dung mô tả về nội dung đang được kiểm thử |
Danh mục bài kiểm thử |
Ví dụ về loại kiểm thử |
|---|---|---|---|
Logic trình xác thực biểu mẫu |
Một lớp xác thực địa chỉ email theo biểu thức chính quy và kiểm tra để đảm bảo rằng bạn đã nhập trường mật khẩu. Không có phần phụ thuộc. |
Kiểm thử đơn vị |
|
Hành vi giao diện người dùng của biểu mẫu đăng nhập |
Biểu mẫu có nút chỉ được bật khi biểu mẫu đã được xác thực |
Kiểm thử thành phần |
Kiểm thử hành vi trên giao diện người dùng chạy trên Robolectric |
Giao diện người dùng của biểu mẫu đăng nhập |
Một biểu mẫu tuân theo quy cách về trải nghiệm người dùng |
Kiểm thử thành phần |
Kiểm thử ảnh chụp màn hình của tính năng Xem trước trong Compose |
Tích hợp với trình quản lý xác thực |
Giao diện người dùng gửi thông tin xác thực đến trình quản lý xác thực và nhận các phản hồi có thể chứa nhiều lỗi. |
Kiểm thử tính năng |
|
Hộp thoại đăng nhập |
Màn hình hiển thị biểu mẫu đăng nhập khi nhấn nút đăng nhập. |
Kiểm thử ứng dụng |
|
Hành trình trọng yếu của người dùng: Đăng nhập |
Quy trình đăng nhập hoàn chỉnh bằng tài khoản thử nghiệm trên máy chủ thử nghiệm |
Bản phát hành dùng thử |
Kiểm thử hành vi giao diện người dùng trong Compose toàn diện chạy trên thiết bị |
Trong một số trường hợp, việc một nội dung thuộc danh mục nào có thể là 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 trạng 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 chỉ đị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ử Ứng viê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á lỗi trong một tính năng mà không cần 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ông cụ để giúp nhà phát triển liên tục chạy các chương trình kiểm thử và thực thi các quy tắc đảm bảo tất cả chương trình kiểm thử đều đạt.
Bạn có thể phân loại các bài kiểm thử theo phạm vi để xác định thời điểm và vị trí chạy chương trình kiểm thử nào. Ví dụ: theo mô hình 5 lớp:
Danh mục |
Môi trường (where) |
Kích hoạt (khi) |
|---|---|---|
Đơn vị |
[Local][4] |
Mỗi lần xác nhận |
Thành phần |
Địa phương |
Mỗi cam kết |
Tính năng |
Trình mô phỏng và cục bộ |
Hợp nhất trước, trước khi hợp nhất hoặc gửi một thay đổi |
Ứng dụng |
Trên máy, trình mô phỏng, 1 điện thoại, 1 thiết bị có thể gập lại |
Sau khi hợp nhất, sau khi hợp nhất hoặc gửi thay đổi |
Bản phát hành dùng thử |
8 điện thoại, 1 thiết bị có thể gập lại, 1 máy tính bảng |
Trước ngày phát hành |
- Các bài kiểm thử Unit và Component (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ỉ 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 sẽ chạy trước khi hợp nhất hoặc gửi thay đổi.
- Các kiểm thử Ứng dụng chạy sau khi hợp nhất.
- Các thử nghiệm 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 thử nghiệm Bản phát hành đề xuất sẽ chạy trên một số lượng lớn thiết bị.
Các quy tắc này có thể thay đổi theo thời gian khi số lượng kiểm thử ảnh hưởng đến năng suất. Ví dụ: nếu chuyển các bài kiểm thử sang tần suất hằng đêm, bạn có thể giảm thời gian xây dựng và kiểm thử CI, nhưng cũng có thể kéo dài vòng lặp phản hồi.