Khám phá cách kết hợp các loại kiểm thử khác nhau thành một chiến lược hợp lý phù hợp với dự án của bạn.
Chào mừng bạn quay lại! Bài viết trước đã đặt ra nhiều nền tảng về cách tiếp cận các loại kiểm thử khác nhau và nội dung của các loại kiểm thử đó, đồng thời làm rõ định nghĩa về loại kiểm thử. Bạn có nhớ hình ảnh meme nhỏ này không? Bạn có thể thắc mắc làm cách nào để tất cả các loại kiểm thử mà bạn đã tìm hiểu có thể hoạt động cùng nhau.
Tiếp theo, bạn sẽ tìm hiểu chính xác điều đó. Bài viết này giới thiệu cách kết hợp các loại thử nghiệm này thành các chiến lược hợp lý và chọn một chiến lược phù hợp với dự án của bạn.
Bạn có thể so sánh các chiến lược với một số hình dạng để nắm bắt ý nghĩa của các chiến lược đó rõ ràng hơn. Dưới đây là danh sách các chiến lược có kích thước và phạm vi phát triển tương ứng.
Hãy cùng xem xét kỹ hơn các chiến lược này và tìm hiểu ý nghĩa đằng sau tên của chúng.
Xác định mục tiêu kiểm thử: Bạn muốn đạt được mục tiêu gì với các kiểm thử này?
Trước khi có thể bắt đầu xây dựng một chiến lược hiệu quả, hãy xác định mục tiêu kiểm thử của bạn. Khi nào bạn cho rằng ứng dụng của mình đã được kiểm thử đầy đủ?
Việc đạt được mức độ kiểm thử cao thường được xem là mục tiêu cuối cùng của các nhà phát triển khi nói đến hoạt động kiểm thử. Nhưng đây có phải là phương pháp tốt nhất không? Có thể có một yếu tố quan trọng khác mà bạn cần cân nhắc khi quyết định chiến lược kiểm thử, đó là đáp ứng nhu cầu của người dùng.
Là nhà phát triển, bạn cũng sử dụng nhiều ứng dụng và thiết bị khác. Về mặt này, bạn là người dùng dựa vào tất cả các hệ thống này để "chỉ cần hoạt động". Đổi lại, bạn dựa vào vô số nhà phát triển để họ cố gắng hết sức nhằm đảm bảo ứng dụng và thiết bị của họ hoạt động. Để xoay chuyển tình thế, với tư cách là nhà phát triển, bạn cũng phải nỗ lực để xứng đáng với niềm tin này. Vì vậy, mục tiêu đầu tiên của bạn phải luôn là phân phối phần mềm hoạt động và phục vụ người dùng. Điều này cũng áp dụng cho các bài kiểm thử mà bạn viết để đảm bảo chất lượng ứng dụng. Kent C. Dodds đã tóm tắt rất rõ điều này trong bài đăng Kiểm thử tĩnh so với kiểm thử đơn vị so với kiểm thử tích hợp so với kiểm thử E2E cho ứng dụng giao diện người dùng:
Các chương trình kiểm thử càng giống với cách sử dụng phần mềm của bạn thì bạn càng có thể tin tưởng vào các chương trình kiểm thử đó.
Tác giả: Kent C. Dodds
Kent mô tả điều này là tăng sự tự tin trong kiểm thử. Bạn càng hiểu rõ người dùng bằng cách chọn loại kiểm thử phù hợp, thì bạn càng có thể tin tưởng rằng kiểm thử của mình sẽ có kết quả hợp lệ. Nói cách khác, bạn càng leo lên cao trên kim tự tháp, bạn càng tự tin. Nhưng chờ đã, kim tự tháp là gì?
Xác định chiến lược kiểm thử: Cách chọn chiến lược kiểm thử
Trước tiên, hãy xác định những phần yêu cầu mà bạn cần kiểm tra để đảm bảo đáp ứng. Tìm hiểu loại thử nghiệm nào nên sử dụng và mức độ chi tiết nào bạn có thể đạt được độ tin cậy cao nhất trong khi vẫn duy trì cấu trúc chi phí hiệu quả. Nhiều nhà phát triển tiếp cận chủ đề này bằng cách sử dụng các phép so sánh. Dưới đây là những kiểu phổ biến nhất, bắt đầu bằng kiểu cổ điển nổi tiếng.
Cổ điển: Kim tự tháp kiểm thử
Ngay khi bắt đầu tìm kiếm các chiến lược kiểm thử, bạn có thể sẽ thấy kim tự tháp tự động hoá kiểm thử như là phép so sánh đầu tiên. Mike Cohn đã giới thiệu khái niệm này trong cuốn sách "Thành công với Agile". Sau đó, Martin Fowler đã mở rộng khái niệm này trong bài viết Kim tự tháp kiểm thử thực tế. Bạn có thể biểu thị kim tự tháp một cách trực quan như sau:
Như minh hoạ trong bản vẽ này, kim tự tháp kiểm thử bao gồm 3 lớp:
Đơn vị. Bạn sẽ thấy các kiểm thử này ở lớp cơ sở của kim tự tháp vì chúng có tốc độ thực thi nhanh và dễ bảo trì. Các lớp này được tách biệt và nhắm đến các đơn vị kiểm thử nhỏ nhất. Ví dụ: xem một kiểm thử đơn vị điển hình cho một sản phẩm rất nhỏ.
Tích hợp. Các kiểm thử này nằm ở giữa kim tự tháp vì có tốc độ thực thi chấp nhận được nhưng giúp bạn hiểu rõ hơn về người dùng so với kiểm thử đơn vị. Ví dụ về kiểm thử tích hợp là kiểm thử API. Bạn cũng có thể phân loại kiểm thử thành phần là loại này.
Kiểm thử E2E (còn gọi là kiểm thử giao diện người dùng). Các thử nghiệm này mô phỏng một người dùng thực sự và hoạt động tương tác của họ. Các chương trình kiểm thử như vậy cần nhiều thời gian hơn để thực thi và do đó tốn kém hơn. Chúng nằm ở đỉnh kim tự tháp.
Độ tin cậy so với tài nguyên
Như đã đề cập ngắn gọn trước đó, thứ tự của các lớp không phải là ngẫu nhiên. Các mục này cho biết mức độ ưu tiên và chi phí tương ứng. Điều này giúp bạn nắm rõ số lượng kiểm thử cần viết cho mỗi lớp. Bạn đã thấy điều này trong định nghĩa về các loại kiểm thử.
Vì kiểm thử E2E gần với người dùng nhất, nên kiểm thử này giúp bạn tự tin nhất rằng ứng dụng của bạn đang hoạt động như dự kiến. Tuy nhiên, các thử nghiệm này yêu cầu một ngăn xếp ứng dụng hoàn chỉnh và một người dùng được mô phỏng, do đó, chúng cũng có thể là thử nghiệm tốn kém nhất. Vì vậy, độ tin cậy sẽ cạnh tranh trực tiếp với các tài nguyên bạn cần để thực thi các chương trình kiểm thử.
Kim tự tháp này cố gắng giải quyết vấn đề này bằng cách giúp bạn tập trung nhiều hơn vào kiểm thử đơn vị và ưu tiên nghiêm ngặt các trường hợp được kiểm thử E2E. Ví dụ: hành trình quan trọng nhất của người dùng hoặc những vị trí dễ bị lỗi nhất. Như Martin Fowler nhấn mạnh, hai điểm thiết yếu nhất trong kim tự tháp của Cohn như sau:
- Viết mã kiểm thử theo nhiều mức độ chi tiết.
- Cấp độ càng cao thì bạn càng nên có ít kiểm thử hơn.
Pyramid đã phát triển! Điều chỉnh kim tự tháp kiểm thử
Trong vài năm qua, các cuộc thảo luận đã xoay quanh kim tự tháp. Kim tự tháp này có vẻ như đơn giản hoá quá mức các chiến lược kiểm thử, bỏ qua nhiều loại kiểm thử và không còn phù hợp với tất cả các dự án thực tế. Do đó, thông tin này có thể gây hiểu lầm. Kim tự tháp có bị mất hình dạng không? Guillermo Rauch có ý kiến về vấn đề này:
Viết mã kiểm thử. Không quá nhiều. Chủ yếu là tích hợp.
do Guillermo Rauch
Đây là một trong những câu trích dẫn được trích dẫn thường xuyên nhất về chủ đề này, vì vậy, hãy cùng phân tích:
- "Viết mã kiểm thử". Không chỉ vì việc này giúp tạo dựng niềm tin mà còn giúp tiết kiệm thời gian bảo trì.
- "Không quá nhiều". Mức độ bao phủ 100% không phải lúc nào cũng tốt vì khi đó, hoạt động kiểm thử của bạn sẽ không được ưu tiên và sẽ có nhiều hoạt động bảo trì.
- "Chủ yếu là tích hợp". Ở đây, chúng ta cũng tập trung vào kiểm thử tích hợp: các kiểm thử này có giá trị kinh doanh cao nhất bằng cách cung cấp cho bạn mức độ tin cậy cao hằng ngày trong khi vẫn duy trì thời gian thực thi hợp lý.
Điều này khiến bạn phải suy nghĩ lại về kim tự tháp kiểm thử và chuyển trọng tâm sang kiểm thử tích hợp. Trong vài năm qua, nhiều phương pháp điều chỉnh đã được đề xuất. Hãy cùng xem xét những phương pháp phổ biến nhất.
Kim cương kiểm thử
Phương pháp điều chỉnh đầu tiên giúp loại bỏ việc quá chú trọng vào kiểm thử đơn vị, như trong kim tự tháp kiểm thử. Giả sử bạn đã đạt được mức độ bao phủ 100% đối với kiểm thử đơn vị. Tuy nhiên, lần tiếp theo bạn tái cấu trúc, bạn sẽ phải cập nhật nhiều bài kiểm thử đơn vị này và bạn có thể muốn bỏ qua các bài kiểm thử đó. Vì vậy, chúng bị xói mòn.
Do đó, cùng với việc tập trung nhiều hơn vào kiểm thử tích hợp, hình dạng sau đây có thể xuất hiện:
Kim tự tháp phát triển thành kim cương. Bạn có thể thấy ba lớp trước đó, nhưng có kích thước khác và lớp đơn vị đã bị cắt:
- Đơn vị. Viết mã kiểm thử đơn vị theo cách bạn đã xác định trước đó. Tuy nhiên, vì các vấn đề này có xu hướng bị xói mòn, nên bạn chỉ nên ưu tiên và chỉ xử lý những trường hợp nghiêm trọng nhất.
- Tích hợp. Các bài kiểm thử tích hợp mà bạn đã biết, kiểm thử sự kết hợp của các đơn vị đơn lẻ.
- E2E. Lớp này xử lý các kiểm thử giao diện người dùng tương tự như kim tự tháp kiểm thử. Hãy cẩn thận chỉ viết kiểm thử E2E cho các trường hợp kiểm thử quan trọng nhất.
Kiểm thử dạng tổ ong
Có một phương pháp điều chỉnh khác do Spotify giới thiệu, tương tự như kim cương kiểm thử nhưng chuyên biệt hơn cho các hệ thống phần mềm dựa trên dịch vụ vi mô. Lưới hình tổ ong kiểm thử là một hình ảnh tương tự khác cho mức độ chi tiết, phạm vi và số lượng kiểm thử cần viết cho một hệ thống phần mềm dựa trên dịch vụ vi mô. Do kích thước nhỏ, độ phức tạp đáng kể nhất trong một dịch vụ vi mô không phải nằm trong chính dịch vụ đó, mà là cách dịch vụ đó tương tác với các dịch vụ khác. Vì vậy, chiến lược kiểm thử cho một dịch vụ vi mô chủ yếu nên tập trung vào kiểm thử tích hợp.
Hình dạng này khiến chúng ta liên tưởng đến tổ ong, do đó có tên như vậy. Lớp này có các lớp sau:
- Kiểm thử tích hợp. Bài viết của Spotify có trích dẫn của J. B. Rainsberger để xác định lớp này: "Một kiểm thử sẽ đạt hoặc không đạt dựa trên độ chính xác của một hệ thống khác". Những kiểm thử như vậy có các phần phụ thuộc bên ngoài mà bạn cần xem xét và ngược lại, hệ thống của bạn có thể là một phần phụ thuộc làm hỏng các hệ thống khác. Tương tự như kiểm thử E2E trong các phép so sánh khác, hãy sử dụng các kiểm thử này một cách thận trọng, chỉ dành cho những trường hợp thiết yếu nhất.
- Kiểm thử tích hợp. Tương tự như các nội dung điều chỉnh khác, bạn nên tập trung vào lớp này. Trong đó có các bài kiểm thử xác minh tính chính xác của dịch vụ theo cách tách biệt hơn, nhưng vẫn kết hợp với các dịch vụ khác. Điều đó có nghĩa là các bài kiểm thử cũng sẽ bao gồm một số hệ thống khác và tập trung vào các điểm tương tác, chẳng hạn như thông qua kiểm thử API.
- Kiểm thử thông tin chi tiết về cách triển khai. Các kiểm thử này tương tự như kiểm thử đơn vị – kiểm thử tập trung vào các phần mã được tách biệt một cách tự nhiên và do đó có độ phức tạp nội bộ riêng.
Nếu bạn muốn tìm hiểu thêm về chiến lược kiểm thử này, hãy xem bài đăng so sánh kim tự tháp kiểm thử với tổ ong của Martin Fowler và bài viết gốc của Spotify.
Cúp kiểm thử
Bạn có thể thấy một tiêu điểm lặp lại về kiểm thử tích hợp. Tuy nhiên, một loại khác mà bạn đã gặp trong bài viết trước không phải là kiểm thử theo lý thuyết nhưng vẫn là một khía cạnh quan trọng mà bạn nên cân nhắc trong chiến lược kiểm thử. Phân tích tĩnh bị thiếu trong kim tự tháp kiểm thử và trong hầu hết các phương pháp điều chỉnh mà bạn đã thấy cho đến nay. Có sự điều chỉnh về huy hiệu kiểm thử để tính đến việc phân tích tĩnh trong khi vẫn tập trung vào kiểm thử tích hợp. Cúp kiểm thử bắt nguồn từ câu nói trước đó của Guillermo Rauch và được phát triển bởi Kent C. Dodds:
Cúp kiểm thử là một hình ảnh tương tự mô tả mức độ chi tiết của các bài kiểm thử theo cách hơi khác. Cấu trúc này có 4 lớp:
- Phân tích tĩnh. Công cụ này đóng vai trò quan trọng trong phép so sánh này và cho phép bạn phát hiện lỗi chính tả, lỗi kiểu và các lỗi khác chỉ bằng cách chạy các bước gỡ lỗi đã được nêu.
- Kiểm thử đơn vị. Các bài kiểm thử này đảm bảo rằng đơn vị nhỏ nhất của bạn được kiểm thử thích hợp, nhưng huy hiệu kiểm thử sẽ không nhấn mạnh các bài kiểm thử này ở mức độ tương tự như kim tự tháp kiểm thử.
- Tích hợp. Đây là trọng tâm chính vì nó cân bằng chi phí và độ tin cậy cao hơn theo cách tốt nhất, giống như các phương pháp điều chỉnh khác.
- Kiểm thử giao diện người dùng. Bao gồm cả kiểm thử E2E và kiểm thử hình ảnh, các kiểm thử này nằm ở vị trí cao nhất của danh hiệu kiểm thử, tương tự như vai trò của chúng trong kim tự tháp kiểm thử.
Để đọc thêm về huy chương kiểm thử, hãy xem bài đăng trên blog của Kent C. Dodds về chủ đề này.
Một số phương pháp khác tập trung vào giao diện người dùng
Tất cả đều tốt, nhưng bất kể bạn gọi chiến lược của mình là "kim tự tháp", "lưới tổ ong" hay "kim cương", thì vẫn còn thiếu một điều gì đó. Mặc dù việc tự động hoá kiểm thử rất có giá trị, nhưng bạn cần nhớ rằng kiểm thử thủ công vẫn rất cần thiết. Tính năng kiểm thử tự động sẽ giúp giảm bớt các công việc thường xuyên và giúp kỹ sư đảm bảo chất lượng tập trung vào các khía cạnh quan trọng. Thay vì thay thế quy trình kiểm thử thủ công, quy trình tự động hoá nên bổ sung cho quy trình này. Có cách nào để tích hợp quy trình kiểm thử thủ công với quy trình tự động để đạt được kết quả tối ưu không?
Kiểm thử ốc quế và kiểm thử cua
Thực sự có hai cách điều chỉnh kim tự tháp kiểm thử tập trung nhiều hơn vào các phương pháp kiểm thử tập trung vào giao diện người dùng này. Cả hai đều có ưu điểm là độ tin cậy cao, nhưng đương nhiên sẽ tốn kém hơn do quá trình thực thi kiểm thử chậm hơn.
Hình đầu tiên, hình nón kem thử nghiệm, trông giống như kim tự tháp đảo ngược. Nếu không có bước kiểm thử thủ công, quy trình này còn được gọi là pizza kiểm thử.
Kiểu ly kem này tập trung nhiều hơn vào kiểm thử thủ công hoặc kiểm thử giao diện người dùng và ít tập trung nhất vào kiểm thử đơn vị. Lỗi này thường xảy ra trong các dự án mà nhà phát triển bắt đầu công việc chỉ với một vài suy nghĩ về chiến lược kiểm thử. Mã băng được coi là một mẫu chống và đúng như vậy. Mã này tốn kém về tài nguyên và công việc thủ công.
Cua kiểm thử tương tự như kem ốc quế kiểm thử, nhưng tập trung nhiều hơn vào kiểm thử toàn diện và kiểm thử hình ảnh:
Chiến lược kiểm thử này còn bao gồm một khía cạnh nữa: xác minh rằng ứng dụng của bạn hoạt động và trông đẹp mắt. Cua kiểm thử nêu bật tầm quan trọng của kiểm thử hình ảnh, được xác định trong bài viết trước. Kiểm thử tích hợp, được chia thành kiểm thử thành phần và kiểm thử API, sẽ chuyển sang chế độ nền và kiểm thử đơn vị đóng vai trò phụ hơn nữa ở đây. Bạn có thể xem thêm thông tin chi tiết về chiến lược kiểm thử này trong bài viết về cua kiểm thử.
Mặc dù tốn kém hơn, nhưng hai chiến lược kiểm thử này vẫn có vị trí riêng: ví dụ: trong các dự án nhỏ hơn, nơi cần ít kiểm thử hơn hoặc cần kiểm thử ít phức tạp hơn. Trong trường hợp này, một chiến lược kiểm thử toàn diện tập trung vào kiểm thử tích hợp có thể là quá phức tạp.
Mặc dù hai chiến lược kiểm thử này tốn kém hơn, nhưng chúng vẫn có vị trí riêng, chẳng hạn như trong các dự án nhỏ hơn đòi hỏi ít kiểm thử hơn và không cần phải bao gồm nhiều yếu tố phức tạp. Trong trường hợp này, chiến lược kiểm thử toàn diện tập trung vào kiểm thử tích hợp có thể không cần thiết phải phức tạp.
Lời khuyên thực tế: Hãy lập chiến lược!
Giờ đây, bạn đã tìm hiểu về các chiến lược kiểm thử phổ biến nhất. Bạn đã bắt đầu với kim tự tháp kiểm thử kinh điển và tìm hiểu nhiều cách điều chỉnh kim tự tháp này. Bây giờ, bạn cần đánh giá các công cụ này cho sản phẩm của mình và quyết định công cụ nào phù hợp nhất với dự án của bạn. Câu trả lời cho câu hỏi này phải bắt đầu bằng cụm từ "Tuỳ thuộc" mà mọi người đều yêu thích. Tuy nhiên, điều đó không làm giảm độ chính xác của kết quả.
Việc lựa chọn chiến lược kiểm thử phù hợp nhất trong số các chiến lược được mô tả (và thậm chí cả những chiến lược bị bỏ qua) phụ thuộc vào ứng dụng của bạn. Kiến trúc này phải phù hợp với cấu trúc, yêu cầu của bạn và quan trọng nhất là người dùng và yêu cầu của họ. Tất cả những điều này có thể khác nhau tuỳ theo ứng dụng. Điều đó hoàn toàn bình thường. Hãy nhớ rằng mục tiêu quan trọng nhất của bạn là phục vụ người dùng, chứ không phải là một định nghĩa trong sách giáo khoa.
Thông thường, các bài kiểm thử thực tế rất khó tách biệt và xác định riêng lẻ. Ngay cả chính Martin Fowler cũng nhấn mạnh phương diện tích cực của các định nghĩa khác nhau, chẳng hạn như trong trường hợp kiểm thử đơn vị. Như Justin Searls đã nêu chính xác trong thông báo trên Twitter:
[…] viết các chương trình kiểm thử rõ ràng giúp thiết lập ranh giới rõ ràng, chạy nhanh và đáng tin cậy, đồng thời chỉ thất bại vì những lý do hữu ích.
do Justin Searls
Hãy tập trung vào các kiểm thử báo cáo lỗi thực tế mà người dùng có thể gặp phải và đừng bị phân tâm khỏi mục tiêu của bạn. Bạn nên thiết kế kiểm thử để mang lại lợi ích cho người dùng, chứ không chỉ để cung cấp 100% phạm vi kiểm thử hoặc để tranh luận về tỷ lệ phần trăm của loại kiểm thử nào cần viết.
Hãy tập trung vào các kiểm thử báo cáo lỗi thực tế mà người dùng có thể gặp phải và không làm bạn mất tập trung vào mục tiêu. Bạn nên thiết kế kiểm thử để mang lại lợi ích cho người dùng, chứ không chỉ để cung cấp phạm vi kiểm thử 100% hoặc để tạo ra cuộc tranh luận về tỷ lệ phần trăm của một loại kiểm thử cụ thể mà bạn nên viết.