Các kỹ thuật kiểm thử thiết kế Test Case chất lượng - Software testing

19 Apr 2023
admin

Các kỹ thuật kiểm thử thiết kế Test Case chất lượng - Software testing

Vinaspar - Phân vùng tương đương (Equivalence Class Partitioning) · Phân tích giá trị biên (Boundary Value Analysis (BVA) ) · Bảng quyết định (Decision Table based testing)

Các kỹ thuật kiểm thử phần mềm thiết kế Test Case phổ biến nhất bao gồm: Phân vùng tương đương (Equivalence partitioning), Phân tích giá trị biên (Boundary value analysis), Bảng quyết định (Decision Tables), Đoán lỗi (Error guessing), Chuyển đổi trạng thái (State Transition).

Các kỹ thuật này là 1 phần testing trong đó có các phương thức blackbox whitebox testing, monkey testing, vvv

1. Phân vùng tương đương (Equivalence partitioning)

Phân vùng tương đương là kỹ thuật chia đầu vào thành những nhóm tương đương nhau. Nếu một giá trị trong nhóm hoạt động đúng thì tất cả các giá trị trong nhóm đó cũng hoạt động đúng và ngược lại.

Thiết kế Test-case bằng phân vùng tương đương tiến hành theo 2 bước: Xác định các lớp tương đương và xác định các ca kiểm thử. Khi thực hiện kỹ thuật Equivalence partitioning, đầu vào sẽ được chia theo nguyên tắc:

1 lớp các giá trị lớn hơn.
1 lớp các giá trị nhỏ hơn.
1 lớp các giá trị hợp lệ.

Phân vùng tương đương là kỹ thuật chia đầu vào thành những nhóm tương đương nhau.

Ví dụ: Mật khẩu chỉ được nhập Zip code 5 số. Coi đầu vào là X = 5, áp dụng kỹ thuật phân vùng tương tương ta có 3 lớp giá trị đầu vào: Lớp giá trị hợp lệ X = 5, lớp giá trị không hợp lệ X < 5 và X > 5. Từ các lớp tương đương phát triển thành Test Case như sau:

Nhập Zip Code = 5 => Hợp lệ
Nhập Zip Code < 5 => Không hợp lệ
Nhập Zip Code > 5 => Không hợp lệ

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

Phân tích giá trị biên là phương pháp test tất cả các giá trị ở vùng biên của dữ liệu vào và dữ liệu ra. Các tester sẽ tập trung vào các giá trị biên chứ không test toàn bộ dữ liệu. Do đó, thay vì phải kiểm thử toàn bộ dữ liệu vào và ra, ta có thể test từ 4 - 6 case mà vẫn đảm bảo hệ thống hoạt động tốt.

Boundary conditions là các vị trí ở giữa, trên và dưới các biên của lớp tương đương. Khi áp dụng kỹ thuật phân tích giá trị biên, người kiểm thử sẽ chọn các giá trị:

Giá trị nhỏ nhất
Giá trị ngay dưới giá trị nhỏ nhất
Giá trị bình thường
Giá trị lớn nhất
Giá trị ngay trên giá trị lớn nhất

Boundary value analysis phân chia dữ liệu thành 5 giá trị cơ bản

Ví dụ: Số lượng sản phẩm cần mua chỉ được phép điền từ [0-10]. Áp dụng kỹ thuật phân tích giá trị biên ta sẽ có các giá trị:

Giá trị nhỏ nhất: 0
Giá trị ngay dưới giá trị nhỏ nhất: -1
Giá trị bình thường: 5
Giá trị ngay trên giá trị lớn nhất: 11
Giá trị lớn nhất: 10

Từ các giá trị phát triển thành các Test Case như sau:

Nhập số lượng sản phẩm = 0 => Hợp lệ
Nhập số lượng sản phẩm = 5 => Hợp lệ
Nhập số lượng sản phẩm = 10 => Hợp lệ
Nhập số lượng sản phẩm = -1 => Không hợp lệ
Nhập số lượng sản phẩm = 11 => Không hợp lệ

3. Bảng quyết định (Decision Tables)

Trong các kỹ thuật viết Test Case, đối với các trường dữ liệu đơn như textbox, các tester thường sử dụng các phương pháp phân vùng tương đương hay phân tích giá trị biên. Đối với kiểm thử hành vi của hệ thống với nhiều trường dữ liệu, Bảng quyết định (Decision table) sẽ giúp chúng ta phân loại và định hình được kịch bản kiểm thử một cách chính xác và rõ ràng hơn.

