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