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ụ: 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 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 đ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 điều gì đó.
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.
Kim tự tháp kiểm thử
Bạn có thể phân loại các kiểm thử trong các ứng dụng hiện đại theo kích thước. Các 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 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 sản xuấ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 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 một kim tự tháp. Có quá nhiều bài kiểm thử toàn diện lớn và quá ít bài 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 bài kiểm thử đượ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 các quy trình kiểm thử toàn diện hằng đêm hoặc hằng tuần chạy.
Bạn cần cân nhắc 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 nên ưu tiên các hoạt động kiểm thử nhỏ 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 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 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 phiên 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 thử nghiệm có thể mở rộng
Theo truyền thống, kim tự 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
- 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 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ử 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ị |
Phương thức hoặc lớp đơn lẻ có ít phần phụ thuộc. |
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 học cùng nhau |
Không |
Local |
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 |
Mocked (Giả lập) |
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 quyền sở hữu của các nhóm khác |
|
Thiết bị |
Có thể gỡ lỗi |
Trước khi hợp nhất |
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ụ thuộc quyền sở hữu của các nhóm khác |
Máy chủ phát hành công khai |
Thiết bị |
Bản phát hành thu nhỏ |
|
Quyết định danh mục kiểm thử
Theo quy 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 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:
Đối tượng kiểm thử |
Nội dung mô tả về những gì đang được kiểm thử |
Danh mục bài kiểm tra |
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 xem trường mật khẩu đã được nhập hay chưa. Không có phần phụ thuộc nào. |
Kiểm thử đơn vị |
|
Hành vi của giao diện người dùng biểu mẫu đăng nhập |
Một 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 |
|
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ý uỷ quyền |
Giao diện người dùng gửi thông tin đăng nhập đến một trình quản lý uỷ quyền 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 người dùng 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 kiểm thử trên một máy chủ dàn dựng |
Bản phát hành dùng thử |
Kiểm thử hành vi giao diện người dùng Compose toàn diện chạy trên thiết bị |
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 QA 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:
Danh mục |
Môi trường (ở đâu) |
Điều kiện kích hoạt (khi) |
|---|---|---|
Đơn vị |
[Địa phương][4] |
Mỗi lần xác nhận |
Thành phần |
Địa phương |
Mỗi lần xác nhận |
Tính năng |
Thiết bị cục bộ và trình mô phỏng |
Trước khi hợp nhất, trước khi hợp nhất hoặc gửi một thay đổi |
Ứng dụng |
Thiết bị cục bộ, trình mô phỏng, 1 điện thoại, 1 điện thoại có thể gập lại |
Sau khi hợp nhất, sau khi hợp nhất hoặc gửi một 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ử Đơ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 chịu ả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 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ị.
Những 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 hoạt động 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.