Nội dung:

1. Test Case là gì
2. Cấu trúc của một Test Case
3. Các kiểu Test Case
4. Ví dụ

1. Test Case là gì

Test case là đơn vị nhỏ nhất của kế hoạch kiểm thử, mô tả các hành động và thông số cần thiết để đạt được cũng như xác minh rõ hành vi mong muốn (expected behaviour) của một chức năng cụ thể hoặc một phần nào đó của phần mềm cần được kiểm tra. Nếu bạn có một nhiệm vụ (task) là kiểm tra một vài chức năng nào đó, bạn có thể tạo một kịch bản kiểm thử (test script) hoặc câu chuyện người dùng (user story). Vậy bạn cần phải biết nên bắt đầu kiểm thử từ đâu, các bước chung chung nào cần để thực thi, và kết quả nên như thế nào. Sau đấy kịch bản này sẽ được chia nhỏ thành các phần chi tiết hơn, đó là test cases - để xác định tất cả các hành vi tích cực, tiêu cực và các hành vi khác của phần mềm.

Ví dụ: Người kiểm thử cần kiểm tra chức năng tải ảnh lên (upload photos) Chúng ta sẽ tạo 1 kịch bản kiểm thử như sau:

1. Người dùng phải đăng nhập
2. Vào trang "tải ảnh lên" (upload photos)
3. Nhấn nút "tải lên" (upload)
4. Chọn ảnh
5. Tải ảnh lên

Bây giờ, kịch bản này nên được chia thành các trường hợp kiểm thử chi tiết như ví dụ sau:

• Kiểm tra khả năng vào trang "tải ảnh lên" của người dùng đã đăng nhập
• Kiểm tra khả năng vào trang "tải ảnh lên" của người dùng chưa đăng nhập
• Kiểm tra xem người dùng có thể nhấn vào nút "tải lên" hay không
• Nhấn vào nút "tải lên" có mở ra cửa sổ để chọn các loại ảnh, và có thể đóng cửa sổ đó hay không
• Điều gì sẽ xảy ra nếu bạn không chọn ảnh, hay bạn chọn định dạng tệp khác (ví dụ video), chọn ảnh có kích thước tối đa, chọn ảnh có kích thước vượt quá kích thước tối đa
• Kiểm tra khả năng tải ảnh lên
• Kiểm tra nếu ảnh được lưu
• Kiểm tra khả năng tải lại ảnh hoặc xóa ảnh
• Điều gì xảy ra với ảnh trong trường hợp mất kết nối Internet hoặc thiết bị đã bị tắt
• Tất cả các nút được hiển thị chính xác ở những vị trí khác nhau hoặc trên các hệ điều hành khác nhau hay không

Và như vậy. Số lượng các trường hợp thử nghiệm phụ thuộc vào kinh nghiệm và trí tưởng tượng của người kiểm thử (tester). Do đó, quá trình viết các trường hợp thử nghiệm (test cases) bắt đầu từ việc tạo ra một kịch bản kiểm thử (test scenario) hoặc câu chuyện của người dùng (user story), và sau đó nó sẽ được phân chia để kiểm tra các trường hợp khác nhau.

2. Cấu trúc của một Test Case

Mục tiêu của tài liệu Test Case là để xác định và kết nối các điều kiện cụ thể cần được xác nhận để cho phép đánh giá hệ thống. Test Cases được hình thành bởi rất nhiều thứ nhưng thường sẽ bao gồm một tập hợp các trường hợp sử dụng, đặc tính hiệu suất và rủi ro trong dự án. Mẫu test case tốt sẽ duy trì tính nhất quán của kiểm thử và giúp cho tất cả các bên liên quan dễ dàng hiểu rõ các trường hợp kiểm thử. Viết các trường hợp kiểm thử ở định dạng chuẩn làm giảm nỗ lực kiểm tra và tỷ lệ lỗi.

3. Các loại Test Case

Khi bắt đầu sự nghiệp, bất kỳ người kiểm thử (tester) nào cũng phải đối mặt với vấn đề khi đội trưởng, quản lý dự án hoặc khách hàng bày tỏ sự không hài lòng với việc bạn chỉ viết được một vài trường hợp thử nghiệm. Để đảm bảo hiệu quả các chức năng bằng kiểm thử, các trường hợp kiểm thử cần được chia ra thành các loại. Từ những trường hợp kiểm thử ban đầu, số lượng có thể tăng lên ít nhất gấp 3 lần. Các loại Test case được mô tả bằng những cách khác nhau từ những nguồn khác nhau, nhưng bản chất của các thành phần thì không thay đổi. Chúng tôi cung cấp những loại Test Cases sau để bạn có thể phân chia trong kế hoạch kiểm thử của mình.

Positive - Tích cực

Các trường hợp kiểm thử (test cases) nhằm kiểm tra hoạt động đúng của chức năng được xác nhận bằng cách sử dụng chuẩn đầu vào chính xác được chỉ định trong tài liệu phần mềm. Ví dụ: trường hợp thử nghiệm tích cực sẽ kiểm tra tất cả các định dạng đúng của email, mà phải đáp ứng các yêu cầu sau:

I. Phần đầu tiên của địa chỉ email, trước @ có thể chứa bất kỳ ký tự nào ASCII:

