1. Tóm tắt nhanh & màn hình bạn sẽ test
Nếu bạn đã quen viết test case cơ bản cho từng màn hình đơn lẻ, chương này đưa bạn lên một tầm mới: kỹ thuật viết test case tối ưu cho một hệ thống ERP có hàng trăm màn hình, hàng nghìn ca kiểm thử và nhiều đội cùng đóng góp. Ở quy mô đó, một ca viết cẩu thả không chỉ gây rủi ro bỏ sót lỗi mà còn kéo theo chi phí bảo trì khổng lồ mỗi khi nghiệp vụ thay đổi. Chúng ta sẽ đi qua từng nguyên tắc bằng ví dụ thật từ ERPCore, có hình minh hoạ và phần tự làm thử.
2. Nguyên tắc lõi: Atomic & Độc lập
Atomic nghĩa là mỗi ca kiểm thử chỉ nhắm đúng MỘT mục tiêu kiểm tra — không gộp nhiều việc khác nhau vào cùng một ca 'cho tiện'. Ví dụ ca 'tạo phiếu nhập kho với số lượng vượt định mức' chỉ nên kiểm đúng hành vi đó, không kèm luôn việc kiểm tra in báo cáo hay huỷ phiếu. Khi ca atomic fail, bạn biết ngay chính xác cái gì hỏng, không phải dò lại từ đầu kịch bản dài.
Độc lập nghĩa là ca kiểm thử có thể chạy được ở bất kỳ thời điểm nào, theo bất kỳ thứ tự nào, mà không cần một ca khác chạy trước để chuẩn bị dữ liệu hay trạng thái. Thay vì đi vòng qua giao diện để dựng lại state (đăng nhập, tạo đơn mua, duyệt đơn... rồi mới tới bước cần test), ca độc lập tự seed dữ liệu cần thiết — thường qua API hoặc script chuẩn bị dữ liệu — rồi vào thẳng bước trọng tâm.
3. Vì sao đặc biệt quan trọng ở dự án ERP nhiều module
Ở ERPCore, một quy trình nghiệp vụ thực tế luôn kéo dài qua nhiều module: một đơn mua hàng (Mua hàng) khi về kho sẽ tạo phiếu nhập (Kho), rồi tự động hạch toán (Kế toán). Rất dễ bị cám dỗ viết một chuỗi test case tuần tự bám sát đúng quy trình này để 'kiểm tra luôn cả luồng end-to-end' — nhưng nếu mỗi ca trong chuỗi lại phụ thuộc UI-state của ca trước, bạn đang biến hàng chục ca kiểm thử thành MỘT điểm lỗi duy nhất.
Chi phí thực sự lộ ra khi dự án chạy nhiều sprint: mỗi lần môi trường staging không ổn định hoặc dữ liệu gốc thay đổi, cả chuỗi bị fail hàng loạt dù logic nghiệp vụ hoàn toàn đúng — team mất thời gian điều tra 'lỗi giả' thay vì tìm lỗi thật. Ngược lại, nếu áp dụng atomic/độc lập ngay từ đầu, mỗi module có thể có bộ test case riêng chạy song song, không kéo lùi nhau, và một ca fail chỉ ảnh hưởng đúng phạm vi của nó.
4. Chuẩn bị: đặt tên & tổ chức bộ test case
Trước khi viết ca, cần thống nhất một chuẩn đặt tên và cấu trúc thư mục để 600 ca của 4 module không trở thành mớ hỗn độn không ai tra cứu được.
▶ Bước 1: Tổ chức bộ case theo cây: Module → Chức năng → Loại ca (ví dụ Kho / Nhập kho / Boundary).
▶ Bước 2: Đặt tên ca theo mẫu cố định: mã module-số thứ tự: mô tả ngắn — loại ca. Ví dụ 'TC-INV-014: Tạo phiếu nhập kho — SL vượt định mức (boundary)'.
▶ Bước 3: Trước khi thêm ca mới, tra cứu theo mã module + từ khoá để phát hiện sớm ca gần giống có thể gộp bằng data-driven.
💬 Bình luận (0)
Chưa có bình luận nào. Hãy là người đầu tiên!