Test case là gì? Cách viết test case đơn giản, chất lượng

Test case là gì?

Theo Topchuyengia, test case là một tài liệu mô tả chi tiết cách kiểm thử một chức năng hoặc một phần của phần mềm. Mục đích của test case là đảm bảo các chức năng của phần mềm được kiểm tra chi tiết và có hệ thống. Ngoài ra, các test case cũng làm nhiệm vụ hướng dẫn và tài liệu hóa quá trình kiểm thử để stakeholders có thể hiểu và tái sử dụng khi cần thiết.

Ví dụ: 

Tên test case: Đăng nhập hợp lệ

Mục tiêu kiểm thử: Đảm bảo rằng chức năng đăng nhập hoạt động chính xác khi sử dụng thông tin đăng nhập hợp lệ.

Bước thực hiện:

• Mở trang đăng nhập.
• Nhập tên đăng nhập và mật khẩu.
• Nhấn nút "Đăng Nhập".

Dữ liệu kiểm thử:

• Tên đăng nhập: user123
• Mật khẩu: pass123

Kết quả dự kiến: Người dùng được chuyển đến trang chính sau khi đăng nhập thành công.
Tiêu chí chấp nhận:

• Thời gian thực hiện test case không quá 2 phút.
• Đảm bảo rằng không có lỗi xuất hiện và người dùng được chuyển đến trang chính.

Môi trường kiểm thử: Trình duyệt Google Chrome.

Bước hậu kiểm:

• Xóa dữ liệu đăng nhập.
• Báo cáo kết quả kiểm thử.

Hướng dẫn cách viết Test Case chi tiết

Để viết test case, bạn cần thực hiện các bước sau:

Xác định dữ liệu đầu vào (Input): Đây là bước quan trọng trong cách viết test case và nó tốn khá nhiều thời gian. Bạn sẽ phải biết mình định nhập cái gì để ra được kết quả mong muốn. 

Ví dụ: Muốn kiểm tra chức năng đăng nhập, bạn sẽ nhập username và password vào hệ thống. Cụ thể, tester nhập dữ liệu test: 

1. Nhập username = anhdt 
2. Nhập password = abc@123 
3. **Kết quả mong đợi / Expected result: **.

Một test case tốt cũng phải đề cập rõ ràng kết quả mong đợi của một hệ thống hoặc ứng dụng. Nếu phần mềm không chạy đúng như kết quả mong đợi đó, thì sẽ cho ra lỗi (bug/defect) và test case đó là Fail.
 

Xác định kết quả thực tế (Test Result): Bước quan trọng tiếp theo trong cách viết test case  là ghi lại kết quả thực tế khi bạn thực hiện test theo test case. Kết quả thực tế thường sẽ rơi vào 3 trường hợp là pass, fail, hoặc pending. Nếu kết quả thực tế khác với kết quả mong đợi, bạn cần báo cáo lỗi cho nhà phát triển ngay lập tức.
 

Xác định trường hợp kiểm tra: Trong cách viết test case, chắc chắn bạn cần xem xét các trường hợp có thể xảy ra khi bạn kiểm tra một giá trị nào đó.

Có 3 loại trường hợp chính: Normal case (các trường hợp bình thường), Abnormal case (các trường hợp bất thường), và Boundary case (các trường hợp biên).

Đối với cách viết test case chức năng, bạn cần chú ý đến các điểm sau:

• Các bước thực hiện chỉ mô tả các bước từ phía người dùng cuối, như nhập dữ liệu, nhấn nút button, chọn menu, v.v.
• Kết quả mong đợi có thể bao gồm việc kiểm tra dữ liệu trong cơ sở dữ liệu (CSDL) so với hiển thị trên màn hình, nếu cần thiết. Đây là cách để kiểm tra việc lưu, cập nhật, xóa dữ liệu trong CSDL. Ví dụ: Bạn muốn kiểm tra chức năng đăng ký email, bạn sẽ kiểm tra xem email của bạn có được lưu vào CSDL hay không, bằng cách sử dụng câu lệnh SQL như SELECT * FROM … WHERE …
• Bạn cần xác định yêu cầu của chức năng cần kiểm tra, bao gồm các thành phần giao diện người dùng (UI) như textbox, button, link, v.v.

Ví dụ: Bạn muốn kiểm tra chức năng đăng nhập, bạn sẽ xác định form login gồm 2 textbox email/điện thoại và mật khẩu, 1 button đăng nhập, và 1 link quên tài khoản.

