Use Case Testing Là Gì?
Về mặt khái niệm, Use case testing là một cách để đảm bảo rằng chúng ta đã kiểm thử các luồng xử lý và kịch bản điển hình và đặc biệt cho hệ thống, từ quan điểm của các tác nhân khác nhau tương tác trực tiếp với hệ thống và từ quan điểm của các bên liên quan khác nhau, những người tương tác gián tiếp với hệ thống.
Nếu bảng quyết định tập trung vào các tình huống chuyển đổi, trong đó các điều kiện – đầu vào, điều kiện tiền đề, v.v.. tồn tại tại một thời điểm nhất định cho từng chuyển đổi riêng lẻ là đủ để tự xác định các hành động mà hệ thống nên thực hiện. Thì use case không hoàn toàn cứng nhắc về điểm này. Một luồng xử lý ngoại lệ xảy ra khi một luồng xử lý điển hình không xảy ra. Bản thân khái viện về “Use case” có thể khác nhau đáng kể về hình thức và cách trình bày. Ý tưởng cơ bản là chúng ta có một danh sách các bước được đánh số (hoặc ít nhất là tuần tự) mô tả cách một tác nhân tương tác với hệ thống. Các bước có thể được hiển thị dưới dạng văn bản hoặc dưới dạng một phần của sơ đồ.
Xây Dựng Bài Kiểm Thử Từ Use Case
Giả thuyết lỗi trong kiểm thử dựa vào use case là gì? Nếu với bảng quyết định, chúng ta tìm kiếm sự kết hợp các điều kiện dẫn đến hành động không đúng xảy ra. Thì với use case, chúng chi tiết hơn một chút. Ở đây, chúng ta đang tìm kiếm một tình huống trong đó hệ thống tương tác không đúng với người dùng hoặc mang lại kết quả không đúng.
Hãy cùng xem xét một ví dụ sau đây:
| Ví dụ về use case không chính thức |
|---|
| Mua sắm trực tuyến: Luồng xử lý thông thường |
| 1. Khách hàng đặt một hoặc nhiều mặt hàng vào giỏ hàng |
| 2. Khách hàng chọn thanh toán |
| 3. Hệ thống thu thập thông tin địa chỉ, thanh toán, giao hàng từ khách hàng |
| 4. Hệ thống hiển thị đầy đủ thông tin để Người dùng xác nhận |
| 5. Người dùng xác nhận đơn hàng với hệ thống để giao hàng |
| Các ngoại lệ |
| Khách hàng cố gắng thanh toán khi giỏ hàng trống: Hệ thống đưa ra thông báo lỗi |
| Khách hàng cung cấp địa chỉ, thông tin thanh toán, hoặc thông tin giao hàng không hợp lệ: Hệ thống đưa ra thông báo lỗi phù hợp |
| Khách hàng hủy giao dịch trước hoặc trong quá trình thanh toán: Hệ thống ghi lại nhật ký Khách hàng thoát khỏi sau 10 phút không hoạt động |
Bây giờ, hãy xem xét các test case cho các use case này.
| No. | Test Step | Expected Result |
|---|---|---|
| 1 | Đặt 1 sản phẩm vào giỏ hàng | Mặt hàng trong giỏ hàng |
| 2 | Click vào thanh toán | Màn hình thanh toán |
| 3 | Nhập địa chỉ hợp lệ tại Mỹ, thanh toán hợp lệ bằng American Express, và thông tin phương thức giao hàng hợp lệ | Mỗi màn hình hiểu thị chính xác và đầu vào hợp lệ được chấp nhận. |
| 4 | Xác nhận thông tin đơn hàng | Hiển thị như đã nhập |
| 5 | Xác nhận đơn hàng | Đặt hàng trong hệ thống |
| 6 | Lặp lại step 1-5, nhưng đặt 2 mặt hàng vào giỏ hàng và thanh toán bằng Visa và vận chuyển quốc tế | Như trình bày trong step1-5 |
| 7 | Lặp lại step 1-5 nhưng đặt số lượng mặt hàng tối đa vào giỏ hàng và thanh toán bằng Mastercard | Như trình bày trong step1-5 |
| 8 | Lặp lại các bước 1-5 nhưng thanh toán bằng Discover | Như trình bày trong step1-5 |
Như bạn có thể thấy, mỗi step trong luồng xử lý sẽ ánh xạ với một step trong quy trình kiểm tra. Bạn cũng có thể thấy rằng bài kiểm thử cũng đã thực hiện một số phân tích giá trị biên và phân vùng tương đương về số lượng mặt hàng, hình thức thanh toán và địa chỉ giao hàng. Vì tất cả các lựa chọn này đều hợp lệ nên chúng được kết hợp lại. Lưu ý cách tiếp cận tiết kiệm không gian mô tả cách lặp lại các bước cốt lõi của quy trình kiểm tra với các biến thể, thay vì trình bày lại toàn bộ quy trình kiểm tra, ở phía dưới.
Tiếp theo là các test case mô tả luồng ngoại lệ. Bạn có thể thấy rằng, ở đây phân vùng tương đương được sử dụng ở những điểm mà tại đó khách hàng có thể từ bỏ giao dịch. Đây là một điểm tốt để đưa ra một sự khác biệt quan trọng, đó là giữa các test case hợp lý và cụ thể.
| No. | Test Step | Expected Result |
|---|---|---|
| 1 | Không đặt bất kỳ mặt hàng nào vào giỏ hàng | Giỏ hàng trống |
| 2 | Click vào thanh toán | Thông báo lỗi |
| 3 | Đặt mặt hàng vào giỏ hàng, nhấp vào thanh toán, nhập địa chỉ không hợp lệ, sau đó nhập thông tin thanh toán không hợp lệ, sau đó nhập thông tin giao hàng không hợp lệ | Thông báo lỗi, không thể chuyển sang màn hình tiếp theo cho đến khi thông tin nhập chính xác |
| 4 | Xác nhận thông tin đơn hàng | Hiển thị như đã nhập |
| 5 | Xác nhận đơn hàng | Đặt hàng trong hệ thống |
| 6 | Lặp lại step 1-3 nhưng dừng hoạt động và hủy giao dịch sau khi đặt sản phẩm vào | Người dùng đăng xuất sau đúng 10 phút tính từ lần hoạt động cuối cùng |
| 7 | Lặp lại step 1-3 nhưng dừng hoạt động và hủy giao dịch trên mỗi màn hình | Như trình bày trong step 6 |
| 8 | Lặp lại step 1-4; không xác nhận đơn hàng | Như trình bày trong step 6 |
Thiết Kế Một Use Case Chính Thức
Một use case chính thức gồm những gì? Thông thường, use case chính thức chứa nhiều thông tin hơn trường hợp không chính thức. Dưới đây là một số yếu tố điển hình của một use case chính thức:
- ID: Định danh use case
- Name: Tên viết tắt. Ví dụ: Mua sắm trực tuyến
- Actor: Tác nhân. Ví dụ: Khách hàng
- Description: Đoạn văn ngắn mô tả về use case
- Priority: Mức độ ưu tiên, từ quan điểm thực hiện
- Frequency of use: Tần suất sử dụng
- Preconditions: Điều kiện tiền đề. Điều gì phải đúng để bắt đầu use case thông thường
- Typical workflow: Luồng xử lý bình thường. Thường giống như use case không chính thức, nhưng đôi khi được chia thành hai cột, một cột dành cho hành động của tác nhân và một cột dành cho phản hồi của hệ thống
- Exception workflows: Luồng xử lý ngoại lệ. Mỗi luồng xử lý ngoại lệ thường có các cột hành động của tác nhân và phản hồi của hệ thống
- Postconditions: Hậu điều kiện. Điều gì sẽ đúng về trạng thái của hệ thống sau khi use case hoàn thành bình thường
| ID | 02.001 |
| Name | Mua sắm trực tuyến |
| Actor | Khách hàng |
| Description | Cho phép khách hàng hoàn tất giao dịch bằng cách mua (các) mặt hàng trong giỏ hàng của mình |
| Priority | Rất cao |
| Frequency of use | 25% khách hàng, tối đa 1.000 khách hàng mỗi ngày |
| Preconditions | 1. Một hoặc nhiều mặt hàng trong giỏ hàng 2. Khách hàng đã đăng nhập 3. Khách hàng đã click vào thanh toán |
| Typical workflow | 1. Hệ thống thu thập thông tin địa chỉ, thanh toán, giao dịch từ khách hàng 2. Hệ thống hiển thị đầy đủ thông tin cho người dùng xác nhận 3. Người dùng xác nhận đơn hàng với hệ thống giao hàng |
| Exception 1 | Khách hàng cố gắng thanh toán khi giỏ hàng trống: Hệ thống đưa ra thông báo lỗi |
| Exception 2 | Khách hàng cung cấp thông tin địa chỉ, thanh toán hoặc giao hàng không hợp lệ: Hệ thống đưa ra thống báo lỗi thích hợp |
| Exception 3 | Khách hàng hủy giao dịch trước hoặc trong quá trình thanh toán: Hệ thống ghi lại nhật ký Khách hàng thoát khỏi sau 10 phút không hoạt động |
| Postconditions | Đơn hàng đang hoạt động trên hệ thống |
Khả Năng Áp Dụng
Use case testing thường được áp dụng trong kiểm thử hệ thống và kiểm thử chấp nhận. Nó cũng có thể được sử dụng trong thử kiểm thử tích hợp nếu hành vi của các thành phần hoặc hệ thống được chỉ định theo các trường hợp sử dụng. Các trường hợp sử dụng cũng thường là cơ sở để kiểm tra hiệu năng vì chúng mô tả cách sử dụng thực tế của hệ thống. Các hành vi được mô tả trong các trường hợp sử dụng có thể được chỉ định cho người dùng ảo để tạo tải thực tế trên hệ thống (miễn là các yêu cầu về tải và hiệu suất được chỉ định trong họ hoặc cho họ).
Hạn Chế/ Khó Khăn
Để có hiệu lực, các use case phải truyền tải các giao dịch thực tế của người dùng. Đặc tả use case là một dạng thiết kế hệ thống. Các yêu cầu về những gì người dùng cần thực hiện phải đến từ người dùng hoặc đại diện người dùng và cần được kiểm tra dựa trên các yêu cầu của tổ chức trước khi thiết kế các trường hợp sử dụng tương ứng. Giá trị của use case sẽ giảm nếu nó không phản ánh các yêu cầu thực sự của người dùng và tổ chức hoặc cản trở thay vì hỗ trợ hoàn thành các nhiệm vụ của người dùng. Một định nghĩa chính xác về các hành vi ngoại lệ, thay thế và xử lý lỗi là rất quan trọng để bao phủ được toàn diện. Các trường hợp sử dụng nên được coi là hướng dẫn chứ không phải là định nghĩa đầy đủ về những gì cần được kiểm tra vì chúng có thể không cung cấp định nghĩa rõ ràng về toàn bộ yêu cầu. Cũng có thể có ích khi tạo các mô hình khác, chẳng hạn như sơ đồ và/hoặc bảng quyết định, từ tường thuật use case để cải thiện độ chính xác của kiểm thử và để xác minh chính use case đó. Giống như các dạng đặc tả khác, điều này có thể bộc lộ những điểm bất thường về mặt logic trong đặc tả use case, nếu chúng tồn tại.
Mức Độ Bao Phủ
Mức độ bao phủ tối thiểu có thể chấp nhận được của một use case là phải có một test case cho hành vi cơ bản và đủ các test case bổ sung để bao quát từng hành vi xử lý lỗi và thay thế. Nếu cần một bộ kiểm thử tối thiểu, nhiều hành vi thay thế có thể được tích hợp vào test case miễn là chúng tương thích lẫn nhau. Nếu cần có khả năng phán đoán tốt hơn (ví dụ: để hỗ trợ cách ly các lỗi), một test case bổ sung cho mỗi hành vi thay thế có thể được thiết kế, mặc dù các hành vi thay thế lồng nhau vẫn sẽ yêu cầu một số hành vi đó được hợp nhất thành một test case duy nhất (ví dụ: chấm dứt so với các hành vi thay thế không chấm dứt trong hành vi ngoại lệ “thử lại”).
Loại Lỗi Phát Hiện
Các khiếm khuyết bao gồm xử lý sai các hành vi đã xác định, bỏ sót các hành vi thay thế, xử lý không chính xác các điều kiện được trình bày và các thông báo lỗi được triển khai kém hoặc không chính xác.