Nội dung:
- Test Case là gì
- Cấu trúc của một Test Case
- Các kiểu Test Case
- 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:
- Người dùng phải đăng nhập
- Vào trang "tải ảnh lên" (upload photos)
- Nhấn nút "tải lên" (upload)
- Chọn ảnh
- 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.
| ID | Test Case Field | Description |
|---|---|---|
| 1 | Test case ID | Mỗi test case nên có một ID duy nhất |
| 2 | Test Priority | Rất hữu ích trong khi thực thi test. Có các loại priority: - Low - Medium - High |
| 3 | Test Designed by | Tên của người viết test cases (tester) |
| 4 | Date of test designed | Ngày mà các thử nghiệm được tạo ra |
| 5 | Test Executed by | Người thực thi việc kiểm thử (tester) |
| 6 | Date of the Test Execution | Ngày thực thi việc kiểm thử |
| 7 | Name or Test Title | Tiêu đề phải cung cấp sự mô tả ngắn gọn về trường hợp thử nghiệm, chẳng hạn như "Đặt lại mật khẩu". Tiêu đề khá quan trọng bởi vì nó thường là điều đầu tiên hoặc duy nhất bạn thấy khi nhìn lướt qua một danh sách các trường hợp thử nghiệm (test cases). Tiêu đề rõ ràng là chìa khóa giúp người kiểm thử nhanh chóng tìm ra các trường hợp thử nghiệm đúng. |
| 8 | Description/Summary of Test | Mô tả chi tiết cho trường hợp thử nghiệm (test case). Trong phần này, bạn cũng có thể thiết lập các danh mục để tổ chức các trường hợp thử nghiệm (test cases) thành các nhóm hợp lý. |
| 9 | Pre-condition | Bất kỳ yêu cầu cần được hoàn thành trước khi thực thi trường hợp thử nghiệm (test case) |
| 10 | Test Steps | Các bước kiểm thử, đưa ra cho tester một danh sách được đánh số các bước thực hiện trong hệ thống, giúp cho test case dễ hiểu hơn. Nên có từ 3-8 bước kiểm thử trên 1 trường hợp kiểm thử (test case). Quá nhiều bước sẽ gây khó khăn cho các lập trình viên và nhân viên kiểm thử tái hiện lại các bước khi một báo cáo lỗi (bug report) được đưa ra dựa vào test case. |
| 11 | Test Data | Bạn có thể nhập dữ liệu kiểm thử trực tiếp vào các trường dữ liệu kiểm thử (test data), hoặc chỉ ra một tập tin riêng biệt chứa dữ liệu kiểm thử cho 1 hoặc nhiều trường hợp kiểm thử (test cases). Bằng việc sử dụng một tập tin dữ liệu kiểm thử như vậy, bạn sẽ tránh khỏi dữ liệu kiểm thử mã hóa cứng trong trường hợp kiểm thử, nên 1 trường hợp kiểm thử đơn lẻ có thể được sử dụng để kiểm tra một tập hợp các dữ liệu kiểm thử |
| 12 | Expected Results | Đề cập đến kết quả mong muốn bao gồm lỗi hoặc thông báo xuất hiện trên màn hình. Người kiểm thử cần phải biết kết quả mong muốn để đánh giá xem trường hợp kiểm thử này có thành công hay không. Chi tiết về mức độ tối ưu của trường này thay đổi tùy theo tình hình. |
| 13 | Post-Condition | Trạng thái của hệ thống sau khi chạy trường hợp thử nghiệm là gì? |
| 14 | Status (Fail/Pass) | Đánh dấu trường này là không thành công (Fail), nếu kết quả thực tế (actual result) không giống với kết quả mong đợi (expected resutl). Đánh dấu trường này là thành công (Pass) nếu kết quả thực tế (actual result) giống với kết quả mong đợi (expected resutl) |
| 15 | Notes/Comments/Questions | Nếu có một vài điều kiện đặc biệt cần ghi chú liên quan đến những trường phía trên |
| 16 | Requirements | Danh sách các yêu cầu cho một chu kỳ kiểm tra cụ thể. |
| 17 | Attachments/References | Các tệp và tài liệu được gắn vào trường hợp kiểm thử, chẳng hạn như ảnh chụp màn hình và các tài liệu hỗ trợ khác |
| 18 | Automation? (Yes/No) | Điền vào "CÓ" khi các trường hợp thử nghiệm được chạy tự động |
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.
| Poject Name: Banking System | Test Case |
|---|---|
| Test Case ID: BU_001 | Test Designed by: <Name> |
| Test Priority (Low/Medium/High): Med | Test Designed date: <Date> |
| Module Name: Bank login screen | Test Executed by: <Name> |
| Test Title: Test the Login Functionality in Banking | Test Execution date: <Date> |
| Description: Verify login with valid username and password |
| Pre-conditions: User has valid username and password |
|---|
| Dependencies: |
| Step | Test Steps | Test Data | Expected Result | Actual Result | Status (Pass/Fail) | Notes |
|---|---|---|---|---|---|---|
| 1 | Navigate to login page | User should be able to login | User is able to login | Pass | ||
| 2 | Provide valid username | User= [email protected] | Credential can be entered | As Expected | Pass | |
| 3 | Provide valid password | Password: 1234 | Credential can be entered | As Expected | Pass | |
| 4 | Click on Login button | User logged | User logged successfully | Pass |