1. Tóm tắt nhanh & màn hình bạn sẽ test
Khi bạn mới học viết test case, phản xạ tự nhiên là chỉ test 'chuyện gì xảy ra khi mọi thứ suôn sẻ'. Nhưng một use case đầy đủ không chỉ có MỘT con đường — nó có một luồng chính (basic flow) mô tả kịch bản thành công điển hình, và nhiều luồng thay thế (alternate flow, vẫn dẫn tới thành công nhưng theo cách khác) cùng luồng ngoại lệ (exception flow, dẫn tới thất bại có kiểm soát). Use case testing chính là kỹ thuật đọc đặc tả này và sinh ra một bộ ca kiểm thử bao phủ đủ mọi nhánh, thay vì chỉ một đường thẳng. Chúng ta sẽ thực hành trên use case 'Đặt vé máy bay' của hệ thống SkyBooking — nơi bỏ sót một luồng ngoại lệ có thể khiến khách hàng mất tiền hoặc hãng bay bán trùng một chỗ ngồi.
2. Thành phần của một Use Case: tác nhân, tiền/hậu điều kiện, luồng chính
Use case 'Đặt vé máy bay' của SkyBooking có ba tác nhân: Hành khách (chủ động thực hiện use case), Cổng thanh toán (hệ thống ngoài, xác thực và trừ tiền), và Dịch vụ quản lý ghế (hệ thống nội bộ khóa/nhả ghế theo thời gian thực). Tiền điều kiện (precondition) là điều kiện PHẢI đúng trước khi use case bắt đầu: hành khách đã đăng nhập, đã tìm kiếm và chọn một chuyến bay còn ghế trống. Hậu điều kiện (postcondition) là trạng thái hệ thống PHẢI đạt được sau khi use case kết thúc — và quan trọng, hậu điều kiện cần được đặc tả cho CẢ kết quả thành công lẫn thất bại, không chỉ trường hợp suôn sẻ.
Luồng chính (basic flow) của use case này là: chọn chuyến bay và ghế → nhập thông tin hành khách → hệ thống tính tổng tiền → hành khách xác nhận thanh toán → cổng thanh toán trả về thành công → hệ thống tạo vé, khóa ghế, gửi email xác nhận kèm mã đặt chỗ (PNR). Đây là 'đường đi mặc định' mà mọi luồng thay thế và luồng ngoại lệ đều RẼ RA từ một bước cụ thể trong đó — nắm chắc luồng chính giúp bạn xác định chính xác điểm rẽ nhánh khi phân tích các luồng còn lại.
3. Vì sao Use Case Testing đặc biệt quan trọng ở hệ thống đặt vé máy bay
Hệ thống đặt vé máy bay là nơi hội tụ ba đặc điểm khiến các lỗi ngoài luồng chính trở nên nguy hiểm bất thường. Thứ nhất, có TÀI NGUYÊN GIỚI HẠN dùng chung (ghế trên chuyến bay) mà nhiều hành khách có thể tranh chấp cùng lúc — đây chính là nguồn gốc của các lỗi điều kiện đua (race condition) như bán trùng ghế. Thứ hai, có NHIỀU TÁC NHÂN phối hợp trong cùng một use case (hành khách, cổng thanh toán, dịch vụ quản lý ghế), và một lỗi đồng bộ giữa các tác nhân này (ví dụ: đã trừ tiền nhưng chưa khóa ghế kịp) có thể để lại trạng thái dữ liệu không nhất quán rất khó phát hiện qua kiểm thử hời hợt.
Thứ ba, mỗi bước trong luồng đều CHẠM TIỀN THẬT — giá vé, phụ phí ghế, mã giảm giá, phí hủy vé — nên một lỗi ở nhánh ít được để ý (như luồng hủy vé hoàn tiền) có thể gây thất thoát tài chính lặp lại trên hàng nghìn giao dịch trước khi bị phát hiện. Vì ba lý do này, một use case tưởng đơn giản như 'Đặt vé máy bay' thực chất chứa nhiều nhánh rủi ro cao hơn hẳn so với một form nhập liệu thông thường, và xứng đáng được phân tích kỹ bằng use case testing thay vì chỉ lướt qua luồng chính rồi coi là 'đã test đủ'.
Đây cũng là lý do use case testing thường được xem là kỹ thuật 'trưởng thành' hơn hẳn so với việc chỉ viết test case theo từng trường dữ liệu: nó buộc tester tư duy theo TRÌNH TỰ TƯƠNG TÁC thay vì từng ô nhập rời rạc, và chính trình tự đó — chứ không phải giá trị nhập vào — mới là nơi các lỗi nghiêm trọng nhất của hệ thống đặt vé thường ẩn náu.
4. Chuẩn bị: xác định actor, tiền/hậu điều kiện & luồng chính
Trước khi sinh bất kỳ ca kiểm thử nào, bạn cần một đặc tả use case đủ rõ ràng. Nếu tài liệu nghiệp vụ chưa viết sẵn dưới dạng use case, việc đầu tiên của tester là TỰ DỰNG lại nó từ yêu cầu rời rạc và phỏng vấn nhanh BA/PO.
▶ Bước 1: Liệt kê mọi tác nhân tham gia use case (Hành khách, Cổng thanh toán, Dịch vụ quản lý ghế...) và vai trò cụ thể của từng tác nhân.
▶ Bước 2: Viết rõ tiền điều kiện (trạng thái bắt buộc trước khi bắt đầu) và hậu điều kiện thành công/thất bại (trạng thái bắt buộc sau khi kết thúc).
💬 Bình luận (0)
Chưa có bình luận nào. Hãy là người đầu tiên!