Những người thử nghiệm mới thường nghe hai thuật ngữ này được sử dụng như thể chúng có cùng một ý nghĩa. Họ không làm vậy. Sự khác biệt giữa trường hợp kiểm thử so với kịch bản kiểm thử chủ yếu là về mức độ chi tiết và việc hiểu nó sẽ giúp bạn quyết định số lượng cần viết trước khi bắt đầu kiểm thử.

Hướng dẫn này giải thích từng phần, sau đó thực hiện thông qua một tính năng đặt lại mật khẩu duy nhất, từ yêu cầu, tình huống cho đến các trường hợp thử nghiệm đầy đủ. Tính năng và quy tắc của nó là một ví dụ được phát minh. Thuật ngữ cũng khác nhau một chút giữa các nhóm và công cụ, vì vậy hãy thống nhất ý nghĩa của những từ này trong nhóm của bạn.

Câu trả lời ngắn gọn

Kịch bản thử nghiệm mô tả một tình huống cần kiểm tra, chẳng hạn như “xác minh người dùng có thể đặt lại mật khẩu đã quên”. Nó thường là một dòng và để lại thông tin chi tiết cho người kiểm tra.

trường hợp kiểm thử mô tả chính xác cách kiểm tra một điều kiện trong tình huống đó: điều kiện tiên quyết, các bước, dữ liệu kiểm thử và kết quả mong đợi. Hai người thử nghiệm theo sau nó sẽ đưa ra phán quyết tương tự.

Hãy nghĩ đến việc lên kế hoạch cho một chuyến đi. Kịch bản là “du lịch từ Pune đến Delhi”. Trường hợp thử nghiệm là hành trình đầy đủ, có số chuyến bay, thời gian khởi hành và những việc cần làm ở mỗi chặng.

Trường hợp thử nghiệm và kịch bản thử nghiệm cạnh nhau

Kịch bản thử nghiệm là gì?

Kịch bản thử nghiệm là một mô tả ngắn gọn về điều gì đó mà người dùng có thể làm hoặc một tình huống mà hệ thống phải xử lý. Nó tập trung vào những gì quan trọng từ bên ngoài và thường xuất phát trực tiếp từ yêu cầu hoặc câu chuyện của người dùng.

Các kịch bản có giá trị vì chúng diễn ra nhanh chóng. Bạn có thể liệt kê ba mươi trường hợp trong thời gian cần thiết để viết ba trường hợp chi tiết, điều này khiến chúng trở thành một cách tuyệt vời để xem xét phạm vi đưa tin với chủ sở hữu sản phẩm: “chúng ta đã nghĩ đến mọi thứ chưa?” Người đọc không rành về kỹ thuật có thể theo dõi danh sách các tình huống mà không gặp rắc rối.

Trường hợp thử nghiệm là gì?

Trường hợp thử nghiệm là một tập hợp các điều kiện và bước cụ thể, được sử dụng để xác định xem một thứ có hoạt động hay không. Một trường hợp thử nghiệm điển hình chứa:

• ID duy nhất và tiêu đề rõ ràng
• Điều kiện tiên quyết, nghĩa là điều gì phải đúng trước khi bạn bắt đầu
• Được đánh số bước
• dữ liệu thử nghiệm cụ thể
• Một kết quả mong đợi
• Kết quả thực tế và Trạng thái, được điền khi chạy

Các trường hợp thử nghiệm tỏa sáng khi tính nhất quán có vấn đề. Một thành viên mới trong nhóm có thể chạy chúng, kết quả có thể được so sánh giữa các bản phát hành và bạn có bản ghi về những gì đã được xác minh. Chúng tôi đi sâu hơn vào hướng dẫn về cách viết trường hợp kiểm thử.

Một tính năng, bắt đầu để kết thúc

Bước 1: Yêu cầu

Người dùng quên mật khẩu có thể yêu cầu liên kết đặt lại qua email. Liên kết hoạt động một lần và hết hạn sau 30 phút. Mật khẩu mới phải dài ít nhất 8 ký tự.

Bước 2: Các kịch bản thử nghiệm

Hãy nhìn TS-02. Yêu cầu không bao giờ nói rõ điều gì sẽ xảy ra với một email không xác định và việc viết kịch bản đã bộc lộ khoảng trống đó. Trang có nên tiết lộ rằng địa chỉ chưa được đăng ký? Để bảo mật, điều này thường không nên thực hiện vì điều đó cho phép kẻ tấn công khám phá các tài khoản hợp lệ. Việc phát hiện sớm những câu hỏi này là một trong những lợi ích lớn nhất của việc viết kịch bản.

Bước 3: Các trường hợp thử nghiệm

Bây giờ chúng tôi chỉ mở rộng TS-05 thành các trường hợp thử nghiệm. Một kịch bản trở thành nhiều kịch bản:

Những giá trị này không phải là ngẫu nhiên. TC-051 và TC-052 nằm ở hai bên của giới hạn, sử dụng phân tích giá trị biên và các giá trị khác đến từ phân vùng tương đương.

Mẫu trường hợp thử nghiệm

Đây là TC-052 được viết đầy đủ. Sao chép bố cục này nếu nhóm của bạn chưa có tiêu chuẩn:

