1. Test Case là gì
Test case là đơn vị nhỏ nhất của chiến lược kiểm thử, giới thiệu 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 đợi (expected behaviour) của một chức năng cụ thể hoặc một phần nào đó của công cụ 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 sử 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à hiệu 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 – để định hình tất cả các hành vi tích cực, tiêu cực và các hành vi không giống của công cụ.
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 sử 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ư gợi ý sau:
- Kiểm tra khả năng vào trang “tải hình lên” của người sử dụng đã đăng nhập
- Kiểm tra cấp độ vào trang “tải ảnh lên” của người dùng chưa đăng nhập
- Kiểm tra nhìn thấy người sử dụng đủ nội lực nhấn vào nút “tải lên” tốt k
- Nhấn vào nút “tải lên” có xây dựng ra cửa sổ để chọn các loại hình, và đủ nội lực phá sản sổ đó hay không
- Điều gì sẽ xảy ra nếu bạn k chọn hình, tốt bạn chọn định dạng tệp không giống (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 cấp độ tải ảnh lên
- Kiểm tra nếu ảnh được lưu
- Kiểm tra cấp độ tải lại ảnh hoặc xóa hình
- Điều gì xảy ra với hình trong trường hợp mất gắn kết 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. tỉ lệ các trường hợp thử nghiệm phụ thuộc vào trải nghiệm và trí tưởng tượng của người kiểm thử (tester). Do đó, tiến trình viết các trường hợp thử nghiệm (test cases) bắt đầu từ việc xây dựng 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 đích của tài liệu Test Case là để dựng lại và liên kết 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 tạo dựng bởi rất nhiều thứ nhưng thường sẽ bao gồm một chọn lọc các trường hợp dùng, đặc tính hiệu suất và rủi ro trong dự án. Mẫu test case khả thi sẽ duy trì tính nhất quán của kiểm thử và giúp sức tất cả các bên liên quan đơn giản hiểu rõ các trường hợp kiểm thử. viết các trường hợp kiểm thử ở định hướng chuẩn sử dụng giảm cố gắng 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 vạch test cases (tester) |
| 4 | Date of test designed | Ngày mà các thử nghiệm được xây dựng |
| 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 đem đến sự giới thiệu ngắn gọn về trường hợp thử nghiệm, chẳng hạn như “Đặt lại mật khẩu”. tittle 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 mục các trường hợp thử nghiệm (test cases). tiêu đề rõ ràng là chìa kiềm hãm giúp người kiểm thử mau chóng tìm ra các trường hợp thử nghiệm đúng. |
| 8 | Description/Summary of Test | giới thiệu 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 mục lục để tổ chức các trường hợp thử nghiệm (test cases) thành các nhóm chuẩn. |
| 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 easy 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 đủ nội lực 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 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ẻ đủ nội lực được dùng để kiểm tra một chọn lọc các dữ liệu kiểm thử |
| 12 | Expected Results | Đề cập đến kết quả mong đợi gồm có 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ả chờ đợi để đánh giá xem trường hợp kiểm thử này có thành đạt hay không. Chi tiết về mức độ tối ưu của trường này refresh tùy theo tình ả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 đạt (Fail), nếu hiệu quả thực tế (actual result) không giống với hiệu 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ả chờ đợ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 giúp đỡ không giống |
| 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 chủ đề khi đội trưởng, thống trị dự án hoặc người mua 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 kết quả các tác dụ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, tỉ lệ đủ nội lực tăng trưởng ít nhất gấp 3 lần. Các loại Test case được mô tả bằng những cách thức không giống 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 cải thiện. Chúng tôi đem đến những loại Test Cases sau để bạn đủ sức phân chia trong chiến lược 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 thức sử dụng hợp lý đầu vào chính xác được chỉ định trong tài liệu công cụ. Ví dụ: trường hợp thử nghiệm tích cực sẽ kiểm tra tất cả các định hình đúng của email, mà phải cung cấp các yêu cầu sau:
I. Phần đầu tiên của địa chỉ tin nhắn hộp thư online, 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 thức (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 @ đủ sức 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 k 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 đủ nội lực dẫn đến thông báo lỗi. Ngoài ra, loại trường hợp kiểm thử này gồm có xác minh các tình huống không mong đợi đủ sức xảy ra, gợi ý như những trường hợp k được giới thiệu trong tài liệu. Ví dụ: bạn có thể kiểm tra trường email, đưa ra các ký tự k có trong mục lục đượ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 nhìn thấy 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 nguyên nhân 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 đủ nội lực 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à k quá 60 ký tự. vì vậy, bạn phải tất nhiê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 k mô tả các hạn chế như vậy, bạn đủ nội lực tự giới thiệu cho họ, cũng như bàn luận với nhóm để đưa ra thống nhất!
Integration – Tích hợp
Kiểm tra sự liên kết giữa các phần không giống 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 cấp độ 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 gồm có ít nhất hai mô-đun. Bạn có thể vạch 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 tác dụ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à đủ sức sẽ có chủ đề 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 thành phần giao diện người sử dụng bằng các ngôn ngữ không giống nhau và vị trí của chúng (nếu có trợ giúp cho các ngôn ngữ có những quy tắc viết và đọc không giống nhau). Ví dụ: Nếu phần mềm của bạn giúp đỡ một trong những vị trí mà giao diện người sử 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 đủ sức mô tả sự xuất hiện của các giúp đỡ trong chương trình, phím nóng, lỗi… Nếu bạn có một phần mềm háo hức giúp đỡ 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 k sự dụng bất kỳ phần mềm quản lý test case nào, bạn đủ sức dùng công cụ mã nguồn xây dựng hoặc Excel để thống trị 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 đủ sức bớt đi thời gian và gốc lực để đảm bảo hiểu đầy đủ hàng hóa bởi một tỉ lệ 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 người mua, hay bất kỳ bên thứ 3 nào cũng có thể xem và phân tích.)
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ẽ làm họ bao phủ toàn bộ món hàng bằng các kiểm tra chất lượng và không bỏ lỡ bất kỳ dữ liệu cần kíp nào.
| Poject Name: Banking System | Test Case |
|---|---|
| Test Case ID: BU_001 | Test Designed by: |
| Test Priority (Low/Medium/High): Med | Test Designed date: |
| Module Name: Bank login screen | Test Executed by: |
| Test Title: Test the Login Functionality in Banking | Test Execution 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= example@gmail.com | Credential can be entered | As Expected | Pass | |
| 3 | Provide valid password | Password: 1234 | Credential can be entered | As Expected | Pass | |
| 4 | kích on Login button | User logged | User logged successfully | Pass |
Nguồn: https://viblo.asia/