• Chữ Latinh, bất kể trường hợp nào - từ a đến z
• Số từ 0 đến 9
• Các ký tự đặc biệt # $% & '* + - / = ^ _ `{|} ~!
• Dấu "." nếu nó nằm giữa những ký tự khác
• Dấu cách (space) và các ký tự "(): <> @ [] cho phép có giới hạn đối với nhận xét hoặc chỉ dẫn về tên, v.v ...

II. Phần tên miền - sau khi ký hiệu @ có thể chứa:

• Chữ Latinh, bất kể trường hợp nào - từ a đến z
• Số từ 0 đến 9, nếu tên miền chứa không chỉ các giá trị số
• Và "-" nếu nó đặt giữa các ký tự khác

Negative - Tiêu cực

Có những Test cases sẽ kiểm tra dự đoán của bạn về mọi tình huống có thể dẫn đến thông báo lỗi. Ngoài ra, loại trường hợp kiểm thử này bao gồm xác minh các tình huống không mong muốn có thể xảy ra, ví dụ như những trường hợp không được mô tả trong tài liệu. Ví dụ: bạn có thể kiểm tra trường email, đưa ra các ký tự không có trong danh sách được đề cập ở trên. Bạn cũng có thể thử gây gián đoạn các trường, kiểm tra xem dữ liệu lưu trữ trong hệ thống được khởi động lại hay tiếp xúc với các yếu tố bên ngoài khác.

Boundary value - Giá trị biên

Để kiểm tra các giá trị trên một trong hai ràng buộc. Một trong số này liên quan đến các kiểm thử tích cực, còn lại là tiêu cực. Tốt hơn là tách biệt chúng để không bỏ lỡ mất kỳ trường hợp nào. Những trường hợp kiểm thử này là dấu hiệu cho thấy bạn sở hữu bản thiết kế kiểm thử, mà bạn có thể xem dưới đây. Ví dụ: bạn tìm thấy thông tin trong tài liệu mà mật khẩu phải chứa ít nhất 6 và không quá 60 ký tự. Vì vậy, bạn phải chắc chắn biết điều gì sẽ xảy ra nếu bạn gõ 5, 6, 60 và 61 ký tự. Đừng quên trường hợp khi bỏ trống trường mật khẩu. Nếu tài liệu không mô tả các hạn chế như vậy, bạn có thể tự giới thiệu cho họ, cũng như thảo luận với nhóm để đưa ra thống nhất!

Integration - Tích hợp

Kiểm tra sự kết nối giữa các phần khác nhau của chương trình. Đây không hẳn là loại trường hợp kiểm thử, mà giống với mức độ kiểm thử hơn. Nhưng điều này là bắt buộc. Bạn phải mô tả chúng, đặc biệt nếu hệ thống của bạn bao gồm ít nhất hai mô-đun. Bạn có thể viết các trường hợp kiểm thử để kiểm tra sự hiện diện của dữ liệu được nhập trong những phần khác của phần mềm. Ví dụ: nếu bạn có một phần thanh toán cho một loại chức năng cụ thể. Thì bạn phải chắc chắn cho dù chức năng đó hoàn thành sau khi thanh toán. Rốt cuộc, các nhà phát triển có thể đã triển khai các phần này một cách riêng biệt, và có thể sẽ có vấn đề phát sinh khi họ tích hợp các phần đó với nhau.

Testing localisation - Kiểm thử nội địa hoá

Kiểm tra tất cả các yếu tố giao diện người dùng bằng các ngôn ngữ khác nhau và vị trí của chúng (nếu có hỗ trợ cho các ngôn ngữ có những quy tắc viết và đọc khác nhau). Ví dụ: Nếu phần mềm của bạn hỗ trợ một trong những vị trí mà giao diện người dùng được đặt từ phải sang trái, bạn nên chú ý vào hoạt động của các chức năng Drop-down list (danh sách thả xuống), check boxes (ô chọn), switching elements On/Off (các nút chuyển trạng thái on/off)

Viết ra các trường hợp để kiểm tra GUI. Bạn có thể mô tả sự xuất hiện của các hướng dẫn trong chương trình, phím nóng, lỗi… Nếu bạn có một phần mềm tuyệt vời hỗ trợ nhiều ngôn ngữ, hãy chia các trường hợp kiểm thử localisation thành các phần riêng biệt. Nếu bạn không sự dụng bất kỳ công cụ quản lý test case nào, bạn có thể dùng công cụ mã nguồn mở hoặc Excel để quản lý và thực thi các test cases của bạn.

Các ví dụ về mẫu test cases rất hữu ích vì khi sử dụng chúng, bạn có thể tiết kiệm thời gian và nguồn lực để đảm bảo hiểu đầy đủ sản phẩm bởi một số lượng lớn các trường hợp thử nghiệm. Định dạng các test cases khác nhau tùy theo công ty, tổ chức. Có rất nhiều phương pháp về tài liệu test cases, và dưới đây là một số ví dụ:

(Chú ý test case nên được viết bằng tiếng anh, để đảm bảo khách hàng, hay bất kỳ bên thứ 3 nào cũng có thể xem và đánh giá.)

4. Ví dụ

Thuận tiện trong trường hợp tester cần ghi lại chi tiết từng bước. Thích hợp khi các test cases được thực hiện cho những người kiểm thử mới (new tester). Nó sẽ giúp họ bao phủ toàn bộ sản phẩm bằng các kiểm tra chất lượng và không bỏ lỡ bất kỳ dữ liệu quan trọng nào.

Tài liệu tham khảo

https://geteasyqa.com/qa/best-test-case-templates-examples/