TRƯỜNG ĐẠI HỌC CÔNG NGHIỆP TP.HCM MÔN HỌC CÔNG NGHỆ PHẦN MỀM. Chương8: Kiểm thử phần mềm

Hướng dẫn thiết kế Test case Kiểm tra cẩn thận những kết quả từ test case trước đó  Test case phải viết cho giá trị hợp lệ valid và không hợp lệ cũng như điều kiện, input, kết quả mong

Nội dung

1 Kiểm thử đơn vị (unit test)

2 Kiểm thử tích hợp (intergration test)

3 Kiểm thử thẩm tra – chức năng (validation test)

4 Kiểm thử hệ thống (system test)

5 Một số loại kiểm thử khác

1 Thiết kế test case

Kiểm thử hộp trắng (white-box)

Nội dung

3 Kiểm thử hộp đen?

4 Kiểm thử giá trị biên (Boundary Value Analysis)

5 Kiểm thử lớp tương đương (Equivalence Class

Các hoạt động

1 Kiểm thử phần mềm

Testing is the process of exercising a program with the specific intent of finding errors prior to (trước khi) delivery to the end user.

What is

Kiểm thử (Testing):

Bằng kinh nghiệm

 find errors in software (Myers, 1979)

 establish quality of software (Hetzel, 1988)

Một test thành công:

 finds at least one error

 passes (software works correctly)

test-to-fail

test-to-pass

 Kiểm chứng và thẩm định bao gồm kiểm thử

phần mềm

 Kiểm chứng (Verification): “Chúng ta đang xây

dựng sản phẩm theo đúng cách"

 Phần mềm phải phù hợp với đặc tả của nó

 Thẩm định (Validation): “Chúng ta đang xây dựng sản phẩm đúng"

 Phần mềm phải thực hiện những gì người dùng thật sự cầnKiểm chứng và thẩm định (V&V) ???

Kiểm chứng và thẩm định

Ai kiểm thử phần mềm?

developer independent tester

Understands the system but, will test "gently"

Must learn about the system, but, will attempt to break it

2 Chiến lược kiểm thử (Testing Strategy)

1. Kiểm thử đơn vị (unit test)

2. Kiểm thử tích hợp (intergration test)

3. Kiểm thử hệ thống (system test)

4. Các thuật ngữ kiểm thử

3 mức kiểm thử

2.1 Kiểm thử đơn vị

module

to be tested

test cases

results

software engineer

Các mục cần kiểm tra

interface local data structures boundary conditions independent paths error handling paths

module

to be tested

2.2 kiểm thử tích hợp

Chọn lựa chiến luợc:

• Hướng tiếp cận “big bang”

• Chiến lược xây dựng gia tăng

Kiểm thử top down

Module

stub stub

driver

interface local data structures boundary conditions independent paths error handling paths

Driver

Tích hợp Top Down

top module is tested with stubs (nhánh)

stubs are replaced one at

a time, "depth first"

as new modules are integrated, some subset of tests is re-run

A

B

C

Sử dụng stub

 Stub: calender() có gọi đến module tính ngày

calc_day() chưa được phát triển

String calc_day (Date d)

{

return "Sunday";

}

 Driver là một chương trình chính có nhiệm vụ nhận

dữ liệu kiểm thử, chuyển dữ liệu đó xuống cho các module bên dười rồi nhận kết quả và xuất ra

2.3 Kiểm thử hệ thống (System testing)…

…Kiểm thử hệ thống.

2.4 Các thuật ngữ kiểm thử

 Kiểm thử tính năng

 Kiểm thử chấp nhận, Kiểm thử thẩm tra: Kiểm thử Anpha,

Beta

 Kiểm thử hồi quy (regression)

 Kiểm thử kiến trúc, môi trường và ứng dụng đặc trưng

 Mô hình chữ V

 Kiểm thử Smoke

 Kiểm thử so sánh

 Kiểm thử phục hồi (Recovery testing)

 Kiểm thử an ninh (Security testing

 Kiểm thử áp lực (Stress testing)…

Kiểm thử tính năng

 Dùng nhóm kiểm thử độc lập

 Biết những hoạt động mong đợi và output

 Kiểm thử cả valid và invalid

 Không được biến đổi hệ thống

 Có một tiêu chuẩn dừng

Kiểm thử chấp nhận (Acceptance testing)

hay Beta.

Kiểm thử thẩm tra

 Được tiến hành ngay tại nơi sản xuất phần mềm

 Nhà phát triển phần mềm sẽ quan sát người sử dụng dùng sản phẩm và ghi nhận lại những lỗi phát sinh để sửa chữa

 Phần mềm được kiểm tra bên ngoài phạm vi của đơn vị

sản xuất

 Khách hành trực tiếp sử dụng và ghi nhận lỗi để báo lại

cho nhà phát triển sửa chữa

Kiểm thử hồi quy (regression)

1 Việc kết hợp các module lại với nhau có thể ảnh hưởng

đến vòng lặp điều khiển, cấu trúc dữ liệu hay I/O chia sẻ trong một số module

2 Điều đó làm lộ ra một số lỗi không thể phát hiện được khi tiến hành kiểm nghiệm theo đơn vị

3 Kiểm nghiệm hồi quy có thể được tiến hành thủ công

bằng cách thực hiện lại các test-case đã tạo ra Hoặc có thể dùng một công cụ capture-playback để thực hiện tự

động

Kiểm thử kiến trúc, môi trường

 Kiểm thử cơ sở dữ liệu

 Kiểm thử truyền thông mạng

 Kiểm thử tài liệu và trợ giúp

 Kiểm thử hệ thống thời gian thực

 Kiểm thử công việc (task)

Kiểm thử giao diện

Phương pháp kiểm thử

Methods Strategies

white-box methods

black-box methods

2 Kiểm thử hộp trắng (White Box)

1. Thiết kế test case

Một test “tốt”?

 Có khả năng tìm lỗi cao

 Không dư thừa và tốn quá nhiều công sức

để thực hiện

 Phải tinh chế để là test tốt nhất

 Không quá đơn giản và quá phức tạp

3.1 Thiết kế Test Case

"Bugs lurk in corners and congregate at

boundaries "

Boris Beizer

Mục tiêu Tiêu chuẩn

Khám phá lỗi Toàn diện

Test case

Hướng dẫn thiết kế Test case

 Kiểm tra cẩn thận những kết quả từ test case trước đó

 Test case phải viết cho giá trị hợp lệ (valid) và không hợp lệ cũng như điều kiện, input, kết quả mong đợi, không mong đợi (tìm thấy và không tìm thấy…)

 Phải kiểm thử từ nhỏ tới lớn, không thể kiểm thử tất cả các trường hợp

 Khi một phần có nhiều lỗi được tìm nó có khả năng có nhiều lỗi hơn

Ví dụ về định hướng kiểm thử

 Lựa chọn các đầu vào sao cho hệ thống có thể đưa

ra tất cả các thông báo lỗi.

 Thiết kế đầu vào sao cho vùng nhớ đệm bị tràn.

 Lặp lại nhiều lần cùng một đầu vào hoặc một chuỗi các đầu vào.

 Ép hệ thống tạo ra những kết quả không hợp lệ.

 Buộc cho các kết quả tính phải quá lớn hoặc quá nhỏ.

Kiểm thử vét cạn (Exhaustive)

loop < 20 X

2.2 Kiểm thử White-Box

our goal is to ensure that all statements and conditions have been executed at least once

Kiểm thử dựa vào cấu trúc?

trình.

2.3 Kiểm thử đường cơ bản

Path 1: 1,2,3,6,7,8 Path 2: 1,2,3,5,7,8 Path 3: 1,2,4,7,8 Path 4: 1,2,4,7,2,4, 7,8

1

2

3 4

7 8

Biểu đồ luồng cơ bản

Kiểm thử các đường cơ bản

 Kiểm thử các đường cơ bản là một trong những phương

cách kiểm nghiệm white-box

 Bảo đảm số phép thử là ít nhất đủ để phát hiện các lỗi

 Tất cả các đường cơ bản được thử qua ít nhất một lần

 Thử các điều kiện rẽ nhánh ở cả 2 nhánh true và false

 Thử qua vòng lặp tại biên cũng như bên trong

 Thử qua cấu trúc dữ liệu để đảm bảo tính toàn vẹn của nó

 Kiểm thử đường cơ bản áp dụng cho những module có

tính nghiêm ngặt

Đưa ra đường cơ bản

Since V(G) = 4,

Path 1: 1,2,3,6,7,8 Path 2: 1,2,3,5,7,8 Path 3: 1,2,4,7,8 Path 4: 1,2,4,7,2,4, 7,8

1

2

3 4

7 8

Quy trình xác định các đường cơ bản

1 Xác định đường cơ bản, đường này nên là đường thi hành phổ

biến nhất.

2 Để chọn đường thứ 2, thay đổi cung xuất của nút quyết định

đầu tiên và cố gắng giữ lại maximum phần còn lại.

3 Để chọn đường thứ 3, dùng đường cơ bản nhưng thay đổi

cung xuất của nút quyết định thứ 2 và cố gắng giữ lại

maximum phần còn lại.

4 Tiếp tục thay đổi cung xuất cho từng nút quyết định trên đường

cơ bản để xác định đường thứ 4, 5, cho đến khi không còn

nút quyết định nào trong đường cơ bản nữa

12

Sample Test Cases

Assuming Integer Greater than 0 and less than or equal to 200

Test Case X Y Z Expected Output

2.4 Kiểm thử cấu trúc lặp (Loop)

Nested Loops

Concatenated

Loops Unstructured Simple

loop

Vòng lặp lồng nhau

Nested

Loops

1 Bắt đầu ở vòng lặp trong cùng, thiết lập tất

cả các vòng lặp ngoài có giá trị tham số lặp nhỏ nhất (giá trị bộ đếm)

2 Test vòng lặp trong cùng (test vòng lặp đơn)

3 Di chuyển ra vòng lặp ngoài rồi thực hiện với bước 2 với giá trị của vòng lặp bên trong ở giá trị tùy ý

4 Tiếp tục cho hết vòng lặp

Vòng lặp nối tiếp

• Nếu phụ thuộc, chẳng hạn giá trị biến

đếm của vòng lặp 1 dùng để khởi động vòng lặp 2 thì xem như 2 vòng lặp lồng nhau

2.5 Phủ trong kiểm thử

 Phủ cấp 0: kiểm thử những gì có thể kiểm thử được, phần

còn lại để người dùng phát hiện và báo lại sau Đây là mức

độ kiểm thử không thực sự có trách nhiệm

 Phủ cấp 1: kiểm thử sao cho mỗi lệnh được thực thi ít nhất

Phủ cấp 2

 Phủ cấp 2: kiểm thử sao cho mỗi điểm quyết định đều được

thực hiện ít nhất 1 lần cho trường hợp TRUE lẫn FALSE Ta gọi mức kiểm thử này là phủ các nhánh (Branch coverage) Phủ các nhánh đảm bảo phủ các lệnh

foo(0, 0, 0, 0) return 0

Test Case 2 foo(1, 1, 1, 1) return 1

6 ((a==b) OR ((c ==

d) AND bug(a) ))

Test Case 2 foo(1, 1, 1, 1)

Test Case 3 foo(1, 2, 1, 2)

Phủ cấp 3

 Phủ cấp 3: kiểm thử sao cho mỗi điều kiện luận lý con

(subcondition) của từng điểm quyết định đều được thực hiện ít nhất 1 lần cho trường hợp TRUE lẫn FALSE Ta gọi mức kiểm thử này là phủ các điều kiện con (subcondition coverage) Phủ các điều kiện con chưa chắc đảm bảo phủ các nhánh

foo(0, 0, 0, 0) return 0

Test Case 2 foo(1, 1, 1, 1) return 1

foo(1, 1, 1, 1) return value 0

Test Case 3 foo(1, 2, 1, 2) division by zero!

foo(1, 2, 1, 2)

Phủ cấp 4

 Phủ cấp 4: kiểm thử sao cho mỗi điều kiện luận lý

con (subcondition) của từng điểm quyết định đều

được thực hiện ít nhất 1 lần cho trường hợp TRUE lẫn FALSE & điểm quyết định cũng được kiểm thử cho cả 2 nhánh Ta gọi mức kiểm thử này là phủ

các nhánh & điều kiện con (branch & subcondition coverage)

2.6 Kiểm thử luồng dữ liệu

3 Kiểm thử Black-Box

Kiểm thử Black-Box

requirements

output

Kiểm thử Black-Box

Kiểm thử Black-Box

 Hệ thống xem như một hộp kín không cần biết bên trong chỉ cần tạo ra output đúng với chức năng từ

input

 Cần quan tâm về dữ liệu của test case

 Những lớp input nào sẽ tạo ra những test case tốt?

 Hệ thống thường nhạy cảm với những giá trị input xác định nào?

 Biên của những lớp dữ liệu được cô lập như thế nào?

Tỷ lệ và độ lớn của dữ liệu mà hệ thống có thể chịu đựng?

3.2 Kiểm thử giá trị biên

 Boundary Value Testing

 {-1, 0, 1}, {15, 16, 17}, {17, 18, 19}, {54, 55, 56}, and {98, 99, 100}.

Person’s Age

Rule

16 – 18 Can hire on a part-time basis only

Xác định giá trị biên

Monthly Income Number of Dwellings Result Description

$1,000 1 Valid Min income, min dwellings

$83,333 1 Valid Max income, min dwellings

$1,000 5 Valid Min income, max dwellings

$83,333 5 Valid Max income, max dwellings

$1,000 0 Invalid Min income, below min dwellings

$1,000 6 Invalid Min income, above max dwellings

$83,333 0 Invalid Max income, below min dwellings

$83,333 6 Invalid Max income, above max dwellings

$999 1 Invalid Below min income, min dwellings

$83,334 1 Invalid Above max income, min dwellings

TestCase

Kiểm thử lớp tương đương

Equivalence partitions

• Phân hoạch tương đương (Equivalence partitions)

Nhằm giảm các test case

Ví dụ

 Input trong khoảng [a b]

 Chọn một mẫu nhỏ hơn a một mẫu giữa a và b và một mẫu lớn hơn b

 Input là một tập hợp V

 Chọn một mẫu trong V và một mẫu ngoài V

Cách phân hoạch theo input

 Nếu input là một dãy giá trị, chia thành 1 lớp valid và

Phân hoạch tương đương

Testcase cho tìm kiếm nhị phân

Testcase

3.4 Kiểm thử dựa vào bảng quyết định

Vd: Chương trình xác định tam giác

3.5 Kiểm thử giá trị đặc biệt (Ad Hoc Testing)

năng để đưa ra test case.

Loại kiểm thử và kỹ thuật áp dụng

Unit Testing White Box Integration Testing White Box

Black Box

4 Các vấn đề khác

1. Kiểm thử hướng đối tượng (OOT)

2. Tự động kiểm thử

3. Gỡ lỗi (Debugging)

4.1 Kiểm thử hướng đối tượng

 Bắt đầu bằng cách đánh giá sự đúng đắn và toàn vẹn của mô hình OOA và OOD

 Những khác biệt

 Khái niệm lớp ‘unit’

 Việc tích hợp tập trung vào tích hợp các lớp và dựa vào kịch bản

 Việc thẩm định sử dụng phương pháp blackbox

 Thiết kế test case theo phương pháp cũ nhưng phải bao gồm thêm những đặc trưng mới của hướng đối tượng

 Kiểm thử dựa theo mô hình CRC (lớp-nhiệm vụ-công tác)

Chiến lược trong OOT

 Kiểm thử lớp (unit testing)

 use-based testing (kiểm thử dựa vào chức năng)

— dựa vào chức năng (use case)

 cluster testing (kiểm thử dựa vào cộng tác) —

Các loại OOT …

 Thiết kế test case dựa vào dự đoán những lỗi có khả năng xảy ra

the Class Hierarchy)

Design)

 Dựa vào những gì người dùng làm (use-case)

 Kiểm thử tương tác (Inter-class)

