Kiểm thử chức năng- Kiểm thử phần mềm pot

Kiểm thử hệ thống và kiểm thử ngẫu nhiên  Chọn các yếu tố đầu vào có thể thống nhất  Tránh thiên vị thiết kế  Một vấn đề thực tế: Các nhà thiết kế kiểm thử cũng có thể tạo ra cùng

Kiểm thử chức năng

Nội dung

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

 Kiểm thử phân hoạch tương đương

 Kỹ thuật đồ thị nhân quả - bảng quyết định

Kiểm thử chức năng

Kiểm thử chức năng

từ các đặc tả chương trình

được sử dụng để thiết kế trường hợp kiểm thử, không phải để kiểm thử như thế nào

 Kiểm thử dựa trên đặc tả (từ đặc tả)

 kiểm tra hộp đen (không có mã nguồn)

dự định

Kiểm thử hệ thống và kiểm thử

ngẫu nhiên

 Chọn các yếu tố đầu vào có thể thống nhất

 Tránh thiên vị thiết kế

 Một vấn đề thực tế: Các nhà thiết kế kiểm thử cũng có thể tạo

ra cùng những lỗi logic và giả thiết tồi giống nhà thiết kế chương trình (đặc biệt là nếu họ là cùng một người)

 Nhưng đối xử với tất cả các đầu vào là có giá trị như nhau

 Có hệ thống (không đồng đều):

 Cố gắng chọn đầu vào là có giá trị đặc biệt

 Thông thường bằng việc lựa chọn đại diện của các lớp mà ứng dụng gặp lỗi thường xuyên hoặc không phải tất cả trường hợp

 Kiểm thử chức năng là kiểm thử có hệ thống thử nghiệm

Tại sao không ngẫu nhiên?

 Sự phân bố lỗi không đều

trình bậc hai

 Logic thực hiện không đầy đủ: Chương trình không hợp lí trong các trường hợp trong đó b2 - 4ac = 0 và a

= 0

Systematic Partition Testing

Failure (valuable test case)

No failure

Thất bại là thưa thớt trong không gian đầu vào có thể

nhưng dày đặc trong một số bộ phận của không gian

Kiểm thử chức năng: khai thác

các đặc tả

 Kiểm thử chức năng sử dụng các đặc tả (hình thức hoặc không hình thức) để phân vùng

không gian đầu vào

 Ví dụ, đặc tả của chương trình "gốc" gợi ý phân chia giữa các trường hợp với không, một, và hai nghiệm thực

 Kiểm tra từng trường hợp, và ranh giới giữa các

trường hợp

 Không đảm bảo, nhưng kinh nghiệm cho thấy

Tại sao kiểm thử chức năng?

Thiết kế kiểm thử chức năng

sớm

 Mã nguồn chương trình là không cần thiết

 Chỉ có một mô tả về hành vi được dự kiến là cần thiết

 Thậm chí các đặc tả không đầy đủ và chính thức có thể được sử dụng

 Mặc dù chính xác, đặc tả đầy đủ dẫn đến bộ thử tốt hơn

 Thiết kế kiểm thử chức năng sớm có những lợi ích phụ

 Thường cho thấy sự mơ hồ và mâu thuẫn trong đặc tả

 Hữu ích cho việc đánh giá khả năng kiểm thử

 Và cải thiện tiến độ Và ngân sách kiểm thử bằng cách cải

thiện đặc tả

 Giải thích hữu ích của đặc tả

 hoặc trong trường hợp cực đoan (như trong XP), trường hợp kiểm thử chính là đặc tả

Chức năng và cấu trúc: Các

lớp lỗi

cấu trúc) là hiệu quả nhất cho các lớp lỗi

khác nhau

kiếm các lỗi thiết kế

kiếm lỗi lập trình

Kiểm thử chức năng và cấu

trúc: các mức

 Kiểm thử chức năng được áp dụng tại tất cả các mức độ:

 Đơn vị (từ đặc tả giao diện module)

 Tích hợp (từ API hoặc đặc tả hệ thống con)

 Hệ thống (từ đặc tả yêu cầu hệ thống)

 Hồi quy ( từ yêu cầu hệ thống + lịch sử lỗi)

 Kiểm thử cấu trúc (dựa trên mã) áp dụng cho

phần tương đối nhỏ của hệ thống:

Đơn vị

 Đại diện các giá trị của mỗi đầu vào,

 hoặc Hành vi đại diện của một mô hình

 Biến đổi đầu vào / đầu ra thường đơn giản không mô tả một

