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.

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 Got It 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 Got It nhé!

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

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

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

Đọc thêm về quy trình tuyển dụng tại đây.

https://d1iv5z3ivlqga1.cloudfront.net/wp-content/uploads/2021/04/29235048/1_QAG9RXQyyMAY7i9OYo84FA.png
Got It Vietnam
February 22, 2021
Share this post to:
Tags:
0 Comments
Inline Feedbacks
View all comments
Các bài viết liên quan
Got It Tester – Katie: Quả ngọt đến từ trái tim kiên định

Got It Tester – Katie: Quả ngọt đến từ trái tim kiên định

Tốt nghiệp trường Đại học Kinh tế Quốc dân với tấm bằng Quản trị Hệ thống Thông tin (Management Information System), Katie đối mặt với rất nhiều ngã rẽ. Cô bạn có thể theo ngành Business Analyst (BA), có thể lựa chọn làm Software Tester, cũng có thể tiếp tục phát huy thế mạnh ngôn […]
Chương trình đào tạo Tester ở Got It

Chương trình đào tạo Tester ở Got It

Bên cạnh chương trình training dành cho Software Engineer bài bản, đạt chuẩn Silicon Valley, Got It còn chuẩn bị một chương trình training cực kỳ chất lượng cho các bạn ở team Quality Assurance (QA). Đóng vai trò then chốt, đảm bảo chất lượng đầu ra cho những sản phẩm world-class của Got It, […]
CV Tester – 4 lưu ý giúp bạn pass vòng CV

CV Tester – 4 lưu ý giúp bạn pass vòng CV

Với vị trí yêu cầu độ cẩn thận, tỉ mỉ, khả năng quan sát cao như Software Tester, một chiếc CV gây thiện cảm với nhà tuyển dụng trở nên cực kỳ quan trọng. Bởi, CV, tuy đơn giản, sẽ phần nào nói lên cá tính con người bạn. Vậy làm thế nào để CV […]
Những câu hỏi thường gặp khi phỏng vấn Test Engineer

Những câu hỏi thường gặp khi phỏng vấn Test Engineer

Chìa khoá ôn tập giúp bạn “công phá” vòng phỏng vấn QA Engineer tại Got It
Cách tạo test plan cho sản phẩm hoặc tính năng mới

Cách tạo test plan cho sản phẩm hoặc tính năng mới

Nếu bạn đã hiểu test plan là gì, hẳn là bạn sẽ muốn biết cách tạo test plan hoàn chỉnh cho sản phẩm hoặc tính năng mới. Hãy cùng Got It tìm hiểu 5 bước cần thiết cho một test plan hoàn chỉnh. Mục lục1. Phân tích sản phẩm hoặc tính năng bạn đang thử […]
Tìm hiểu những tiêu chí đánh giá chất lượng phần mềm

Tìm hiểu những tiêu chí đánh giá chất lượng phần mềm

Bất cứ một phần mềm nào được đưa ra thị trường đều được đánh giá chất lượng dựa trên những tiêu chí nhất định. Hãy cùng tìm hiểu xem chất lượng phần mềm (CLPM) là gì? Và làm thế nào để đánh giá chính xác được giá trị của một phần mềm hiện nay. Mục […]