Kiểm thử dịch chuyển trạng thái

4.2 Tự động kiểm thử

hệ thống kiểm thử cung cấp những công cụ cho

phép giảm thời gian và chi phí

 Có thể dùng kịch bản để tạo dữ liệu test

 Output có thể dùng để so sánh một cách thủ công Có thể phát triển những hệ thống so sánh file

4.3 Gỡ lỗi (Debugging)

Quy trình gỡ lỗi

test cases

results

suspected causes

regression tests

new test cases

Dấu hiệu và nguyên nhân

Nguyên nhân có thể là do lỗi của

hệ thống hay của bộ biên dịch

Nguyên nhân có thể là những giả định

mà mọi người tin tưởng Dấu hiệu có thể lúc có lúc không

Kỹ thuật gỡ lỗi

Brute force Backtracking

Loại trừ nguyên nhân (cause elimination)

Kiểm thử

BRUTE FORCE

 Áp dụng phương pháp này khi tất cả các phương pháp

khác đều thất bại

 Là phương pháp phổ biến nhất nhưng lại ít hiệu quả

nhất cho việc phát hiện nguyên nhân gây lỗi phần mềm

 Triết lý của phương pháp này là: “Hãy để máy tính tìm ra lỗi”

 Cách thực hiện:

 Lấy dữ liệu trong bộ nhớ để xem xét

 Dùng run-time trace để tìm lỗi