Bảng quyết định là một kỹ thuật tốt để áp dụng cho những trường hợp cần nhiều sự kết hợp. Kỹ thuật này hỗ trợ việc lựa chọn Test Case tối thiểu một cách có hệ thống kỹ thuật với độ bao phủ tối đa.

Có 4 bước để người kiểm thử tạo được Decision Tables:

Liệt kê tất cả Conditions/Inputs.
Tính số lượng kết hợp có thể (Rules).
Đặt tất cả các kết hợp trong bảng.
Giảm thiểu các case kết hợp và quyết định Test Case.

Ví dụ: Tại màn hình Login có 2 field: “User Name” và “Password”. Chỉ login thành công nếu nhập đúng cả 2 field “User Name” và “Password”. Các trường hợp còn lại được hệ thống hiển thị thông báo “Nhập không chính xác. Vui lòng nhập lại”

Áp dụng kỹ thuật Decision Tables, ta xây dựng được bảng kết hợp sau:

(Mỗi giá trị đầu vào sẽ có 2 dạng: T (True - Đúng) và F (Fail - Sai)

Input	Giá trị 1	Giá trị 2	Giá trị 3	Giá trị 4
User Name	T	T	F	F
Password	T	F	T	F
Output	Login thành công	Login không thành công	Login không thành công	Login không thành công

Từ bản kết hợp, các tester phát triển thành các Test Case như sau:

Nhập đúng cả hai field “User Name” và “Password” => Login thành công
Nhập đúng field “User Name”, nhập sai field “Password” => Login không thành công
Nhập sai field “User Name”, nhập đúng field “Password” => Login không thành công
Nhập sai cả hai field “User Name” và “Password” => Login không thành công

4. Đoán lỗi (Error guessing)

Đoán lỗi là kỹ thuật mô tả hành động phỏng đoán lỗi thường gặp của hệ thống dựa trên trực giác và kinh nghiệm của các tester. Người kiểm thử sẽ liệt kê các loại lỗi có thể xảy ra và cho vào Test Case để kiểm tra xác minh vấn đề.

Phương pháp này đặc biệt dựa vào kinh nghiệm và kiến thức của tester. Kỹ thuật đoán lỗi không tuân theo bất kỳ quy tắc cụ thể nào, Test Case có thể được thiết kế tùy thuộc vào nhiều yếu tố như: Đặc trưng hoạt động của phần mềm, lỗi đã xuất hiện ở các dự án tương tự khác…

Các yếu tố mà người kiểm thử hay sử dụng để đoán lỗi:

Trực giác kiểm thử.
Có kiến thức liên quan, hiểu rõ về hệ thống.
Bài học rút ra từ các lần kiểm thử phần mềm trước, các lỗi thường gặp…
Tập trung test theo từng phần, từng chức năng sẽ giúp tester chú trọng và lý giải những vấn đề xảy ra ở vùng nào.

Ví dụ:

Dự đoán trường hợp nhập khoảng trắng vào các field văn bản
Kiểm tra xử lý hệ thống khi click button khi chưa nhập giá trị
Lường trước lỗi xảy ra khi thiết định lại cài đặt của thiết bị kiểm thử

5. Chuyển đổi trạng thái (State Transition)

Chuyển đổi trạng thái được hiểu là kỹ thuật thay đổi điều kiện đầu vào gây ra sự biến đổi trạng trái trong Ứng dụng được kiểm thử (Application under Test - AUT). Các tester thực hiện kỹ thuật này bằng cách nhập các điều kiện đầu vào khác nhau nhưng vẫn tuân theo một trình tự được thiết lập sẵn. Các giá trị kiểm tra đầu vào sẽ bao gồm: Tích cực và tiêu cực để đánh giá hành vi của hệ thống một cách chuẩn xác nhất.

Kỹ thuật chuyển đổi trạng thái nên được sử dụng khi các tester đang kiểm tra ứng dụng cho một tập hợp giới hạn các giá trị đầu vào. Ngoài ra, kỹ thuật này nên được sử dụng khi nhóm tester muốn kiểm tra chuỗi sự kiện xảy ra trong ứng dụng.

Sơ đồ minh họa kỹ thuật chuyển đổi trạng thái.

Ví dụ:

Nếu user nhập mật khẩu hợp lệ trong 3 lần thử bất kỳ đầu tiên, hệ thống xử lý đăng nhập thành công. Nếu user nhập mật khẩu không hợp lệ trong lần thử đầu tiên hoặc lần thứ hai, hệ thống sẽ báo nhập lại mật khẩu. Khi user nhập sai mật khẩu lần thứ 3, hệ thống sẽ không cho nhập lại mật khẩu và tiến hành khóa tài khoản.

Một số Test Case được tạo từ chuỗi sự kiện trên như sau:

a. Nhập sai mật khẩu lần 1 => Hệ thống báo nhập lại mật khẩu

b. Nhập sai mật khẩu lần 2 => Hệ thống báo nhập lại mật khẩu

c. Nhập sai mật khẩu lần 3 => Hệ thống báo khóa tài khoản

d. Nhập sai mật khẩu lần 1, đúng lần 2 => Đăng nhập thành công

e. Nhập sai mật khẩu 2 lần, đúng lần 3 => Đăng nhập thành công

1.1. BACK BOX TEST

1.1.1. Định nghĩa Kiểm tra hộp đen (Black box testing) là một phương pháp kiểm thử phần mềm mà việc kiểm tra các chức năng của một ứng dụng không cần quan tâm vào cấu trúc nội bộ hoặc hoạt động của nó.

1.1.2. Đối tượng được kiểm thử Là thành phần phần mền (TPPM) có thể là 1 hàm chức năng, 1 modul chức năng, 1 phân hệ chức năng...

1.1.3. Phương pháp thử nghiệm: Dựa vào chức năng Kiểm thử hộp đen (Black box test) có thể được áp dụng hầu như đến mọi cấp độ của kiểm thử phần mềm:

Kiểm thử đơn vị (Unit test)
Kiểm thử tích hợp (Intergration test)
Kiểm thử hệ thống (System test)
Kiểm thử chấp nhận (Acceptance test).

Tuy nhiên, Black box test được sử dụng thích hợp nhất trong kiểm thử hệ thống (System test) và Kiểm thử chấp nhận (Acceptance test)

1.1.4. Đặc điểm

Là chiến lược kiểm thử TPPM dựa vào thông tin duy nhất là các đặc tả về yêu cầu chức năng của TPPM tương ứng.
Người kiểm thử không cần thiết phải có kiến thức về việc mã hoá, cấu trúc bên trong của TPPM, cũng như không yêu cầu phải biết lâp trình phần mềm.
Việc kiểm thử được tiến hành dựa vào việc kiểm thử TPPM làm được gì, có phù hợp với yêu cầu của người dùng hay không. Các tester nhập số liệu vào phần mềm và chỉ cần xem kết quả của phần mềm và các mục tiêu kiểm tra.
Mức test này thường yêu cầu các tester phải viết test case đầy đủ trước khi test; khi test, đơn giản chỉ cần thực hiện theo các bước mô tả trong test case thao tác và nhập data vào, sau đó xem kết quả trả về hoặc hành vi của phần mềm, rồi so sánh với kết quả mong đọi được viết trong testcase

1.1.5. Tạo test case và Thực hiện test case

Khi viết test case: Dựa vào yêu cầu và giao diện bên ngoài của chương trình (Không can thiệp vào bên trong code của chương trình)
Khi thực hiện test: Thực hiện trên giao diện của chương trình (yêu cầu chương trình phải chạy được mới test được, không can thiệp vào code)

1.2. WHITE BOX TEST

1.2.1. Định nghĩa Kiểm thử hộp trắng (While box test) là phương pháp thử nghiệm phần mềm, trong đó các thiết kế, cấu trúc giải thuật bên trong, và việc thực hiện các công việc đều được biết đến

1.2.2. Đối tượng kiểm thử Là 1 thành phần của phần mềm (1 chức năng, 1 module chức năng, 1 phân hệ chức năng....)

1.2.3. Phương pháp thử nghiệm: Dựa vào thuật giải Kiểm thử hộp trắng dựa vào thuật giải cụ thể, vào cấu trúc dữ liệu bên trong của ₫ơn vị phần mềm cần kiểm thử ₫ể xác ₫ịnh ₫ơn vị phần mềm ₫ó có thực hiện ₫úng không.

Với những TPPM quá lớn sẽ tốn rất nhiều thời gian và công sức để kiểm thử nếu như dùng kiểm thử tích hợp (Integration test) hay kiểm thử chức năng (Functional test)).
Kỹ thuật white box test thích hợp dùng để kiểm thử đơn vị (Unit test)

