Xác định các trường hợp kiểm thử và mức độ ưu tiên

Xác định nội dung cần kiểm thử, xác định các trường hợp kiểm thử và ưu tiên.

Ramona Schwering

Trong bài đăng trước, bạn đã tìm hiểu về các chiến lược kiểm thử, số lượng kiểm thử cần thiết để kiểm thử một ứng dụng và cách tìm ra chiến lược phù hợp nhất để có được kết quả đáng tin cậy nhất trong khi vẫn cân nhắc đến tài nguyên của bạn. Tuy nhiên, điều này chỉ cho chúng ta biết lượng dữ liệu cần kiểm thử. Bạn vẫn cần xác định chính xác nội dung cần kiểm thử. Ba tiêu chí sau đây có thể giúp bạn hiểu rõ những gì cần làm trong một kiểm thử, cũng như xem loại kiểm thử và mức độ chi tiết nào phù hợp nhất:

1. Chăm sóc đường dẫn hạnh phúc của bạn. Đây là câu chuyện người dùng chung nhất hoặc chính của ứng dụng, trong đó người dùng sẽ nhanh chóng nhận thấy lỗi.
2. Quyết định kỹ lưỡng về mức độ chi tiết. Hãy tìm hiểu thêm thông tin chi tiết nếu trường hợp sử dụng của bạn dễ bị tấn công hoặc nếu lỗi có thể gây ra thiệt hại lớn.
3. Ưu tiên các kiểm thử cấp thấp hơn, chẳng hạn như kiểm thử đơn vị và kiểm thử tích hợp, so với kiểm thử toàn diện cấp cao hơn bất cứ khi nào có thể.

Phần còn lại của bài viết này sẽ khám phá các tiêu chí này và cách áp dụng các tiêu chí này khi bạn xác định các trường hợp kiểm thử.

Trường hợp kiểm thử là gì?

Trong quá trình phát triển phần mềm, trường hợp kiểm thử là một chuỗi các hành động hoặc tình huống được thiết kế để xác nhận hiệu quả của một chương trình hoặc ứng dụng phần mềm. Mục đích của một trường hợp kiểm thử là đảm bảo rằng phần mềm hoạt động như dự kiến và tất cả các tính năng và chức năng của phần mềm đều hoạt động chính xác. Người kiểm thử hoặc nhà phát triển phần mềm thường tạo các trường hợp kiểm thử này để đảm bảo rằng phần mềm đáp ứng các yêu cầu và thông số kỹ thuật đã chỉ định.

Khi một trường hợp kiểm thử được chạy, phần mềm sẽ thực hiện một loạt các bước kiểm tra để đảm bảo trường hợp kiểm thử đó tạo ra kết quả mong muốn. Trong khi thực hiện việc đó, kiểm thử sẽ thực hiện các nhiệm vụ sau:

• Xác minh. Quy trình kiểm tra kỹ lưỡng phần mềm để đảm bảo phần mềm hoạt động mà không gặp lỗi. Điều quan trọng là phải xác định xem sản phẩm được tạo có đáp ứng tất cả các yêu cầu không chức năng cần thiết và đạt được mục đích dự kiến hay không. Câu hỏi mà báo cáo này trả lời là: "Chúng ta có đang xây dựng sản phẩm đúng cách không?"
• Xác thực. Quy trình đảm bảo rằng sản phẩm phần mềm đáp ứng các tiêu chuẩn cần thiết hoặc các yêu cầu cấp cao. Quy trình này bao gồm việc kiểm tra xem sản phẩm thực tế có khớp với sản phẩm dự kiến hay không. Về cơ bản, chúng ta đang trả lời câu hỏi: "Chúng ta có đang xây dựng sản phẩm phù hợp với yêu cầu của người dùng không?"

Giả sử chương trình không mang lại kết quả như mong đợi. Trong trường hợp đó, trường hợp kiểm thử sẽ là người đưa tin, do đó sẽ báo cáo kết quả không thành công và nhà phát triển hoặc người kiểm thử sẽ cần điều tra vấn đề và tìm giải pháp. Hãy coi các bước kiểm tra và hành động là đường dẫn mà máy tính tuân theo, bất kể loại kiểm thử. Các nhóm dữ liệu đầu vào hoặc điều kiện dùng để kiểm tra được gọi là "lớp tương đương". Các hệ thống này sẽ nhận được hành vi hoặc kết quả tương tự từ hệ thống đang được kiểm thử. Các đường dẫn cụ thể được thực thi bên trong một kiểm thử có thể khác nhau nhưng phải khớp với các hoạt động và câu nhận định được thực hiện trong kiểm thử.

Đường dẫn kiểm thử: Các loại trường hợp kiểm thử thông thường

Trong quá trình phát triển phần mềm, trường hợp kiểm thử là một tình huống thực thi mã, từ đó dự kiến và kiểm thử một hành vi nhất định. Thông thường, có 3 trường hợp để tạo các trường hợp kiểm thử.