Bạn muốn kiểm tra chức năng đăng nhập, bạn sẽ xây dựng test case cho các trường hợp như sau:

Xây dựng testcase:

• Về UI: Bạn sẽ kiểm tra màu sắc, font, kích thước, vị trí, loại của các textbox, button, link, v.v.
• Về chức năng: Bạn sẽ kiểm tra các trường hợp normal, abnormal, và boundary cho các textbox email/điện thoại và mật khẩu, button đăng nhập, và link quên mật khẩu.

Các trường hợp kiểm tra:

• Normal case: Bạn nhập đúng username và password, hoặc bạn không nhập gì cả, hoặc bạn nhập sai username hoặc password,..
• Abnormal case: Bạn nhập số điện thoại có mã vùng, mã nước vào trước đó, hoặc bạn nhập email không có @, ngoài ra bạn còn có thể test các case không có kết nối internet (offline mode), hoặc bạn có cuộc gọi đến khi đang đăng nhập (nếu là mobile),...
• Boundary case: Bạn nhập username hoặc password có số ký tự tối thiểu hoặc tối đa cho phép. Hoặc tạo ra 1 email với nhiều ký tự để test, hoặc 1 email ngắn nhất có thể để test,...

Bố cục chính của một Test Case

Khi tiến hành kiểm thử phần mềm, mỗi Test Case cần được thiết kế một cách cụ thể và chi tiết. Dưới đây là các thành phần chính cần có trong một Test Case:

• Test Case ID: Là số thứ tự duy nhất để nhận diện từng Test Case, nó giúp quản lý, theo dõi và phân biệt test case với nhau. Trước tiên, bạn cần xác định số lượng Test Case mà mình phải thực hiện. Số lượng Test Case khác nhau sẽ tùy thuộc vào mỗi dự án khác nhau.
• Function (Chức năng): Dùng để mô tả chức năng hoặc tính năng cụ thể của ứng dụng mà Test Case này sẽ kiểm thử. Thông thường, khi Testing, chúng ta sẽ tập trung vào một chức năng cụ thể của ứng dụng. Nhưng các chức năng này có thể được chia thành các chức năng nhỏ hơn. Ví dụ, khi Đăng nhập Facebook, có thể chia thành 2 chức năng là: Đăng nhập và Kiểm tra form đăng nhập.
• Test Data: Đây là dữ liệu đầu vào được sử dụng trong quá trình kiểm thử.
• Test Steps:  Bao gồm các bước thực hiện chi tiết từ bắt đầu đến kết thúc của Test Case.
• Expected Results: Kết quả mong đợi sau khi thực hiện Test Case, dùng để so sánh với kết quả thực tế.
• A Result: Kết quả thực tế sau khi thực hiện Test Case, được ghi nhận là pass, fail hoặc pending.
• Comments: Phần này dùng để ghi chú bất kỳ thông tin phát sinh hoặc quan sát được trong quá trình kiểm thử. Đồng thời, chúng cũng được sử dụng để lưu trữ các thông tin phát sinh trong suốt quá trình.

Ngoài ra, bạn cũng có thể thêm các thông tin khác như:

• Tester: Người thực hiện kiểm thử.
• Execution Date: Ngày thực hiện kiểm thử.
• Test Requirement: Liên kết Test Case với yêu cầu cụ thể, giúp theo dõi độ bao phủ kiểm thử.

Lưu ý quan trọng khi viết Test Case

Các lưu ý cần nắm khi viết Test case:

• File test case cần có các bước test đơn giản, minh bạch, dễ hiểu, để bất kỳ tester nào cũng có thể thực hiện được.
• Mục đích và phạm vi của test case cũng cần được mô tả chi tiết, để biết test case này kiểm tra chức năng nào, áp dụng cho trường hợp nào, v.v.
• Điều kiện tiền đề và dữ liệu test cũng cần được ghi rõ ở từng test case, để biết test case này cần chuẩn bị gì trước khi thực hiện, và cần nhập gì vào hệ thống.
• Test case nên được review chéo bởi các thành viên trong team, để đảm bảo chất lượng và độ phủ của test case.
• Không nên gộp quá nhiều kết quả mong đợi vào một test case, mà nên tách ra thành nhiều test case nhỏ, để dễ theo dõi và báo cáo kết quả.
• Khi tạo test case, nên sử dụng các công cụ hỗ trợ như Excel, Word, Google Sheets, v.v. hoặc các phần mềm quản lý test như TestRail, Jira, TestLink, v.v."