1.2.4. Đặc điểm

Là chiến lược kiểm thử TPPM dựa vào giải thuật, cấu trúc bên trong chức năng của TPPM tương ứng.
Người kiểm thử phải có kiến thức nhất định về việc mã hoá, cấu trúc bên trong của chức năng, biết lâp trình phần mềm.
Việc kiểm thử được tiến hành dựa vào việc kiểm xem giải thuật, mã lệnh đã làm có đúng không.
Mức test này thường yêu cầu các tester phải viết test case đầy đủ các nhánh trong code; khi test, sẽ set điều kiện và data để chạy vào đủ tất cả các nhánh trong giải thuật, đảm bảo thực hiện đầy đủ.

1.2.5. Tạo testcase và thực hiện test

Khi viết test case: Dựa vào yêu cầu và nội dung Source Code (can thiệp vào bên trong Code của chương trình)
Khi thực hiện test: Thực thi test trong code (không cần thực thi chương trình, vì thực hiện test white box sẽ sử dụng framework nào đó hỗ trợ (Ví dụ như test kiểu debug)
Trong kiểm tra này, đòi hỏi người tester phải có kiến thức và kỹ năng nhất định về ngôn ngữ lập trình được dùng, hiểu thuật giải trong thành phần phần mềm, để có thể hiểu được chi tiết về đoạn code cần kiểm thử .

1.3. GRAY BOX TEST

Ngoài 2 kỹ thuật đã được nhắc đến: Black box test và white box test, thì có 1 kỹ thuật, Gray box test là sự kết hợp giữa black box test và white box test. 1.3.1. Định nghĩa Gray Box Testing là một phương pháp kiểm thử phần mềm được kết hợp giữa Phương pháp Kiểm thử Black Box (hộp đen) và White Box (hộp trắng). Trong Kiểm thử Hộp xám, cấu trúc bên trong sản phẩm chỉ được biết một phần

1.3.2. Phương pháp thử nghiệm: Dựa vào giải thuật và chức năng

Gray box test có thể được sử dụng ở nhiều mức kiểm thử khác nhau. Tuy nhiên, chủ yếu được ứng dụng trong Kiểm thử tích hợp (Intergration test)

1.3.3. Tạo testcase và thực hiện test

Khi viết test case: Dựa vào yêu cầu và nội dung Source Code (can thiệp vào bên trong Code của chương trình)
Khi thực hiện test: Thực hiện trên giao diện của chương trình (yêu cầu chương trình phải chạy được mới test được, không can thiệp vào code)

2. ƯU ĐIỂM, NHƯỢC ĐIỂM CỦA BLACK BOX TEST VÀ WHITE BOX TEST

Nội dung	Black box test	White box test
1. Ưu điểm	- Thích hợp trong việc kiểm tra từng phân đoạn lớn các mã lệnh, chức năng lớn - Người thử nghiệm không cần hiểu biết về mã lệnh được viết trong chương trình - Tách biệt giữa quan điểm của người sử dụng và người phát triển phần mềm	- Thích hợp trong việc tìm kiếm lỗi và các vấn đề trong mã lệnh - Biết được yêu cầu bên trong của phần mềm, kiểm tra sẽ sát hơn - Cho phép tìm kiếm các lỗi ẩn bên trong - Các lập trình viên có thể tự kiểm tra - Giúp tối ưu việc mã hoá - Do yêu cầu kiến thức cấu trúc bên trong của phần mềm, nên việc kiểm soát lỗi tối đa nhất
2. Nhược điểm	- Độ bao phủ hạn chế vì chỉ có một phần nhỏ trong số các kịch bản thử nghiệm được thực hiện - Kiểm tra không hiệu quả do người thử nghiệm không hiểu biết gì về cấu trúc bên trong phần mềm. - Tester có hạn chế về hiểu biết về ứng dụng	- Không thể tìm thấy tính năng chưa thực hiện hoặc bỏ sót - Đòi hỏi hiểu sâu về cấu trúc bên trong của phần mềm được thử nghiệm - Yêu cầu truy xuất mã lệnh bên trong chương trình

3. SỰ KHÁC NHAU GIỮA BLACK BOX TEST VÀ WHITE BOX TEST

Tiêu chuẩn	Black box test	White box test
1. Định nghĩa	- Kiểm tra hộp đen là phương pháp thử nghiệm phần mềm được sử dụng để kiểm tra các phần mềm mà không quan tâm đến cấu trúc bên trong của chương trình.	- Kiểm tra hộp trắng là phương pháp kiểm thử phần mềm, sử dụng để kiểm tra phần mềm mà yêu cầu phải biết cấu trúc bên trong của chương trình.
2. Trách nhiệm	- Thử nghiệm được thực hiện bên ngoài, không liên quan đến nhà phát triển phần mềm.	- Thông thường, các thử nghiệm được thực hiện bởi nhà phát triển phần mềm.
3. Cấp độ test sử dụng	- Thử nghiệm áp dụng ở cấp độ cao như: kiểm tra hệ thống (System test), kiểm tra chấp nhận (Acceptance test)	- Thử nghiệm được áp dụng ở mức độ thấp hơn như thử nghiệm đơn vị (Unit Test), thử nghiệm hội nhập (Integration test)
4. Biết lập trình	- Không yêu cầu hiểu biết về Lập trình	- Yêu cầu hiểu biết nhất định về lập trình.
5. Biết việc thực hiện chương trình	- Không yêu cầu hiểu về cấu trúc bên trong chức năng, và không cẩn hiểu làm thế nào để có được chức năng đó	- Yêu cầu hiểu cấu trúc bên trong chức năng được thực hiện như nào.
6. Cơ sở tạo Test Cases	- Kiểm tra hộp đen được bắt đầu dựa trên tài liệu yêu cầu kỹ thuật	- Kiểm tra hộp trắng được bắt đầu dựa trên các tài liệu thiết kế chi tiết

4. SƠ LƯỢC VỀ CÁC KỸ THUẬT KIỂM TRA HỘP ĐEN

4.1. Quy trình kiểm thử hộp đen

Với đặc điểm của Kiểm thử hộp đen là chỉ dựa vào chức năng của phần mềm, do đó quy trình kiểm thử qua các bước chính như sau:

Phân tích đặc tả về các yêu cầu chức năng mà TPPM cần thực hiện
Dùng 1 kỹ thuật đinh nghĩa các testcase xác định để định nghĩa các testcase, gồm 3 thông tin sau: + Giá trị dữ liệu để TPPM xử lý (hoặc hợp lệ, hoặc không hợp lệ) + Trạng thái của TPPM cần có để thực hiện testcase + Giá trị dữ liệu xuất mà TPPM phải tạo được
Kiểm thử các testcase đã định nghĩa
So sánh kết quả thu được với kết quả kỳ vọng trong từ testcase, từ đó lập báo cáo về kết quả kiểm thử

4.2. Các kỹ thuật phổ biến trong kiểm thử hộp đen

Kỹ thuật phân lớp tương ₫ương (Equivalence Class Partitioning).
Kỹ thuật phân tích các giá trị biên (Boundary value analysis).
Kỹ thuật dùng các bảng quyết ₫ịnh (Decision Tables)
Kỹ thuật kiểm thử các bộ n thần kỳ (Pairwise)
Kỹ thuật dùng bảng chuyển trạng thái (State Transition)
Kỹ thật phân tích vùng miền (domain analysis)
Kỹ thuật dựa trên ₫ặc tả Use Case (Use case)
Kỹ thuật dùng lược ₫ồ quan hệ nhân quả (Cause-Effect Diagram) Trong bài viết này tôi chỉ nêu sơ lược về một số kỹ thuật kiểm thử trên. Chi tiết sẽ được cụ thể trong các bài viết sau

4.2.1. Kỹ thuật phân lớp tương ₫ương

Ý tưởng của kỹ thuật này là cố gắng phân các testcase ra thành nhiều nhóm khác nhau : các testcase trong mỗi nhóm xác định TPPM thực hiện cùng 1 hành vi. Mỗi nhóm testcase thỏa mãn tiêu chuẩn trên ₫ược gọi là 1 lớp tương ₫ương, ta chỉ cần xác ₫ịnh 1 testcase ₫ại diện cho nhóm và dùng testcase này ₫ể kiểm thử TPPM. Như vậy ta ₫ã giảm rất nhiều testcase cần ₫ịnh nghĩa và kiểm thử, nhưng chất lượng kiểm thử không bị giảm sút bao nhiêu so với vét cạn. Điều này là dựa vào kỳ vọng: - Nếu 1 testcase trong lớp tương ₫ương nào ₫ó gây lỗi TPPM thì các testcase trong lớp này cũng sẽ gây lỗi như vậy.

Nếu 1 testcase trong lớp tương ₫ương nào ₫ó không gây lỗi TPPM thì các testcase trong lớp này cũng sẽ không gây lỗi.
Với các giá trị không hợp lệ: Ta nên tạo 1 lớp tương đương đại diện các testcase chứa các giá trị không hợp lệ theo đặc tả để xem TPPM phản ứng như nào với những trường hợp này

4.2.2. Kỹ thuật phân tích các giá trị ở biên

Khi tạo testcase, ta chỉ dùng Kỹ thuật phân lớp tương đương thì hẳn là chưa đủ. Kinh nghiệm cho thấy rằng lỗi thường nằm ở biên (₫ầu hay cuối) của 1 khoảng liên tục nào ₫ó (lớp tương ₫ương). Do ₫ó với Kỹ thuật phân tích giá trị biên tập trung tạo các testcase ứng với những giá trị ở biên này. Nên thông thường là có sự kết hợp cả 2 kỹ thuật: Phân lớp tương đương và Phân tích giá trị biên để viết các testcase. Ý tưởng của kỹ thuật là chỉ ₫ịnh nghĩa các testcase ứng với các giá trị ngay trên biên hay lân cận biên của từng lớp tương ₫ương. Do ₫ó kỹ thuật này chỉ thích hợp với các lớp tương ₫ương xác ₫ịnh bởi các giá trị liên tục (số nguyên, số thực), chứ nó không thích hợp với lớp tương ₫ương ₫ược xác ₫ịnh bởi các giá trị liệt kê mà không có mối quan hệ lẫn nhau. Quy trình cụ thể ₫ể thực hiện kiểm thử dựa trên các giá trị ở biên: - Nhận dạng các lớp tương ₫ương dựa trên ₫ặc tả về yêu cầu chức năng của TPPM.

Nhận dạng 2 biên của mỗi lớp tương ₫ương. Tạo các testcase cho mỗi biên của mỗi lớp tương ₫ương :
1 testcase tại giá trị biên.
1 testcase ngay dưới biên.
1 testcase ngay trên biên. Ý nghĩa ngay trên và ngay dưới biên phụ thuộc vào ₫ơn vị ₫o lường cụ thể : Số nguyên , số thập phân...

4.2.3. Kỹ thuật dùng bảng quyết ₫ịnh (decision table)

Bảng quyết ₫ịnh là 1 công cụ rất hữu ích ₫ể ₫ặc tả các yêu cầu phần mềm hoặc ₫ể ₫ặc tả bảng thiết kế hệ thống phần mềm. Nó miêu tả các qui tắc nghiệp vụ phức tạp mà phần mềm phải thực hiện dưới dạng dễ ₫ọc và dễ kiểm soát :

	Rule 1	Rule 2	...	Rule p
Conditions
Conditions-1
...
Conditions-m
Actions
Actions-1
...
Actions-n

Trong đó:

Condition-1 tới Condition-m miêu tả m ₫iều kiện dữ liệu nhập khác nhau có thể có.
Action-1 tới Action-n miêu tả n hoạt ₫ộng khác nhau mà hệ thống có thể thực hiện phụ thuộc vào tổ hợp ₫iều kiện dữ liệu nhập nào.
Mỗi cột miêu tả 1 luật cụ thể : tổ hợp ₫iều kiện nhập cụ thể và các hoạt ₫ộng cụ thể cần thực hiện. Lưu ý các hoạt ₫ộng cần thực hiện không phụ thuộc vào thứ tự các ₫iều kiện nhập, nó chỉ phụ thuộc vào giá trị các ₫iều kiện nhập. Tương tự, các hoạt ₫ộng cần thực hiện không phụ thuộc vào trạng thái hiện hành của TPPM, chúng cũng không phụ thuộc vào các ₫iều kiện nhập ₫ã có trước ₫ó.

Kết luận

Việc đảm bảo bộ Test Case luôn vừa có độ bao phủ tốt, vừa được tối ưu để tiết kiệm thời gian và chi phí luôn là một thách thức lớn đối với bất kỳ Tester nào. Chính vì thế việc nắm rõ được các kỹ thuật kiểm thử là một điều quan trọng thiết yếu đối với các Tester. Hi vọng với bài viết trên, ITNavi đã giúp các bạn nắm được 5 kỹ thuật kiểm thử chính: Phân tích giá trị biên, phân vùng tương đương, bảng kết hợp, chuyển đổi trạng thái và đoán lỗi. Vận dụng tốt 5 kỹ thuật kiểm thử trên sẽ giúp các tester tạo được bộ Test Case chất lượng cao.