Phương thức đầu tiên là phương thức phổ biến nhất và có thể bạn đang sử dụng. Đây là đường dẫn suôn sẻ, còn gọi là "trường hợp ngày tốt lành" hoặc "đường dẫn vàng". Đường dẫn này xác định trường hợp sử dụng phổ biến nhất của tính năng, ứng dụng hoặc thay đổi của bạn — cách tính năng, ứng dụng hoặc thay đổi đó hoạt động hiệu quả cho khách hàng.

Đường dẫn kiểm thử quan trọng thứ hai cần được đề cập trong các trường hợp kiểm thử thường bị bỏ qua vì không thoải mái – như tên gọi của nó. Đây là "đường dẫn đáng sợ", hay nói cách khác là kiểm thử âm. Đường dẫn này nhắm đến các tình huống khiến mã hoạt động không đúng cách hoặc chuyển sang trạng thái lỗi. Việc kiểm thử những trường hợp này đặc biệt quan trọng nếu bạn có các trường hợp sử dụng dễ bị xâm phạm, gây rủi ro cao cho các bên liên quan hoặc người dùng.

Có một số đường dẫn khác mà bạn nên biết và cân nhắc sử dụng, nhưng thường thì chúng ít được sử dụng hơn. Bảng sau đây tóm tắt các thay đổi đó:

Có một số phương pháp để phân loại các đường dẫn đó. Có hai phương pháp phổ biến là:

• Phân vùng tương đương. Phương thức kiểm thử phân loại các trường hợp kiểm thử thành các nhóm hoặc phân vùng, nhờ đó giúp tạo các lớp tương đương. Điều này dựa trên ý tưởng rằng nếu một trường hợp kiểm thử trong một phân vùng phát hiện ra một lỗi, thì các trường hợp kiểm thử khác trong cùng một phân vùng có thể sẽ cho thấy các lỗi tương tự. Vì tất cả dữ liệu đầu vào trong một lớp tương đương cụ thể phải thể hiện hành vi giống hệt nhau, nên bạn có thể giảm số lượng trường hợp kiểm thử. Tìm hiểu thêm về việc phân vùng tương đương.
• Phân tích giới hạn. Một phương thức kiểm thử, còn gọi là phân tích giá trị biên, kiểm tra các giới hạn hoặc giá trị cực đại của giá trị đầu vào để tìm mọi vấn đề hoặc lỗi tiềm ẩn có thể phát sinh ở giới hạn về khả năng hoặc quy tắc ràng buộc của hệ thống.

Phương pháp hay nhất: Viết trường hợp kiểm thử

Một trường hợp kiểm thử cổ điển do người kiểm thử viết sẽ chứa dữ liệu cụ thể để giúp bạn nắm bắt nội dung của kiểm thử mà bạn muốn tiến hành và tất nhiên là thực thi kiểm thử. Một người kiểm thử thông thường sẽ ghi lại nỗ lực kiểm thử của họ trong một bảng. Có hai mẫu mà chúng ta có thể sử dụng ở giai đoạn này, giúp chúng ta định cấu trúc các trường hợp kiểm thử và sau đó là chính các kiểm thử:

• Mẫu Sắp xếp, hành động, xác nhận. Mẫu kiểm thử "sắp xếp, hành động, xác nhận" (còn gọi là "AAA" hoặc "Ba A") là một cách sắp xếp các bài kiểm thử thành ba bước riêng biệt: sắp xếp bài kiểm thử, sau đó thực hiện bài kiểm thử và cuối cùng là rút ra kết luận.
• Mẫu Given, when, then. Mẫu này tương tự như mẫu AAA nhưng có một số điểm xuất phát từ phát triển do hành vi thúc đẩy.

Các bài viết sau này sẽ trình bày chi tiết hơn về các mẫu này, ngay khi chúng ta đề cập đến cấu trúc của chính một bài kiểm thử. Nếu bạn muốn tìm hiểu sâu hơn về các mẫu này ở giai đoạn này, hãy xem hai bài viết sau: Arrange-Act-Assert: A pattern for writing good tests (Sắp xếp-Hành động-Xác nhận: Một mẫu để viết mã kiểm thử hiệu quả) và Given-When-Then (Điều kiện-Thời điểm-Sau đó).

Theo tất cả những điều đã học được từ bài viết này, bảng sau đây tóm tắt một ví dụ kinh điển:

Trong kiểm thử tự động, bạn không cần phải ghi lại tất cả các trường hợp kiểm thử này theo cách mà người kiểm thử cần, mặc dù việc này chắc chắn sẽ hữu ích. Bạn có thể tìm thấy tất cả thông tin này trong kiểm thử nếu chú ý. Vì vậy, hãy chuyển đổi trường hợp kiểm thử cổ điển này thành một kiểm thử tự động.