LẦN VẾT NGƯỢC (Backtracking)

 Cách thực hiện: bắt đầu tại dòng mã nguồn có triệu

chứng lỗi thực hiện lần ngược trở lại từng dòng mã nguồn cho đến khi tìm thấy dòng gây ra lỗi

 Là một phương pháp gỡ lỗi khá phổ biến có thể dùng

thành công trong các chương trình nhỏ nhưng khó áp

LOẠI TRỪ NGUYÊN NHÂN

 Cách thực hiện:

 Khi một lỗi được phát hiện, cố gắng đưa ra một danh sách các nguyên nhân có thể gây ra lỗi (các giả thiết)

 Danh sách này được xem xét lại để loại bỏ dần các

nguyên nhân không đúng cho đến khi tìm thấy một nguyên nhân khả nghi nhất (dùng dữ liệu liên quan)

 Khi đó dữ liệu kiểm thử sẽ được tinh chế lại để tiếp tục tìm lỗi

Gỡ lỗi bằng kiểm thử

 Dùng Test case.

 Dùng cùng với phương pháp quy nạp.

Các lưu ý

Đừng vội vã hãy suy xét đến những dấu hiệu

mà bạn thấy Dùng công cụ hỗ trợ (dynamic debugger…)

Khi bế tắc nên nhờ người khác trợ giúp

Khi gỡ lỗi cần phải thực hiện kiểm thử hồi qui (regression tests)

1

2

3

4