Các loại test cơ bản: Functional, Non-Functional và Regression cho fresher
6 tháng trước · 12 phút đọc
Ba loại test này xuất hiện ở đâu trong dự án thật?
Mình nhớ lần đầu được assign task "viết test case cho tính năng đăng ký tài khoản". Mình viết: nhập đúng thông tin → tạo được tài khoản. Xong. Reviewer hỏi: "Bạn có test xem trang load bao lâu không? Sau khi dev fix bug ở form đăng nhập, bạn có test lại đăng ký không?" Lúc đó mình mới hiểu mình chỉ đang làm một phần rất nhỏ của testing.
Đó là lý do bài này tồn tại. Ba loại test - functional, non-functional, regression - không phải lý thuyết xa xôi. Chúng là ba góc nhìn khác nhau để đảm bảo một tính năng thực sự hoạt động tốt, không chỉ "chạy được".
Ba góc nhìn kiểm thử: chức năng, hiệu suất, và ổn định sau thay đổi
Trước khi đi vào từng loại, mình muốn nói thẳng: bạn không cần thuộc lòng định nghĩa sách giáo khoa. Cần hiểu tại sao mỗi loại tồn tại và khi nào dùng. Phỏng vấn hỏi câu này, nhà tuyển dụng muốn biết bạn có tư duy hay không, không phải bạn có nhớ định nghĩa hay không.
Functional test: kiểm tra app làm đúng việc của nó không
Kiểm thử chức năng (functional test) trả lời câu hỏi đơn giản nhất: tính năng này có hoạt động đúng như yêu cầu không?
Tưởng tượng bạn đang test tính năng đăng nhập của một app mobile. Functional test sẽ kiểm tra:
- Nhập email đúng + password đúng → vào được trang chủ
- Nhập sai password → hiện thông báo lỗi
- Để trống email → không cho submit
- Nhập email không đúng định dạng (
abc@không có tên miền) → báo lỗi - Quên mật khẩu → link reset gửi về đúng email
Mỗi dòng trên là một test case. Functional test tập trung vào input và output: bạn làm gì, app phản hồi gì. Không quan tâm app phản hồi nhanh hay chậm, không quan tâm server dùng gì. Chỉ quan tâm đúng hay sai.
Functional test: input rõ ràng, output kiểm chứng được
Trong thực tế, functional test chiếm phần lớn công việc hàng ngày của một tester. Mỗi tính năng mới, mỗi bug được fix, bạn đều cần viết và chạy functional test case. Đây là loại test mà fresher học đầu tiên - và học tốt nhất khi thực hành ngay trên app thật.
Lưu ý quan trọng: Functional test không phải chỉ test "happy path" - tức là chỉ test trường hợp mọi thứ đúng. Mình từng bỏ qua test trường hợp password có ký tự đặc biệt (@, #, $), kết quả là sau release 3 ngày có user báo không đăng nhập được. Bài học đắt giá: luôn test cả invalid input và edge case (trường hợp biên).
Non-functional test: khi "chạy đúng" chưa đủ
"Chạy được" và "chạy tốt" là hai chuyện khác nhau.
Kiểm thử phi chức năng (non-functional test) không hỏi "app có làm đúng không?", mà hỏi "app làm tốt đến mức nào?" Đây là loại test mà nhiều fresher hay bỏ qua vì không thấy ngay kết quả - cho đến khi sản phẩm lên production và user bắt đầu complain.
Non-functional test bao gồm nhiều loại con, nhưng với fresher cần nắm 3 cái phổ biến nhất:
Performance testing - kiểm thử hiệu suất: Trang load trong bao lâu? Nút submit phản hồi sau bao nhiêu giây? Ngưỡng chấp nhận được thường là dưới 3 giây cho thao tác thông thường. Dùng tool như JMeter, Lighthouse, hoặc đơn giản hơn là Chrome DevTools để đo.
Load testing - kiểm thử tải: App có chịu được khi hàng nghìn người dùng cùng lúc không? Scenario kinh điển: flash sale trên Shopee, hàng ngàn người click "Mua ngay" cùng lúc. Nếu không test trước, server có thể crash ngay lúc quan trọng nhất.
Security testing - kiểm thử bảo mật: Dữ liệu user có bị lộ không? Form đăng nhập có bị tấn công SQL injection không? Loại này thường do tester cấp cao hoặc security engineer phụ trách, nhưng fresher nên biết khái niệm cơ bản.
Non-functional test: 3 loại phổ biến mà fresher cần biết
Bạn có thể chưa phải tự chạy load testing hay security testing ngay khi mới vào nghề. Nhưng hiểu khái niệm giúp bạn đặt câu hỏi đúng khi review test plan, và không bị "câm" khi phỏng vấn hỏi về chủ đề này.
Regression test: test lại sau mỗi lần thay đổi
Mình từng bỏ qua bước này và ân hận mãi. Dev fix một bug nhỏ ở màn hình thanh toán. Mình test lại bug đó - đã fix đúng. Bấm "Pass". Hai ngày sau, user báo không thêm được sản phẩm vào giỏ hàng - một tính năng hoàn toàn khác. Hoá ra khi fix bug thanh toán, dev vô tình sửa luôn một hàm dùng chung, kéo theo giỏ hàng bị ảnh hưởng.
Đó là lý do kiểm thử hồi quy (regression testing) tồn tại.
Regression test là gì? Sau khi có bất kỳ thay đổi nào trong code - fix bug, thêm tính năng mới, cập nhật thư viện - bạn cần test lại các tính năng cũ để chắc chắn chúng không bị phá vỡ.
Regression test chạy sau mỗi thay đổi để đảm bảo không có gì bị phá vỡ
Vấn đề thực tế: một dự án web/mobile có thể có hàng trăm tính năng. Không thể test toàn bộ sau mỗi thay đổi - không đủ thời gian. Nên cách tiếp cận thực dụng là:
- Xác định vùng ảnh hưởng: Dev thay đổi module nào? Module nào liên quan? Tập trung test những vùng đó trước.
- Regression test case có sẵn: Các tính năng core (đăng nhập, thanh toán, đặt hàng) nên có sẵn test case để chạy lại nhanh.
- Smoke test trước: Chạy qua nhanh các luồng chính - kiểm thử khói (smoke testing) - xem app còn sống không trước khi test kỹ.
Với fresher, bước đầu tiên là lập danh sách các tính năng core của dự án và giữ test case cho chúng luôn cập nhật. Khi có thay đổi, bạn có thứ để chạy ngay thay vì phải nhớ lại từ đầu.
So sánh nhanh: khi nào dùng loại nào?
Đây là phần phỏng vấn hay hỏi nhất. Không phải "định nghĩa là gì" mà là "khi nào bạn chọn cái nào?"
| Tình huống | Dùng loại test nào |
|---|---|
| Tính năng mới vừa xong, test lần đầu | Functional test |
| Dev fix bug, cần verify fix đúng | Functional test (test case cho bug đó) |
| Sau khi fix bug, đảm bảo không phá gì cũ | Regression test |
| App sắp release, kiểm tra các luồng chính | Smoke test (một dạng regression) |
| App load chậm, user complain | Performance test (non-functional) |
| Sắp có event lớn, nhiều user cùng lúc | Load test (non-functional) |
| Form đăng ký có lỗ hổng bảo mật không | Security test (non-functional) |
Bảng quyết định: tình huống nào dùng loại test nào
Một sprint làm việc bình thường của tester sẽ có cả ba loại:
- Dev commit code mới → bạn chạy functional test cho tính năng mới
- Dev fix bug từ sprint trước → bạn verify bằng functional test, rồi chạy regression các module liên quan
- Cuối sprint, trước khi release → chạy smoke test toàn bộ luồng chính
- Nếu dự án có SLA về performance → đội test thêm non-functional test định kỳ
Thấy không? Không phải lúc nào cũng dùng cả ba. Biết tình huống nào cần cái gì mới là kỹ năng thật sự.
Checklist áp dụng ngay cho dự án đầu tiên
Bạn vừa được onboard vào dự án. Chưa biết bắt đầu từ đâu? Dùng checklist này.
Khi nhận tính năng mới để test:
- [ ] Đọc tài liệu yêu cầu (requirement) hoặc hỏi BA/dev nếu không có tài liệu
- [ ] Viết test case cho happy path trước (trường hợp mọi thứ đúng)
- [ ] Thêm test case cho invalid input (sai định dạng, để trống, ký tự đặc biệt)
- [ ] Thêm test case cho edge case (giá trị giới hạn, số 0, chuỗi rất dài)
- [ ] Chạy và ghi kết quả từng test case
Sau khi dev fix bug:
- [ ] Test lại đúng bug đó theo test case đã viết
- [ ] List ra các tính năng liên quan đến module vừa thay đổi
- [ ] Chạy regression test cho các tính năng đó
- [ ] Nếu không đủ thời gian: ưu tiên test các luồng chính nhất (smoke test)
Trước khi release:
- [ ] Chạy smoke test toàn bộ luồng chính (đăng ký, đăng nhập, tính năng core)
- [ ] Check xem có bug nào đang open không nên hold release
- [ ] Nếu có SLA performance: chạy kiểm tra tốc độ load trang
Checklist đơn giản nhưng đủ để không bỏ sót bước nào
Mình gợi ý bạn tải checklist này về, in ra hoặc lưu vào note. Tuần đầu đi làm sẽ bận và dễ quên. Có checklist trước mắt giúp bạn không skip bước quan trọng dù đang busy.
Nếu muốn học bài bản từ đầu - từ viết test case, báo cáo bug, đến các kỹ thuật kiểm thử nâng cao hơn - khóa Kiểm thử phần mềm đi từ kiến thức cơ bản, tập trung vào trọng tâm có việc làm ngay. Mình thấy phù hợp cho bạn trái ngành muốn chuyển sang tester một cách có hệ thống.
Tải checklist dưới dạng file để lưu lại và dùng dần: Tải checklist kiểm thử cho fresher
Câu hỏi phỏng vấn thường gặp về chủ đề này
Ba loại test này xuất hiện rất nhiều trong phỏng vấn tester fresher. Dưới đây là cách trả lời tự nhiên, không học vẹt.
"Bạn phân biệt functional và non-functional test như thế nào?"
Cách trả lời tốt: "Functional test kiểm tra tính năng có làm đúng việc của nó không - ví dụ form đăng nhập có nhận đúng input và trả về đúng output không. Non-functional test kiểm tra chất lượng của cách làm đó - như trang load trong bao lâu, hoặc có chịu được nhiều người dùng cùng lúc không. Cùng một tính năng đăng nhập, tôi có thể test cả hai: functional để xem có đúng không, performance để xem có nhanh không."
"Regression test là gì và khi nào bạn chạy?"
Cách trả lời tốt: "Regression test là test lại các tính năng cũ sau mỗi lần có thay đổi code, để đảm bảo thay đổi đó không làm hỏng thứ gì đang hoạt động. Tôi thường chạy sau khi dev fix bug hoặc merge tính năng mới vào, tập trung vào các module liên quan đến phần vừa thay đổi và các tính năng core của dự án."
Trả lời phỏng vấn: nói bằng ngôn ngữ của mình, dùng ví dụ cụ thể
"Dự án bạn chưa có kinh nghiệm, làm sao biết viết test case?"
Câu này không hỏi về loại test, nhưng liên quan. Trả lời thật: bạn đã tự thực hành trên app thật (demo app, app công khai), biết phân loại test case theo functional/regression, biết cần test cả happy path lẫn edge case. Đó là nền tảng. Còn domain knowledge về dự án cụ thể thì học khi làm.
Thấy khó ở bước trả lời phỏng vấn là hoàn toàn bình thường. Mình cũng mất vài lần mock interview mới nói được tự nhiên. Điểm mấu chốt: đừng học thuộc định nghĩa, hãy hiểu để giải thích bằng lời của mình.