Mở đầu — vì sao bài này quan trọng
Hãy tưởng tượng bạn là kỹ sư QA tại một sàn thương mại điện tử Việt Nam. Ứng dụng chạy trơn tru suốt quá trình phát triển: bạn bấm nút, trang tải nhanh, mọi chức năng đều đúng. Rồi đến ngày 12/12, chương trình Flash Sale khai màn lúc 0h. Trong vòng 90 giây, hàng chục nghìn người dùng cùng bấm "Mua ngay". Server oằn mình, thời gian phản hồi từ 200ms nhảy lên 15 giây, rồi trang trắng xóa hiện lỗi 503. Doanh thu của cả tháng chuẩn bị cho một đêm — bốc hơi trong mười phút.
Câu chuyện này lặp lại mỗi năm, ở mọi quốc gia, với mọi doanh nghiệp online. Điều đáng nói là: phần mềm ấy không có bug chức năng nào. Mọi test case functional đều pass. Vấn đề nằm ở chỗ nó hoạt động đúng nhưng không hoạt động đủ nhanh khi có nhiều người dùng cùng lúc. Đó chính là địa hạt của Performance Testing (kiểm thử hiệu năng) — và cũng là lý do bài học đầu tiên này quan trọng.
Trước khi bạn chạm vào JMeter hay k6 ở những bài sau, bạn cần một nền tảng tư duy vững chắc: Performance Testing là gì, nó khác gì với functional testing, và quan trọng nhất — có những loại performance test nào, mỗi loại trả lời cho câu hỏi kinh doanh nào. Nếu bạn nắm sai cái này, bạn sẽ chạy đúng công cụ nhưng sai bài toán, cho ra những con số đẹp mà vô nghĩa. Bài này đặt viên gạch đầu tiên cho toàn bộ hành trình.
Khái niệm cốt lõi
Performance Testing là gì?
Performance Testing là hoạt động kiểm tra cách một hệ thống phần mềm phản ứng dưới một khối lượng công việc (workload) nhất định, xét trên các khía cạnh: tốc độ (speed), khả năng mở rộng (scalability), độ ổn định (stability) và khả năng chịu tải (capacity).
Điểm khác biệt cốt lõi so với functional testing mà bạn cần khắc cốt ghi tâm:
- Functional testing hỏi: "Hệ thống có làm ĐÚNG việc không?" — Bấm nút thanh toán thì đơn hàng có được tạo không?
- Performance testing hỏi: "Hệ thống làm việc đó NHANH và ỔN ĐỊNH đến mức nào khi có nhiều người cùng dùng?" — Khi 5.000 người cùng bấm thanh toán, mỗi đơn mất bao lâu để xử lý, và có bao nhiêu đơn bị lỗi?
Vì sao performance lại là chuyện sống còn?
Có ba lý do khiến performance không thể xem nhẹ:
1. Tiền bạc trực tiếp. Nhiều nghiên cứu kinh điển (Amazon, Google) chỉ ra rằng mỗi 100ms chậm đi có thể làm giảm vài phần trăm tỷ lệ chuyển đổi. Với một sàn TMĐT doanh thu 100 tỷ/năm, chậm 1 giây có thể tương đương nhiều tỷ đồng bốc hơi.
2. Trải nghiệm và uy tín. Người dùng Việt Nam ngày nay thiếu kiên nhẫn. Một ứng dụng ngân hàng treo lúc chuyển tiền cuối tháng sẽ nhanh chóng bị nhắc tên trên mạng xã hội, ảnh hưởng thương hiệu lâu dài.
3. Chi phí hạ tầng. Performance testing giúp bạn biết cần bao nhiêu server để phục vụ X người dùng — tránh mua thừa (lãng phí) hoặc mua thiếu (sập hệ thống).
Các loại Performance Test
Đây là phần cốt lõi nhất của bài. Có nhiều "loại" performance test, mỗi loại là một kịch bản đặt câu hỏi khác nhau. Hiểu sai loại test đồng nghĩa với đo sai thứ.
Load Testing (kiểm thử tải). Đây là loại phổ biến và nền tảng nhất. Bạn đưa hệ thống vào mức tải kỳ vọng bình thường — tức lượng người dùng mà bạn dự đoán sẽ có trong điều kiện vận hành thực tế — và quan sát nó phản ứng ra sao.
- Câu hỏi trả lời: "Hệ thống có chịu được 1.000 người dùng đồng thời (concurrent users) như dự kiến không, với thời gian phản hồi chấp nhận được không?"
- Mục đích: Xác nhận hệ thống đáp ứng yêu cầu vận hành hằng ngày trước khi lên production.
- Câu hỏi trả lời: "Giới hạn tối đa của hệ thống là bao nhiêu? Khi vượt giới hạn, nó gãy êm (từ chối lịch sự) hay gãy loạn (sập trắng, mất dữ liệu)?"
- Mục đích: Biết trần chịu đựng và kiểm tra khả năng phục hồi (recovery) sau khi tải giảm xuống.
- Câu hỏi trả lời: "Khi lượng truy cập bùng nổ tức thì (như mở bán vé concert, Flash Sale 0h), hệ thống có kịp xoay xở không?"
- Mục đích: Kiểm tra khả năng co giãn tức thời (auto-scaling) và hàng đợi (queue).
- Câu hỏi trả lời: "Chạy liên tục 24 giờ, hệ thống có bị rò rỉ bộ nhớ (memory leak), đầy log, cạn kết nối database không?"
- Mục đích: Đảm bảo độ ổn định dài hạn, thứ mà một bài test 10 phút không bao giờ phát hiện được.
Bốn khái niệm bổ trợ bạn cần biết ngay
Để đọc hiểu bất kỳ báo cáo performance nào, hãy nắm bốn thuật ngữ nền:
- Concurrent users (người dùng đồng thời): số người thực sự đang tương tác với hệ thống cùng một thời điểm — khác với tổng số người dùng đăng ký.
- Workload / Load profile (hồ sơ tải): bức tranh mô tả tải trông như thế nào — bao nhiêu người, làm hành động gì, theo phân bổ ra sao.
- Baseline (mốc chuẩn): kết quả đo lần đầu, dùng làm điểm so sánh cho các lần sau. Không có baseline thì mọi con số đều vô nghĩa vì không có gì để đối chiếu.
- SLA (Service Level Agreement): cam kết về mức hiệu năng, ví dụ "95% request phải trả về dưới 2 giây". Đây là "vạch đích" để phán xét test đậu hay rớt.
Tình huống thực tế
Tình huống 1: Sàn TMĐT chuẩn bị cho ngày 12/12
Một công ty TMĐT giả định tên ShopViet đặt mục tiêu phục vụ 50.000 đơn hàng trong đêm 12/12. Đội QA quyết định làm Load Test trước: mô phỏng 8.000 concurrent users thực hiện hành trình "duyệt sản phẩm → thêm giỏ → thanh toán". Kết quả: thời gian phản hồi trung bình 1,2 giây, không lỗi. Đội tuyên bố "sẵn sàng".
Nhưng khi Flash Sale mở lúc 0h, hệ thống sập chỉ sau 40 giây. Vì sao? Vì thực tế không phải 8.000 người rải đều, mà là 30.000 người ập vào cùng một khoảnh khắc — đó là kịch bản Spike, không phải Load. Load test của họ hoàn toàn đúng phương pháp nhưng trả lời sai câu hỏi.
Bài học rút ra: Chọn đúng loại performance test theo đúng đặc tính tải thực tế quan trọng hơn việc chạy test thật nhiều. Với sự kiện bùng nổ tức thời, bạn cần Spike Test; Load Test chỉ chứng minh hệ thống chịu được tải đều đặn mà thôi.
Tình huống 2: Ứng dụng ngân hàng và cú "rò rỉ" âm thầm
Một ngân hàng số giả định tên VietPay phát hành phiên bản mới. Đội QA chạy Load Test 30 phút với 2.000 concurrent users — mọi thứ hoàn hảo, thời gian phản hồi ổn định 300ms. App được duyệt lên production.
Sau ba ngày, khách hàng bắt đầu than phiền app chậm dần rồi treo vào mỗi buổi chiều. Điều tra cho thấy mỗi request để lại một kết nối database không được đóng đúng cách. Sau vài chục giờ vận hành, pool kết nối cạn kiệt, hệ thống nghẹt thở. Đây chính là lỗi mà Soak Test sinh ra để bắt — nhưng đội QA chỉ chạy test 30 phút, quá ngắn để vấn đề lộ diện.
Bài học rút ra: Một số lỗi hiệu năng — memory leak, connection leak, đầy đĩa log — chỉ xuất hiện theo thời gian. Test ngắn không bao giờ thay thế được Soak Test. Thời lượng test phải phản ánh thời lượng vận hành thực.
Tình huống 3: Startup gọi vốn và bài toán capacity
Một startup giáo dục giả định tên HocNhanh chuẩn bị chiến dịch quảng cáo lớn, dự kiến tăng từ 5.000 lên 100.000 người dùng trong một tháng. Nhà đầu tư hỏi: "Nếu người dùng tăng 20 lần, hệ thống có trụ nổi không, và cần bao nhiêu server?"
Đội kỹ thuật chạy Stress Test: tăng tải dần từ 5.000 lên đến khi hệ thống gãy. Họ phát hiện điểm gãy nằm ở 22.000 concurrent users, do database trở thành nút thắt cổ chai. Từ con số này, họ tính ra cần nâng cấp database và thêm 3 server ứng dụng để đạt mốc 100.000 an toàn — và trình bày kế hoạch chi phí cụ thể cho nhà đầu tư.
Bài học rút ra: Performance testing không chỉ là việc "test cho vui" của QA — nó tạo ra dữ liệu ra quyết định kinh doanh. Stress test giúp trả lời câu hỏi capacity một cách có bằng chứng, thay vì đoán mò.
Hướng dẫn từng bước
Dưới đây là quy trình tư duy khi tiếp cận bất kỳ bài toán performance nào. Bạn chưa cần công cụ — đây là bước lập kế hoạch, thứ quyết định 80% thành công.
Bước 1 — Xác định mục tiêu kinh doanh. Bắt đầu từ câu hỏi kinh doanh, không phải từ công cụ. Ví dụ: "Chúng ta cần phục vụ được bao nhiêu người trong sự kiện sắp tới?" hoặc "Hệ thống hiện tại chịu được trần bao nhiêu?".
Bước 2 — Chọn đúng loại test. Ánh xạ câu hỏi sang loại test:
- Xác nhận tải bình thường → Load Test
- Tìm điểm gãy / capacity → Stress Test
- Sự kiện bùng nổ tức thời → Spike Test
- Ổn định dài hạn → Soak Test
Bước 4 — Định nghĩa tiêu chí đậu/rớt (SLA). Viết ra rõ ràng trước khi chạy, ví dụ: "95% request dưới 2 giây, tỷ lệ lỗi dưới 1%". Không có tiêu chí thì kết quả test không thể phán xét.
Bước 5 — Thiết lập môi trường giống production. Test trên môi trường quá khác production sẽ cho số liệu vô dụng. Cấu hình server, dữ liệu, mạng phải càng giống thật càng tốt.
Bước 6 — Đo baseline. Chạy một lần với tải nhẹ để lấy mốc chuẩn. Đây là điểm tham chiếu cho mọi kết luận về sau.
Bước 7 — Chạy, quan sát, phân tích. Thực thi test, thu thập số liệu, so với SLA và baseline. Nếu rớt, tìm nguyên nhân (bottleneck) — chủ đề của các bài sau.
Lỗi thường gặp & mẹo
Lỗi 1 — Nhầm loại test. Chạy Load Test rồi tưởng đã sẵn sàng cho Flash Sale (như ShopViet). Mẹo: Luôn tự hỏi "tải thực tế trông như thế nào?" trước khi chọn loại test.
Lỗi 2 — Không có SLA rõ ràng. Chạy test xong nhìn con số "2,5 giây" mà không biết đó là tốt hay tệ. Mẹo: Định nghĩa tiêu chí đậu/rớt trước, không phải sau khi có kết quả.
Lỗi 3 — Test trên môi trường "đồ chơi". Chạy trên laptop cá nhân với database rỗng rồi kết luận về production có hàng triệu bản ghi. Mẹo: Dữ liệu và cấu hình phải sát production; database rỗng luôn cho kết quả lạc quan giả tạo.
Lỗi 4 — Bỏ qua Soak Test vì "mất thời gian". Như VietPay, nhiều lỗi nguy hiểm nhất chỉ lộ ra sau nhiều giờ. Mẹo: Với hệ thống chạy 24/7, đừng bao giờ bỏ Soak Test.
Lỗi 5 — Chỉ nhìn giá trị trung bình. Trung bình 1 giây nghe ổn, nhưng có thể 5% người dùng phải chờ 20 giây. Mẹo: Sẽ học ở bài metrics — luôn xem phân vị (percentile), đừng chỉ tin số trung bình.
Mẹo tổng quát: Performance testing là một vòng lặp, không phải làm một lần. Test → tìm nút nghẽn → sửa → test lại. Đừng kỳ vọng chạy một lần là xong.
Bài tập thực hành
- Ánh xạ tình huống → loại test. Với mỗi kịch bản sau, xác định loại performance test phù hợp nhất và giải thích ngắn gọn:
- Viết SLA. Cho một ứng dụng đặt đồ ăn, hãy viết ra 3 tiêu chí SLA cụ thể (có con số) mà bạn sẽ dùng để phán xét một load test là đậu hay rớt.
- Phân tích ca thất bại. Đọc lại tình huống ShopViet. Nếu bạn là trưởng nhóm QA, hãy liệt kê 3 việc bạn sẽ làm khác đi để tránh sự cố 12/12.
- Dựng load profile. Cho một sàn TMĐT dự kiến 10.000 concurrent users, hãy phác thảo một load profile: tỷ lệ % giữa các hành động (duyệt / tìm kiếm / thêm giỏ / thanh toán) và mô tả cách bạn sẽ ramp-up tải.
Tóm tắt
- Performance Testing kiểm tra hệ thống nhanh, ổn định và chịu tải đến mức nào — khác hẳn functional testing vốn chỉ hỏi hệ thống có làm đúng việc không. Một phần mềm có thể pass 100% functional test mà vẫn sập dưới tải.
- Có bốn loại test nền tảng, mỗi loại trả lời một câu hỏi kinh doanh riêng: Load (chịu tải bình thường?), Stress (điểm gãy ở đâu?), Spike (chịu nổi cú sốc đột ngột?), Soak (bền theo thời gian?).
- Chọn đúng loại test theo đặc tính tải thực tế quan trọng hơn việc chạy thật nhiều test — bài học từ sự cố Flash Sale của ShopViet.
- Bốn khái niệm nền cần nắm: concurrent users, load profile, baseline và SLA. Không có baseline và SLA thì mọi con số đều vô nghĩa.
- Performance testing tạo ra dữ liệu ra quyết định kinh doanh (capacity, chi phí hạ tầng), không chỉ là công việc kỹ thuật thuần túy.
- Quy trình đúng đắn bắt đầu từ mục tiêu kinh doanh, rồi mới chọn loại test, dựng load profile, định nghĩa SLA — công cụ như JMeter hay k6 chỉ là bước thực thi cuối cùng.