1. Tóm tắt nhanh & màn hình bạn sẽ test
Bạn đã quen với việc test chức năng đúng/sai trên vài chục bản ghi mẫu. Nhưng một hệ quản lý thuê bao viễn thông thật sự — như của một nhà mạng phục vụ hàng chục triệu khách hàng — không bao giờ chỉ có vài chục bản ghi. Câu hỏi mà kiểm thử dung lượng trả lời rất khác: 'Chức năng này ĐÚNG khi ít dữ liệu, nhưng nó có còn ĐÚNG và còn CHẠY ĐƯỢC khi cơ sở dữ liệu có 5 triệu, 20 triệu bản ghi thuê bao hay không?'. Đây là kỹ năng nâng cao, đòi hỏi bạn tư duy như một tester ở dự án doanh nghiệp thật, không chỉ dừng ở test case đơn lẻ.
2. Kiểm thử dung lượng là gì & khác Load/Performance Testing thế nào
Nhiều bạn nhầm lẫn volume testing với load testing hay performance testing vì cả ba đều 'liên quan đến hiệu năng'. Cách phân biệt rõ nhất: hãy tự hỏi 'BIẾN SỐ nào đang thay đổi trong bài test'. Nếu bạn giữ nguyên 1 người dùng nhưng tăng dần số bản ghi trong DB từ 1.000 lên 5 triệu để xem tìm kiếm/phân trang có còn đúng và còn nhanh không — đó là volume testing. Nếu bạn giữ nguyên dữ liệu nhưng tăng dần số người dùng/request bắn đồng thời để đo độ trễ và điểm nghẽn — đó là load testing/performance testing.
Ở hệ quản lý thuê bao viễn thông, cả hai loại kiểm thử đều bắt buộc vì thực tế sản xuất có cả hai áp lực cùng lúc: cơ sở dữ liệu chứa hàng chục triệu thuê bao (áp lực dung lượng), trong khi hàng trăm nhân viên tổng đài và hàng chục hệ thống đối tác gọi API cùng lúc (áp lực tải). Một hệ thống vượt qua load testing với 1.000 bản ghi mẫu KHÔNG có nghĩa là nó sẽ chạy đúng khi dữ liệu thật đạt 20 triệu bản ghi — đó chính là lỗ hổng mà rất nhiều đội kiểm thử bỏ sót.
3. Vì sao hệ viễn thông nhiều triệu thuê bao đặc biệt cần Volume Testing
Một nhà mạng viễn thông cỡ vừa đã có thể phục vụ 5–20 triệu thuê bao đang hoạt động, cộng thêm hàng chục triệu bản ghi lịch sử cước, tin nhắn, cuộc gọi mỗi tháng. Dữ liệu không đứng yên — nó tăng liên tục mỗi ngày. Một tính năng chạy mượt lúc mới go-live với 500.000 thuê bao hoàn toàn có thể bắt đầu ì ạch sau 2 năm khi dữ liệu tăng gấp 10 lần, mà không có bất kỳ thay đổi nào về code. Đây là lý do volume testing không phải việc làm một lần, mà cần lặp lại định kỳ theo tốc độ tăng trưởng dữ liệu thật.
Ngoài ra, hệ thống thuê bao còn có những đặc thù làm rủi ro dung lượng nghiêm trọng hơn nhiều ngành khác: (1) tra cứu/tìm kiếm thuê bao là thao tác diễn ra hàng nghìn lần mỗi phút tại tổng đài — chỉ cần chậm thêm vài giây cũng nhân lên thành thiệt hại lớn về năng suất; (2) đối soát cước cuối ngày/cuối tháng phải xử lý TOÀN BỘ thuê bao trong một cửa sổ thời gian giới hạn, nếu chậm sẽ trễ chu kỳ tính cước gây khiếu nại hàng loạt; (3) báo cáo quản trị thường bị yêu cầu xuất 'toàn bộ' dữ liệu, dễ dẫn tới tràn bộ nhớ nếu không có giới hạn.
Vì thế, một tester ở dự án viễn thông cần chủ động đưa volume testing vào kế hoạch kiểm thử từ sớm — không đợi tới khi khách hàng than phiền 'sao dạo này chậm thế' mới bắt đầu điều tra. Việc phát hiện điểm suy giảm hiệu năng theo khối lượng dữ liệu TRƯỚC khi go-live, hoặc trước mỗi đợt tăng trưởng lớn về thuê bao, giúp đội ngũ chủ động tối ưu thay vì chữa cháy trong sản xuất.
4. Chuẩn bị: sinh dữ liệu khối lượng lớn (test data)
Nguyên liệu quan trọng nhất của volume testing là chính bộ DỮ LIỆU khối lượng lớn — và đây cũng là phần dễ bị làm sai nhất nếu bạn chưa có kinh nghiệm. Bạn không thể nhập tay hàng triệu bản ghi, cũng không nên copy nguyên si dữ liệu production chứa thông tin nhạy cảm.
▶ Bước 1: Xác định các bậc thang dữ liệu cần kiểm (ví dụ 1.000 / 100.000 / 1 triệu / 5 triệu / 20 triệu thuê bao) dựa theo dữ liệu thật hiện tại và tốc độ tăng trưởng dự kiến.
▶ Bước 2: Viết script sinh dữ liệu (seed/generator) chạy theo lô (batch insert), mô phỏng phân bố giống thật: số điện thoại đa dạng đầu số, tên trùng lặp có chủ đích (để test tìm kiếm trùng tên), nhiều gói cước và trạng thái thuê bao khác nhau.
▶ Bước 3: Nếu bắt buộc dùng dữ liệu gần với production, ẩn danh/che các trường nhạy cảm (số điện thoại, CMND/CCCD, địa chỉ) trước khi nạp vào môi trường test.
💬 Bình luận (0)
Chưa có bình luận nào. Hãy là người đầu tiên!