Các Loại Testing Tester Cần Biết: Manual, Automation, Performance và Khi Nào Dùng Loại Nào
7 tháng trước · 13 phút đọc
Testing không phải chỉ có một loại - đó là điều nhiều fresher bỡ ngỡ
Mình nhớ lần đầu đi phỏng vấn, interviewer hỏi: "Bạn biết những loại testing nào?" Mình trả lời "manual testing" rồi... im lặng. Kết quả không cần nói thêm.
Thực tế, testing là một hệ sinh thái với nhiều loại khác nhau, mỗi loại phục vụ một mục đích riêng. Không phải dự án nào cũng cần tất cả, nhưng bạn cần biết đủ để chọn đúng - và quan trọng hơn, để trả lời phỏng vấn tự tin.
Bài này mình sẽ đi qua các loại testing phổ biến nhất mà tester Việt Nam đang dùng hàng ngày. Không học thuộc định nghĩa - mình giải thích theo kiểu "tại sao cần, khi nào dùng, ví dụ thực tế".
Bức tranh tổng thể trước khi đi vào từng loại
Một lưu ý nhỏ trước khi bắt đầu: các loại testing thường được chia theo 2 trục chính. Trục thứ nhất là cách thực hiện (manual hay automation). Trục thứ hai là mục tiêu kiểm thử (functional hay non-functional). Hiểu 2 trục này, bạn sẽ không bao giờ lẫn lộn nữa.
Manual testing: Chậm mà chắc, không thể thiếu
Manual testing là kiểm thử thủ công - tester tự tay thực hiện từng bước như một người dùng thật. Không script, không bot, chỉ có bạn, app, và bộ test case.
Tại sao vẫn cần manual dù có automation? Vì máy không cảm nhận được UI xấu, không nhận ra luồng người dùng bị confusing, không phán đoán được "cái này tuy đúng nhưng sẽ làm khách hàng khó chịu". Đó là thứ chỉ con người mới làm được.
Manual phù hợp nhất khi cần phán đoán của con người
Ví dụ thực tế: Dự án app đặt xe như Grab clone của một startup Hà Nội. Dev vừa deploy tính năng "đặt xe theo lịch". Automation test pass hết vì logic đúng. Nhưng khi mình test manual, phát hiện: flow đặt lịch trước 30 phút không có thông báo xác nhận, người dùng không biết đặt thành công hay chưa. Bug không phải về logic, mà về trải nghiệm. Automation không bắt được.
Ưu điểm của manual testing:
- Phát hiện usability issues và visual bugs
- Phù hợp tính năng mới, thay đổi thường xuyên
- Không cần đầu tư ban đầu về script/tool
- Linh hoạt, thay đổi hướng test ngay khi cần
Nhược điểm:
- Chậm hơn automation, không scalable cho regression lớn
- Tốn sức khi test lặp lại nhiều lần
- Phụ thuộc vào sự tập trung của tester (mệt = bỏ sót)
Khi nào dùng? Tính năng mới ra, exploratory testing, kiểm tra UX/UI, khi chưa có đủ thời gian viết automation script.
Automation testing: Đầu tư một lần, chạy mãi mãi
Automation testing là viết script để máy tự chạy test thay bạn. Nghe hấp dẫn, nhưng đây là điểm nhiều fresher hiểu sai: automation không thay thế manual, nó bổ sung cho manual.
Một công ty fintech ở TP.HCM mình từng tham khảo có hàng trăm test case trong regression suite. Nếu chạy manual mỗi sprint: mất khoảng 3 ngày full-time. Sau khi automation: chạy xong trong 45 phút, tester dùng thời gian còn lại test tính năng mới. Đó là lý do automation tồn tại.
Automation giải phóng tester khỏi công việc lặp lại
Tool phổ biến ở Việt Nam hiện tại:
- Selenium - web testing, phổ biến nhất, nhiều tài liệu tiếng Việt
- Cypress - web testing, developer-friendly, đang được nhiều team trẻ adopt
- Appium - mobile testing (Android/iOS)
- Postman + Newman - API testing automation
- JMeter - load/performance testing (mình sẽ nhắc lại ở phần sau)
Khi nào automation KHÔNG phải lựa chọn tốt?
- Tính năng đang thay đổi liên tục (script hỏng mỗi sprint = tốn công maintain hơn viết mới)
- Dự án ngắn hạn, deadline gấp (viết script mất thời gian hơn test tay)
- UI phức tạp, dynamic nhiều, script dễ flaky
Fresher không cần automation ngay. Học manual vững trước, hiểu test case viết tốt như thế nào, rồi mới nghĩ đến automation. Nhiều bạn học Selenium từ tuần đầu nhưng test case còn viết thiếu happy path - đó là đi ngược.
Functional vs Non-functional: Hai trục không thể nhầm
Đây là cặp khái niệm hay bị nhầm nhất trong phỏng vấn. Mình giải thích nhanh:
Functional testing = kiểm tra app làm đúng chức năng không. "Bấm nút đăng nhập có vào được không?" "Thêm vào giỏ hàng có cộng đúng số lượng không?" Đây là test "what" - hệ thống làm gì.
Non-functional testing = kiểm tra app hoạt động tốt như thế nào. "Trang load trong bao lâu?" "1000 người dùng cùng lúc có chịu được không?" "Dữ liệu có được mã hóa không?" Đây là test "how well" - hệ thống hoạt động ra sao.
Functional và non-functional - hai góc nhìn bổ sung cho nhau
Ví dụ dễ nhớ: App thanh toán điện tử.
- Functional: Chuyển 100.000đ từ ví A sang ví B có trừ đúng/cộng đúng không?
- Non-functional: Nếu 50.000 người cùng chuyển tiền lúc 12h trưa, hệ thống có sập không?
Cả hai đều cần. Một app functional hoàn hảo nhưng load 30 giây thì cũng không ai dùng. Ngược lại, app nhanh nhưng tính tiền sai thì còn tệ hơn.
Các loại functional testing phổ biến:
- Unit testing (dev tự làm)
- Integration testing
- System testing
- Acceptance testing (UAT - user acceptance testing)
Các loại non-functional testing phổ biến:
- Performance testing (mình sẽ đi sâu phần sau)
- Security testing
- Usability testing
- Compatibility testing (test trên nhiều browser/device)
Performance testing: Tại sao app chậm là bug nghiêm trọng
53% (HubSpot (2024)) người dùng bỏ một trang web nếu load chậm hơn 3 giây. Con số này giải thích tại sao performance testing không phải "thêm cho đẹp" mà là yêu cầu bắt buộc với bất kỳ dự án có người thật dùng.
Performance testing là umbrella term - bên trong có nhiều loại nhỏ hơn:
-
Load testing: Kiểm tra hệ thống chịu được bao nhiêu user đồng thời trong điều kiện bình thường. Ví dụ: app bán hàng của Tiki mỗi ngày có bao nhiêu người mua, hệ thống chịu được không?
-
Stress testing: Đẩy hệ thống vượt ngưỡng cho phép để xem điểm gãy ở đâu. Ví dụ: Flash sale 11/11, traffic đột biến gấp 10 lần - hệ thống sẽ chậm dần hay crash hẳn?
-
Spike testing: Kiểm tra khi traffic tăng đột ngột rồi giảm ngay. Khác stress testing ở chỗ không duy trì áp lực lâu.
-
Endurance testing (hay soak testing): Chạy hệ thống với load bình thường trong thời gian dài (8-24h) để phát hiện memory leak.
4 loại performance testing - mỗi loại trả lời một câu hỏi khác nhau
Tool thực tế hay dùng ở VN: Apache JMeter (free, phổ biến nhất), Locust (Python-based, dễ script), k6 (developer-friendly, đang hot).
Fresher cần biết performance testing ở mức hiểu khái niệm và đọc được report, chưa cần tự viết script. Khi nào project có yêu cầu cụ thể, học tool theo thực tế sẽ nhanh hơn học lý thuyết.
Security testing: Loại ít flashy nhưng sai là thảm họa
Security testing kiểm tra xem hệ thống có lỗ hổng bảo mật không - liệu kẻ tấn công có thể khai thác gì không. Đây không phải lĩnh vực của fresher tester để "tự làm" ngay, nhưng bạn cần biết nó tồn tại và hiểu các khái niệm cơ bản.
Tại sao quan trọng? Năm 2023-2024, Việt Nam ghi nhận 191 vụ (Viettel Threat Intelligence (Viettel Cyber Security)) vụ tấn công mạng ảnh hưởng đến dữ liệu người dùng. Nhiều trong số đó xuất phát từ lỗ hổng mà một security test cơ bản có thể phát hiện được.
Các lỗ hổng phổ biến tester cần biết tên
Các loại security testing cơ bản:
- Vulnerability scanning: Dùng tool quét tự động tìm lỗ hổng đã biết (OWASP ZAP, Burp Suite)
- Penetration testing (pentest): Mô phỏng tấn công thật để tìm lỗ hổng sâu hơn - thường do chuyên gia security làm
- SQL Injection test: Kiểm tra xem input có được sanitize đúng không. Ví dụ: nhập
' OR 1=1 --vào ô tìm kiếm, hệ thống có trả về dữ liệu không nên trả về không? - XSS (Cross-site scripting) test: Kiểm tra xem script độc hại có chạy được trên trình duyệt người dùng không
Tester thường không làm pentest chuyên sâu. Nhưng trong test case cho form, API, hay login page, bạn nên có vài test case security cơ bản như test SQL injection và XSS. Đây là điểm phân biệt tester biết nghề với tester chỉ test happy path.
Khi nào dùng loại nào? Checklist cho fresher
Đây là câu hỏi thực tế nhất. Biết 10 loại testing không quan trọng bằng biết khi nào dùng cái nào.
Mình đúc kết thành bảng quyết định đơn giản:
| Tình huống | Loại testing nên dùng |
|---|---|
| Tính năng mới, chưa ổn định | Manual testing |
| Regression sau mỗi sprint | Automation testing |
| Kiểm tra chức năng đúng không | Functional testing |
| Kiểm tra tốc độ, chịu tải | Performance testing |
| App sắp go-live, có traffic thật | Load + stress testing |
| Form, API, login có dữ liệu nhạy cảm | Security testing (cơ bản) |
| Test trên nhiều browser/device | Compatibility testing |
| Cho khách hàng dùng thử trước | UAT (User Acceptance Testing) |
Sơ đồ quyết định chọn loại testing theo tình huống
Thực tế một sprint ở team 3-4 người:
- Dev xong tính năng → Tester manual test tính năng mới (functional)
- Sau khi pass → Chạy automation regression để đảm bảo tính năng cũ không bị ảnh hưởng
- Trước release lớn → Chạy thêm performance test nếu có thay đổi ảnh hưởng tốc độ
- Với tính năng liên quan dữ liệu nhạy cảm → Thêm vài security test case cơ bản
Không phải lúc nào cũng cần tất cả. Dự án landing page đơn giản không cần stress testing. App thanh toán thì security testing là bắt buộc. Bối cảnh quyết định tất cả.
Nếu bạn muốn có nền tảng vững về testing từ đầu, khóa Kiểm thử phần mềm của F8 đi từ kiến thức cơ bản nhất, tập trung vào kiến thức trọng tâm giúp bạn có việc sau 2 tháng - cover cả phần phân loại testing này với bài tập thực hành.
Checklist chọn loại testing cho fresher tải tại đây: Tải checklist chọn loại testing (interactive HTML)
Tổng kết và bước tiếp theo
Testing không chỉ có một loại. Nhưng cũng đừng bị choáng ngợp - bạn không cần master tất cả ngay.
Như mình hay nói với các bạn mới: bắt đầu từ manual testing, hiểu functional testing thật vững, rồi các loại khác sẽ tự nhiên đến khi dự án cần. Đừng học automation trước khi biết viết test case tốt.
Tóm lại những gì cần nhớ:
- Manual vs Automation: cách thực hiện - tay hay máy
- Functional vs Non-functional: mục tiêu - đúng hay tốt
- Performance testing: load, stress, spike, endurance - mỗi loại trả lời một câu hỏi
- Security testing: biết khái niệm, thêm vào test case khi cần
- Chọn loại nào: dựa vào bối cảnh dự án, không có công thức cố định
Bức tranh tổng thể sau khi đi qua tất cả các loại testing
Nếu phỏng vấn hỏi "bạn biết những loại testing nào", giờ bạn không chỉ liệt kê tên - bạn giải thích được tại sao cần, khi nào dùng, ví dụ thực tế. Đó là câu trả lời của người biết nghề.
Bài tiếp mình sẽ đi vào viết test case cụ thể cho từng loại - bắt đầu từ functional testing vì đó là nền tảng bạn dùng mỗi ngày. Bookmark lại nhé!