Slide 7.1
Software Engineering
Lili
ICEC
NEFU
CHAPTER 7
Testing
Slide 7.2
Overview








Slide 7.3
The test workflow: Implementation
Test case selection（测试用例的选择）
Black-box unit-testing techniques
Black-box test cases: The Osbert Oglesby case
study
Glass-box unit-testing technique
Code walkthroughs and inspections (代码走查和审查)
Comparison of unit-testing techniques
Management aspects of unit testing
Overview (contd)




When to rewrite rather than debug a module
Integration testing （集成测试）
Product testing （产品测试）
Acceptance testing （验收测试）
Slide 7.4
7.1 The Test Workflow: Implementation
Slide 7.5

Unit testing
Informal unit testing by the programmer
Methodical unit testing by the SQA group

There are two types of methodical unit testing
Non-execution-based testing （基于非执行的测试）
Execution-based testing （基于执行的测试）
7.2 Test Case Selection

Slide 7.6
Worst way — random testing
There is no time to test all but the tiniest fraction of all
possible test cases, totaling perhaps 10100 or more

We need a systematic way to construct test cases
7.2.1 Testing to Specifications versus Testing to Code
（规格说明测试与代码测试）
Slide 7.7

There are two extremes to testing

Test to specifications (also called black-box, datadriven, functional, or input/output driven testing)
Ignore the code — use the specifications to select test
cases

Test to code (also called glass-box, logic-driven,
structured, or path-oriented testing)
Ignore the specifications — use the code to select test
cases
7.2.2 Feasibilityof Testing to Specifications
（规格说明测试的可行性）

Slide 7.8
Example:
The specifications for a data processing product
include 5 types of commission and 7 types of discount
（假定某个数据处理产品的规格说明指出，必须包含5类佣金和7
类折扣）
35 test cases
Feasibility of Testing to Specifications (contd)
Slide 7.9

Suppose the specifications include 20 factors,
each taking on 4 values
There are 420 or 1.1 × 1012 test cases
If each takes 30 seconds to run, running all test cases
takes more than 1 million years（一百多万年）

The combinatorial explosion makes testing to
specifications impossible
7.2.3 Feasibility of Testing to Code（代码测试可行性）
Slide 7.10

Each path through a artifact must be executed at
least once （要求对模块通过的每条路经最少执行一次）
Feasibility of Testing to Code (contd)

Slide 7.11
Code example:
单次循环存
在5条路径,
共18次循环
Figure 7.1
Figure 7.2
Feasibility of Testing to Code (contd)

The flowchart has over 1012 different paths
51+5253+54+…+518=4.77×1012
Slide 7.12
Feasibility of Testing to Code (contd)

Slide 7.13
Testing to code is not reliable(代码测试不可靠)
If ((x+y+z)/3==x)
print”x,y,z are equal in value”;
Else
print”x,y,z are unequal”;
Test case 1: x=1,y=2,z=3
Test case 2: x=y=z=2
print”x,y,z are unequal”
print”x,y,z are equal in value”
到此两个路径都检查到了,但是却没有检查出错误
Test case 3: x=2,y=1,z=3
We
print”x,y,z are equal in value”
can exercise every path without detecting every fault
Feasibility of Testing to Code (contd)

Slide 7.14
Criterion “exercise all paths” is not reliable
Products exist for which some data exercising a given
path detect a fault, and other data exercising the same
path do not
7.3 Black-Box Unit-testing Techniques
(黑盒单元测试技术)
Slide 7.15

Neither exhaustive testing to specifications nor
exhaustive testing to code is feasible(穷尽测试不可能)

The art of testing:
Select a small, manageable set of test cases(测试用例集)
to
Maximize the chances of detecting a fault, while
Minimizing the chances of wasting a test case

Every test case must detect a previously
undetected fault
(每个测试用例必须能够检测出一个先前未检测出的错误)
Black-Box Unit-testing Techniques (contd)
Slide 7.16

We need a method that will highlight as many
faults as possible
First black-box test cases (testing to specifications)
Then glass-box methods (testing to code)
7.3.1 Equivalence Testing and Boundary Value Analysis
(等价测试和边界值分析)

Slide 7.17
If the system works for any one test case in the range
(1..16,383), then it will probably work for any other
test case in the range
Range (1..16,383) constitutes an equivalence class(等价类)
Equivalence Testing
Slide 7.18

Any one member of an equivalence class is as
good a test case as any other member of the
equivalence class

Range (1..16,383) defines three different
equivalence classes:
Equivalence Class 1: Fewer than 1 record
Equivalence Class 2: Between 1 and 16,383 records
Equivalence Class 3: More than 16,383 records
Boundary Value Analysis

Slide 7.19
Select test cases on or just to one side of the
boundary of equivalence classes
This greatly increases the probability of detecting a fault
Database Example (contd)




Test case 1: 0 records
Slide 7.20
Member of equivalence
class 1 and adjacent to
boundary value
Test case 2: 1 record
Boundary value
Test case 3: 2 records
Adjacent to boundary
value
Test case 4: 723 records Member of
equivalence class 2
Database Example (contd)



Slide 7.21
Test case 5: 16,382 records Adjacent to
boundary value
Test case 6: 16,383 records Boundary value
Test case 7: 16,384 records Member of
equivalence class 3
and adjacent to
boundary value
Equivalence Testing of Output Specifications
Slide 7.22

We also need to perform equivalence testing of
the output specifications

Example:
In 2003, the minimum Social Security deduction (最少社
会保险减扣) from any one paycheck was $0.00, and the
maximum was $5,394.00(减扣值范围为 [0.00, 5,3940.00]美元)
Test cases must include input data that should result in
deductions of exactly $0.00 and exactly $5,394.00(测试
用例应该包括正好能够产生0.00美元和5,3940.00美元减扣的输入值)
Also, test data that might result in deductions of less
than $0.00 or more than $5,394.00(此外,测试用例还应该包
括能够产生小于0.00美元和多于5,3940.00美元减扣的输入值)
Overall Strategy (二者结合策略)

Slide 7.23
Equivalence classes together with boundary value
analysis to test both input specifications and
output specifications
This approach generates a small set of test data with
the potential of uncovering a large number of faults
7.3.2 Functional Testing
Slide 7.24

We base the test data on the functionality of the
code artifacts

Each item of functionality or function is identified

Test data are devised to test each (lower-level)
function separately

Then, higher-level functions composed of these
lower-level functions are tested
Functional Testing (contd)

Slide 7.25
In practice, however
Higher-level functions are not always neatly constructed
out of lower-level functions using the constructs of
structured programming
(在实践中,高层功能不是使用这样的结构化方式从低层功能构建来)
Instead, the lower-level functions are often intertwined
(相反,低层功能常常以某种方式相互绞在一起)

Also, functionality boundaries do not always
coincide with code artifact boundaries
(功能经常与模块边界不一致)
The distinction between unit testing and integration
testing becomes blurred
This problem also can arise in the object-oriented
paradigm when messages are passed between objects
7.4 Black-Box Test Cases: The Osbert Oglesby Case Study
Slide 7.26
Black-Box Test Cases
Figure 7.3
Black-Box Test Cases: Osbert Oglesby (contd)
Slide 7.27

Functional testing test cases
Figure 7.4