Kỹ thuật thiết kế test case trong kiểm thử phần mềm

Bạn có bao giờ thắc mắc tại sao các tester cần phải biết thiết kế test case trong kiểm thử phần mềm? Đó là bởi khi nắm vững những kỹ thuật thiết kế, bạn sẽ tiết kiệm được thời gian kiểm thử rất nhiều.

• Tìm hiểu thêm: Test Case mẫu và những lưu ý bạn nên biết

Vậy có bao nhiêu loại kỹ thuật thiết kế test case? Có những điều gì cần lưu ý trong quá trình thiết kế? Hãy cùng TTC tìm hiểu về các nhóm kỹ thuật ấy trong bài viết dưới hôm nay nhé!

1. Tại sao phải thiết kế test case trong kiểm thử phần mềm?

Test case (trường hợp kiểm thử) là một trong những yếu tố ảnh hưởng đến chi phí test (kiểm thử). Số lượng test case càng nhiều thì quá trình kiểm thử sẽ càng tốn nhiều thời gian và tiền bạc. Ngoài ra, tuy số lượng test case nhiều, nhưng nếu các test case không chính xác thì tất cả sẽ như “bỏ đi”. Chất lượng sản phẩm sẽ không được đảm bảo.

Do đó, bạn phải thiết kế test case thật tối ưu và hiệu quả trước khi bắt đầu kiểm thử. Nhưng làm sao để thiết kế test case tối ưu nhất?

Ứng dụng kỹ thuật thiết kế test case trong kiểm thử phần mềm giúp tối ưu quá trình kiểm thử

Đáp án chính là những kỹ thuật thiết kế test case (hay kỹ thuật thiết kế kiểm thử phần mềm). Dựa vào bản chất của chúng, các kỹ thuật này được phân loại thành 3 nhóm sau:

• Specification-based (thiết kế dựa trên đặc tả) hay kỹ thuật black-box (kỹ thuật hộp đen)
• Structure-based (thiết kế dựa trên cấu trúc) hay kỹ thuật white-box (kỹ thuật hộp trắng)
• Experience-based (thiết kế dựa trên kinh nghiệm)

Với kỹ thuật phù hợp, tester (kiểm thử viên) sẽ thiết kế được các test case có hiệu quả cao. Quan trọng hơn cả, trước khi thiết kế test case, tester phải trả lời được hai câu hỏi sau:

• Kỹ thuật thiết kế test case nào là phù hợp nhất cho vấn đề đang cần giải quyết?
• Nên kết hợp những kỹ thuật thiết kế test case nào với nhau cho quá trình test hiện tại?

Để trả lời hai câu hỏi trên, chúng ta cần phải nắm được khái quát về những kỹ thuật đó. Cùng tìm hiểu các kỹ thuật này nhé!

2. Ba nhóm kỹ thuật thiết kế test case trong kiểm thử phần mềm

2.1. Kỹ thuật specification-based

Nhóm kỹ thuật thiết kế test case dựa trên specification-based

Nhóm kỹ thuật specification-based chỉ tập trung kiểm thử những yếu tố bên ngoài của hạng mục kiểm thử. Chúng có thể là các đặc điểm kỹ thuật, thiết kế, cách vận hành bên ngoài,… Nhờ đó, tester có thể test chất lượng bên ngoài mà không làm hỏng cấu trúc bên trong phần mềm. Nhóm kỹ thuật này gồm có:

a. Equivalence partitioning (phân vùng tương đương)

Equivalence partitioning là kỹ thuật sẽ phân loại các input thành những phân vùng theo một logic nhất định. Từ đó, tester sẽ chọn một input từ mỗi phân vùng để thiết kế và thực thi test case. Nếu input đó hợp lệ hoặc không hợp lệ thì cả phân vùng cũng hợp lệ hoặc không hợp lệ.

b. Boundary value analysis (phân tích giá trị biên)

Boundary value analysis được dùng để phát hiện lỗi ở những boundary value (giá trị biên). Test case sẽ được thiết kế cùng với các boundary value của equivalence partitioning. Nếu input nằm trong boundary value thì test case là positive testing (kiểm thử tích cực). Ngược lại, nếu input nằm ngoài boundary value thì test case là negative testing (kiểm thử tiêu cực).

c. Decision table testing (kiểm thử bảng quyết định)

Decision table là kỹ thuật kiểm thử giúp tester đánh giá output khi kết hợp các input với nhau. Bảng quyết định trình bày các điều kiện input cùng những hành động hay output tương ứng. Qua đó, bạn có thể xây dựng logic phần mềm dựa trên bảng quyết định.

d. State transition testing (kiểm thử chuyển đổi trạng thái)

Khi dùng kỹ thuật state transition, tester bắt buộc phân tích phần mềm theo một trình tự nhất định. Trình tự này là thứ tự chuyển đổi trạng thái của phần mềm trong sơ đồ chuyển đổi trạng thái. Kỹ thuật này được dùng để kiểm thử khả năng nhập, thoát và chuyển đổi trạng thái của phần mềm.