hệ thống Chúng ta sử dụng các mô hình trong đặc tả chương trình, trong thiết kế chương trình, và thiết kế kiểm thử

 3 Hình thành đặc tả kiểm thử

 Thông thường: kết hợp các giá trị đầu vào, hoặc hành vi mô hình

 4 Triển khai và thực thi các kiểm thử thực tế

Từ đặc tả đến test cases

Functional Specifications

Independently Testable Feature

Model

Representative Values

Test Test

and error cases

 Correct zip code

 With 0, 1, or many cities

 Malformed zip code

 Empty; 1-4 characters; 6 characters; very long

Các kỹ thuật kiểm thử chức

năng

Ví dụ

Chương trình tam giác

 Đều nếu 3 cạnh bằng nhau

 Cân nếu có 2 cạnh bằng nhau

 Thường nếu không có cạnh nào bằng

nhau

c

Chương trình Tam giác

nguyên và quyết định chúng có tạo thành một tam giác đều, một tam giác cân, một tam giác cạnh không đều, hoặc nếu không tạo thành một tam giác nào trong các loại trên

phức tạp, do các mối quan hệ giữa các yếu

tố đầu vào và đầu ra

Hàm NextDate

định dạng nhất định và in ra ngày của ngày hôm sau

04 01 1998

gồm

 Hoa hồng được tính trên doanh số bán hàng:

10% trên doanh số bán hàng lên đến và bao

gồm cả $ 1000, 15% cho $ 800 tiếp , và 20%

trên khoản tiền trên $ 1800

 Chương trình này có logic tính toán để kiểm tra đầu vào và đầu ra là không phức tạp

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

Kiểm thử biên

 Kiểm thử các giá trị, hoặc kích thước hoặc số

lượng gần giới hạn thiết kế

 Giá trị giới hạn

 chiều dài giới hạn

 Khối lượng giới hạn

 Chuỗi Null vs chuỗi rỗng

 Lỗi có xu hướng xảy ra gần các giá trị cực đầu vào

 Robustness(Mạnh mẽ): phần mềm phản ứng

như thế nào khi được vượt quá giới hạn?

Giá thiết lỗi đơn

Các giả định lỗi đơn từ độ tin cậy :

"Thất bại hiếm khi là kết quả của sự xuất

hiện đồng thời hai lỗi”

 Vượt quá giới hạn

 Trường hợp thử nghiệm tồi tệ nhất (Worst-case testing)

 Như kiểm tra giá trị ranh giới, nhưng loại bỏ giả thiết lỗi đơn

 Trường hợp thử nghiệm mạnh mẽ tồi tệ nhất (Robust

worst-case testing)

 Cũng giống như thử nghiệm mạnh mẽ ở trên, nhưng loại bỏ giả thiết lỗi đơn

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

sử dụng các giá trị đầu vào biến tại:

 Mức tối thiểu của nó,

 chỉ ở trên mức tối thiểu,

 tại một giá trị không đáng kể,

 Ngay dưới mức tối đa,

 Tại mức tối đa

Kiểm thử giá trị biên đầu vào

Input Boundary Value Testing

Test cases for a variable x, where a ≤ x ≤ b

Experience shows that errors occur more frequently for extreme values of a variable

x

x(min) x(min+) x(nom) x(max -) x(max)

Input Boundary Value Testing (2 Variables)

Test cases for variables x 1 and x 2 , where

Robustness Testing

Bao gồm các giá trị dưới giá trị tối thiểu và

cao hơn giá trị tối đa

gọi là “kiểm thử âm tính" - làm thế nào để

chương trình xử lý các sai sót trong đầu vào?

với một số ngôn ngữ mạnh mẽ, giao diện đồ họa với các giá trị bảng cố định hoặc thả

Robustness Testing

Test cases for a variable x, where a ≤ x ≤ b

x

1.Ép tại biên đầu vào

2 phản ứng Chấp nhận được cho các đầu vào không hợp lệ?

3 Dẫn đến thử nghiệm thăm dò (hacker kiểm tra)

Robustness Testing (2 Variables)

c

d

x 2

x 1

Worst-Case Testing

 Vứt bỏ giả thiết lỗi đơn ( Single Fault Assumption)

 Cho phép các giá trị đầu vào đồng

thời tại các biên của chúng

Worst Case Testing (2 Variables)

Loại trừ "single fault" assumption

Robust Worst-Case Testing

 Loại bỏ giả thiết lỗi đơn

 Cho phép các giá trị đầu vào tiếp cận đồng thời và vượt quá biên của

chúng

Robust Worst Case (Paranoid)

Testing with 2 Variables

c

d

x 2

x 1

Giới hạn của kiểm thử giá trị

biên

giá trị không ở biên