ID:            TC-052
Title:         Reset rejects a password of 7 characters
Scenario:      TS-05 New password rules are enforced
Priority:      High
Preconditions: Account asha@example.com exists
               A valid, unused reset link has been requested
Test data:     New password: abcd123

Steps:
  1. Open the reset link from the email
  2. Enter abcd123 in New password
  3. Enter abcd123 in Confirm password
  4. Click Reset password

Expected:      Error "Password must be at least 8 characters"
               Password is unchanged, and the link stays valid
Actual:        (filled in during the run)
Status:        (Pass / Fail / Blocked)

Lưu ý rằng kết quả mong đợi sẽ kiểm tra nhiều hơn thông báo lỗi. Nó cũng xác nhận rằng mật khẩu cũ vẫn hoạt động và liên kết vẫn có thể sử dụng được. Các trường hợp kiểm thử yếu thường dừng lại ở những gì hiển thị trên màn hình.

Vị trí của chúng phù hợp trong bức tranh lớn hơn

Theo truyền thống, các kịch bản và trường hợp được viết trong giai đoạn thiết kế thử nghiệm của vòng đời thử nghiệm phần mềm.

Khi nào nên sử dụng mỗi

Kịch bản thường là đủ khi:

• Đội ngũ nhỏ, có kinh nghiệm và hiểu rõ về sản phẩm.
• Thời gian ngắn hoặc yêu cầu thay đổi thường xuyên.
• Tính năng này có rủi ro thấp.
• Bạn muốn xem xét phạm vi đưa tin một cách nhanh chóng với các bên liên quan.
• Bạn đang hướng dẫn thử nghiệm thăm dò.

Các trường hợp kiểm thử chi tiết có giá trị nỗ lực khi:

• Một thất bại sẽ gây tốn kém, chẳng hạn như với dữ liệu thanh toán, bảo mật hoặc sức khỏe.
• Cơ quan quản lý hoặc kiểm toán viên cần bằng chứng về những gì đã được kiểm tra.
• Người thử nghiệm mới hoặc thuê ngoài phải chạy thử nghiệm.
• Kết quả phải được lặp lại một cách chính xác, như trong bộ hồi quy.
• Các bước sẽ trở thành các bài kiểm tra tự động.

Hầu hết các đội trưởng thành đều sử dụng cả hai. Họ liệt kê các kịch bản cho mọi thứ và chỉ viết các trường hợp đầy đủ cho những rủi ro cao nhất. Không cần phải ghi lại từng bước của trang cài đặt rủi ro thấp giống như chuyển khoản ngân hàng.

Kịch bản, trường hợp và tự động hóa

Một ca kiểm thử được viết tốt sẽ gần như liên kết trực tiếp tới một bài kiểm thử tự động. Điều kiện tiên quyết trở thành thiết lập, các bước trở thành hành động và kết quả mong đợi trở thành một xác nhận. Các khung phát triển theo hướng hành vi thậm chí còn sử dụng từ “Kịch bản” cho các thông số kỹ thuật thực thi của chúng:

Scenario: Reset rejects a short password
  Given I have opened a valid reset link
  When I submit the new password "abcd123"
  Then I see "Password must be at least 8 characters"
  And my password is unchanged

Điều khó hiểu là cái mà BDD gọi là kịch bản lại gần với trường hợp thử nghiệm hơn nhiều vì nó có dữ liệu và kết quả cụ thể. Đó là một lời nhắc tốt để đồng ý về các điều khoản. Để tự động hóa các bước kiểm tra này, hãy xem hướng dẫn Playwright hoặc hướng dẫn pytest của chúng tôi.

Điều gì khiến họ tốt

Những lỗi thường gặp

• Chỉ viết các đường dẫn hạnh phúc. Hầu hết các lỗi đều ở trong tình trạng lỗi, vì vậy hãy bao gồm những gì sẽ xảy ra.
• Sử dụng kết quả mong đợi mơ hồ. “Nó sẽ hoạt động bình thường” cho phép bất kỳ người thử nghiệm nào quyết định bất cứ điều gì.
• Ghi chép đầy đủ mọi thứ. Hàng nghìn trường hợp không ai duy trì còn tệ hơn một tập hợp nhỏ hữu ích.
• Bỏ qua kịch bản. Đi thẳng vào các vụ án có thể khiến toàn bộ khu vực bị lãng quên.
• Để những chiếc ốp lưng trở nên cũ kỹ. Khi sản phẩm thay đổi, những chiếc ốp lưng cũ sẽ đánh lừa mọi người. Hãy xem xét chúng thường xuyên.
• Ràng buộc các bước với những chi tiết dễ vỡ. “Nhấp vào nút màu xanh ở trên cùng” phá vỡ mọi thiết kế lại.

Lời kết

Các kịch bản mang lại cho bạn chiều rộng và các trường hợp thử nghiệm mang lại cho bạn chiều sâu. Bắt đầu với các kịch bản cho tính năng tiếp theo của bạn và xem xét chúng với nhà phát triển và chủ sở hữu sản phẩm. Sau đó chỉ mở rộng những rủi ro thành các trường hợp đầy đủ. Bạn sẽ tìm thấy những khoảng trống sớm hơn và bạn sẽ dành thời gian viết của mình vào nơi có giá trị.

Câu hỏi thường gặp

Tiếp tục học hỏi