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.

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.

Trường hợp kiểm thử đang xác minh.

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ử.

Đường dẫn suôn sẻ.

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 đi đáng sợ.

Đườ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 đó:

Đường dẫn kiểm thử Giải thích
Đường dẫn tức giận Điều này dẫn đến lỗi, nhưng là lỗi dự kiến; ví dụ: nếu bạn muốn đảm bảo việc xử lý lỗi hoạt động đúng cách.
Đường dẫn quá hạn Đường dẫn này xử lý mọi tình huống liên quan đến bảo mật mà ứng dụng của bạn cần thực hiện.
Đường vắng Đường dẫn kiểm thử trường hợp trong ứng dụng của bạn không nhận đủ dữ liệu để hoạt động, ví dụ: kiểm thử giá trị rỗng.
Đường dẫn quên Kiểm thử hành vi của ứng dụng khi không có đủ tài nguyên, chẳng hạn như kích hoạt tình trạng mất dữ liệu.
Đường dẫn không quyết định Kiểm thử với một người dùng đang cố gắng thực hiện các hành động hoặc làm theo các câu chuyện người dùng trong ứng dụng của bạn nhưng chưa hoàn tất các quy trình công việc đó. Điều này có thể xảy ra, chẳng hạn như khi người dùng làm gián đoạn quy trình làm việc của họ.
Đường dẫn tham lam Cố gắng kiểm thử bằng cách sử dụng một lượng lớn dữ liệu đầu vào.
Đường dẫn gây căng thẳng Cố gắng tải ứng dụng của bạn bằng mọi phương tiện cần thiết cho đến khi ứng dụng không còn hoạt động (tương tự như kiểm thử tả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:

Thông tin Giải thích
Điều kiện tiên quyết Mọi việc cần làm trước khi viết mã kiểm thử.
Đối tượng đang được kiểm thử Những thông tin nào cần được xác minh?
Dữ liệu đầu vào Biến và giá trị của biến.
Các bước cần thực thi Tất cả những việc bạn sẽ làm để kiểm thử: tất cả hành động hoặc lượt tương tác bạn thực hiện trong kiểm thử.
Kết quả dự kiến Điều gì sẽ xảy ra và những kỳ vọng nào cần được đáp ứng.
Kết quả thực tế Điều thực sự xảy ra.

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.

Thông tin Dịch sang tự động hoá kiểm thử
Điều kiện tiên quyết Tất cả những gì bạn cần, sắp xếp kiểm thử và suy nghĩ về những gì được cung cấp để tạo ra trường hợp kiểm thử.
Đối tượng đang được kiểm thử "Đối tượng" này có thể là nhiều thứ: một ứng dụng, luồng, đơn vị hoặc thành phần đang được kiểm thử.
Dữ liệu đầu vào Giá trị tham số.
Các bước cần thực thi Tất cả các hành động và lệnh được thực thi bên trong kiểm thử, những việc bạn làm và tìm hiểu điều gì sẽ xảy ra khi bạn làm một số việc nhất định.
Kết quả dự kiến Câu nhận định mà bạn sử dụng để xác thực ứng dụng, những điều bạn xác nhận trong ứng dụng.
Kết quả thực tế Kết quả của kiểm thử tự động.