Boundary Value Test Cases for the

examples

Boundary Value Test Cases for the

Triangle Program

mỗi biến: min, min+, nominal value, max-,

max

yêu cầu 4x3 + 3 = 15 test cases

Input Boundary Value Analysis

Worst Case Boundary Value

Analysis

Side a = 1, 2, 100, 199, 200

times Side b = 1, 2, 100, 199, 200

times Side c = 1, 2, 100, 199, 200

= 125 test cases

Test Cases for the NextDate &

Commission

 NextDate function

 Commission problem

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

 lấy trường hợp kiểm thử dựa trên các phân vùng

 Xác định ranh giới sau đó xác định tương đương

 Mục tiêu:

 Đạt được một cảm giác kiểm thử hoàn toàn và tránh dư thừa

 Nếu một tập hợp các giá trị gây cho chương trình hành xử chính xác trong cùng một cách , thì đó là một ứng cử viên cho một lớp tương đương

Equivalence Classes

 Một lớp học tương đương đại diện cho một tập hợp của các trạng thái hợp lệ hoặc không hợp lệ cho điều kiện đầu vào

 Một điều kiện đầu vào là:

 một số giá trị cụ thể, một loạt các giá trị

 một tập hợp các giá trị liên quan, hoặc một điều kiện Boolean

All Rights Reserved

system Valid inputs

invalid inputs outputs

 Nếu một điều kiện đầu vào xác định một phần tử của tập hợp, hợp lệ và một trong các lớp không hợp lệ

tương đương được xác định

 Nếu một điều kiện đầu vào là Boolean, một hợp lệ và một lớp không hợp lệ được định nghĩa

49

Xác định lớp tương đương

 Hãy tìm dãy số hoặc giá trị

 Tìm các thành viên trong nhóm

 Một số trường hợp có thể dựa trên thời gian

 Bao gồm các yếu tố đầu vào không hợp lệ

 Bao gồm các biên nội bộ

 Đừng lo lắng nếu chúng chồng chéo nhau - thừa tốt hơn thiếu

 Tuy nhiên, những trường hợp kiểm thử hầu như chắc chắn sẽ chồng chéo với các trường hợp

kiểm tra giá trị ranh giới

Các kiểu lớp tương đương

(two variables)

 Weak normal (bình thường yếu)

 một dữ liệu từ mỗi lớp hợp lệ cho mỗi biến

 Strong normal (bình thường mạnh)

 một dữ liệu từ mỗi lớp chéo nhau trong các lớp hợp lệ

 Lớp tương đương truyền thống

 Đối với đầu vào hợp lệ, sử dụng một giá trị từ mỗi lớp hợp lệ

 Đối với đầu vào không hợp lệ, một trường hợp kiểm thử sẽ có một giá trị không hợp lệ và các giá trị còn lại tất cả sẽ có giá trị hợp lệ

 Các loại loại này thường áp dụng khi các biến có các

biên cục bộ

Các kiểu lớp tương đương

 Miền đầu vào

 Phạm vi đầu ra

Ví dụ miền đầu vào

a ≤ x < b, b ≤ x < c, or c ≤ x ≤ d

e ≤ y < f or f ≤ y ≤ g

Weak Equivalence Class Test Cases

Strong Equivalence Class Test

Ví dụ các Testcase cho lớp tương

đương

Chương trình tam giác

Lớp tương đương đầu vào

Lớp tương đương dựa trên đầu vào: Chúng ta

có ít nhất 9 lớp (5 „tam giác‟, 3 „không tam

giác‟, 1 „vô nghĩa‟):

Lớp tương đương đầu ra cho

chương trình tam giác

 Có 4 lớp tương đương đầu ra:

 Đều - Equilateral

 Cân - Isosceles

 Không đều - Scalene

 Không phải tam giác - Not a triangle

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

cho NextDate

28, Day = 29, Day = 30, Day = 31}

{Month has 30 days, Month has 31 days,

Month = February}

nhuận, Year không là năm nhuận}

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

cho NextDate

 Testcase Lớp tương đương truyền thống

 Đầu vào hợp lệ được lựa chọn một cách máy móc từ

khoảng giữa của phạm vi hợp lệ

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

cho NextDate

 Weak Equivalence Class Test Cases

 Đầu vào được lựa chọn một cách máy móc từ khoảng giữa của các lớp tương ứng

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

cho NextDate

 Strong Equivalence Class Test Cases

 36 strong equivalence class test cases

Equivalence Classes testing

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

cho bài toán tính hoa hồng

 Variable Input Domain Equivalence Classes

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

cho bài toán tính hoa hồng

