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ế và biết cách kết hợp, bạn sẽ tiết kiệm được thời gian kiểm thử rất nhiều. Vậy có bao nhiêu loại kỹ thuật thiết kế test case? Cùng Got It tìm hiểu về các nhóm kỹ thuật trong bài viết dưới đây 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. Việc test tất cả các test case có thể tạo ra là điều không nên và không thể xảy ra. 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ử. Vậy 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ử
Ứ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 là 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 sang mục mới với Got It nào!

2. 3 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

thiết kế test case trong kiểm thử phần mềm dựa trên 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 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ó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

Nếu bạn quan tâm, hãy xem các vị trí đang tuyển dụng của Got It tại: bit.ly/gotit-hanoi và đọc thêm về quy trình tuyển dụng tại đây.

Hien Huynh
Hien Huynh
February 22, 2021
0
Share this post to:
Tags:
0 Comments
Inline Feedbacks
View all comments
Các bài viết liên quan
Tester là ai? 3 điều cần nắm vững khi tìm hiểu về tester

Tester là ai? 3 điều cần nắm vững khi tìm hiểu về tester

Trên đà phát triển công nghiệp 4.0, nghề tester ngày càng trở nên hot. Cũng vì thế mà càng có nhiều người bắt đầu tìm hiểu về tester hơn. Bài viết hôm nay sẽ tập trung giải đáp thắc mắc của bạn về nghề tester và một số điều cần nắm vững khi muốn làm […]
Top 8 website tự học tester miễn phí (updated 2021)

Top 8 website tự học tester miễn phí (updated 2021)

Ở bài viết này, Got It sẽ giới thiệu top 8 website tự học tester miễn phí tốt nhất. Với nguồn tài liệu phong phú và chất lượng, các website này chính là những gì bạn cần để chinh phục nghề tester. Trước khi đề cập về các website, Got It muốn chia sẻ một […]
Test script là gì? 6 bước chuyển test case thành test script

Test script là gì? 6 bước chuyển test case thành test script

Trong bài viết trước, chúng ta đã hiểu test case là gì và cách viết test case hoàn chỉnh. Hôm nay, Got It sẽ giúp bạn hiểu test script là gì và cách dựng test script từ test case. Cùng bắt đầu nhé! Mục lụcTest script là gì?6 bước biến test case thành test script1. […]
Software testing là gì? 7 nguyên tắc phải biết trong software testing

Software testing là gì? 7 nguyên tắc phải biết trong software testing

Vì ngành software testing chứa rất nhiều kiến thức, bạn có thể bị rối khi tìm hiểu về nó. Vậy hãy để Got It giải đáp giúp bạn software testing là gì cũng như những nguyên tắc cơ bản cần phải biết. Cùng xắn tay áo lên và bắt đầu ghi chép nào! Mục lụcSoftware […]
Tự học Automation Test từ cơ bản đến nâng cao

Tự học Automation Test từ cơ bản đến nâng cao

Automating đang là xu hướng phát triển trong lĩnh vực kiểm thử phần mềm. Do đó, các tester cần phải tự học Automation Test để đáp ứng được yêu cầu của nhà tuyển dụng. Nếu bạn đang muốn tự học Automation Test nhưng chưa biết bắt đầu từ đâu? Hãy tham khảo bài viết này […]
UAT testing là gì? Quy trình thực hiện UAT testing

UAT testing là gì? Quy trình thực hiện UAT testing

UAT testing là thuật ngữ đề cập đến giai đoạn cuối trong quá trình kiểm thử, trước khi tung ra trên thị trường. Vậy chính xác thì UAT testing là gì? Bài viết này sẽ giải thích về khái niệm này và những bước chính trong quy trình thực hiện UAT testing. Cùng bắt đầu […]