e. Use case testing (kiểm thử trường hợp sử dụng)

Kỹ thuật này dựa vào use case (trường hợp sử dụng). Use case mô tả sự tương tác giữa phần mềm và tác nhân khác như người dùng, hệ thống khác,… Do đó, test case được thiết kế dựa trên use case giúp test các yêu cầu nghiệp vụ, chức năng.

2.2. Kỹ thuật structure-based

Nhóm kỹ thuật thiết kế test case dựa trên structure-based

Nhóm kỹ thuật structure-based giúp tester kiểm thử cấu trúc và cách vận hành bên trong của phần mềm. Cấu trúc phần mềm thường bao gồm code (mã), control flow (luồng điều khiển), data flow (luồng dữ liệu),… Lúc này, tester sẽ nạp các input để thực thi code và kiểm tra đối chiếu những output thu được. Vì có liên quan đến cấu trúc phần mềm nên tester phải có kiến thức lập trình. Dưới đây là các kỹ thuật thiết kế test case thuộc nhóm structure-based:

a. Statement testing (kiểm thử câu lệnh)

Trong kỹ thuật statement testing, mọi câu lệnh trong cấu trúc code sẽ thực thi ít nhất một lần. Qua đó, tester có thể test được cách vận hành của toàn bộ source code (mã nguồn) phần mềm. Tuy nhiên, tester không thể kiểm thử điều kiện sai mà chỉ có thể thực thi các điều kiện đúng.

b. Decision testing (kiểm thử quyết định)

Decision testing sẽ thực thi, test những quyết định dựa trên decision result (kết quả quyết định). Để làm điều này, test case sẽ đi theo các control flow từ decision point (điểm quyết định). Decision testing giúp kiểm thử xem có câu lệnh không thể truy cập hay gây bất thường không.

c. Condition testing (kiểm thử điều kiện)

Condition testing được dùng để test các biểu thức Boolean có dạng True (đúng) hoặc False (sai). Mỗi biểu thức Boolean sẽ được thực thi ít nhất một lần bằng cả tham số True và False. Với kỹ thuật này, test case được thiết kế để những điều kiện Boolean có thể thực thi dễ dàng.

d. Multiple condition testing (kiểm thử đa điều kiện)

Mục đích của kỹ thuật này là kiểm thử mọi tổ hợp điều kiện có thể của quyết định. Công thức tính số tổ hợp này là 2 lũy thừa bậc N, với N là số biến điều kiện. Số lượng tổ hợp này cũng chính là số lượng test case mà bạn phải dùng.

e. Path testing (kiểm thử lộ trình)

Trong kỹ thuật này, tester sẽ test từng câu lệnh có trong source code để tìm lỗi. Việc này giúp xác định lỗi tiềm ẩn trong một đoạn code. Tuy nhiên, tester không nên áp dụng kỹ thuật path testing khi kiểm thử các phần mềm phức tạp. Với cấu trúc code phức tạp, số test case hay câu lệnh mà bạn phải kiểm thử là rất nhiều.

2.3. Kỹ thuật experience-based

Nhóm kỹ thuật thiết kế test case dựa trên experience-based

Như tên gọi của mình, nhóm kỹ thuật này phụ thuộc vào hiểu biết và năng lực của tester. Những kiến thức, kinh nghiệm của tester sẽ là cơ sở để thiết kế test case. Do đó, chất lượng của các test case dựa trên kinh nghiệm sẽ hoàn toàn phụ thuộc vào tester. Nhóm kỹ thuật này được chia thành 2 loại:

a. Exploratory testing (kiểm thử thăm dò)

Đây là kỹ thuật test không cần chuẩn bị hay theo một lịch trình cụ thể. Khi thực hiện exploratory testing, tester sẽ vừa phân tích phần mềm, vừa thiết kế và thực thi kiểm thử. Ngoài ra, việc lên kế hoạch và lưu kết quả cũng diễn ra linh động trong quá trình kiểm thử.

b. Error guessing (phỏng đoán lỗi)

Error guessing được dùng để dự đoán các lỗi tiềm ẩn dựa trên kiến thức của tester. Những kiến thức này thường về cách vận hành trước đây của phần mềm, các lỗi đã và có khả năng xuất hiện, những lỗi mà tester từng phát hiện,…

Tóm lại, một tester chuyên nghiệp cần biết linh hoạt trong việc lựa chọn kỹ thuật thiết kế để giảm thiểu test case đến mức tối ưu mà vẫn hiệu quả trong việc phát hiện lỗi. Hy vọng qua bài viết này, các bạn có thể nắm rõ hơn về những kỹ thuật thiết kế test case trong kiểm thử phần mềm.

Theo educba & professionalqa