Software Engineering 2007/2008 Chapter 8 Testing the Programs

2007/2008 Software Engineering

Chapter 8

Testing the Programs

Learning objectives

Learning Objectives:After studying this chapter, you should be able to: Define different types of faults and how to classify the

m. Define the purpose of testing( 测试目的 ). Describe unit testing and integration testing( 综合

测试 ) and understand the differences between them. Describe several different testing strategies( 策略 )

and understand their differences. Describe the purpose of test planning. Apply several techniques for determining when to stop

testing.

8.1 SOFTWARE FAULTS AND FAILURES

Fault identification ( 缺点 , 故障识别 ) is the process of determining what fault or faults caused the failure,

and fault correction( 纠正 ) or removal is the process of making changes to the system so the faults are

removed.


Types of Faults algorithmic fault

branching too soon( 分支太早 )branching too late( 分支太迟 ) testing for the wrong condition( 错误条件下的测试 ) forgetting to initialize variables or set loop invariants

( 忽略设置初始化变量或循环变量 ) forgetting to test for a particular condition (such as w

hen division by zero might occur)( 忽略测试特殊条件（比如被零除可能会发生） )

comparing variables of inappropriate data types( 将变量与不匹配的数据类型比较 )


Computation and precision （精确） faults Occur （出现） when a formula‘s( 公式 ) implementat

ion is wrong or does not compute the result to the required degree of accuracy （正确度） .

For instance, combining integer and fixed-or floating-point variables in an expression may produce unexpected results.

documentation faultsOccur When the documentation does not match wh

at the program actually does.


overload( 过载 ) faults occur when these data structures (such as queues, buffers, t

ables, and so on ) are filled past their specified capacity. capacity( 容量 ) or boundary( 边界 ) faults

occur when the system's performance becomes unacceptable as system activity reaches its specified limit.

Timing( 适时 , 时间选择 ) or coordination( 配合 , 协调 ) faults

occur when the code coordinating these events is inadequate.


Throughput( 吞吐率 , 吞吐量 ) or performance ( 性能 ,特性 ) faults

occur when the system does not perform at the speed prescribed by the requirements.

Recovery( 恢复 , 校正 ) faults occur when a failure is encountered( 遭遇 ) and the system

does not behave as the designers desire or as the customer requires.

hardware and system software faults arise( 出现 , 发生 ) when the supplied hardware and system

software do not actually work according to the documented operating conditions and procedures.

8.2 Test organization

Module( component , unit )testing verifies that the component functions properl

y with the types of input expected from studying the component's design.

Integration testing is the process of verifying( 验证 ) that the system c

omponents work together as described in the system and program design specifications.


function testing evaluates the system to determine if the fun

ctions described by the requirements specification are actually performed by the integrated system.

performance testing compares the system with the remainder( 余

项 , 剩余 ) of these software and hardware requirements.


◆acceptance

confer( 协商 ) with the customer to make certain that the system works according to customer expectations.

◆installation test( 安装检测 , 测试 )

make sure that the system still functions as it should.


8.3 UNIT TESTING

◎Examining the Code Proving Code( 校对 , 验证 ) Correct Testing Program Components

open- and closed-box testing Closed-box testing suffers from( 遭受 ) uncertainty

( 不确定性 ) about whether the test cases selected will uncover a particular fault.

open-box testing always admits( 容许 ) the danger of paying too much attention to the code’s internal processing. We may end up testing what the program does instead of what it should do.

8.3 UNIT TESTING

by considering the program as a closed box, we can use the program's external specifications to generate initial test cases. These cases should incorporate not only the expected input data, but also boundary conditions( 边界条件 ) for the input and output, as well as several cases of invalid( 无效的 ) data.

we may include a test case for each of the following:

8.3 UNIT TESTING

a very large positive integer( 正整数 )

a positive integer

a positive, fixed-point( 固定点 , 定点 ) decimal( 十进的 , 小数 )

a number greater than 0 but less than 1

zero

a negative number( 负数 )

a nonnumeric( 非数值的 ) character

8.3 UNIT TESTINGTest Thoroughness( 彻底性；完全性 )

Statement testing

Every statement in the component is executed at least once in some test.

Branch testing

For every decision point( 判定点 ) in the code,

each branch is chosen at least once in some test.

Path testing( 路径测试 )

Every distinct( 不同的 ) path through the code is executed at least once in some test.

8.3 UNIT TESTING

Definition-use( 用定义的 ) path testing

Every path from every definition of every variable to every use of that definition is exercised in some test.

……

8.4 INTEGRATION TESTING External Documentation

Describing the problem In the first section of the code‘s documentati

on, you should explain what problem is being addressed （提交） by the component.

Describing the Algorithms You should explain each algorithm used by th

e component, including formulas （规则，公式） , boundary or special conditions, and even its derivation （出处） or reference to the book or paper from which it is derived （起源） .

8.4 INTEGRATION TESTING

Bottom-up Integrationeach component at the lowest level of

the system hierarchy is tested individually( 单独地 ) first. Then, the next components to be tested are those that call the previously( 先前 ) tested ones. This approach is followed repeatedly until all components are included in the testing.


A component being tested may call another that is not yet tested, so we write a stub( 存根程序 ), a special-purpose program to simulate the activity of the missing component. The stub answers the calling sequence and passes back output data that lets the testing process continue.


Top-down Integration( 自顶向下集成 )

A disadvantage to top-down testing is the possibility that a very large number of stubs may be required.

8.5 TESTING OBJECT-ORIENTED SYSTEMS

Testing the Code Rumbaugh et al. (1991) propose that you begin te

sting object-oriented systems by asking several questions:

. When your code expects a unique( 唯一的 ) value, is there a path that generates a unique result?

. When there are many possible values, is there a way to select a unique result?

. Are there useful cases that are not handled?

8.5 TESTING OBJECT-ORIENTED SYSTEMS

you find asymmetric( 不对称的 ) associations or generalizations( 广义化 , 概括，概况 )

you find disparate( 完全不同的 ) attributes and operations on a class

one class is playing two or more roles an operation has no good target class you find two associations with the same na

me and purpose

8.6 TEST PLANNING

we must plan each of these test steps:1. establishing( 建立 , 确定 ) test objectives2. designing test cases3. writing test cases4. testing test cases5. executing( 执行 ) tests6. evaluating( 评估 , 评价 ) test results

8.7 AUTOMATED TESTING TOOLS

Code Analysis Tools 1. Code analyzer: The components are evaluated automati

cally for proper syntax. Statements can be highlighted if the syntax is wrong, if a construction is faultprone, or if an item has not been defined.

2. Structure checker: This tool generates a graph from the components submitted as input. The graph depicts the logic flow and the tool checks for structural flaws.

3. Data analyzer: The tool reviews the data structures, data declarations, and component interfaces, and then notes improper linkage among components, conflicting data definitions, and illegal data usage.

4. Sequence checker: The tool checks sequences of events; if coded in the wrong sequence, the events are highlighted.

Documents

Software Engineering 2007/2008 Chapter 8 Testing the Programs