Bạn có bao giờ thắc mắc làm sao những phần mềm từ đơn giản đến phức tạp lại hoạt động mượt mà và ổn định như vậy? Bí quyết nằm ở các kỹ thuật kiểm thử phần mềm, những phương pháp, quy trình giúp các lập trình viên xây dựng và duy trì sản phẩm công nghệ chất lượng. Trong bài viết này, chúng ta sẽ cùng khám phá các kỹ thuật phần mềm phổ biến và hiệu quả nhất, giúp bạn hiêu rõ cách các “bộ não” công nghệ vận hành và làm thế nào để áp dụng vào dự án của mình một cách dễ dàng hơn.
1. Vai trò và phân loại các kỹ thuật kiểm thử phần mềm
Kỹ thuật kiểm thử phần mềm là tập hợp các phương pháp, quy trình và công cụ giúp các lập trình viên phát triển phần mềm một cách khoa học, hiệu quả và bền vững. Thay vì chỉ viết code một cách ngẫu hứng, kỹ thuật phần mềm giúp đảm bảo sản phẩm cuối cùng hoạt động đúng như mong muốn, dễ bảo trì và nâng cấp trong tương lai.
Nói cách khác, kỹ thuật kiểm thử phần mềm giúp bạn:
- Thiết kế test case thông minh hơn, ít nhưng chất lượng.
- Tập trung đúng chỗ dễ phát sinh lỗi.
- Tiết kiệm thời gian, công sức mà vẫn đảm bảo chất lượng.
- Nâng cao kỹ năng phân tích hệ thống
Các loại kỹ thuât kiểm thử phổ biến hiện này:
Kỹ thuật kiểm thử không phải là một khái niệm trừu tượng mà được chia thành các nhóm rõ ràng, tùy theo cách bạn tiếp cận hệ thống.
1.1 Kiểm thử hộp đen (black-bõ testing)
Kiểm thử hộp đen là nhóm kỹ thuật mà bạn không quan tâm đến code bên trong, chỉ tập trung vào đầu vào – đầu ra của hệ thống. Đa số các kỹ thuật như phân vùng tương đương, giá trị biên, bảng quyết định hay chuyển đổi trạng thái đều nằm trong nhóm này.
→ Dành cho tester, QA, hoặc cả dev muốn kiểm thử logic mà không cần đọc code.
1.2 Kiểm thử hộp trắng (white-box testing)
Ngược lại với hộp đen, kiểm thử hộp trắng yêu cầu bạn phải hiểu luồng code, logic điều kiện, vòng lặp, hàm gọi nhau như thế nào để test. Ví dụ như kiểm thử tất cả các nhánh if-else, vòng lặp for…
→ Thường áp dụng bởi lập trình viên, hoặc tester có kiến thức về code.
1.3 Kiểm thử dựa trên kinh nghiệm (experience-based testing)
Nhóm này không theo công thức cụ thể, mà dựa vào trực giác, kinh nghiệm của người kiểm thử để phán đoán các chỗ có thể gây lỗi – ví dụ như những phần hệ thống từng lỗi nhiều lần, những input đặc biệt, hoặc flow người dùng hay quên điền thông tin.
→ Kỹ thuật đoán lỗi (Error Guessing) là ví dụ tiêu biểu.
2. Các kỹ thuật kiểm thử phần mềm
Bây giờ chúng ta sẽ đi vào phần chính của chủ đề này, 5 kỹ thuật kiểm thử phần mềm phổ biến và cực kỳ hữu ích trong thực tế. Các kỹ thuật kiểm thử phần mềm này không chỉ giúp bạn viết test case dễ dàng hơn, mà còn nâng cao khả năng phát hiện lỗi trong kiểm thử phần mềm, ngay cả khi hệ thống còn đang trong giai đoạn phát triển.
Đừng lo nếu bạn chưa từng nghe tới các tên như “phân tích giá trị biên” hay “bảng quyết định”. Chúng ta sẽ đi từng kỹ thuật một cách dễ hiểu nhất, có ví dụ minh họa cụ thể, và gợi ý cách áp dụng vào công việc hàng ngày.
Dưới đây là 5 kỹ thuật bạn cần nắm vững nếu muốn kiểm thử phần mềm một cách khoa học, logic và tiết kiệm thời gian:
2.1 Phân vùng tương đương (Equivalence Partitioning)
Nếu bạn đang viết test case cho một input số tuổi từ 18 đến 60 và bạn tính test từng con số từ 1 đến 100 thì…. Thay vào đó, phân vùng tương đương sẽ giúp bạn “nhóm” các giá trị đầu vào lại thành các phần tương đương, để chỉ cần test một đại diện là đủ.
Phân vùng tương đương là một kỹ thuật kiểm thử thuộc nhóm kiểm thử hộp đen. Mục tiêu của kỹ thuật này là:
“Chia đầu vào của chương trình thành các vùng dữ liệu mà tại đó hệ thống được cho là xử lý giống nhau.”
Nói đơn giản: Nếu hệ thống xử lý các giá trị 20, 25, 30 giống nhau → ta chỉ cần test 1 trong số đó.
Có 2 loại lớp tương đương chính:
- Lớp hợp lệ (Valid Partition): là những giá trị đầu vào mà hệ thống cho phép.
- Lớp không hợp lệ (Invalid Partition): là những giá trị không hợp lệ, hệ thống phải từ chối hoặc báo lỗi.
Các áp dụng phân vùng tương đương:
- Phân tích yêu cầu đầu vào.
- Xác định các phạm vi hoặc loại dữ liệu hợp lệ.
- Chia thành các lớp dữ liệu khác nhau (hợp lệ & không hợp lệ).
- Chọn ít nhất một đại diện cho mỗi lớp để viết test case.
Ví dụ minh họa để giúp bạn hình dung rõ hơn về kỹ thuật kiểm thử phân vùng tương đương:
Yêu cầu: Hệ thống chỉ chấp nhận độ tuổi từ 18 đến 60 để đăng ký tài khoản.
→ Ta có thể chia đầu vào thành các lớp:
| Loại lớp | Miêu tả | Đại diện |
| Hợp lệ | 18 ≤ tuổi ≤ 60 | 25 |
| Không hợp lệ | Tuổi < 18 | 16 |
| Không hợp lệ | Tuổi > 60 | 65 |
→ Vậy là bạn chỉ cần viết 3 test case thay vì kiểm tra tất cả các độ tuổi từ 1 đến 100.
Vậy khi nào nên dùng kỹ thuật này?
Khi bạn cần test các input có thể chia thành các nhóm rõ ràng, ví dụ như độ tuổi, số lượng, số tiền, trạng thái đơn hàng…
2.2 Phân tích giá trị biên (Boundary Value Analysis)
Bạn còn nhớ kỹ thuật “phân vùng tương đương” không? Nó giúp chia đầu vào thành các nhóm. Nhưng có một sự thật thú vị là: lỗi thường không nằm giữa các nhóm, mà nằm ngay ở ranh giới
Ví dụ như tuổi 18 hay tuổi 60, chứ không phải 25 hay 40.
Đó chính là lý do chúng ta cần đến kỹ thuật phân tích giá trị biên – một trong những “vũ khí lợi hại” nhất trong kiểm thử phần mềm.
Phân tích giá trị biên (Boundary Value Analysis – BVA) là kỹ thuật kiểm thử tập trung vào các giá trị cận trên và cận dưới của một phạm vi hợp lệ hoặc không hợp lệ. Vì sao? Vì những chỗ này rất dễ bị lỗi kiểu như: thiếu dấu =, thiếu kiểm tra biên, off-by-one (ví dụ code chỉ cho tuổi > 18 thay vì ≥ 18)…
Ví dụ về phân tích giá trị biên:
- Xác định dải giá trị đầu vào hợp lệ (ví dụ: 18 đến 60).
- Lấy các giá trị ở biên:
- Cận dưới: 18 → test các giá trị: 17 (dưới), 18 (biên), 19 (trên biên)
- Cận trên: 60 → test các giá trị: 59 (dưới biên), 60 (biên), 61 (trên)
- Viết test case dựa vào những giá trị này.
Ví dụ minh họa: Yêu cầu hệ thống cho phép đăng ký nếu tuổi từ 18 đến 60.
→ Ta sẽ test:
| Trường hợp | Giá trị |
| Dưới cận dưới | 17 |
| Tại cận dưới | 18 |
| Trên cận dưới | 19 |
| Dưới cận trên | 59 |
| Tại cận trên | 60 |
| Trên cận trên | 61 |
Vậy chúng ta sẽ có tổng cộng 6 test case, vừa đủ để hệ thống có xử lý đúng không.
Vậy khi nào nên dùng kỹ thuật này?
- Khi đầu vào có giới hạn rõ ràng, ví dụ: giới hạn độ tuổi, chiều dài password, số lượng item…
- Khi bạn nghi ngờ hệ thống dễ bị lỗi ở biên, nhất là khi dev viết logic điều kiện như >=, <=.
2.3 Bảng quyết định kiểm thử (Decision Table Testing)
Nếu bạn từng kiểm thử một chức năng mà có quá nhiều điều kiện ràng buộc nhau (kiểu như “nếu A đúng và B sai thì làm C, còn nếu A sai mà B đúng thì làm D…”), thì bảng quyết định kiểm thử sẽ là “cứu tinh” của bạn.
Đây là cách tuyệt vời để biến logic phức tạp thành bảng đơn giản, dễ nhìn – dễ test – dễ hiểu.
Decision Table Testing là kỹ thuật kiểm thử hộp đen dùng để xử lý các tình huống có nhiều điều kiện và nhiều hành động xảy ra. Mỗi hàng trong bảng thể hiện một điều kiện hoặc một hành động, còn mỗi cột là một kịch bản cụ thể.
Cấu trúc bảng quyết định gồm:
- Hàng điều kiện (Condition rows): các điều kiện logic cần kiểm tra.
- Hàng hành động (Action rows): kết quả hoặc hành động tương ứng.
- Các cột (Rules): mỗi cột là một tổ hợp điều kiện dẫn đến hành động tương ứng.
Ví dụ minh họa: yêu cầu hệ thống cấp voucher giảm giá như sau:
- Nếu là khách hàng thân thiết và mua > 1 triệu → giảm 10%
- Nếu không thân thiết nhưng mua > 2 triệu → giảm 5%
- Các trường hợp còn lại → không giảm
| Điều kiện | Rule 1 | Rule 2 | Rule 3 |
| Khách hàng thân thiết | Có | Không | Không |
| Mua > 2 triệu | Có | Có | Không |
| Hành động: Giảm 10% | ✅ | ❌ | ❌ |
| Hành động: Giảm 5% | ❌ | ✅ | ❌ |
| Hành động: Không giảm | ❌ | ❌ | ✅ |
→ Từ bảng này, bạn dễ dàng viết ra 3 test case đại diện và không bỏ sót logic nào.
Vậy khi nào nên dùng kỹ thuật này?
- Khi bạn test các chức năng có nhiều “nhánh” quyết định (kiểu: nếu – thì – và – hoặc…)
- Khi làm việc với các yêu cầu nghiệp vụ có nhiều luật ràng buộc.
2.4 Đoán lỗi (Error Guessing)
Bạn có bao giờ trong đầu bỗng nghĩ “Chắc cái chỗ này sẽ bị lỗi” và… đúng là lỗi thiệt không? Đó chính là cảm giác khi bạn sử dụng đoán lỗi trong kiểm thử (Error Guessing) – một kỹ thuật kiểm thử phần mềm dựa vào kinh nghiệm cá nhân và trực giác nghề nghiệp.
Dù nghe có vẻ “cảm tính”, nhưng đây lại là kỹ thuật được nhiều tester lão làng áp dụng rất hiệu quả trong thực tế.
Đoán lỗi là kỹ thuật kiểm thử không dựa vào một công thức cụ thể nào. Thay vào đó, tester sẽ dựa vào kinh nghiệm, trực giác, và hiểu biết về hệ thống để suy đoán những chỗ dễ phát sinh lỗi – từ đó viết test case kiểm tra kỹ hơn ở những điểm đó.
Ví dụ thực tế:
Bạn đang kiểm thử một form nhập email, bạn sẽ:
- Thử nhập email thiếu @ → “abc.com”
- Thử nhập email có 2 dấu @ → “a@@b.com”
- Copy-paste email từ Word xem có lỗi khoảng trắng không
- Nhập email rất dài → kiểm tra độ dài tối đa
Khi nào nên dùng?
- Khi bạn đã hoàn thành các test case chính nhưng vẫn có thời gian để “khám phá”.
- Khi kiểm thử các chức năng có input phức tạp, ít quy định chặt chẽ.
- Khi bạn từng gặp lỗi ở những chỗ tương tự ở dự án khác (kinh nghiệm là vàng
2.5 Chuyển đổi trạng thái phần mềm (State Transition Testing)
Bạn có bao giờ kiểm thử một hệ thống mà hành vi phụ thuộc vào trạng thái hiện tại không? Ví dụ:
- Tài khoản chưa kích hoạt thì không đăng nhập được
- Đơn hàng đã huỷ thì không thể chuyển sang “đang giao”
- Người dùng đang bị khóa thì không thể reset mật khẩu
Đó chính là những tình huống điển hình để áp dụng kỹ thuật chuyển đổi trạng thái phần mềm (State Transition Testing).
Chuyển đổi trạng thái phần mềm là một kỹ thuật kiểm thử hộp đen, được dùng khi hành vi của hệ thống thay đổi tùy theo trạng thái hiện tại. Kỹ thuật này mô phỏng hệ thống như một máy trạng thái (state machine) – nơi có:
- Các trạng thái: hệ thống đang ở đâu? (VD: “mới tạo”, “đang xử lý”, “đã huỷ”)
- Các sự kiện: điều gì khiến trạng thái thay đổi? (VD: “bấm thanh toán”, “admin huỷ đơn”)
- Chuyển đổi: từ trạng thái này → trạng thái khác khi có sự kiện xảy ra.
Cách thực hiện kỹ thuật chuyển đổi trạng thái:
- Xác định các trạng thái có thể có của đối tượng (user, đơn hàng, tài khoản…)
- Liệt kê các sự kiện dẫn đến thay đổi trạng thái.
- Xây dựng sơ đồ hoặc bảng chuyển đổi trạng thái.
Viết test case để kiểm tra:
- Chuyển đổi hợp lệ
- Chuyển đổi không hợp lệ (phải báo lỗi)
Ví dụ minh họa: Ứng dụng đặt hàng có 4 trạng thái đơn hàng
- Mới tạo
- Đang giao
- Đã giao
- Đã huỷ
| Trạng thái hiện tại | Sự kiện | Trạng thái mới |
| Mới tạo | Xác nhận đơn | Đang giao |
| Đang giao | Giao thành công | Đã giao |
| Mới tạo | Huỷ đơn | Đã huỷ |
| Đang giao | Huỷ đơn | ❌ Không cho phép |
| Đã giao | Huỷ đơn | ❌ Không cho phép |
→ Bạn có thể viết test case để kiểm tra:
- Người dùng có thể huỷ đơn khi đơn ở trạng thái “Mới tạo”.
- Người dùng không thể huỷ đơn khi đơn đang được giao hoặc đã giao.
3. So sánh và lựa chọn kỹ thuật kiểm thử phù hợp
Vậy khi nào nên dùng kỹ thuật nào? Có cần dùng hết không? Hay chỉ cần chọn 1-2 cái cho nhanh?
Câu trả lời là: Không có kỹ thuật nào là tốt nhất cho mọi tình huống cả, mà bạn cần chọn kỹ thuật phù hợp với ngữ cảnh. Ở phần này, Stepmedia sẽ giúp bạn so sánh nhanh các kỹ thuạt và gợi ý cách lựa chọn thông minh.
| Kỹ thuật | Mục đích chính | Khi nào nên dùng | Ưu điểm nổi bật |
| Phân vùng tương đương | Rút gọn số lượng test case | Khi đầu vào có thể chia thành các nhóm tương tự | Tiết kiệm thời gian test |
| Giá trị biên | Kiểm tra lỗi ở ranh giới dữ liệu | Khi có điều kiện biên, ví dụ min/max, độ dài input | Phát hiện lỗi “cận biên” rất tốt |
| Bảng quyết định | Kiểm thử logic phức tạp | Khi có nhiều điều kiện và hành động kết hợp | Trực quan, tránh bỏ sót tổ hợp điều kiện |
| Đoán lỗi | Dựa vào kinh nghiệm để bắt bug | Khi cần kiểm thử linh hoạt, khám phá thêm | Phát hiện lỗi khó đoán, tăng độ bao phủ kiểm thử |
| Chuyển đổi trạng thái | Kiểm thử hệ thống có luồng trạng thái | Khi chức năng phụ thuộc vào trạng thái hiện tại | Hiểu rõ logic luồng hoạt động của hệ thống |
Gợi ý cách để chọn một trong các kỹ thuật kiểm thử phần mềm phù hợp:
- Nếu bạn mới bắt đầu viết test case: hãy bắt đầu với phân vùng tương đương và giá trị biên. Đây là hai kỹ thuật dễ học, dễ áp dụng mà hiệu quả rất cao.
- Nếu hệ thống có nhiều trạng thái (ví dụ như đơn hàng, tài khoản, luồng xử lý) → ưu tiên dùng chuyển đổi trạng thái.
- Nếu yêu cầu có nhiều luật ràng buộc phức tạp (ví dụ giảm giá, điều kiện phê duyệt) → bảng quyết định sẽ giúp bạn tổ chức test case logic và dễ nhìn hơn.
- Nếu bạn là tester có kinh nghiệm thực chiến → đừng quên áp dụng đoán lỗi để “soi” những bug mà tài liệu không nói tới.
Trong thực tế, kết hợp 2-3 kỹ thuật thường mang lại hiệu quả cao hơn là chỉ dùng một kỹ thuật.
Kết hợp phân vùng tương đương + giá trị biên → test hiệu quả và chính xác.
Kết hợp bảng quyết định + đoán lỗi → vừa test logic chuẩn vừa tìm bug ngoài dự đoán.
4. Kết luận
Việc hiểu và áp dụng đúng các kỹ thuật kiểm thử phần mềm không chỉ giúp bạn viết test case hiệu quả hơn mà còn giúp nâng cao tư duy kiểm thử, tiết kiệm thời gian, và phát hiện ra những lỗi quan trọng trước khi phần mềm đến tay người dùng.
Trong bài viết này, chúng ta đã cùng tìm hiểu các kỹ thuật kiểm thử phổ biến và được sử dụng rộng rãi trong thực tế.
Không phải dự án nào cũng cần áp dụng tất cả các kỹ thuật cùng lúc. Tuy nhiên, việc hiểu và biết cách sử dụng từng kỹ thuật đúng lúc sẽ giúp bạn trở thành một tester chuyên nghiệp, kiểm thử một cách thông minh và có chiến lược hơn.
Cuối cùng, dù bạn là một tester mới bắt đầu, một QA nhiều kinh nghiệm, hay một developer quan tâm đến chất lượng sản phẩm, thì việc nắm vững những kỹ thuật này sẽ là nền tảng vững chắc để bạn phát triển sự nghiệp và tạo ra những sản phẩm phần mềm chất lượng cao.
