Cách giúp bạn viết Test Case Nhanh – Đơn giản – Hiệu quả

test case

Test Case là tập hợp các hành động được thực thi để xác minh một tính năng hoặc chức năng cụ thể của ứng dụng phần mềm. Bài viết này mô tả cách thiết kế Test Case và tầm quan trọng của các thành phần trong Test Case.

Định dạng của Test Case tiêu chuẩn

Test Case ID Kịch bản kiểm thửCác bước kiểm thửDữ liệu Kiểm thửKết quả dự kiếnKết quả thực tếPass/Fail
TU01Kiểm thử đăng nhập của khách hàng với dữ liệu hợp lệ.Bước 1: Truy cập trang web Link  
Bước 2: Nhập tên người dùng
và mật khẩu
Bước 3: Click vào Submit
Tên người dùng: guru99 Mật khẩu: pass99Người dùng đăng nhập vào website thành côngNhư mong đợiPass
TU02Kiểm thử đăng nhập của khách hàng với dữ liệu không hợp lệBước 1: Truy cập trang web Link  
Bước 2: Nhập tên người dùng
và mật khẩu
Bước 3: Click vào Submit
Tên người dùng: guru99 Mật khẩu: glass99Người dùng đăng nhập vào website thành côngNhư mong đợiPass

Một Test Case bao gồm các thông tin sau:

  • Mô tả về những yêu cầu được kiểm thử.
  • Giải thích về cách hệ thống sẽ được kiểm thử.
  • Các thiết lập khi kiểm thử như: phiên bản ứng dụng đang kiểm thử, phần mềm, những tệp dữ liệu, hệ điều hành, phần cứng, truy cập bảo mật, ngày thực hiện, các điều kiện tiền đề và bất kỳ thông tin thiết lập nào khác phù hợp với các yêu cầu đang được kiểm thử.
  • Đầu vào và đầu ra hoặc hành động và kết quả mong đợi.
  • Bất kỳ bằng chứng hoặc tệp đính kèm.
  • Sử dụng ngôn ngữ hoạt động.
  • Test Case không được quá 15 bước.
  • Kịch bản kiểm thử tự động được chú thích đầu vào, mục đích và kết quả mong đợi.
  • Thiết lập những thay đổi cho các kiểm thử cần thiết trước.

Cách để viết Test Case tốt nhất.

1. Các Test Case cần phải đơn giản và minh bạch:

Tạo các Test Case đơn giản nhất có thể. Test Case phải rõ ràng và ngắn gọn vì tác giả của Test Case có thể không thực hiện chúng.

Sử dụng ngôn ngữ dễ hiểu như: đi đến trang chủ, nhập dữ liệu, click vào Submit… Điều này làm cho việc hiểu các bước kiểm thử dễ dàng và thực hiện kiểm thử nhanh hơn.

2. Tạo Test Case với vai trò như người dùng cuối

Mục tiêu cuối cùng của bất kỳ dự án phần mềm nào là tạo ra phần mềm đáp ứng yêu cầu của khách hàng và dễ sử dụng cũng như dễ vận hành. Người kiểm thử phải tạo Test Case dựa trên quan điểm người dùng cuối.

3. Tránh lặp lại Test Case.

Không lặp lại các Test Case. Nếu một Test Case là cần thiết để thực hiện một số Test Case khác, hãy nêu Test Case Id trong cột điều kiện tiền đề.

4. Không phỏng đoán

Không phỏng đoán các chức năng và tính năng của ứng dụng phần mềm trong khi chuẩn bị Test Case, phải bám sát các Tài liệu kỹ thuật.

5. Đảm bảo bao phủ 100%

Hãy chắc chắn rằng bạn viết các Test Case để kiểm thử tất cả các yêu cầu phần mềm được đề cập trong tài liệu đặc tả. Sử dụng Ma trận truy xuất nguồn gốc (Traceability Matrix) để đảm bảo không có chức năng hay điều kiện nào chưa được kiểm thử.

6. Các Test Case phải được xác định.

Đặt tên các Test Case sao cho chúng được xác định dễ dàng khi theo dõi lỗi hoặc xác định yêu cầu phần mềm ở giai đoạn sau.

7. Thực hiện các kỹ thuật kiểm thử

Không thể kiểm thử mọi điều kiện có thể có trong ứng dụng phần mềm. Kỹ thuật kiểm thử sau đây giúp bạn chọn những Test Case với khả năng tìm thấy lỗi tối đa.

Phân tích giá trị biên (Boundary Value Analysis): Đây là kỹ thuật kiểm thử xác định các ranh giới cho phạm vi giá trị được chỉ định.

Phân vùng tương đương (Equivalence Partition): Kỹ thuật này phân vùng phạm vi thành các phần giống nhau hoặc nhóm có xu hướng có cùng kết quả.

Kỹ thuật chuyển trạng thái (State Transition Technique): Phương pháp này được sử dụng khi hệ thống có xử lý thay đổi từ trạng thái này sang trạng thái khác sau hành động cụ thể.

Kỹ thuật đoán lỗi (Error Guessing Technique): Dự đoán lỗi có thể phát sinh trong khi kiểm thử. Đây không phải là kỹ thuật chính thức và kỹ thuật này tận dụng trải nghiệm của tester với ứng dụng.

8. Làm sạch môi trường kiểm thử

Test Case bạn tạo phải đảm bảo môi trường kiểm thử đúng theo yêu cầu, phải phục hồi môi trường kiểm thử về trạng thái trước khi kiểm thử khi môi trường kiểm thử đã bị thay đổi và môi trường kiểm thử phải sử dụng được. Điều này đặc biệt đúng đối với kiểm thử cấu hình.

9. Lặp lại và không thay đổi

Test Case sẽ tạo ra kết quả giống nhau mỗi lần bất kể ai kiểm thử nó

10. Đánh giá ngang hàng.

Sau khi tạo các Test Case, hãy để các đồng nghiệp của bạn review Test Case. Đồng nghiệp của bạn có thể phát hiện ra các lỗi trong thiết kế Test Case của bạn mà bạn có thể dễ dàng bỏ qua.