Cases

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

cho bài toán tính hoa hồng

 Traditional Input Domain Equivalence Class Test Cases

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

cho bài toán tính hoa hồng

 Traditional Input Domain Equivalence Class Test Cases

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

cho bài toán tính hoa hồng

 Output Range Equivalence Classes

Lưu ý trên lớp tương đương

hoặc đầu ra

thường là tốt nhất để có {0} là lớp tương

đương của nó

xác định các lớp tốt nhất

Lưu ý trên lớp tương đương

 Dạng truyền thống của kiểm thử lớp tương

đương thường không triệt để như là thử nghiệm lớp tương đương yếu, do đó, không phải là toàn diện như là hình thức kiểm thử lớp tương

đương mạnh

 Nếu các điều kiện lỗi là một ưu tiên cao, chúng

ta có thể mở rộng kiểm thử lớp tương đương

mạnh mẽ bao gồm các lớp không hợp lệ

 Kiểm thử lớp tương đương là thích hợp khi dữ liệu đầu vào được định nghĩa với phạm vi và bộ giá trị rời rạc

Lưu ý trên lớp tương đương

 Kiểm thử lớp tương đương được cải tiến bằng phương pháp lai với kiểm tra giá trị ranh giới

 Kiểm thử lớp tương đương được chỉ định khi các chức năng chương trình rất phức tạp

 Kiểm thử lớp tương đương mạnh làm cho một giả định rằng các biến độc lập khi đó các tích đề-các được thực hiện

 Nếu có bất kỳ phụ thuộc, thường sẽ tạo ra trường hợp kiểm thử

"lỗi”, như họ đã làm trong chức năng NextDate

 Kỹ thuật bảng quyết định giải quyết vấn đề này

Decision Tables Based Testing

Decision Tables

thấy hành động kết quả từ các điều kiện đó

kiểm thử

tâm điều kiện

a1 a2 a3 a4

T F

True False

—

X

X

X

X

X

X

X

X

X

One Decision Table for the

—

—

—

X

T

T F T F

T

F

T

F

X

T

F

X

T

X

F

X

75

Decision Table-Based Testing

 Phương pháp chức năng khắt khe nhất - thực thi chặt chẽ hợp lý

 Được sử dụng để biểu diễn và phân tích mối

quan hệ logic phức tạp

 Bảng Quyết định được khai báo - không có thứ

tự đặc biệt trong những điều kiện này

 Bảng hỗ trợ quyết định có tính thống nhất và

đầy đủ

 Phụ thuộc có thể mang lại các kết hợp không

thể, vì vậy chúng ta thường có một hành động

Refined Decision Table for the

Triangle Problem

c1: a < b+c?

c2: b < a+c?

c3: c < a+b?

c4: a = b?

c5: a = c?

c6: b = c?

a1: Not a triangle

a2: Scalene

a3: Isosceles

a4: Equilateral

F T T T T T T T T T T

F T T T T T T T T T

F T T T T T T T T

T T T T F F F F

T T F F T T F F

T F T F T F T F

X X X

X

X X X

X

A Redundant Decision Table

• Rule 9 is identical to Rule 4 (T, F, F)

• Since the action entries for rules 4 and 9 are identical,

Conditions 1-4 5 6 7 8 9 c1: T F F F F T

c2: T T F F F

c3: T F T F F

a1: X X X X

a2: X X X

a3: X X X X X

An Inconsistent Decision Table

• Rule 9 is identical to Rule 4 (T, F, F)

• Since the action entries for rules 4 and 9 are different

Conditions 1-4 5 6 7 8 9 c1: T F F F F T

c2: T T F F F

c3: T F T F F

a1: X X X

a2: X X X X

a3: X X X X

Procedure for Decision-Table

• don't care entries

• redundant and inconsistent rules

3 Each rule defines a test case

Decision Tables Based Testing Test

cases for the examples

Test Cases for the Triangle

Problem

Exercises

Notes on Dicision Tables

 The decision table technique is indicated for

applications characterized by any of the following:

 prominent If-Then-Else logic

 logical relationships among input variables

 calculations involving subsets of the input variables

 cause and effect relationships between inputs and outputs

 high cyclomatic (McCabe) complexity (see Chapter 9)

Notes on Dicision Tables

 Decision tables don't scale up very well (a limited

entry table with n conditions has 2n rules)

 There are several ways to deal with this:

 use extended entry decision tables, algebraically simplify tables, "factor" large tables into smaller ones, and look for repeating patterns of condition entries

 As with other techniques, iteration helps

 The first set of conditions and actions you identify may be unsatisfactory Use it as a stepping stone, and gradually