Những câu hỏi thường gặp về cách viết test case

Dưới đây là một số câu hỏi thường gặp liên quan đến cách viết test case mà bạn có thể tham khảo:

Câu hỏi 1: Test case là gì và tại sao cần viết test case?

Trả lời: Test case là một tập hợp các điều kiện, đầu vào, hành động và kết quả mong đợi để kiểm tra một chức năng hoặc một khía cạnh nào đó của phần mềm. Viết test case giúp đảm bảo chất lượng của phần mềm, phát hiện và sửa lỗi kịp thời, tiết kiệm thời gian và chi phí, và tăng hiệu quả của quá trình kiểm thử.

Câu hỏi 2: Test case nên viết khi nào và bởi ai?

Trả lời: Test case nên viết ngay sau khi có tài liệu yêu cầu và thiết kế của phần mềm, và trước khi bắt đầu viết code. Test case nên được viết bởi các tester chuyên nghiệp, hoặc các nhà phát triển, hoặc các nhà phân tích nghiệp vụ (BA), hoặc các khách hàng, tùy thuộc vào mô hình phát triển và phương pháp kiểm thử được áp dụng.

Câu hỏi 3: Test case nên viết bao nhiêu và kiểm tra những gì?

Trả lời: Test case nên viết đủ để bao phủ tất cả các yêu cầu và chức năng của phần mềm, và kiểm tra các trường hợp có thể xảy ra. Test case nên viết theo nguyên tắc 80/20, tức là 80% test case kiểm tra các trường hợp bình thường, và 20% test case kiểm tra các trường hợp bất thường và biên. Test case nên viết theo các mức độ khác nhau, từ test case mức cao (test scenario) đến test case mức thấp (test case chi tiết).

Câu hỏi 4: Test case gồm những gì?

Trả lời: Để viết test case, bạn cần có các thông tin sau:

• Test case ID: Mã số duy nhất cho mỗi test case, để phân biệt và theo dõi chúng
• Test summary: Mục tiêu của test case, tức là chức năng hoặc khía cạnh nào của phần mềm cần kiểm tra
• Test precondition: Điều kiện cần thiết để bắt đầu test case, ví dụ như đăng nhập, kết nối internet, v.v.
• Test steps: Các hành động cụ thể để thực hiện test case, ví dụ như nhập dữ liệu, nhấn nút, chọn menu, v.v.
• Expected result: Kết quả mong muốn khi thực hiện test case, ví dụ như hiển thị thông báo, lưu dữ liệu, v.v.

Câu hỏi 5: Làm sao để viết test case có độ bao phủ cao?

Trả lời: Để viết test case đảm bảo độ bao phủ cao, nó phải bao gồm các loại test case cho UI (nếu có – vì ví dụ bạn đang test API thì sẽ không có UI, do đó không cần có test cho trường hợp này). Có test case cho các trường hợp negative case (unhappy case) và happy case (positive case). Điều quan trọng hơn hết, tập test case của bạn phải bao phủ mọi nghiệp vụ, chức năng cần thiết theo mô tả yêu cầu.

Câu hỏi 6: Phải viết test case cho dự án nào?

Trả lời: Việc viết test case có thể khác nhau tùy thuộc vào loại dự án bạn tham gia, là gia công phần mềm (outsourcing) hay phát triển phần mềm (product). Tuy nhiên, bạn ít nhất cũng nên có checklist để đảm bảo kiểm thử đầy đủ các chức năng quan trọng, và phần mềm đáp ứng tất cả các yêu cầu đã đặt ra.

Câu hỏi 7: Có bắt buộc phải viết test case không?

Trả lời: Một số dự án sẽ không có đủ thời gian để viết test case. Thông thường, tester (QC) sẽ viết test case trong khi lập trình viên (dev) đang phát triển phần mềm.

Tuy nhiên đôi khi dự án không hoàn toàn là viết mới mà chỉ cập nhập hoặc nâng cấp hệ thống có sẵn, thì thời gian lập trình thường sẽ nhanh hơn thời gian viết test case. Nếu như cần gấp thì mình vẫn có thể test (kiểm thử) trước khi viết test case xong. Hoặc vừa kiểm thử vừa viết.