Hầu hết các trường hợp kiểm thử đều thất bại trước khi phát hiện ra bất kỳ lỗi nào. Chúng thường được viết dưới dạng danh sách kiểm tra mơ hồ, thiếu các điều kiện tiên quyết, gộp nhiều hành động vào một bước, hoặc mô tả kết quả mong đợi một cách quá chung chung đến mức hai người kiểm thử đọc cùng một trường hợp cũng có thể không thống nhất về định nghĩa của “đạt yêu cầu”. Kết quả là: lỗi lọt qua, các phiên kiểm thử không thể tái hiện, và bộ phận đảm bảo chất lượng (QA) trở thành điểm nghẽn thay vì là mạng lưới an toàn.
Việc viết một trường hợp kiểm thử tốt không chỉ phụ thuộc vào kỹ năng kiểm thử mà còn liên quan nhiều đến thiết kế xác minh. Trong lĩnh vực dịch vụ tài chính, người ta gọi đó là quy trình "người thực hiện - người kiểm tra". Trong lĩnh vực lệnh hạt nhân, người ta gọi đó là "nguyên tắc hai người". Nguyên tắc cơ bản là giống nhau: công việc quan trọng tuyệt đối không được dựa vào một hành động duy nhất mà không được kiểm tra. Một trường hợp kiểm thử được viết tốt sẽ áp dụng cùng mức độ nghiêm ngặt đó vào phần mềm. Nó tách biệt những gì bạn mong đợi với những gì bạn quan sát được, khiến khoảng cách giữa hai yếu tố này trở nên không thể bỏ qua.
Chúng tôi sẽ hướng dẫn bạn cách viết các trường hợp kiểm thử, tại sao chúng lại quan trọng, và cách nâng cao chất lượng các trường hợp kiểm thử theo thời gian.
Tóm tắt
Một trường hợp kiểm thử xác định các bước cụ thể, dữ liệu đầu vào và kết quả mong đợi cần thiết để xác minh rằng một tính năng hoạt động chính xác. Mỗi trường hợp kiểm thử cần có một ID duy nhất, các điều kiện tiên quyết và kết quả mong đợi được ghi rõ để có thể kiểm tra kết quả. Hướng dẫn này bao gồm quy trình viết gồm bảy bước, ba ví dụ minh họa và cách duy trì độ tin cậy của bộ kiểm thử khi sản phẩm thay đổi.
Trường hợp kiểm thử là gì?
Một trường hợp kiểm thử là một tài liệu có cấu trúc, trong đó định nghĩa các bước cụ thể, dữ liệu đầu vào, điều kiện tiên quyết và kết quả mong đợi cần thiết để xác minh xem một phần mềm cụ thể có hoạt động chính xác hay không. Đây không phải là kế hoạch kiểm thử (nơi phác thảo chiến lược kiểm thử) hay kịch bản kiểm thử (một đoạn mã tự động hóa việc thực thi các bước theo chương trình). Trường hợp kiểm thử chính là bản mô tả kỹ thuật mà cả hai thành phần trên đều được xây dựng dựa trên đó.
Ví dụ: Bạn đang kiểm thử chức năng đăng nhập của một ứng dụng web. Một trường hợp kiểm thử cho tính năng này sẽ xác định các yếu tố sau:
- Các hành động mô tả các bước mà người dùng thực hiện và các phản hồi dự kiến từ hệ thống
- Các điều kiện xác định các quy tắc mà hệ thống phải đáp ứng để tiến hành từng bước
- Nhập dữ liệu với các giá trị mẫu để kiểm tra các kết quả khác nhau và xác minh cả các tình huống thành công lẫn thất bại
So sánh giữa các trường hợp kiểm thử thủ công và tự động hóa
Trí tuệ nhân tạo (AI) hiện đã trở thành một phần của hầu hết các quy trình kiểm thử. Theo Báo cáo Tình hình Kiểm thử năm 2026 của PractiTest, 76,8% chuyên gia kiểm thử sử dụng AI trong công tác đảm bảo chất lượng (QA), trong đó việc tạo/lập kịch bản kiểm thử (69,6%) và bảo trì kịch bản (59,6%) là hai ứng dụng phổ biến nhất. Sự chuyển đổi này thể hiện rõ nhất ở các kịch bản kiểm thử tự động hóa, do đó việc hiểu rõ sự khác biệt giữa chúng và các kịch bản kiểm thử thủ công là điều rất đáng quan tâm.
| Tham số | Các trường hợp kiểm thử thủ công | Các trường hợp kiểm thử tự động hóa |
|---|---|---|
| Thực thi | Được thực hiện bởi một người kiểm thử tuân theo một bộ các bước đã được ghi chép rõ ràng | Được thực thi bằng các công cụ phần mềm, tập lệnh hoặc các tác nhân AI |
| Tốc độ | Chậm chạp và tốn thời gian, vì con người phải nhập dữ liệu và xác minh kết quả một cách thủ công | Có thể thực thi hàng trăm trường hợp kiểm thử cùng lúc |
| Khả năng lặp lại | Dễ xảy ra lỗi do con người và cách hiểu các bước không nhất quán | Các kịch bản kiểm thử được duy trì tốt sẽ mang lại tính lặp lại và nhất quán cao |
| Tích hợp CI/CD | Khó tích hợp vào các quy trình triển khai diễn ra nhanh chóng do các điểm nghẽn do con người gây ra | Tích hợp trực tiếp vào các quy trình CI/CD để chạy kiểm thử trên mỗi lần xây dựng |
| Bảo trì | Yêu cầu cập nhật thủ công các tài liệu mỗi khi yêu cầu thay đổi | Cần bảo trì kỹ thuật để cập nhật các tập lệnh khi giao diện người dùng (UI) hoặc logic thay đổi |
| Phù hợp nhất cho | Kiểm thử khám phá | Kiểm thử lặp lại và kiểm thử hồi quy |
Tại sao các trường hợp kiểm thử được viết tốt lại quan trọng
Bạn phát hiện các lỗi tái phát trước khi người dùng gửi yêu cầu hỗ trợ. Mỗi lần thay đổi mã nguồn đều tiềm ẩn rủi ro làm hỏng một chức năng vốn đã hoạt động bình thường. Một trường hợp thử nghiệm được viết tốt sẽ trở thành điểm kiểm tra cố định, được thực thi sau mỗi lần triển khai. Khi một nhà phát triển tái cấu trúc mã đăng nhập của bạn sau một năm và vô tình làm hỏng cơ chế quản lý phiên, chính trường hợp thử nghiệm đó sẽ phát hiện ra vấn đề này trên môi trường staging.
Bạn biến việc “đạt” hay “không đạt” thành một sự thật, chứ không phải là ý kiến chủ quan. Các kết quả mong đợi mơ hồ như “hệ thống phản hồi phù hợp” buộc mỗi người kiểm thử phải tự diễn giải ý nghĩa của từ “phù hợp”. Hai người kiểm thử chạy cùng một trường hợp, một người đánh dấu là “đạt”, người kia báo lỗi, và giờ đây cả nhóm lại phải dành thời gian giải quyết mâu thuẫn này thay vì tập trung vào việc gỡ lỗi phần mềm. Khi kết quả mong đợi của bạn là “hệ thống hiển thị thông báo lỗi: ‘Mật khẩu không hợp lệ’ và giữ người dùng ở trang đăng nhập”, thì không còn chỗ cho việc diễn giải. Kết quả hoặc là khớp hoặc là không. Đó là quy tắc hai người trong thực tế: trường hợp kiểm thử là người tạo ra, người kiểm thử là người kiểm tra, và cả hai cần phải nói cùng một ngôn ngữ.
Bạn biến kiến thức ngầm thành tài sản có thể tái sử dụng. Trong hầu hết các nhóm, kỹ sư QA cấp cao thường nắm giữ một bản đồ vô hình về mọi trường hợp ngoại lệ, mọi giải pháp thay thế, mọi lời nhắc nhở kiểu “à, nhớ kiểm tra thêm X nữa nhé”. Khi người đó nghỉ phép hoặc chuyển sang nhóm khác, bản đồ đó cũng theo họ đi. Các trường hợp kiểm thử được ghi chép với các điều kiện tiên quyết và giá trị biên rõ ràng sẽ bảo tồn kiến thức đó một cách có cấu trúc. Một người kiểm thử mới gia nhập nhóm có thể chọn TC_LOGIN_005 và kiểm thử luồng khóa tài khoản sau năm lần thử ngay từ ngày đầu tiên, mà không cần hỏi ai về ngưỡng giới hạn là bao nhiêu hay bộ đếm thời gian được đặt lại như thế nào.
Bạn xác định nguyên nhân lỗi ở từng bước cụ thể, chứ không phải ở các khu vực chung chung. Khi một trường hợp kiểm thử gộp các thao tác “truy cập trang, nhập thông tin đăng nhập và nhấp vào nút Gửi” thành một bước duy nhất và kiểm thử thất bại, tất cả những gì bạn biết là “có gì đó trong luồng đăng nhập đã bị lỗi”. ” Khi mỗi hành động là một bước riêng biệt với kết quả mong đợi riêng, lỗi sẽ được xác định cụ thể ở bước 4: “Nhấp vào ‘Gửi liên kết đặt lại’ → dự kiến nhận được thông báo thành công, nhưng lại nhận được lỗi 500. ” Sự chính xác này giúp cắt giảm đáng kể thời gian gỡ lỗi vì nhà phát triển biết chính xác tương tác nào đã kích hoạt lỗi, chứ không chỉ biết cần tìm kiếm trong khu vực tính năng nào.
Bạn sẽ thấy những gì đã được bao phủ và những điểm mù. Nếu không có các trường hợp kiểm thử có cấu trúc, phạm vi kiểm thử chỉ là phỏng đoán. Với chúng, bạn có thể liên kết từng trường hợp với một yêu cầu cụ thể và ngay lập tức phát hiện ra các lỗ hổng. Nếu tính năng đặt lại mật khẩu của bạn có sáu tình huống (đặt lại thành công, liên kết đã hết hạn, liên kết được sử dụng lại, email chưa đăng ký, định dạng không hợp lệ, nhiều yêu cầu) và bạn chỉ có các trường hợp kiểm thử cho ba tình huống, thì lỗ hổng đó sẽ hiển thị và có thể định lượng được. Sự hiển thị đó chính là yếu tố biến việc kiểm thử từ “chúng tôi đã kiểm thử nó” thành “đây chính xác là những gì chúng tôi đã kiểm thử, đây là những gì chúng tôi chưa kiểm thử, và đây là rủi ro mà chúng tôi chấp nhận.”
Các thành phần của một trường hợp kiểm thử tốt
Một trường hợp kiểm thử hữu ích không chỉ đơn thuần mô tả những gì cần kiểm thử. Nó còn ghi lại bối cảnh, các bước thực hiện và hành vi dự kiến của hệ thống, để các kiểm thử viên, nhà phát triển hoặc quản lý sản phẩm khác có thể tái hiện lại bài kiểm thử và xác minh kết quả.
Các thành phần của một trường hợp thử nghiệm bao gồm:
- Mã định danh duy nhất
- Mục đích hoặc mô tả
- Điều kiện tiên quyết
- Các bước thực hiện
- Kết quả mong đợi
- Kết quả thực tế để so sánh
Đối với ví dụ về hàm đăng nhập trang web mà chúng tôi đã chia sẻ ở trên, trường hợp thử nghiệm của bạn nên bao gồm:
ID trường hợp kiểm thử: Mỗi trường hợp kiểm thử cần có một ID duy nhất. Khi kiểm thử một tính năng, các nhóm đảm bảo chất lượng (QA) thường tạo ra nhiều trường hợp kiểm thử để xác thực các điều kiện tương tự. ID trường hợp kiểm thử giúp theo dõi, tổ chức và tham chiếu chúng một cách dễ dàng trong quá trình gỡ lỗi hoặc lập báo cáo.
Vídu: TC_LOGIN_001
Mô tả: Phần này giải thích hàm mà trường hợp kiểm thử đang xác thực. Nó cung cấp một bản tóm tắt ngắn gọn để bất kỳ ai đọc trường hợp kiểm thử đều có thể hiểu ngay mục đích của nó.
Ví dụ: Kiểm tra xem người dùng đã đăng ký có thể đăng nhập thành công vào ứng dụng bằng thông tin đăng nhập hợp lệ hay không.
Điều kiện tiên quyết: Điều kiện tiên quyết mô tả trạng thái hệ thống cần thiết trước khi thực thi trường hợp thử nghiệm. Nếu thiếu các điều kiện này, người kiểm thử có thể chạy cùng một trường hợp thử nghiệm trong các điều kiện khác nhau và nhận được kết quả không nhất quán.
Vídu:
- Tài khoản người dùng phải đã tồn tại trong hệ thống
- Tài khoản người dùng phải đang hoạt động và không bị khóa
- Trang đăng nhập phải có thể truy cập được
Các bước: Đây là các thao tác mà người dùng hoặc người kiểm thử thực hiện để chạy trường hợp kiểm thử. Mỗi bước cần phải rõ ràng và có thứ tự để bất kỳ ai trong nhóm cũng có thể tái hiện lại quá trình kiểm thử.
- Người dùng truy cập vào trang đăng nhập
- Người dùng nhập địa chỉ email đã đăng ký
- Người dùng nhập mật khẩu chính xác
- Người dùng nhấp vào nút Đăng nhập
Kết quả mong đợi: Phần này xác định hệ thống sẽ làm gì nếu tính năng hoạt động đúng.
- Nếu thông tin đăng nhập hợp lệ, hệ thống sẽ xác thực người dùng
- Người dùng được chuyển hướng đến bảng điều khiển
- Phiên làm việc của người dùng đã được tạo thành công
Nếu thông tin đăng nhập không hợp lệ, hệ thống nên hiển thị thông báo lỗi phù hợp.
Kết quả thực tế: Đây là những ghi nhận của người kiểm thử sau khi chạy trường hợp thử nghiệm. Nếu hành vi quan sát được khác với kết quả mong đợi, vấn đề đó sẽ được ghi nhận là một lỗi.
Ví dụ về quan sát:
- Đã nhập thông tin đăng nhập hợp lệ nhưng nhận được thông báo lỗi “Mật khẩu không hợp lệ”
Bây giờ, hãy áp dụng kỹ năng viết trường hợp kiểm thử của bạn vào thực tế.
Bạn có biết không? Chỉ 2,1% các nhóm đánh giá các phương pháp kiểm thử AI của họ là đã được tối ưu hóa, trong khi hơn 85% vẫn đang ở giai đoạn ban đầu hoặc thử nghiệm. Ứng dụng phổ biến nhất là tạo các trường hợp kiểm thử (69,6%), chứ không phải các công việc chiến lược như xác định rủi ro (19,9%).
Cách viết các trường hợp thử nghiệm (Quy trình từng bước)
Việc viết một trường hợp kiểm thử bao gồm bảy bước: phân tích yêu cầu, lập danh sách các tình huống, lập kế hoạch cấu trúc, viết các bước kèm theo kết quả mong đợi, tạo tệp đính kèm, đưa ra để đánh giá, sau đó thực thi và ghi lại.
Bước 1: Phân tích các yêu cầu
Trước khi viết trường hợp kiểm thử, hãy hiểu rõ tính năng đó được thiết kế để làm gì. Đây là lúc bạn xem xét các tài liệu có sẵn—PRD (tài liệu yêu cầu sản phẩm), câu chuyện người dùng, thông số kỹ thuật tính năng và tài liệu thiết kế—và xác định mọi chức năng cần được kiểm tra.
Ví dụ: Bạn đang phát triển một tính năng cho phép người dùng đặt lại mật khẩu qua email. Để xây dựng một trường hợp kiểm thử cho tính năng này, bạn cần hiểu:
- Tính năng này giải quyết vấn đề gì, tức là người dùng có thể lấy lại quyền truy cập vào tài khoản của mình nếu họ quên mật khẩu không?
- Người dùng có thể thực hiện những thao tác nào, ví dụ như yêu cầu liên kết đặt lại mật khẩu, nhận liên kết đó qua email và cài đặt mật khẩu mới?
- Khi thực hiện các thao tác đó, điều gì sẽ xảy ra? Tức là, hệ thống có gửi liên kết đặt lại mật khẩu và cho phép người dùng cập nhật mật khẩu thành công không?
- Có bất kỳ hạn chế nào không, tức là, liên kết có hết hạn sau một khoảng thời gian nhất định hay trở nên không hợp lệ sau một lần sử dụng không?
- Có bất kỳ quy tắc hoặc yêu cầu xác thực nào không, tức là mật khẩu mới có cần tuân thủ các yêu cầu cụ thể về định dạng hoặc độ dài không?
- Có hàm nào còn mơ hồ hoặc chưa được định nghĩa rõ ràng không? Nếu có, hãy làm rõ vấn đề này với các bên liên quan.
Sự rõ ràng này sẽ cung cấp cho bạn nền tảng để xác định một mục tiêu rõ ràng cho trường hợp kiểm thử của bạn.
Mục tiêu: Xác minh rằng người dùng đã đăng ký có thể đặt lại mật khẩu thành công qua email.
Bước 2: Xác định các kịch bản kiểm thử khác nhau
Tiếp theo, liệt kê các kịch bản kiểm thử mà bạn cần xác thực. Một kịch bản kiểm thử là một tình huống ở mức tổng quát — thường sẽ nhánh thành nhiều trường hợp kiểm thử bao quát các đầu vào và kết quả khác nhau.
Đối với tính năng đặt lại mật khẩu, các kịch bản của bạn có thể trông như sau:
- Đặt lại mật khẩu thành công: Kiểm tra xem người dùng đã đăng ký có thể yêu cầu liên kết đặt lại mật khẩu và cài đặt mật khẩu mới hay không
- Email chưa được đăng ký: Kiểm thử xem điều gì sẽ xảy ra khi một email không tồn tại trong hệ thống được gửi đi
- Liên kết đã hết hạn: Kiểm tra xem hệ thống có khối truy cập khi nhấp vào liên kết đặt lại sau khi liên kết đó hết hạn hay không
- Liên kết đã được sử dụng lại: Kiểm tra xem một liên kết đặt lại đã được sử dụng trước đó có thể được sử dụng lại hay không
- Mật khẩu mới không hợp lệ: Đảm bảo rằng các mật khẩu không đáp ứng yêu cầu về định dạng sẽ bị từ chối
- Nhiều yêu cầu làm mới: Kiểm thử xem liên kết nào vẫn còn hiệu lực khi người dùng gửi nhiều yêu cầu trong một hàng
Mỗi kịch bản ở đây sẽ được chuyển thành một hoặc nhiều trường hợp kiểm thử, bao quát các đầu vào và điều kiện cụ thể. Việc phân tách tính năng theo cách này đảm bảo bạn có phạm vi kiểm thử bao quát cả hành vi dự kiến lẫn các trường hợp biên mà người dùng thực tế chắc chắn sẽ gặp phải.
Bước 3: Lập kế hoạch kiểm thử và thiết lập cấu trúc trường hợp kiểm thử
Đối với các bài kiểm thử hồi quy lặp đi lặp lại, bạn cần một cấu trúc cho phép ghi chép các trường hợp kiểm thử và kết quả của chúng một cách nhất quán. Một mẫu trường hợp kiểm thử được định nghĩa rõ ràng sẽ mang lại sự nhất quán đó và cho phép tái sử dụng mà không cần phải bắt đầu lại từ đầu mỗi lần.
Lập kế hoạch thực hiện kiểm thử bằng cách làm rõ các yếu tố sau:
Ai sẽ thực hiện việc kiểm thử?
Người thực hiện bài kiểm thử này cần có vai trò hoặc trình độ chuyên môn nào? Tùy thuộc vào mức độ phức tạp của bài kiểm thử và mức độ can thiệp của con người cần thiết, hãy phân công các vai trò:
- Chuyên viên kiểm thử QA: Kiểm thử chức năng và kiểm thử hồi quy, chẳng hạn như xác minh luồng đăng nhập, xác thực biểu mẫu hoặc quy trình thanh toán
- Nhóm bảo mật: Các bài kiểm thử liên quan đến xác thực, kiểm soát truy cập hoặc các lỗ hổng rò rỉ dữ liệu
- Nhà phát triển: Các bài kiểm thử đơn vị cho các hàm riêng lẻ như băm mật khẩu hoặc tạo token
Việc kiểm thử sẽ được tiến hành như thế nào?
- Các thiết bị và hệ điều hành nào sẽ được sử dụng để chạy thử nghiệm?
- Sẽ sử dụng những công cụ hoặc khung kiểm thử nào?
- Việc kiểm thử sẽ được thực hiện thủ công hay thông qua một tác nhân AI?
- Kết quả sẽ được ghi lại như thế nào — trong công cụ quản lý kiểm thử, bảng tính hay hệ thống theo dõi lỗi?
Các điều kiện tiên quyết là gì?
Danh sách công việc để liệt kê mọi điều kiện phải đúng trước khi thực hiện bước 1, và đảm bảo mỗi điều kiện đều có thể được người kiểm thử kiểm tra được:
Vídu:
- Tài khoản người dùng đã tồn tại với địa chỉ email “test@example.com”
- Người dùng đã đăng xuất khỏi hệ thống
- Dịch vụ email đang hoạt động và có thể gửi tin nhắn
- Môi trường kiểm thử đã sẵn sàng và đang hoạt động
Dữ liệu kiểm thử nào sẽ được sử dụng?
Xác định chính xác các giá trị đầu vào cần thiết để chạy thử nghiệm — dữ liệu hợp lệ, dữ liệu không hợp lệ và các giá trị biên.
Vídu:
- Hợp lệ: địa chỉ email đã đăng ký “test@example.com”, mật khẩu đáp ứng các yêu cầu về định dạng
- Không hợp lệ: email chưa được đăng ký, mật khẩu không đáp ứng giới hạn số ký tự tối thiểu
- Giới hạn: mật khẩu phải chính xác bằng giới hạn ký tự tối thiểu và tối đa
Bước 4: Viết các bước kiểm thử và kết quả mong đợi
Chia nhỏ quy trình thực thi thành các bước tuần tự. Sử dụng thuật ngữ nhất quán và đảm bảo mỗi bước chỉ bao gồm một hành động. Khi định nghĩa các bước, hãy nêu rõ kết quả mong đợi và tiêu chí để xác định trường hợp "đạt" hay "không đạt".
Tiếp tục với luồng đặt lại mật khẩu, các bước kiểm thử sẽ như sau:
| Các bước | Kết quả mong đợi |
| Truy cập trang đăng nhập | Trang đăng nhập hiển thị với một liên kết “Quên mật khẩu” có thể nhấp vào |
| Nhấp vào “Quên mật khẩu” | Người dùng được chuyển hướng đến trang yêu cầu đặt lại mật khẩu |
| Nhập địa chỉ email vào trường "Email" | Email được chấp nhận mà không có lỗi xác thực |
| Nhấp vào “Gửi liên kết đặt lại” | Thông báo thành công hiển thị: “Liên kết đặt lại đã được gửi đến test@ví dụ.com” |
| Mở liên kết đặt lại trong email | Người dùng được chuyển hướng đến trang tạo mật khẩu mới |
| Nhập mật khẩu mới hợp lệ | Trường mật khẩu chấp nhận đầu vào mà không báo lỗi |
| Nhấp vào “Đặt lại mật khẩu” | Thông báo thành công hiển thị và người dùng được chuyển hướng đến trang đăng nhập |
Bây giờ, hãy xác định các bước và kết quả mong đợi cho các kịch bản thay thế (đã được đề cập trước đó). Hãy mô tả điều gì sẽ xảy ra khi người dùng nhập địa chỉ email không hợp lệ hoặc mật khẩu không phù hợp với các tiêu chí đã được xác định trước.
Phần thưởng: Dưới đây là cách bạn có thể tự động hóa việc tạo tài liệu bằng AI cho tất cả các trường hợp thử nghiệm của mình.
Bước 5: Đính kèm các tệp đính kèm liên quan
Đính kèm các tài liệu hoặc tệp đính kèm có liên quan để giúp các chuyên viên kiểm thử thực hiện trường hợp kiểm thử trong bối cảnh đầy đủ và không gây nhầm lẫn. Các tài liệu này có thể bao gồm:
- Ảnh chụp màn hình có chú thích về Giao diện người dùng tại các bước quan trọng
- Video ghi lại màn hình minh họa cách thực hiện kiểm thử trong các tình huống khác nhau và kết quả dự kiến
- Nhật ký hệ thống hoặc tệp cấu hình để hỗ trợ chẩn đoán các vấn đề phía máy chủ khi một bài kiểm thử thất bại
- Tài liệu yêu cầu liên kết trường hợp thử nghiệm với câu chuyện người dùng hoặc tiêu chí chấp nhận mà nó xác thực
- Tệp dữ liệu kiểm thử chứa các đầu vào hợp lệ và không hợp lệ, hoặc dữ liệu được tạo ngẫu nhiên như số thẻ tín dụng, địa chỉ ngẫu nhiên hoặc thông tin đăng nhập của người dùng
- Lập tài liệu bao gồm phiên bản phần mềm cụ thể, phần cứng cần thiết, hệ điều hành và bất kỳ giấy phép bảo mật nào cần thiết
- Đối với kiểm thử API, các thông số kỹ thuật OpenAPI hoặc tài liệu về điểm cuối (endpoint) mô tả chi tiết các phương thức yêu cầu, tham số và mã trạng thái dự kiến
Bước 6: Yêu cầu đánh giá trường hợp thử nghiệm
Hãy chia sẻ trường hợp kiểm thử đã viết với đồng nghiệp hoặc trưởng nhóm QA cấp cao trước khi thực hiện. Trong quá trình xem xét, hãy đảm bảo rằng:
- Trường hợp kiểm thử này rất toàn diện và bao quát tất cả các tình huống có thể xảy ra dựa trên các yêu cầu
- Các bước được trình bày rõ ràng và thể hiện theo trình tự luồng thực thi thực tế
- Mỗi kết quả mong đợi đều chỉ ra một kết quả có thể quan sát được (một thông báo, một chuyển hướng, một mã trạng thái), chứ không phải một đặc tính như “hoạt động chính xác”.
- Dữ liệu kiểm thử và các điều kiện tiên quyết phải hoàn thành và chính xác
- Mọi giả định được đưa ra trong quá trình viết đều được ghi chép rõ ràng
Bước 7: Thực thi và ghi lại kết quả
Tiến hành kiểm thử và ghi lại kết quả thực tế so với từng kết quả mong đợi. Đánh dấu từng bước kiểm thử là "đạt" hoặc "không đạt". Đối với mỗi bước không đạt, hãy báo cáo lỗi ngay lập tức và liên kết lỗi đó với trường hợp kiểm thử tương ứng. Ngoài ra, nếu xảy ra bất kỳ hành vi bất thường nào mà không thể xác định rõ là "đạt" hay "không đạt", hãy ghi chú lại trong trường bình luận để xem xét thêm.
Đọc thêm: Cách sử dụng AI để đảm bảo chất lượng
Ví dụ về việc viết trường hợp thử nghiệm
Ba ví dụ sau đây minh họa cách cấu trúc trường hợp kiểm thử giống nhau có thể được điều chỉnh để phù hợp với các loại kiểm thử phần mềm khác nhau. Mỗi ví dụ đều sử dụng các thành phần và định dạng bước đã được đề cập trước đó trong hướng dẫn này, nhưng mức độ phức tạp, dữ liệu kiểm thử và các chế độ lỗi sẽ thay đổi tùy thuộc vào nội dung bạn đang xác minh.
Ví dụ 1: Luồng thanh toán thương mại điện tử (giao diện người dùng, luồng làm việc nhiều bước)
Một nhóm QA tại một nhà bán lẻ trực tuyến đang kiểm thử trải nghiệm thanh toán trước đợt giảm giá dịp lễ. Luồng này trải dài trên nhiều trang: giỏ hàng → vận chuyển → thanh toán → xác nhận. Thách thức đặc biệt ở đây là sự phụ thuộc vào trạng thái: mỗi bước phụ thuộc vào việc bước trước đó hoàn thành chính xác, và dữ liệu kiểm thử (nội dung giỏ hàng, địa chỉ giao hàng, phương thức thanh toán) phải được duy trì xuyên suốt tất cả các bước đó.
Người kiểm thử: Rahul D.
Ngày thi: 09/03/2026
ID trường hợp thử nghiệm: TC_CHECKOUT_003
Mô tả: Kiểm tra xem người dùng đã đăng nhập có thể hoàn thành giao dịch mua hàng bằng thẻ tín dụng đã lưu và hình thức vận chuyển tiêu chuẩn hay không.
Điều kiện tiên quyết:
- Tài khoản người dùng đã tồn tại với ít nhất một thẻ tín dụng đã lưu và một địa chỉ giao hàng đã lưu
- Có ít nhất một mục còn hàng và đã được thêm vào giỏ hàng
- Môi trường kiểm thử đang chạy trên Chrome 128, macOS
| Bước | Kết quả mong đợi | Kết quả thực tế | Đạt/Không đạt |
| Chuyển đến trang giỏ hàng | Giỏ hàng hiển thị đúng mục, số lượng và tổng phụ | Như dự kiến | Vượt qua |
| Nhấp vào “Tiến hành thanh toán” | Tải trang giao hàng với địa chỉ đã lưu được lựa chọn sẵn | Như dự kiến | Vượt qua |
| Lựa chọn “Giao hàng tiêu chuẩn” và nhấp vào Tiếp tục | Trang thanh toán hiển thị tổng số tiền đơn đặt hàng đã bao gồm phí vận chuyển | Như dự kiến | Vượt qua |
| Xác nhận thông tin thẻ tín dụng đã lưu và nhấp vào “Đơn đặt hàng” | Trang xác nhận đơn đặt hàng hiển thị số đơn đặt hàng, tóm tắt mục và ngày giao hàng dự kiến | Trang thanh toán tải lại kèm thông báo lỗi: “Không thể xử lý thanh toán” | Thất bại |
Tóm tắt kết quả: Luồng thanh toán xử lý việc chuyển từ giỏ hàng sang thông tin vận chuyển đúng cách, nhưng việc xử lý thanh toán thất bại khi sử dụng thẻ tín dụng đã lưu. Lỗi đã được ghi nhận: việc tra cứu thẻ tín dụng đã được mã hóa (tokenized) bị hết thời gian chờ khi cổng thanh toán mất hơn 3 giây để phản hồi.
Ví dụ 2: Điểm cuối API REST (không có giao diện người dùng, xác thực đầu vào/đầu ra)
Một kỹ sư backend đang kiểm thử điểm cuối API “Tạo người dùng” trước khi nó được nhóm front-end sử dụng. Không có giao diện nào để nhấp qua: trường hợp kiểm thử xác thực trực tiếp nội dung yêu cầu, mã phản hồi và tính bền vững của dữ liệu. Thách thức đặc trưng ở đây là kiểm thử hợp đồng giữa các hệ thống, chứ không phải trải nghiệm người dùng.
Người kiểm thử: Sarah S.
Ngày thi: 09/05/2026
ID trường hợp kiểm thử: TC_API_USER_001
Mô tả: Kiểm tra xem yêu cầu POST đến /api/v1/users có tạo ra một người dùng mới và trả về phản hồi chính xác hay không.
Điều kiện tiên quyết:
- Môi trường kiểm thử API đang hoạt động và có thể truy cập được
- Token xác thực có quyền truy cập của quản trị viên đã được tạo và đang có hiệu lực
- Không có người dùng nào có địa chỉ email “newuser@testdomain.com” tồn tại trong cơ sở dữ liệu
| Bước | Kết quả mong đợi | Kết quả thực tế | Đạt/Không đạt |
| Gửi yêu cầu POST đến /api/v1/users với nội dung hợp lệ: { "name": "Test User", "email": "newuser@testdomain. com", "vai trò": "viewer" } | Phản hồi trả về mã trạng thái 201 với nội dung JSON chứa ID người dùng, tên, email và vai trò | 201 được trả về với nội dung chính xác | Vượt qua |
| Gửi lại yêu cầu POST tương tự với email giống hệt | Phản hồi trả về mã lỗi 409 (Xung đột) kèm thông báo: “Người dùng có email này đã tồn tại” | Trả về 200 OK; người dùng trùng lặp đã được tạo | Thất bại |
| Gửi yêu cầu POST mà không có trường “email” | Phản hồi trả về mã trạng thái 400 Bad Request kèm theo lỗi xác thực: “Email là trường bắt buộc” | 400 được trả về như mong đợi | Vượt qua |
| Thực hiện truy vấn GET /api/v1/users/{id} bằng ID từ bước 1 | Phản hồi trả về mã trạng thái 200 OK với thông tin người dùng khớp với dữ liệu gốc | Như dự kiến | Vượt qua |
Tóm tắt kết quả: Điểm cuối tạo người dùng chính xác và xác thực các trường bắt buộc, nhưng không đảm bảo tính duy nhất của địa chỉ email ở cấp độ cơ sở dữ liệu. Các bản ghi trùng lặp đã được tạo ra mà không gặp lỗi. Lỗi đã được ghi lại với mức độ nghiêm trọng: Cao.
Ví dụ 3: Kiểm soát truy cập dựa trên vai trò (bảo mật, ranh giới quyền truy cập)
Một nhóm bảo mật đang kiểm thử xem ứng dụng có hạn chế đúng các hành động dựa trên vai trò người dùng hay không trước khi tiến hành kiểm toán tuân thủ. Thách thức đặc biệt ở đây là bạn không kiểm thử xem một tính năng có hoạt động đúng hay không; mà bạn đang kiểm thử xem tính năng đó có bị từ chối đúng cách hay không. Kết quả mong đợi cho hầu hết các bước là bị chặn, chứ không phải thành công.
Người kiểm thử: Marcus L.
Ngày thi: 09/08/2026
ID trường hợp kiểm thử: TC_RBAC_002
Mô tả: Xác minh rằng người dùng có vai trò “Viewer” không thể tạo, chỉnh sửa hoặc xóa các dự án.
Điều kiện tiên quyết:
- Có hai tài khoản: một tài khoản có vai trò “quản trị viên” và một tài khoản có vai trò “Viewer”
- Trong không gian làm việc phải có ít nhất một dự án, được tạo bởi Quản trị viên
- Người dùng đang đăng nhập trên Firefox 130, Windows 11
| Bước | Kết quả mong đợi | Kết quả thực tế | Đạt/Không đạt |
| Truy cập trang Dự án | Người dùng xem danh sách dự án ở chế độ chỉ đọc; nút “Tạo dự án” bị ẩn hoặc bị vô hiệu hóa | Nút hiển thị nhưng bị mờ | Vượt qua |
| Hãy thử nhấp vào “Tạo dự án” | Hệ thống ngăn chặn thao tác; biểu mẫu dự án mới không được tải | Không có biểu mẫu nào được tải; chú thích hiển thị “Bạn không có quyền truy cập” | Vượt qua |
| Mở một dự án hiện có và thử chỉnh sửa tiêu đề | Trường tiêu đề không thể chỉnh sửa, hoặc hệ thống chặn việc lưu | Trường tiêu đề có thể chỉnh sửa; các thay đổi đã được lưu thành công | Thất bại |
| Thử xóa dự án thông qua menu ba chấm | Tùy chọn "Xóa" bị ẩn hoặc thao tác bị chặn do lỗi quyền truy cập | Tùy chọn "Xóa" không hiển thị trong menu | Vượt qua |
Tóm tắt kết quả: Quyền truy cập tạo và xóa đã được hạn chế đúng cách đối với người xem (Viewers), nhưng quyền chỉnh sửa không được áp dụng ở cấp độ trường dữ liệu. Người xem (Viewer) có thể sửa đổi tiêu đề dự án dù chỉ có quyền truy cập chỉ đọc. Lỗi đã được ghi nhận với mức độ nghiêm trọng: Nghiêm trọng (ngăn cản tuân thủ).
Công cụ nào là tốt nhất để quản lý các trường hợp kiểm thử?
Các trường hợp kiểm thử có thể được quản lý trong một công cụ QA chuyên dụng (TestRail, Zephyr), một công cụ quản lý dự án tổng quát (ClickUp, Jira) hoặc một bảng tính; lựa chọn phù hợp phụ thuộc vào việc bạn cần tính năng thực thi tích hợp sẵn hay chỉ cần đang theo dõi.
ClickUp
ClickUp for Software Teams là một nền tảng quản lý dự án, nơi các trường hợp kiểm thử được lưu trữ dưới dạng công việc cùng với các sprint, lỗi và yêu cầu Hợp nhất mà chúng liên quan đến. Đây không phải là một công cụ quản lý kiểm thử chuyên dụng, nhưng cấu trúc công việc linh hoạt của nó cho phép các nhóm xây dựng quy trình làm việc cho các trường hợp kiểm thử bằng cách sử dụng các trạng thái, trường và loại công việc tùy chỉnh mà không cần đến một công cụ riêng biệt.
Các tính năng chính của ClickUp
- Cấu trúc phân cấp linh hoạt để tổ chức các trường hợp kiểm thử trong các Không gian, Thư mục và Danh sách công việc với các Trường Tùy chỉnh cho loại kiểm thử, mức độ ưu tiên và môi trường
- Hơn 15 chế độ xem trong ClickUp (Bảng, Danh sách công việc, Bảng dữ liệu) để theo dõi quá trình thực thi kiểm thử theo trạng thái, người được giao nhiệm vụ hoặc sprint
- Các tài liệu để lưu trữ PRD, kế hoạch kiểm thử và hướng dẫn thiết lập môi trường cùng với các trường hợp kiểm thử mà chúng hỗ trợ
- Tính năng trò chuyện tích hợp sẵn giúp giao tiếp giữa bộ phận đảm bảo chất lượng và nhà phát triển mà không cần chuyển sang Slack hay email
- Tóm tắt công việc được hỗ trợ bởi AI thông qua ClickUp Brain để nắm bắt bối cảnh nhanh chóng trong các buổi đánh giá sprint
Các giới hạn của ClickUp
- Không có công cụ thực thi thử nghiệm tích hợp sẵn
- Các báo cáo chuyên biệt về kiểm thử (độ bao phủ theo yêu cầu, tỷ lệ đạt theo chu kỳ) cần các bảng điều khiển tùy chỉnh thay vì các báo cáo đảm bảo chất lượng có sẵn sẵn.
Giá dịch vụ ClickUp
Đánh giá và nhận xét về ClickUp
- G2: 4. 6/5 (hơn 14.100 đánh giá)
- Capterra: 4,6/5 (hơn 4.600 đánh giá)
Người dùng thực tế nói gì về ClickUp?
Dưới đây là nhận xét của một người đánh giá trên G2:
Điều tôi thích nhất ở ClickUp là nó tập hợp mọi thứ vào một nơi duy nhất. Các công việc, dòng thời gian, ghi chú và cập nhật đều nằm trong cùng một hệ thống, giúp giảm thiểu việc chuyển đổi qua lại giữa các công cụ. Tôi cũng đánh giá cao tính linh hoạt của nó. Chúng tôi có thể tùy chỉnh trạng thái, trường và chế độ xem để phù hợp với cách làm việc thực tế của nhóm. Điều này giúp duy trì sự tổ chức dễ dàng hơn và hiển thị rõ ràng ai chịu trách nhiệm cho việc gì cũng như tình trạng của các dự án tại bất kỳ thời điểm nào.
Điều tôi thích nhất ở ClickUp là nó tập hợp mọi thứ vào một nơi duy nhất. Các công việc, dòng thời gian, ghi chú và cập nhật đều được lưu trữ trong cùng một hệ thống, giúp giảm thiểu việc phải chuyển đổi qua lại giữa các công cụ. Tôi cũng đánh giá cao tính linh hoạt của nó. Chúng tôi có thể tùy chỉnh trạng thái, trường dữ liệu và chế độ xem để phù hợp với cách làm việc thực tế của nhóm. Điều này giúp duy trì sự tổ chức một cách dễ dàng hơn và mang lại cái nhìn rõ ràng về ai chịu trách nhiệm cho việc gì cũng như tình trạng của các dự án tại bất kỳ thời điểm nào.
Phù hợp nhất cho: Trưởng nhóm QA muốn biến một bài kiểm thử thất bại thành phiếu báo lỗi cho nhà phát triển chỉ với một cú nhấp chuột, đồng thời hiển thị yêu cầu kéo (PR), các bước kiểm thử và sprint ngay từ cùng một công việc.
Bỏ qua nếu: Chu kỳ kiểm thử của bạn chủ yếu được tự động hóa. Nếu 80% bộ kiểm thử của bạn được chạy từ một đường ống CI, bạn cần một công cụ có thể tự động thu thập kết quả thực thi, chứ không phải công cụ yêu cầu con người cập nhật trạng thái.
TestRail
TestRail là một nền tảng quản lý kiểm thử chuyên dụng được xây dựng dành cho các nhóm QA cần kiểm soát có cấu trúc đối với toàn bộ quy trình kiểm thử của họ. Nền tảng này xử lý toàn bộ chu kỳ từ việc viết, chạy đến báo cáo các trường hợp kiểm thử, với sự tích hợp với DevOps và CI/CD để cung cấp kết quả.
Các tính năng chính của TestRail
- Quản lý tập hợp các trường hợp thử nghiệm và bộ thử nghiệm tập trung với các trường hợp thử nghiệm có thể tái sử dụng trên các dự án
- Kế hoạch kiểm thử và các cột mốc quan trọng để tổ chức và lên lịch các đợt kiểm thử xuyên suốt các sprint và phiên bản phát hành
- Báo cáo chi tiết với phân tích độ bao phủ, đang theo dõi tiến độ và lịch sử thực thi
- Tích hợp với Jira, GitHub, Jenkins, Azure DevOps và hơn 20 công cụ DevOps khác
- API REST để tự động hóa các công việc và đồng bộ hóa dữ liệu kiểm thử với các hệ thống bên ngoài
Các giới hạn của TestRail
- Không có hệ thống quản lý yêu cầu hoặc theo dõi vấn đề tích hợp sẵn — các nhóm phải dựa vào các công cụ bên ngoài như Jira, điều này có thể làm gián đoạn khả năng truy vết
- Việc tổ chức theo thư mục trở nên khó quản lý khi kho lưu trữ các trường hợp thử nghiệm mở rộng lên đến hàng nghìn trường hợp
Giá của TestRail
- Chuyên nghiệp: 39 USD/người dùng được cấp phép/tháng
- Enterprise: 78 USD/người dùng được cấp phép/tháng
Đánh giá và nhận xét về TestRail
- G2: 4. 4/5 (hơn 600 đánh giá)
- Capterra: 4,3/5 (hơn 160 đánh giá)
Người dùng thực tế nói gì về TestRail?
Dưới đây là nhận xét của một người đánh giá trên G2:
Điều tôi thấy có giá trị nhất ở TestRail là nó cung cấp cho nhóm QA của chúng tôi một môi trường bảo mật và được tổ chức tốt để quản lý các kế hoạch kiểm thử, trường hợp kiểm thử và các lần chạy kiểm thử. Tôi đánh giá cao sự đơn giản trong việc cấu trúc và triển khai các bộ kiểm thử, cũng như khả năng tái sử dụng các trường hợp kiểm thử đã tạo trước đó. Sự tích hợp với Jira và các công cụ CI/CD đã giúp quy trình làm việc của chúng tôi trở nên gắn kết hơn và dễ theo dõi hơn. Khả năng theo dõi tiến độ và độ bao phủ kiểm thử theo thời gian thực đã hỗ trợ rất nhiều cho kế hoạch sprint và báo cáo. Trong công việc hàng ngày với tư cách là Kỹ sư QA, việc sử dụng TestRail cũng đã giúp tôi tiết kiệm được một lượng thời gian đáng kể.
Điều tôi thấy có giá trị nhất ở TestRail là nó cung cấp cho nhóm QA của chúng tôi một môi trường bảo mật và được tổ chức khoa học để quản lý kế hoạch kiểm thử, trường hợp kiểm thử và các lần chạy kiểm thử. Tôi đánh giá cao sự đơn giản trong việc cấu trúc và triển khai bộ kiểm thử, cũng như khả năng tái sử dụng các trường hợp kiểm thử đã tạo trước đó. Việc tích hợp với Jira và các công cụ CI/CD đã giúp quy trình làm việc của chúng tôi trở nên gắn kết hơn và dễ theo dõi hơn. Khả năng theo dõi tiến độ và độ bao phủ kiểm thử theo thời gian thực đã hỗ trợ rất nhiều cho kế hoạch sprint và báo cáo. Trong công việc hàng ngày với tư cách là Kỹ sư QA, việc sử dụng TestRail cũng đã giúp tôi tiết kiệm được một lượng thời gian đáng kể.
Phù hợp nhất cho: Nhóm QA gồm năm thành viên trở lên đang thực hiện các chu kỳ kiểm thử chính thức cho mỗi bản phát hành, trong đó người quản lý cần trả lời câu hỏi “tỷ lệ phần trăm của Bản phát hành 2.0 đã được thực thi và đạt yêu cầu là bao nhiêu” thông qua bảng điều khiển, chứ không phải bảng tính.
Bỏ qua nếu: Bộ trường hợp kiểm thử của bạn có dưới vài trăm trường hợp hoặc các chuyên viên kiểm thử của bạn kiêm luôn vai trò lập trình viên. Ở quy mô đó, chi phí trên mỗi người dùng được cấp phép và việc đăng nhập riêng biệt sẽ mang lại cho bạn các báo cáo mà bạn sẽ không bao giờ xem đến.
Zephyr
Zephyr là plugin quản lý kiểm thử của SmartBear dành cho Jira, được phát triển để quản lý các trường hợp kiểm thử ngay trong giao diện Jira. Plugin này hỗ trợ cả kiểm thử thủ công và tự động hóa, kèm theo các tính năng báo cáo và truy vết mạnh mẽ dành cho các nhóm phát triển theo phương pháp Agile và doanh nghiệp.
Các tính năng chính của Zephyr
- Tích hợp Jira gốc — tạo, liên kết và thực thi các trường hợp kiểm thử trực tiếp từ các vấn đề trên Jira
- Thư viện kiểm thử phân cấp xuyên dự án để tái sử dụng và tổ chức các trường hợp kiểm thử trên quy mô lớn
- Hơn 70 báo cáo sẵn có bao quát phạm vi kiểm thử, tiến độ thực thi và theo dõi lỗi
- Hỗ trợ BDD với cú pháp Gherkin cho các quy trình phát triển hướng hành vi
- Tích hợp CI/CD với Jenkins, GitHub, GitLab, Bitbucket và Bamboo
Các giới hạn của Zephyr
- Giấy phép được cấp cho mỗi người dùng Jira, không phải cho mỗi người kiểm thử
- Các kho lưu trữ kịch bản kiểm thử lớn (với hàng nghìn kịch bản) có thể gây cảm giác khó điều hướng hơn so với các công cụ độc lập như TestRail
- Dịch vụ hỗ trợ được cung cấp thông qua Atlassian Marketplace, điều này tạo thêm một lớp hỗ trợ cho các nhóm đã quen với việc nhận hỗ trợ trực tiếp từ nhà cung cấp
Giá cả của Zephyr
- Gói cơ bản: Từ 5,99 USD/người dùng/tháng (11–50 người dùng)
- Gói tiêu chuẩn: Từ 6,81 USD/người dùng/tháng (11–50 người dùng)
- Nâng cao: Từ 8,73 USD/người dùng/tháng (11–50 người dùng)
Đánh giá và nhận xét về Zephyr
- G2: 4. 1/5 (hơn 80 đánh giá)
- Capterra: Chưa có đủ đánh giá
Người dùng thực tế nói gì về Zephyr?
Dưới đây là nhận xét của một người đánh giá trên G2:
Đây là công cụ tốt nhất để nhập các trường hợp kiểm thử trực tiếp từ bảng tính Excel. Sử dụng công cụ này, công việc của các kiểm thử viên sẽ nhẹ nhàng hơn so với việc nhập các trường hợp kiểm thử vào Jira. Ngoài ra, tính năng nổi bật nhất của công cụ này là khả năng đánh dấu các trường hợp kiểm thử là "đạt" hoặc "không đạt" và thêm tệp đính kèm.
Đây là công cụ tốt nhất để nhập trực tiếp các trường hợp kiểm thử từ bảng tính Excel. Sử dụng công cụ này, công việc của các kiểm thử viên sẽ trở nên nhẹ nhàng hơn so với việc nhập các trường hợp kiểm thử vào Jira. Ngoài ra, tính năng nổi bật của công cụ này là khả năng đánh dấu các trường hợp kiểm thử là "đạt" hoặc "không đạt" và thêm tệp đính kèm.
Phù hợp nhất cho: Các nhóm phải tuân thủ quy định hoặc thường xuyên bị kiểm toán (như trong lĩnh vực fintech, y tế) cần đảm bảo mọi bài kiểm thử đều được liên kết với một yêu cầu trên Jira và mọi lỗi đều được liên kết trở lại bài kiểm thử đã phát hiện ra nó, tất cả đều được thực hiện trong cùng một hệ thống Atlassian.
Bỏ qua nếu: Hệ thống Jira của bạn có quy mô lớn nhưng nhóm QA lại nhỏ. Một hệ thống Jira có 200 người dùng được cấp phép với 10 tester sẽ phải trả tiền cho 190 giấy phép Zephyr mà không ai sử dụng; một công cụ độc lập được tính phí theo từng tester sẽ rẻ hơn.
Jira
Jira là nền tảng quản lý dự án và theo dõi vấn đề của Atlassian, được các nhóm kỹ thuật và kiểm thử phần mềm (QA) sử dụng rộng rãi để quản lý các đợt sprint, lỗi và quy trình phát triển. Mặc dù Jira không phải là công cụ quản lý kiểm thử chuyên dụng, nhiều nhóm vẫn sử dụng nó kết hợp với các giải pháp như Zephyr Scale hoặc Xray để quản lý các trường hợp kiểm thử trong thiết lập Jira hiện có của họ.
Các tính năng chính của Jira
- Bảng Scrum và Kanban để quản lý các sprint, danh sách công việc tồn đọng và quy trình kiểm thử Agile
- Các quy trình làm việc, loại vấn đề và trường dữ liệu có thể tùy chỉnh để phù hợp với cách nhóm của bạn theo dõi công việc
- Lộ trình nâng cao để lập kế hoạch cho các nhóm và theo dõi các mối phụ thuộc (Premium)
- Hơn 1.000 tích hợp nền tảng, bao gồm GitHub, Confluence, Slack và các công cụ CI/CD
- Các quy tắc tự động hóa để kích hoạt các hành động trên các dự án dựa trên các cập nhật về vấn đề hoặc thay đổi trạng thái
Những giới hạn của Jira
- Quản lý trường hợp kiểm thử yêu cầu một plugin từ Marketplace (Zephyr Scale, Xray) với phí riêng cho từng người dùng ngoài phí đăng ký Jira
- Đường cong học tập dốc hơn đối với người dùng không có kiến thức kỹ thuật, cùng với chi phí đào tạo ban đầu có thể tăng lên đáng kể đối với các nhóm lớn hơn
Giá của Jira
- Miễn phí
- Tiêu chuẩn: 7,91 USD/người dùng/tháng
- Premium: 14,54 USD/người dùng/tháng
- Enterprise: Giá tùy chỉnh
Đánh giá và nhận xét trên Jira
- G2: 4,3/5 (hơn 7.900 đánh giá)
- Capterra: 4,4/5 (hơn 15.400 đánh giá)
Người dùng thực tế nói gì về Jira?
Dưới đây là nhận xét của một người đánh giá trên G2:
Jira là một trong những phần mềm kỹ thuật số yêu thích của tôi để theo dõi và trực quan hóa hiệu suất của tất cả các dự án công việc của tôi khi hợp tác với tất cả các thành viên trong nhóm làm việc, bởi vì nó cung cấp các tính năng hiệu suất ảo tốt nhất trong phân khúc của mình, giúp tôi dễ dàng đạt được tất cả các mục tiêu nghề nghiệp của mình.
Jira là một trong những phần mềm kỹ thuật số yêu thích của tôi để theo dõi và trực quan hóa hiệu suất của tất cả các dự án công việc của tôi khi hợp tác với tất cả các thành viên trong nhóm làm việc, bởi vì nó cung cấp các tính năng hiệu suất ảo tốt nhất trong phân khúc của mình, giúp tôi dễ dàng đạt được tất cả các mục tiêu nghề nghiệp của mình.
Phù hợp nhất cho: Các nhóm kỹ thuật đang đánh giá xem liệu họ có thực sự cần một hệ thống quản lý kiểm thử chuyên dụng hay không. Việc thực hiện một vài chu kỳ kiểm thử bằng cách sử dụng các loại vấn đề tùy chỉnh trong Jira trước tiên sẽ giúp xác định xem khối lượng công việc có đủ lớn để cần đến một plugin hay không.
Bỏ qua nếu: Bạn đã biết mình cần quản lý kiểm thử. Việc chuyển thẳng sang sử dụng plugin hoặc công cụ độc lập sẽ giúp tránh được việc phải di chuyển dữ liệu khi các loại vấn đề tùy chỉnh không còn đáp ứng được quy mô.
Những sai lầm thường gặp cần tránh khi tạo các trường hợp kiểm thử
Hãy tránh những sai lầm sau đây khi viết các trường hợp kiểm thử, vì chúng có thể làm giảm hiệu quả tổng thể của chúng.
| Sai lầm | Việc cần làm thay vào đó |
|---|---|
| Viết các trường hợp thử nghiệm quá muộn | Hãy huy động các chuyên viên kiểm thử tham gia vào các giai đoạn thu thập yêu cầu và thiết kế để xác định các vấn đề tiềm ẩn trước khi bắt đầu mã hóa |
| Không cập nhật các trường hợp thử nghiệm | Cập nhật trường hợp kiểm thử ngay khi tính năng được nâng cấp, thay đổi chức năng hoặc thay đổi giao diện người dùng |
| Không có điều kiện sau | Mô tả trạng thái mà hệ thống nên có sau khi kiểm thử hoàn thành (người dùng thử nghiệm đã bị xóa, giỏ hàng đã được làm trống, phiên đã đóng) để trường hợp kiểm thử tiếp theo bắt đầu từ trạng thái ban đầu. |
| Chỉ dữ liệu theo kịch bản thuận lợi | Mỗi trường nhập liệu cần có ít nhất một giá trị mà hệ thống phải từ chối. Ghi chép lại cách bộ dữ liệu được tạo ra hoặc trích xuất |
| Không ưu tiên các trường hợp kiểm thử | Xếp hạng mức độ ưu tiên cho từng trường hợp kiểm thử dựa trên tác động đến hoạt động kinh doanh, tần suất sử dụng và rủi ro thất bại. Điều này giúp bạn tập trung nỗ lực kiểm thử và đưa ra các quyết định sáng suốt hơn về ngân sách và phương pháp kiểm thử |
Cách duy trì tính hữu ích của các trường hợp thử nghiệm theo thời gian
Một bộ kiểm thử chỉ thực sự đáng tin cậy khi mỗi trường hợp kiểm thử đều độc lập, có mục tiêu nhắm vào các đầu vào có khả năng gây lỗi cao nhất và được loại bỏ ngay khi không còn đưa ra kết quả đáng tin cậy. Sáu phương pháp này là yếu tố phân biệt giữa các bộ kiểm thử có thể phát hiện lỗi trong nhiều năm và những bộ kiểm thử bị bỏ qua ngay sau sprint thứ hai.
Viết các bài kiểm thử độc lập và nguyên tử
Một trường hợp kiểm thử nên cài đặt trạng thái riêng của mình và tuyệt đối không được phụ thuộc vào việc một trường hợp khác đã được chạy trước đó. Khi TC_CHECKOUT_003 giả định rằng TC_CHECKOUT_002 đã để lại một mục trong giỏ hàng, một lỗi sẽ gây ra chuỗi lỗi dẫn đến năm lỗi khác, và bạn sẽ phải mất cả buổi sáng để tìm ra lỗi nào là lỗi thực sự. Nếu tiêu đề của một trường hợp kiểm thử cần từ “và”, hãy chia nó thành hai trường hợp riêng biệt.
Kiểm thử tại các ranh giới
Lỗi thường tập trung ở các giá trị biên của phạm vi đầu vào được chấp nhận, chứ không phải ở giữa. Nếu trường mật khẩu chấp nhận từ 8 đến 128 ký tự, hãy kiểm thử các giá trị 7, 8, 128 và 129, chứ không chỉ một mật khẩu 12 ký tự thông thường. Phân tích giá trị biên là một kỹ thuật chính thức trong tiêu chuẩn thiết kế kiểm thử ISO/IEC/IEEE 29119-4 chính xác vì lý do này: nó phát hiện các lỗi "chênh lệch một đơn vị" mà các đầu vào ngẫu nhiên có thể bỏ sót.
Sử dụng phương pháp phân vùng tương đương để loại bỏ các trường hợp thử nghiệm trùng lặp
Nhóm các đầu vào mà hệ thống nên xử lý giống nhau, sau đó kiểm thử một trường hợp đại diện cho mỗi nhóm. Mọi định dạng email hợp lệ đều hoạt động giống nhau trong biểu mẫu đăng nhập, vì vậy chỉ cần một email hợp lệ là đủ. Việc kiểm thử user@example.com, jane@company.com và bob@domain.org như ba trường hợp riêng biệt sẽ làm tăng gấp ba lần khối lượng bảo trì mà không tăng độ bao phủ.
Tách biệt dữ liệu kiểm thử khỏi các bước kiểm thử
Việc ghi cứng “enter test@example.com” vào một bước có nghĩa là bạn phải viết lại bước đó mỗi khi môi trường kiểm thử thay đổi. Hãy giữ các bước ở dạng chung chung (“nhập địa chỉ email đã đăng ký”) và lưu các giá trị thực tế trong trường dữ liệu kiểm thử hoặc tệp dữ liệu. Như vậy, các bước này có thể chạy trên môi trường staging, QA và pre-production mà không cần chỉnh sửa, và việc thay thế bằng bộ dữ liệu mới cho bài kiểm thử tiêu cực chỉ cần thay đổi một dòng code.
Đang theo dõi các bài kiểm thử không ổn định và tỷ lệ lỗi lọt qua
Một trường hợp kiểm thử không ổn định (flaky) sẽ thất bại một cách không nhất quán mà không phải do lỗi thực sự của sản phẩm, và mỗi trường hợp như vậy khiến nhóm có xu hướng bỏ qua kết quả "đỏ". Theo dõi tần suất mỗi trường hợp dao động giữa "đậu" và "trượt" trên các bản dựng giống hệt nhau. Nếu một trường hợp kiểm thử không ổn định xảy ra hơn một vài lần mỗi tháng, hãy viết lại hoặc loại bỏ nó. Kết hợp chỉ số này với tỷ lệ lỗi thoát (defect escape rate – các lỗi được phát hiện trong môi trường sản xuất mà trường hợp kiểm thử lẽ ra phải phát hiện được) để xác định những khu vực có độ bao phủ mỏng, chứ không chỉ những nơi có kết quả nhiễu.
Tự động hóa các bài kiểm thử mà bạn thực hiện thường xuyên nhất
Các trường hợp kiểm thử hồi quy, kiểm thử nhanh (smoke test) và kiểm thử chức năng tần suất cao là những ứng cử viên hàng đầu cho tự động hóa vì chúng được chạy trên mỗi bản dựng và hiếm khi thay đổi. Hãy chuyển những trường hợp này vào các kịch bản trong quy trình CI/CD của bạn, và sử dụng các công cụ hỗ trợ bởi trí tuệ nhân tạo (AI) với các bộ định vị tự phục hồi ở những nơi các thành phần giao diện người dùng (UI) thường xuyên thay đổi. Điều này giúp giải phóng các kiểm thử viên con người để tập trung vào công việc khám phá và các loại kiểm thử phần mềm đòi hỏi sự phán đoán, như kiểm thử khả năng sử dụng và tìm kiếm các trường hợp biên.
Cách viết và chạy các trường hợp kiểm thử trong ClickUp
Phần "Công cụ" ở trên đã đề cập đến vai trò của ClickUp. Phần này sẽ hướng dẫn cách thiết lập thực tế, tương ứng với các bước đã được nêu ở phần trước của hướng dẫn.
Tổ chức thư viện trường hợp kiểm thử của bạn. Tạo một Không gian cho sản phẩm của bạn, một Thư mục cho từng lĩnh vực tính năng (ví dụ: Xác thực, Thanh toán, Hướng dẫn sử dụng) và một Danh sách công việc cho từng chu kỳ kiểm thử hoặc sprint. Mỗi tác vụ sẽ trở thành một trường hợp kiểm thử riêng biệt. Sử dụng Trường Tùy chỉnh của ClickUp để ghi lại các thành phần như ID trường hợp kiểm thử, điều kiện tiên quyết, dữ liệu kiểm thử, mức độ ưu tiên và môi trường.
Viết các bước kiểm thử trực tiếp trong công việc. Sử dụng phần mô tả công việc để ghi lại các bước thực thi tuần tự và kết quả mong đợi. Danh sách kiểm tra (checklist) rất phù hợp cho các luồng từng bước, nơi người kiểm thử cần đánh dấu từng hành động đã hoàn thành, trong khi phần mô tả chứa các thông tin bối cảnh như điều kiện tiên quyết và dữ liệu kiểm thử.
Theo dõi quá trình thực thi và kết quả. Tạo các Trạng thái tùy chỉnh phản ánh quy trình làm việc kiểm thử của bạn: Chưa bắt đầu → Đang tiến độ → Đạt → Thất bại → Bị chặn. Khi một bài kiểm thử thất bại, hãy chuyển nó thành công việc lỗi hoặc tạo một công việc liên kết được giao cho nhà phát triển, kèm theo mức độ ưu tiên, các phụ thuộc và thời hạn. Tích hợp với GitHub và GitLab cho phép bạn liên kết lỗi đó trực tiếp với yêu cầu kéo (PR) đã gây ra lỗi. Nếu nguyên nhân gốc rễ là lỗi mã nguồn, bạn có thể giao công việc lỗi đó cho ClickUp Codegen Agent, công cụ này sẽ đọc công việc, các thông số kỹ thuật liên quan và bình luận, viết mã sửa lỗi, và mở Yêu cầu Hợp nhất với tiến độ được cập nhật trở lại công việc.
Mẹo chuyên nghiệp: Các trưởng nhóm QA có thể nhanh chóng nắm bắt tình hình của bất kỳ công việc nào bằng cách yêu cầu ClickUp Brain tóm tắt các công việc liên quan đến lỗi chưa được khắc phục. Nhờ đó, họ có đầy đủ thông tin cần thiết cho các buổi đánh giá sprint mà không cần phải lục lọi từng công việc riêng lẻ để ghép nối các thông tin lại với nhau.
Thực hiện các chu kỳ kiểm thử với các chế độ xem. Sử dụng Chế độ xem Bảng (Board View) được phân nhóm theo trạng thái để nắm bắt ngay lập tức tỷ lệ đỗ/trượt trong quá trình chạy kiểm thử. Chế độ xem Bảng (Table View) hoạt động như một ma trận kiểm thử truyền thống khi bạn cần xem xét kết quả trên hàng chục trường hợp kiểm thử. Lọc theo người được giao nhiệm vụ để cân bằng khối lượng công việc, hoặc theo mức độ ưu tiên để tập trung kiểm thử sơ bộ (smoke test) vào các đường dẫn quan trọng trước tiên.
Mẫu Quản lý Kiểm thử ClickUp cung cấp cho bạn một cách thức tập trung để quản lý toàn bộ quy trình kiểm thử trên nhiều lĩnh vực tính năng, kịch bản kiểm thử và các trường hợp ngoại lệ tại một nơi duy nhất. Sử dụng mẫu này để theo dõi phản hồi của người dùng, quản lý lịch trình kiểm thử, giám sát tiến độ các bài kiểm thử và đánh giá kết quả đỗ/trượt mà không cần chuyển đổi giữa các công cụ.
Quản lý quy trình kiểm thử của bạn một cách hiệu quả
Một trường hợp kiểm thử được coi là hợp lệ ngay khi hai người có thể thực hiện nó một cách độc lập và đều nhận được kết quả "đạt" hoặc "không đạt" giống nhau. Mọi nội dung trong hướng dẫn này (mỗi bước thực hiện một hành động, điều kiện tiên quyết rõ ràng, kết quả mong đợi không để lại chỗ cho sự diễn giải) đều tuân theo tiêu chuẩn duy nhất đó. Nếu bạn đã có kế hoạch cho các sprint trong ClickUp, cách thiết lập được đề cập ở trên cho phép bạn viết, thực hiện và theo dõi các trường hợp kiểm thử cùng với các lỗi mà chúng phát hiện ra, mà không cần thêm bất kỳ công cụ nào khác.
Các câu hỏi thường gặp về trường hợp thử nghiệm
Một yêu cầu nên có bao nhiêu trường hợp kiểm thử?
Một yêu cầu duy nhất có thể cần một trường hợp kiểm thử hoặc mười trường hợp, tùy thuộc vào số lượng kịch bản, trường hợp biên và các biến thể đầu vào mà nó liên quan. Mục tiêu là bao quát tất cả các đường dẫn thực tế, đảm bảo độ bao phủ đầy đủ mà không bị trùng lặp.
Sự khác biệt giữa trường hợp thử nghiệm và kịch bản thử nghiệm là gì?
Một trường hợp kiểm thử ghi lại những gì cần kiểm thử và kết quả mong đợi, được viết để thực hiện thủ công. Ngược lại, kịch bản kiểm thử là phiên bản tự động hóa: mã thực thi các bước đó một cách tự động.
Các bước kiểm thử nên chi tiết đến mức nào?
Chia bài kiểm thử thành các bước logic, tuần tự, dễ theo dõi ngay cả khi không có bối cảnh trước đó. Tránh gộp nhiều hành động lại với nhau hoặc thêm sự phức tạp không cần thiết.
Một kịch bản kiểm thử nêu rõ cái gì cần kiểm thử trong một dòng (“Xác minh việc đặt lại mật khẩu”); một trường hợp kiểm thử chỉ định cách thức thực hiện, bao gồm các điều kiện tiên quyết, các bước thực hiện, dữ liệu kiểm thử và kết quả mong đợi. Một kịch bản thường tạo ra từ 3 đến 10 trường hợp kiểm thử, bao quát các trường hợp bình thường, đầu vào không hợp lệ và các điều kiện biên. Kịch bản được xác định trước và định hướng cho kế hoạch độ bao phủ; các trường hợp kiểm thử được xác định sau và định hướng cho việc thực thi.
Một trường hợp kiểm thử tích cực sử dụng đầu vào hợp lệ và mong đợi kết quả thành công: email và mật khẩu chính xác sẽ đăng nhập người dùng. Một trường hợp kiểm thử tiêu cực sử dụng đầu vào không hợp lệ hoặc không mong đợi và mong đợi hệ thống sẽ thất bại một cách trơn tru: mật khẩu sai sẽ hiển thị thông báo “Mật khẩu không hợp lệ” mà không tạo phiên. Các bộ kiểm thử hoàn thiện thường có tỷ lệ trường hợp tích cực so với tiêu cực khoảng 1:3 đến 1:5, bởi vì hầu hết các lỗi trong môi trường sản xuất thường xuất hiện trong các đường dẫn lỗi, chứ không phải các đường dẫn thành công.
Kế hoạch kiểm thử xác định phạm vi, phương pháp tiếp cận, nguồn lực và lịch trình cho toàn bộ nỗ lực kiểm thử. Bộ kiểm thử là tập hợp các trường hợp kiểm thử được nhóm lại để thực hiện trong một lần chạy, chẳng hạn như “bộ kiểm thử hồi quy cho phiên bản 2.1”. Trường hợp kiểm thử là đơn vị cơ bản trong cả hai: một bước kiểm tra được ghi chép với kết quả là “đạt” hoặc “không đạt”. Kế hoạch xác định chiến lược, bộ kiểm thử xác định phạm vi, còn trường hợp kiểm thử xác định kết quả.