Mở đầu — vì sao bài này quan trọng
Có một sự thật phũ phàng trong nghề QA: phần lớn hệ thống không "chết" vì lỗi chức năng. Nút bấm vẫn hoạt động, form vẫn submit đúng, dữ liệu vẫn lưu chính xác. Nhưng đến ngày sale lớn, đến giờ vàng người dùng đổ vào, hệ thống bắt đầu quay tròn vòng loading, timeout, rồi sập. Lúc đó không ai hỏi "test case chức năng của các bạn pass bao nhiêu phần trăm" — người ta hỏi "tại sao web không vào được".
Đó chính là khoảng trống mà Performance Test Strategy (chiến lược kiểm thử hiệu năng) phải lấp đầy. Nhiều đội QA Việt Nam vẫn xem performance testing như một hoạt động ad-hoc: đến gần release thì mở JMeter lên, bắn vài nghìn request, thấy server không sập thì báo cáo "OK". Đây là cách làm nguy hiểm, vì nó không trả lời được câu hỏi quan trọng nhất: hệ thống chịu được bao nhiêu, ở đâu là điểm gãy, và khi gãy thì gãy như thế nào.
Là một QA Lead, bạn không viết script performance mỗi ngày. Nhưng bạn phải là người thiết kế chiến lược: xác định mục tiêu đo lường, chọn loại test phù hợp với rủi ro kinh doanh, quyết định môi trường và dữ liệu, và diễn giải kết quả thành ngôn ngữ mà CTO và giám đốc kinh doanh hiểu được. Bài này tập trung riêng vào tư duy chiến lược đó — cách biến performance testing từ một hoạt động kỹ thuật rời rạc thành một phần có kế hoạch, có mục tiêu rõ ràng trong bức tranh chất lượng tổng thể.
Khái niệm cốt lõi
Bốn mục tiêu chiến lược của performance testing
Trước khi chạm vào bất kỳ công cụ nào, một performance test strategy tốt phải xác định rõ nó phục vụ mục tiêu gì. Có bốn mục tiêu chính, và trong thực tế bạn thường theo đuổi nhiều mục tiêu cùng lúc:
1. Xác nhận SLA được đáp ứng (Confirm SLA met). SLA (Service Level Agreement) là cam kết về mức chất lượng dịch vụ. Trong performance, SLA thường được biểu diễn bằng các chỉ số như "p95 latency < 500ms" — nghĩa là 95% số request phải trả về trong dưới 500 mili-giây. Lưu ý: ta dùng percentile (p95, p99) chứ không dùng trung bình (average), vì trung bình che giấu những trường hợp tệ nhất. Một hệ thống có latency trung bình 200ms nghe rất đẹp, nhưng nếu p99 là 8 giây thì cứ 100 người dùng lại có 1 người phải chờ đến phát điên.
2. Tìm điểm nghẽn (Identify bottleneck). Khi hệ thống chậm, nguyên nhân nằm ở đâu? Database query thiếu index? Connection pool cạn kiệt? CPU của application server chạm trần? Băng thông mạng? Third-party API bên ngoài phản hồi chậm? Performance test không chỉ nói "chậm hay không" mà phải giúp định vị ở đâu chậm.
3. Kiểm chứng khả năng mở rộng (Validate scaling). Nếu ta thêm một server nữa, throughput có tăng gấp đôi không, hay chỉ tăng 30%? Auto-scaling có kích hoạt kịp thời khi tải tăng đột ngột không? Đây là câu hỏi sống còn với hệ thống cloud.
4. Tạo sự tự tin trước khi ra mắt (Pre-launch confidence). Trước một sự kiện lớn — sale 12/12, ra mắt sản phẩm, đợt tuyển sinh — đội ngũ và ban lãnh đạo cần một câu trả lời dựa trên dữ liệu, không phải cảm tính: "Chúng ta đã kiểm chứng hệ thống chịu được X người dùng đồng thời."
Các loại performance test và khi nào dùng
Chiến lược nằm ở chỗ chọn đúng loại test cho đúng rủi ro:
- Load test: đưa hệ thống đến mức tải dự kiến (ví dụ lượng người dùng cao điểm bình thường) để xác nhận nó đáp ứng SLA. Đây là loại phổ biến nhất.
- Stress test: đẩy tải vượt mức dự kiến cho đến khi hệ thống gãy, để tìm điểm giới hạn (breaking point) và quan sát cách nó gãy. Gãy có "duyên" (từ chối request lịch sự, trả lỗi 503) hay gãy thảm khốc (treo, mất dữ liệu)?
- Spike test: tăng tải đột ngột trong thời gian ngắn — mô phỏng khoảnh khắc mở cổng sale hoặc chốt đơn phút chót — để xem hệ thống phản ứng với cú sốc thế nào.
- Soak/Endurance test: giữ tải trung bình trong thời gian dài (8–24 giờ) để phát hiện memory leak, connection leak, hoặc suy giảm hiệu năng theo thời gian — những lỗi mà test ngắn không bao giờ lộ ra.
- Volume test: kiểm tra hành vi khi lượng dữ liệu lớn (database 500 triệu bản ghi), không nhất thiết nhiều người dùng.
Ba con số bạn phải nắm: latency, throughput, error rate
Mọi performance test đều xoay quanh ba chỉ số. Latency (thời gian phản hồi) — nhanh hay chậm. Throughput (thông lượng, đo bằng request/giây hoặc transaction/giây) — xử lý được bao nhiêu. Error rate (tỷ lệ lỗi) — bao nhiêu request thất bại dưới tải. Một hệ thống "nhanh" mà chỉ chịu được 50 req/s là vô dụng nếu bạn cần 5.000 req/s. Ba con số này luôn phải đọc cùng nhau.
Tình huống thực tế
Ví dụ 1 — Sàn thương mại điện tử và cú sập giờ vàng 12/12
Một sàn TMĐT tại Việt Nam (giả định tên "ShopFast") chuẩn bị cho đợt sale 12/12. Năm trước, đúng 0h00 khi mở flash sale, web sập trong 8 phút — ước tính thiệt hại vài tỷ đồng doanh thu và vô số khách hàng bực bội.
Năm nay QA Lead thiết kế lại chiến lược. Đầu tiên, họ lấy dữ liệu APM (Application Performance Monitoring) từ đợt sale năm ngoái để dựng workload model: 0h00 lượng người dùng đồng thời nhảy từ 5.000 lên 80.000 chỉ trong 90 giây, 70% traffic đổ vào ba API là trang sản phẩm, giỏ hàng và thanh toán. Đây rõ ràng là kịch bản cần spike test, không phải load test đều đều.
SLA đặt ra: p95 của API thanh toán < 800ms, error rate < 1% ở mức 80.000 người dùng đồng thời. Khi chạy spike test đến 80.000, họ phát hiện điểm nghẽn nằm ở connection pool tới database chỉ cấu hình 100 kết nối — dưới tải cao, các request phải xếp hàng chờ kết nối, latency vọt lên 6 giây. Đây chính xác là mục tiêu "identify bottleneck". Fix bằng cách tăng pool, thêm read replica cho truy vấn sản phẩm, và đưa danh sách sản phẩm hot vào cache Redis. Chạy lại: p95 còn 620ms ở 80.000 users.
Bài học: chiến lược phải bắt nguồn từ dữ liệu tải thực tế, không phải con số bịa. Và loại test (spike) phải khớp với hình dạng rủi ro kinh doanh (mở cổng flash sale).
Ví dụ 2 — Ứng dụng ngân hàng số và bài học soak test
Một ngân hàng số tại Đông Nam Á (giả định "NeoBank") ra mắt tính năng chuyển tiền tức thời. Đội QA chạy load test 2 giờ ở mức 3.000 giao dịch/phút, mọi chỉ số đẹp: p95 = 300ms, error rate 0%. Họ cho lên production.
Sau 3 ngày, hệ thống bắt đầu chậm dần rồi phải restart mỗi đêm để "hồi phục". Nguyên nhân: một memory leak trong service ghi log giao dịch — mỗi giao dịch giữ lại một object không được giải phóng. Trong 2 giờ test, rò rỉ chưa đủ lớn để lộ ra; nhưng chạy liên tục 72 giờ ở production thì bộ nhớ cạn dần.
QA Lead rút kinh nghiệm, bổ sung soak test 24 giờ vào chiến lược bắt buộc cho mọi service xử lý tiền. Trong lần chạy soak sau đó cho một tính năng khác, họ bắt được đúng dạng leak này trước khi lên production — đồ thị memory tăng tuyến tính không bao giờ trở về mức nền là dấu hiệu kinh điển.
Bài học: load test ngắn trả lời câu hỏi "chịu được tải không", nhưng chỉ soak test dài mới trả lời "chịu được lâu dài không". Với hệ thống tài chính, câu hỏi thứ hai quan trọng không kém.
Ví dụ 3 — Startup SaaS và cái bẫy "test trên môi trường tí hon"
Một startup SaaS về quản lý bán hàng (giả định "SalesKit") có khách hàng lớn sắp onboarding với 2.000 nhân viên dùng đồng thời. Đội test hào hứng chạy load test, kết quả: hệ thống chịu tốt 3.000 users, p95 dưới 400ms. Tự tin ký hợp đồng.
Ngày go-live, hệ thống chậm thê thảm chỉ với 800 người dùng thật. Điều tra ra: môi trường staging nơi họ test dùng database chỉ có 10.000 bản ghi mẫu, trong khi production của khách hàng có 12 triệu bản ghi. Các query không có index chạy nhanh trên bảng nhỏ nhưng chậm gấp trăm lần trên bảng lớn. Ngoài ra, staging chạy 4 CPU còn production 8 CPU nhưng cấu hình cache khác hẳn — kết quả test hoàn toàn không đại diện.
Bài học: kết quả performance test chỉ có giá trị khi môi trường và dữ liệu tiệm cận production. Test trên môi trường tí hon với dữ liệu tí hon cho ra những con số đẹp nhưng dối trá. Đây là lý do chiến lược performance phải nêu rõ yêu cầu về môi trường và khối lượng dữ liệu.
Hướng dẫn từng bước
Đây là quy trình xây dựng một performance test strategy mà bạn có thể áp dụng cho bất kỳ dự án nào:
Bước 1 — Xác định mục tiêu và SLA đo lường được. Ngồi với product owner và tech lead để chốt các ngưỡng cụ thể: p95/p99 latency là bao nhiêu cho từng nhóm API quan trọng? Throughput mục tiêu? Error rate chấp nhận được? Số người dùng đồng thời cao điểm? Không có con số cụ thể thì không có bài test có ý nghĩa.
Bước 2 — Dựng workload model từ dữ liệu thật. Lấy log production hoặc dữ liệu APM để hiểu traffic thực: giờ cao điểm, tỷ lệ giữa các API, hành trình người dùng điển hình (đăng nhập → tìm kiếm → xem → mua). Nếu là sản phẩm mới chưa có dữ liệu, ước lượng dựa trên kế hoạch kinh doanh và cộng thêm biên an toàn.
Bước 3 — Chọn loại test theo rủi ro. Ánh xạ mỗi rủi ro kinh doanh sang một loại test: sự kiện sale đột biến → spike test; vận hành liên tục → soak test; câu hỏi mở rộng → stress + scaling test; xác nhận vận hành hằng ngày → load test.
Bước 4 — Chuẩn bị môi trường và dữ liệu đại diện. Đảm bảo cấu hình hạ tầng, khối lượng dữ liệu càng gần production càng tốt. Nếu không thể bằng 100%, hãy test ở tỷ lệ đã biết (ví dụ 50% production) rồi ngoại suy có ghi chú rõ giả định.
Bước 5 — Chọn công cụ và xây kịch bản. Các công cụ phổ biến: JMeter (miễn phí, mạnh, phổ biến ở VN), k6 (viết script bằng JavaScript, hợp với dev), Gatling (Scala, báo cáo đẹp), Locust (Python). Kịch bản phải phản ánh hành trình người dùng thật, có think time (thời gian nghỉ giữa các thao tác), không phải bắn request vô tội vạ.
Bước 6 — Bật monitoring song song. Đây là bước hay bị bỏ quên. Trong lúc chạy test, phải theo dõi cả phía server: CPU, RAM, disk I/O, database slow query, connection pool, garbage collection. Nếu chỉ nhìn con số phía client (latency, throughput) mà không nhìn server, bạn biết hệ thống chậm nhưng không biết tại sao.
Bước 7 — Chạy, phân tích, và diễn giải. So kết quả với SLA. Khi vượt ngưỡng, dùng dữ liệu monitoring để định vị bottleneck. Trình bày kết quả bằng ngôn ngữ kinh doanh: "Hệ thống đáp ứng SLA đến 60.000 users; vượt mức này error rate tăng — cần thêm hạ tầng nếu dự kiến quá 60.000."
Bước 8 — Đưa vào CI/CD như một quality gate. Chiến lược trưởng thành không chạy performance test một lần rồi quên. Hãy tích hợp một baseline performance test nhẹ vào pipeline để phát hiện suy giảm hiệu năng (performance regression) ngay khi code mới làm chậm hệ thống.
Lỗi thường gặp & mẹo
Lỗi 1 — Chỉ nhìn average, bỏ qua percentile. Trung bình 200ms có thể che giấu p99 = 5 giây. Luôn báo cáo p95 và p99.
Lỗi 2 — Test không có monitoring phía server. Biết "chậm" mà không biết "chậm ở đâu" thì test gần như vô dụng cho việc cải thiện.
Lỗi 3 — Bỏ qua think time. Nếu script bắn request liên tục không nghỉ, bạn tạo ra mức tải phi thực tế (một người dùng thật không click 50 lần/giây), dẫn đến kết luận sai lệch.
Lỗi 4 — Chạy performance test từ một máy tính duy nhất. Máy chạy test (load generator) cũng có giới hạn CPU/mạng. Khi cần tải lớn, bạn phải phân tán qua nhiều máy, nếu không chính load generator trở thành điểm nghẽn và bạn đo nhầm giới hạn của nó chứ không phải của hệ thống.
Lỗi 5 — Quên "làm nóng" (warm-up). Nhiều hệ thống chậm ở phút đầu do cache lạnh, JIT chưa tối ưu. Bỏ dữ liệu giai đoạn warm-up ra khỏi phân tích, hoặc thiết kế test có giai đoạn ramp-up.
Mẹo: Bắt đầu nhỏ và tăng dần (ramp-up) thay vì đổ full tải ngay — bạn sẽ quan sát được hệ thống bắt đầu xuống cấp ở mức nào, không chỉ biết nó đã gãy. Đường cong throughput-vs-users thường phẳng dần rồi đi xuống; điểm nó bắt đầu phẳng chính là ngưỡng công suất thực tế.
Mẹo: Luôn test trong môi trường cô lập về mạng, tránh test lên production giờ cao điểm; nếu buộc phải test trên production, dùng kỹ thuật kiểm soát tải và cảnh báo team trực.
Bài tập thực hành
- Thiết kế SLA: Chọn một ứng dụng bạn biết (ví dụ app đặt đồ ăn). Viết ra SLA hiệu năng cho 3 API quan trọng nhất, dùng percentile (p95/p99), throughput mục tiêu và error rate chấp nhận được. Giải thích vì sao chọn các con số đó.
- Ánh xạ loại test: Cho ba tình huống — (a) sàn TMĐT chuẩn bị flash sale, (b) hệ thống core banking chạy 24/7, (c) migrate database sang bảng 100 triệu bản ghi — hãy chỉ ra loại performance test phù hợp nhất cho từng tình huống và lý do.
- Phân tích bottleneck: Bạn chạy load test, latency tăng vọt nhưng CPU và RAM của app server đều dưới 40%. Liệt kê ít nhất 4 nguyên nhân khả dĩ và cách kiểm chứng từng cái.
- Viết mini workload model: Với một app có 100.000 người dùng, giờ cao điểm 8h tối, hãy phác thảo tỷ lệ traffic giữa các chức năng (đăng nhập, duyệt, mua...) và ước lượng số request/giây ở cao điểm. Nêu rõ giả định.
Tóm tắt
Performance Test Strategy không phải là "mở JMeter bắn vài nghìn request rồi xem có sập không". Nó là một kế hoạch có mục tiêu rõ ràng, bám vào bốn trụ cột: xác nhận SLA, tìm điểm nghẽn, kiểm chứng khả năng mở rộng, và tạo sự tự tin trước ra mắt.
Những nguyên tắc cốt lõi cần khắc sâu: đo bằng percentile chứ không bằng trung bình; chọn loại test (load, stress, spike, soak) theo hình dạng rủi ro kinh doanh chứ không theo thói quen; dựng workload model từ dữ liệu thật; đảm bảo môi trường và dữ liệu đại diện cho production; luôn bật monitoring phía server để định vị bottleneck; và cuối cùng, diễn giải kết quả thành ngôn ngữ kinh doanh mà lãnh đạo hiểu và ra quyết định được.
Ba câu chuyện — sàn TMĐT sập giờ vàng, ngân hàng số dính memory leak, startup test trên môi trường tí hon — đều cho thấy cùng một điều: sai lầm hiếm khi nằm ở công cụ, mà nằm ở chiến lược. Là QA Lead, giá trị lớn nhất bạn tạo ra không phải là biết bấm nút chạy test, mà là biết đặt đúng câu hỏi, chọn đúng bài test, và biến những con số kỹ thuật thành sự tự tin có căn cứ cho cả tổ chức.