“Test scenario” (kịch bản kiểm thử) và “test case” (trường hợp kiểm thử) thường được sử dụng như thể chúng có cùng ý nghĩa. Nhưng thực ra không phải vậy. Việc nhầm lẫn giữa chúng là nguyên nhân khiến các kế hoạch kiểm thử trở nên quá mơ hồ để thực hiện hoặc quá chi tiết để đọc. Một thuật ngữ mô tả cái gì cần kiểm thử; thuật ngữ còn lại mô tả chính xác cách thức kiểm thử. Hiểu đúng mối quan hệ này sẽ giúp phạm vi kiểm thử của bạn vừa có thể kiểm toán được vừa có thể chạy được.
Hướng dẫn này định nghĩa từng thuật ngữ, trình bày sự khác biệt giữa chúng và chỉ ra cách hai thuật ngữ này hoạt động cùng nhau trong một quy trình kiểm thử API thực tế bằng cách sử dụng Apidog.
Kịch bản kiểm thử là gì?
Kịch bản kiểm thử là một tuyên bố cấp cao về một điều gì đó đáng để kiểm thử. Nó nêu tên một hành vi hoặc điều kiện mà không chỉ rõ các bước, đầu vào hoặc giá trị mong đợi chính xác.
Hãy nghĩ nó như một tiêu đề. Đối với quy trình thanh toán thương mại điện tử, các kịch bản có thể là:
- Xác minh thanh toán cho người dùng đã đăng ký với thẻ đã lưu
- Xác minh thanh toán cho người dùng khách
- Xác minh thanh toán khi một mặt hàng hết hàng trong quá trình mua hàng
- Xác minh thanh toán khi bị từ chối
Mỗi dòng cho bạn biết cái gì cần xác thực và tại sao nó quan trọng đối với doanh nghiệp. Không dòng nào cho bạn biết cần gọi đến endpoint nào hay gửi payload gì. Một kịch bản được viết từ quan điểm của người dùng hoặc yêu cầu, vì vậy nó vẫn dễ đọc đối với cả quản lý sản phẩm và kỹ sư.
Các kịch bản trả lời một câu hỏi: liệu chúng ta đã nghĩ đến mọi thứ cần hoạt động chưa? Chúng là bản đồ phạm vi kiểm thử. Nếu một kịch bản bị thiếu, thì dù có bao nhiêu trường hợp kiểm thử chi tiết cũng không thể lấp đầy khoảng trống đó.
Trường hợp kiểm thử là gì?
Trường hợp kiểm thử là một kiểm tra cụ thể, có thể chạy được, nằm bên dưới một kịch bản. Nó chỉ định chính xác đầu vào, điều kiện tiên quyết, hành động và kết quả mong đợi, với độ chính xác đủ để hai người thực hiện nó sẽ nhận được cùng một kết quả.
Lấy kịch bản “xác minh thanh toán cho người dùng khách.” Nó được chia thành các trường hợp như:
POST /ordersvới payload khách hợp lệ trả về201và mộtorder_idPOST /orderskhông có địa chỉ giao hàng trả về400và mộtvalidation_errorPOST /ordersvới SKU hết hàng trả về409vàerror: out_of_stock
Mỗi trường hợp nêu tên endpoint, nội dung, trạng thái mong đợi và các trường phản hồi mong đợi. Nó đủ cụ thể để tự động hóa. Nếu bạn muốn có phân tích chi tiết từng trường của một trường hợp, bài viết cách viết các trường hợp kiểm thử API sẽ trình bày chi tiết mẫu, và test case vs test script làm rõ vị trí của mã có thể chạy được.
Đặc điểm nổi bật của một trường hợp kiểm thử là tính chính xác. “Thanh toán hoạt động” cùng lắm chỉ là một đoạn kịch bản. “POST một đơn hàng khách hợp lệ, mong đợi 201 với một order_id không rỗng” là một trường hợp kiểm thử.
Những điểm khác biệt chính
Hai khái niệm này khác nhau ở nhiều khía cạnh. Bảng này là phiên bản tóm tắt.
| Khía cạnh | Kịch bản kiểm thử (Test scenario) | Trường hợp kiểm thử (Test case) |
|---|---|---|
| Cấp độ | Cấp cao, cái gì cần kiểm thử | Cấp thấp, cách thức kiểm thử |
| Chi tiết | Ngắn gọn, một dòng | Từng bước với dữ liệu |
| Trọng tâm | Mục tiêu kinh doanh hoặc chức năng | Thực thi kỹ thuật |
| Đầu vào | Không xác định | Payload và tham số chính xác |
| Kết quả mong đợi | Ngụ ý | Nêu rõ chính xác (trạng thái, nội dung, thời gian) |
| Đối tượng | Sản phẩm, QA, kỹ thuật | Người kiểm thử và công cụ tự động hóa |
| Số lượng | Ít cho mỗi tính năng | Nhiều cho mỗi kịch bản |
| Tạo ra | Trong quá trình lập kế hoạch kiểm thử | Sau khi các kịch bản được thống nhất |
Mối quan hệ là phân cấp. Một kịch bản sinh ra nhiều trường hợp. Kịch bản kiểm soát độ rộng của phạm vi kiểm thử; các trường hợp kiểm soát chiều sâu và độ chặt chẽ. Một lỗi phổ biến là viết hàng tá trường hợp chi tiết mà không có bản đồ kịch bản nào ở trên chúng, điều này khiến không thể biết liệu tính năng có được bao phủ đầy đủ hay chỉ được kiểm thử mạnh mẽ ở một góc.
Một cách khác để nhìn nhận: một kịch bản có thể được đánh dấu là “đã bao phủ” hoặc “chưa bao phủ.” Một trường hợp kiểm thử chỉ có thể được đánh dấu là “đã qua” hoặc “đã thất bại.” Bạn cần cả hai trạng thái để quản lý chất lượng.
Cách kịch bản và trường hợp kiểm thử hoạt động cùng nhau
Một quy trình làm việc thực tế chuyển từ tổng quát đến cụ thể theo năm bước.
1. Xác định các kịch bản từ yêu cầu. Đọc đặc tả hoặc tài liệu API và liệt kê mọi hành vi đáng xác minh, bao gồm cả các luồng không mong muốn (unhappy paths). Đây là nơi phát hiện ra phạm vi kiểm thử bị thiếu, vì vậy hãy dành thời gian thực sự cho bước này.
2. Xác định mục tiêu của từng kịch bản. Nêu rõ ý nghĩa của “hoàn thành”. Đối với “xác minh thanh toán khách,” mục tiêu là một khách hàng có thể đặt hàng và nhận được xác nhận, trong khi các đơn hàng không hợp lệ bị từ chối một cách rõ ràng.
3. Viết các trường hợp kiểm thử dưới mỗi kịch bản. Mở rộng mỗi kịch bản thành các trường hợp cụ thể với đầu vào và kết quả mong đợi. Bao gồm luồng chính (happy path), mọi lỗi xác thực và các điều kiện biên liên quan.
4. Đánh giá tính đầy đủ. Quay lại cây cấu trúc. Liệu mỗi kịch bản có ít nhất một trường hợp luồng chính và một trường hợp tiêu cực không? Liệu mọi mã trạng thái được ghi lại có xuất hiện trong một số kết quả mong đợi không? Những khoảng trống được tìm thấy ở đây thì rẻ; những khoảng trống được tìm thấy trong sản xuất thì không.
5. Thực thi và theo dõi kết quả. Chạy các trường hợp, ghi lại trạng thái đạt/không đạt cho từng trường hợp, và tổng hợp kết quả lên cấp kịch bản để các bên liên quan thấy được phạm vi kiểm thử, không chỉ là số lượng dấu tích xanh.
Đối với các nhóm định hướng hành vi (behavior-driven teams), các kịch bản ánh xạ tự nhiên vào định dạng Given-When-Then của Gherkin; hướng dẫn Gherkin cho kiểm thử API BDD cho thấy cấu trúc đó giữ cho các kịch bản dễ đọc trong khi vẫn có thể thực thi được.
Một ví dụ minh họa: từ kịch bản đến các trường hợp
Lấy một API cho một ứng dụng ghi chú, với một hành vi duy nhất đáng để kiểm thử: người dùng có thể tạo một ghi chú. Đó là kịch bản.
Kịch bản: Người dùng có thể tạo một ghi chú. Một dòng. Nó thuộc về kế hoạch kiểm thử, dễ đọc bởi bất kỳ ai. Nó không đề cập đến endpoint, payload, hoặc mã trạng thái, và không nên.
Bây giờ hãy mở rộng nó thành các trường hợp. Mỗi trường hợp là một kiểm tra có thể chạy được với đầu vào chính xác và kết quả mong đợi chính xác.
- Trường hợp 1, luồng chính (happy path).
POST /notesvới{"title": "Groceries", "body": "milk, eggs"}và một token hợp lệ. Mong đợi201, một thân phản hồi vớiidkhông rỗng,titlebằngGroceries, và một dấu thời giancreated_at. Phản hồi dưới 600 ms. - Trường hợp 2, thiếu trường bắt buộc.
POST /notesvới{"body": "milk, eggs"}và một token hợp lệ. Mong đợi400,errorbằngvalidation_error, vàdetailsnêu tên trườngtitle. - Trường hợp 3, chưa xác thực.
POST /notesvới một thân hợp lệ và không có token. Mong đợi401và không cóidtrong phản hồi. - Trường hợp 4, payload quá lớn.
POST /notesvớibody2 MB. Mong đợi413và một thông báo lỗi rõ ràng.
Một kịch bản, bốn trường hợp. Kịch bản cho bạn biết cái gì; các trường hợp cho bạn biết cách thức, với độ chính xác đủ để bất kỳ người kiểm thử hoặc công cụ tự động nào cũng đưa ra cùng một phán quyết. Nếu sau này bạn thêm “người dùng có thể đính kèm một tệp vào ghi chú,” đó là một kịch bản mới, và nó sinh ra một tập hợp các trường hợp riêng. Kế hoạch phát triển theo một cách có cấu trúc, có thể kiểm toán được thay vì trở thành một đống các kiểm tra.
Xây dựng kịch bản và trường hợp kiểm thử trong Apidog
Apidog mô hình hóa trực tiếp hệ thống phân cấp này, vì vậy cấu trúc trong kế hoạch kiểm thử của bạn khớp với cấu trúc trong công cụ của bạn.
Một kịch bản kiểm thử trong Apidog là một chuỗi các yêu cầu API có thứ tự, mỗi yêu cầu có các xác nhận riêng. Bạn xây dựng nó một cách trực quan: thêm các endpoint liên quan đến hành vi, xâu chuỗi chúng để đầu ra của một yêu cầu cung cấp cho yêu cầu tiếp theo (một đăng nhập trả về một token, yêu cầu tiếp theo sử dụng nó), và đặt các xác nhận trên mỗi bước.
Mỗi khối yêu cầu-cộng-xác nhận thực chất là một trường hợp kiểm thử. Bạn xác nhận mã trạng thái, các trường trong thân phản hồi, sự phù hợp với lược đồ (schema conformance), và thời gian phản hồi bằng cách nhấp chuột, mà không cần viết script. Kiểm thử dựa trên dữ liệu cho phép một trường hợp chạy với nhiều hàng đầu vào từ tệp CSV hoặc JSON, vì vậy một trường hợp tiêu cực duy nhất có thể bao phủ mọi sự kết hợp không hợp lệ.
Các kịch bản sau đó được nhóm thành bộ kiểm thử để thực hiện các lần chạy có tổ chức, lặp lại trên toàn bộ API. Bạn có thể chạy một bộ kiểm thử cục bộ, theo lịch trình, hoặc trong CI, và Apidog tạo ra một báo cáo hiển thị kết quả ở cả cấp độ trường hợp và cấp độ kịch bản. Chế độ xem kép đó là phần thưởng: các kỹ sư thấy trường hợp nào thất bại, và các nhà lãnh đạo thấy kịch bản nào đang gặp rủi ro.
Tải xuống Apidog để xây dựng kịch bản đầu tiên của bạn và xem cách tổng hợp từ trường hợp lên kịch bản trong thực tế.
Tại sao bạn cần cả hai, không phải một
Các nhóm đôi khi cố gắng bỏ qua một lớp. Bỏ qua các kịch bản và chỉ viết các trường hợp sẽ tạo ra một danh sách dài, phẳng không có bản đồ bao phủ; bạn không thể trả lời “chúng tôi đã kiểm thử thanh toán khách đầy đủ chưa?” mà không đọc lại từng trường hợp. Bỏ qua các trường hợp và chỉ giữ lại các kịch bản sẽ tạo ra một kế hoạch mà không ai có thể thực hiện một cách nhất quán, vì “xác minh thanh toán” có ý nghĩa khác nhau đối với mỗi người kiểm thử.
Hai lớp này cũng phục vụ các đối tượng đọc khác nhau. Một quản lý sản phẩm đọc các kịch bản để xác nhận rằng những điều đúng đang được kiểm thử. Một kỹ sư tự động hóa đọc các trường hợp để xây dựng các công cụ chạy. Một báo cáo kiểm thử chỉ hiển thị các trường hợp đã qua không cho ban lãnh đạo biết gì về phạm vi bao phủ; một báo cáo tổng hợp các trường hợp lên các kịch bản cho họ biết chính xác những tính năng nào an toàn để phát hành.
Giữ các kịch bản ổn định và các trường hợp được cập nhật. Các kịch bản chỉ thay đổi khi ý định của tính năng thay đổi. Các trường hợp thay đổi bất cứ khi nào hợp đồng API thay đổi. Khi bạn coi chúng là các tạo phẩm riêng biệt với các vòng đời riêng biệt, kế hoạch kiểm thử của bạn sẽ luôn chính xác và dễ bảo trì.
Các câu hỏi thường gặp
Kịch bản kiểm thử có giống như bộ kiểm thử không? Không. Một kịch bản mô tả một hành vi cần kiểm thử. Một bộ là một tập hợp các kiểm thử có thể thực thi được nhóm lại để chạy. Một bộ có thể chứa các trường hợp từ nhiều kịch bản. Xem test suite vs test case.
Một kịch bản nên có bao nhiêu trường hợp kiểm thử? Đủ để bao phủ luồng chính (happy path) cộng với mọi chế độ thất bại mà kịch bản ngụ ý. Một kịch bản đơn giản có thể cần ba hoặc bốn trường hợp; một kịch bản phức tạp cần nhiều hơn.
Ai viết kịch bản so với trường hợp? Các kịch bản thường được soạn thảo cùng với sản phẩm và QA, vì chúng mã hóa ý định. Các trường hợp thường được viết bởi QA hoặc nhà phát triển, vì chúng mã hóa chi tiết kỹ thuật. Định dạng test case specification giúp giữ cho việc viết trường hợp nhất quán.
Tôi có cần kịch bản nếu các kiểm thử của tôi được tự động hóa không? Có. Tự động hóa chạy các trường hợp, nhưng các kịch bản vẫn trả lời liệu có tồn tại các trường hợp đúng không. Tự động hóa mà không có bản đồ phạm vi bao phủ chỉ làm cho việc thất bại nhanh hơn.