Software Testing(软件测试)
福州大学·软件学院·王灿辉
wangch8131@sina.com
SOFTWARE ENGINEERING
The Development Phase
Software
Design
Code
Generation
Software
Testing
SOFTWARE ENGINEERING
Software Quality Assurance
• 软件质量保证（SQA）应该从产品的计划
和设计开始，直到投入使用和售后服务的
软件生存周期的每一个阶段中的每一个步
骤，每一个有关的人，包括软件开发人员、
测试人员、项目经理、销售人员和用户都
必须严把质量关，只有这样才能保证软件
的高质量，这就是现代软件质量保证的基
本策略。
SOFTWARE ENGINEERING
Software Testing
• 测试是软件生命周期中的一个重要阶段。它
直接影响着软件的质量和软件的可靠性。因
此，人们往往花费了大量的时间和人力用于
软件测试。在软件开发的全过程中，尽管对
每个阶段均有严格的技术审查，但是，要发
现所有的错误是不可能的。因此，软件在投
入生产性运行之前要尽可能多地发现软件中
的差错，以提高软件的质量。
SOFTWARE ENGINEERING
Software Testing
• 一旦编码开始，正式测试必须随即开始。
• 测试要求开发者首先抛弃“刚开发的软
件是正确的”这一先入为主的观念，然
后努力去构造测试用例来“破坏”软件。
• 神话：若我们确实擅长编程，就应当不
会有错误。
SOFTWARE ENGINEERING
Software Testing
• 测试不应该被看作是安全网
• 只有在软件体系结构完成后,独立的测试
组（ITG）才介入
• 任何测试策略都必须包含测试计划测试
用例设计、测试执行及测试结果数据的
收集与评估
• 测试是可以事先计划并可以系统地进行
的一系列活动
SOFTWARE ENGINEERING
Software Testing
• The importance of software testing and
its implications with respect to software
quality cannot be overemphasized.
• Software testing is a critical element of
software quality assurance and
represents the ultimate review of
specification,design,and coding.
SOFTWARE ENGINEERING
Software Testing
• 开发人员应该意识到：所有的错误都是
严重的，不存在微不足道的错误。这样
才能少犯错误。
• 错误的分类是技术性的。如：手册错误
可能导致机毁人亡。假设某个财务软件
有两个错误：错误A使该系统死机，错
误B导致工资计算错误。按分类，错误A
比错误B严重。但事实上B要比A严重。
SOFTWARE ENGINEERING
Software Testing
• In fact,testing is the one step in the
software engineering process that could
be viewed (psychologically,at least) as
destructive rather than constructive.
• Software developer are by their nature
constructive people.
• 错觉：“程序编完后，研制工作就接近尾声了”。
• 实际：“测试占开发费用的40%至50%，对有
关生命危险的软件甚至占80%”
SOFTWARE ENGINEERING
Software Testing
• 测试必须按照软件需求和设计阶段所制订的测试
计划进行，其结果以“测试分析报告”的形式提
交。
回归测试
软件配置
评价
错误
纠错
改正
测试
测试配置
测试计划文
档的一部分
可靠性
模型
预测的可靠性
SOFTWARE ENGINEERING
测试工作量
•
•
•
到目前为止，证明软件百分之百正确是不可能的，而且
进行穷举测试也是不可能的。你永远也不能完成测试。
因此我们的测试策略是在一定的开发周期和某种经济条
件下，通过有限的测试以尽可能多地发现错误。
按软件工程中的40—20—40规则（编程工作占开发工作
的20%，编程前---计划、需求分析、概要设计和详细设
计，和编程后---测试的工作量各占开发工作的40%）。
测试在整个软件的开发中必须占40%左右的工作量。
各类测试在测试总工作量所占的比例根据具体项目及开
发人员的配置情况而定。
SOFTWARE ENGINEERING
测试结束标志
• 依照测试工作量及下述标准可判定是否可以结束测
试过程：
1) 如果测试没有发现错误，说明测试失败，则必须更
换测试人员作进一步测试。
2) 如果有规律地出现一些严重的，需要修改设计的错
误，则说明软件的质量和可靠性存在问题，必须重
写相应模块，甚至整个软件。
3) 如果软件功能正常，发现的错误容易纠正，则说明
软件的质量和可靠性可接受（不排除测试不充分的
可能）。
SOFTWARE ENGINEERING
Testing Objectives
1. Testing is a process of executing a program
with the intent of finding an error.
2. A good test case is one that has a high probability of finding an as-yet undiscovered error.
3. A successful test is one that uncovers an asyet undiscovered error.
• Testing cannot show the absence of defects,it
can only show that software errors are
present.
SOFTWARE ENGINEERING
Testing Objectives
• 理解测试的目的是个很重要的意识问题。如果
说测试的目的是为了说明程序中没有缺陷，那
么测试人员就会向这个目标靠拢，因而下意识
地选用一些不易暴露错误的测试示例。这样的
测试是虚假的。目前的科技成果鉴定会普遍存
在类似的虚假现象。
• 尽管已经明白了测试的目的是为了发现尽可能
多的缺陷，但当测试人员真的发现了一堆缺陷
时，却不可乐颠颠地跑去恭喜那个倒霉的开发
者，否则会打架的。
SOFTWARE ENGINEERING
测试与质量
• 测试有助于提高软件的质量，但是提高软件的
质量不能依赖于测试。测试与质量的关系很象
在考试中“检查”与“成绩”的关系。
• 学习好的学生，在考试时通过认真检查能减少
因疏忽而造成的答题错误，从而“提高”了考
试成绩（取得他本来就该得的好成绩）。 而学
习差的学生，他原本就不会做题目，无论检查
多么细心，也不能提高成绩。
• 软件的高质量是设计出来的，而不是靠测试修
补出来的。
SOFTWARE ENGINEERING
Testing Principles(1)
1. All tests should be traceable to customer
requirements.
2. Tests should be planed long before testing
begins.
3. The Pareto principle applies to software testing.
Stated simply,the Pareto principle implies that
80 percent of all errors uncovered during
testing will likely be traceable to 20 percent of
all program modules.
SOFTWARE ENGINEERING
Testing Principles(2)
4. Testing should begin “in the small” and
progress toward testing “in the large.”
5. Exhaustive testing is not possible.
6. To be most effective,testing should be
conducted by an independent third
party.
SOFTWARE ENGINEERING
Testing Principles(3)
• 程序员或程序设计机构不应测试自己设计的程序；
• 测试用例设计不仅要有确定的输入数据，而且要有
确定的、详尽的预期输出数据；
• 测试用例设计不仅要有合理的输入数据，还要有不
合理的输入数据；
• 除了检查程序是否做完了它应做的事之外，还要检
查它是否做了不应做的事；
•
保留全部测试用例，并作为软件配置的组成部分之一；
• 程序中存在错误的概率与该段程序中已经发现的错
误数成正比。
SOFTWARE ENGINEERING
Testability(可测试性)
• Operability: “The better it work,the
more efficiently it can be tested.”
• Observability: “What you see is what
you test.”
• Controllability: “The better we can
control the software,the more the testing
can be automated and optimized.”
SOFTWARE ENGINEERING
Testability(可测试性)
• Decomposability: “By controlling the scope of
testing,we can more quickly isolate problems
and perform smarter retesting.”
• Simplicity: “The less there is to test,the more
quickly we can test it.”
• Stability: “The fewer the changes,the fewer
the disruptions to testing.”
• Understandability: “The more information
we have,the smarter we will test.”
SOFTWARE ENGINEERING
Attributes of a “good” test
• A good test has a high probability of
finding an error.
• A good test is not redundant.
• A good test should be “best of breed.”
The test that has the highest likelihood of
uncovering a whole class of errors should be used.
• A good test should be neither too simple
nor too complex.
SOFTWARE ENGINEERING
软件测试分类
• 测试分为如下的几类：
1) 模块测试（单元测试、分调、单调）
2) 组装测试（整体测试、集成测试、联调）
3) 有效性测试 （确认测试）
4) 系统（组装、集成）测试
5) 并行测试（平行测试、双轨制运行）
6) α测试、β测试
7) 验收测试（接收测试）：由用户完成
• 此外部分测试可能需要进行回归测试。
SOFTWARE ENGINEERING
软件测试步骤
模块
模块测试
模块
模块测试
……
模块
模块测试
测试过
的模块
经装配好
的软件 确认测试
确认过
的软件
组装测试
系统测试
其他系
统元素
可运行
的系统
软件试运行、验收
SOFTWARE ENGINEERING
测试过程和研制过程的对应关系
系统定义
软件计划
需求分析
概要设计
详细设计
编码
模块测试
组装测试
确认测试
系统测试
验收测试
研制是一个自顶向下逐步细化的过程，
而测试则是按相反顺序的集成过程。
SOFTWARE ENGINEERING
测试方法和测试技术
桌前检查
静态技术
代码会审
步行检查
路径测试
测试方法和
测试技术
白盒测试
条件测试
数据测试
循环测试
动态技术
等价类划分
黑盒测试
边界值分析
比较测试
SOFTWARE ENGINEERING
测试用的程序实例
• 三角形问题：接受3个1—100之间的整
数，判别由这3条边构成的三角形的类
型：等边、等腰、不等边或非三角形。
• NextDate函数：接受3个整数，输出非
法日期或输入日期的下一个日期。
• 佣金问题：销售商根据不同的销售额可
以获得不同的奖励。
SOFTWARE ENGINEERING
测试方法和测试技术
—程序的静态分析
• 检查逻辑设计和编码错误。不涉及程序的实
际执行，用人工进行分析。
1) 桌前检查(Desk Check)：程序员自己检查程序效
果不太理想。解决办法：互相交换程序检查。
2) 代码会审(Code Inspections)：由一组人通过阅
读、讨论和争议，对程序进行静态分析的过程。
3) 步行检查(Walkthroughs)：预先准备测试数据，
让与会者充当“计算机”一检查程序的状态。
有时比真正运行程序可能发现更多的错误。
SOFTWARE ENGINEERING
测试方法和测试技术
—程序的动态测试
• 在程序的测试中，十全十美的测试情况是不
存在的，即任何程序的测试都是不彻底的，
测试不能发现程序中的所有错误。
• 在测试方法中，最简单的，也是最差的一种
测试方法是随机输入的测试。这种将随机选
择的输入值作为输入数据的测试往往检测不
出较多的错误。通常，在程序的测试中采用
二类方法：黑盒法和白盒法。
SOFTWARE ENGINEERING
测试方法和测试技术
—程序的动态测试
• 无论是白盒法还是黑盒法，关键都是如何选
择高效的测试用例(高效的测试用例是指一个
用例能够覆盖尽可能多的测试情况，从而提
高测试效率)。
• Black-box testing alludes to test that are
conducted at the software interface.
• White-box testing of software is predicated on
close examination of procedural detail.
SOFTWARE ENGINEERING
测试方法和测试技术
—程序的动态测试
• 由于无法进行穷举测试，所以测试用例
(test case)的设计在软件测试中起很重要的
作用。测试用例设计的基本目的是确定一
组最有可能发现某个错误或某类错误的测
试数据。
• 测试用例的设计技术有许多种。如：路径
测试，各种逻辑覆盖（语句、条件、循环
等），等价类划分，边界值分析，因果图
和程序图等图形技术。
SOFTWARE ENGINEERING
测试方法和测试技术
—White-box Testing
• White-box testing,sometimes called
glass-box testing,is a test case design
method that uses the control structure of
the procedural design to derive test cases.
• 白盒法检查程序的内部结构，即检测程
序的逻辑。
SOFTWARE ENGINEERING
测试方法和测试技术
—White-box Testing
• Using white-box testing methods,the software
engineer can derive test cases that
(1)guarantee that all independent paths
within a module have been exercised at least
once;(2)exercise all logical decision on their
true and false sides;(3)execute all loops at
their boundaries and within their operational
bounds;and (4)exercise internal data
structures to assure their validity.
SOFTWARE ENGINEERING
White-box Testing
—Basic Path Testing
• The basic path method enables the test
designer to derive a logical complexity
measure of a procedural design and use
this measure as a guide for defining a basic
set of execution paths.Test cases derived to
exercise the basic set are guaranteed to
execute every statement in the program at
least one time during testing.
SOFTWARE ENGINEERING
White-box Testing —Basic Path Testing
—Flow Graph Notation
Sequence
If-then-else
While
Case
Until
Flow graph Notation
SOFTWARE ENGINEERING
White-box Testing —Basic Path Testing
—Flow Graph Notation
• Translating Flow chart and PDL to a flow graph.
1
Edge
2,3
6
7
R3
4,5
8
R2
Region
R1
9
R4
10
Node
11
SOFTWARE ENGINEERING
White-box Testing —Basic Path Testing
—Cyclomatic complexity
• McCabe认为程序的复杂性很大程度上取决
于程序控制流的复杂性。
• Cyclomatic(环路) Complexity is a software
metric that provides a quantitative measure
of the logical complexity of a program.
• Cyclomatic complexity has a foundation in
graph theory and provides us with an
extremely useful software metric.
SOFTWARE ENGINEERING
White-box Testing —Basic Path Testing
—Cyclomatic complexity
• Complexity is computed in one of three ways:
1) The number of regions of flow graph
correspond to the cyclomatic complexity.
2) Cyclomatic complexity,V(G),for a flow graph
G is define as V(G)=Edge-Node+2.
3) cyclomatic complexity,V(G),for a flow graph
G is also define as V(G)=P+1,where P is the
number of predicate nodes contained in the
flow graph G.
SOFTWARE ENGINEERING
White-box Testing —Basic Path Testing
—Cyclomatic complexity
• Cyclomatic complexity for example can
be computed:
1) The flow graph has 4 regions.
2) V(G)=11edges-9nodes+2=4
3) V(G)=3 predicate nodes+1=4
• 测试工作量和潜在错误的个数与V(G)成正比
• McCabe认为在一个模块内 V(G)一般应控制在10以
内，当V(G)在3至9之间时被认为是良好的结构和恰
当的复杂性(度)。
SOFTWARE ENGINEERING
White-box Testing —Basic Path Testing
—Independent Paths
• The value computed for cyclomatic
complexity defines the number of
independent paths I the basic set of a
program and provide us with an upper
bound for the number of the tests that
must be conducted to ensure that all
statements have been executed at least
once.
SOFTWARE ENGINEERING
White-box Testing —Basic Path Testing
—Independent Paths
• An independent path is any path
through the program that introduces at
least one new set of processing
statements or a new condition.When
stated in terms of a flow graph,an
independent path must move along at
least edge that has not been traversed
before the path is defined.
SOFTWARE ENGINEERING
White-box Testing —Basic Path Testing
—Independent Paths
•
•
•
•
•
A set of independent paths for example:
Path 1:1-11
Path 2:1-2-3-4-5-10-1-11
Path 3:1-2-3-6-8-9-10-1-11
Path 4:1-2-3-6-7-9-10-1-11
• The path
1-2-3-4-5-10-1-2-3-6-8-9-10-1-11
is not considered to be an independent path.
SOFTWARE ENGINEERING
White-box Testing —Basic Path Testing
—Deriving Test Cases
• The basic path testing method can be applied
to a procedural design or to source code.
1) Using the design or code as a foundation,
draw a corresponding flow graph.
2) Determine the cyclomatic complexity of the
resultant flow graph.
3) Determine a basic set of linearly independent paths.
4) Prepare test cases that will force execution of
each path in the basic set.
SOFTWARE ENGINEERING
White-box Testing
—Condition Testing
• 白盒法又称为逻辑覆盖法，因为要以程
序（模块）内部的逻辑结构为基础来设
计测试用例，主要用于单元测试。
弱
强
语
句
覆
盖
判
定
覆
盖
条
件
覆
盖
判
定
条
件
覆
盖
条
件
组
合
覆
盖
SOFTWARE ENGINEERING
White-box Testing
—Condition Testing
• Condition testing is a test case design
method that exercises the logical
conditions contained in a program
module.
• The condition testing method focuses on
testing each condition in the program.
• 条件测试包括四类覆盖：判定覆盖、条件
覆盖 、判定/条件覆盖 、条件的组合覆盖
SOFTWARE ENGINEERING
White-box Testing
—Condition Testing
开始
a
被测试的
程序的流
程图
A>1
AND
B=0
Y
c
X=X/A
N
b
A=2 OR
X>1
N
Y
e
X=X+1
d
结束
SOFTWARE ENGINEERING
White-box Testing—Condition Testing
—判定覆盖
• 判定覆盖又称作分支覆盖，它是使程序
中的每个判定至少出现一次“真值”和
一次“假值”，即程序中的每个分支至
少经过一次。
• 对此，我们可以设计如下测试数据对判
定逻辑进行覆盖：
A=3，B=0，X=1(通过路径acd)
A=2，B=1，X=3(通过路径abe)
SOFTWARE ENGINEERING
White-box Testing—Condition Testing
—条件覆盖
• 条件覆盖是判定中的每个条件的所有可能
的结果至少出现一次，并且使每条语句(不
是每个分支)至少执行一次(语句覆盖)。
• 对此，条件覆盖的测试可由下面两组数据
进行：
A=2，B=0，X=4 (通过路径ace)
A=1，B=1，X=1 (通过路径abd)
• 条件覆盖一般情况下比判定覆盖要强。
SOFTWARE ENGINEERING
White-box Testing—Condition Testing
—条件覆盖
• 但是，也有例外的情况（如果，测试数据设
计得不好的话），例如下例所示：
• IF A>1 AND B=0 中，若设计一组条件覆盖的
测试数据如下：
A=2，B=1
A=1，B=0
• 则这组数据满足条件覆盖，但不会执行IF语
句中的THEN的子句。
SOFTWARE ENGINEERING
White-box Testing—Condition Testing
—条件覆盖
• 设计下面两组数据：
A=1，B=0，X=3
A=2，B=1，X=1
• 满足条件覆盖（四个条件：A>1, B=0,
A=2, X>1均取过“真”值和“假”值）
但它们都通过路径abe，所以不满足判
定覆盖。
SOFTWARE ENGINEERING
White-box Testing—Condition Testing
—判定/条件覆盖
• 判定/条件覆盖方式是使判定中每个条件
的所有可能结果至少出现一次。而每个
判定本身所有的可能结果也至少出现一
次。
• 下面两组数据满足判定/条件覆盖：
A=2，B=0，X=4 (通过路径ace)
A=1，B=1，X=1 (通过路径abd)
SOFTWARE ENGINEERING
White-box Testing—Condition Testing
—条件的组合覆盖
• 条件的组合覆盖所设计的测试数据使每
个判定中的条件的各种组合至少出现一
次，并且每条语句至少执行一次。
• 例子中条件的所有可能组合有8种：
①A＞1,b＝0
⑤A＝2,X＞1
②A＞1,b≠0
⑥A＝2,X≤1
③A≤1,b＝0
⑦A≠2,X＞1
④A≤1,b≠0
⑧A≠2,X≤1
SOFTWARE ENGINEERING
White-box Testing—Condition Testing
—条件的组合覆盖
• 要测试上述8种组合（满足条件组合覆
盖），可设计下述4组数据：
A=2,B=0,X=4 覆盖①⑤
A=2,B=1,X=1 覆盖②⑥
A=1,B=0,X=2 覆盖③⑦
A=1,B=1,X=1 覆盖④⑧
• 但上述的4组测试数据并没有覆盖所有
的每一条路径（路径acd未通过）。
SOFTWARE ENGINEERING
White-box Testing
—Data Flow Testing
• The data flow testing method selects test paths
of a program according to the location of
definition and uses of variables in the program.
• One simple data flow testing strategy is to
require that every DU chain be covered at
least once.We refer to this strategy as the DU
testing strategy. It has been shown that DU
testing does not guaranteed to be coverage of
all branches of a program.
SOFTWARE ENGINEERING
White-box Testing
—Loop Testing
• Loop testing is a white-box testing
technique that focuses exclusively on the
validity of loop constructs.
• Four different classes of loops can be
defined: simple loops,concatenated
loops,nested loops, and unstructured
loops.
SOFTWARE ENGINEERING
White-box Testing —Loop Testing
—Simple Loops
• The following set of tests should be applied to
simple loops.
1) Skip the loop entirely.
2) Only one pass through the loop.
3) Two passes through the loop.
4) M passes through the loop where m<n.
5) n-1,n,n+1 passes through the loop.
• Where n is the maximum number of
allowable passes through the loop.
SOFTWARE ENGINEERING
White-box Testing —Loop Testing
—Nested Loops(1)
• Beizer suggests an approach that will help to
reduce the number of tests:
1. Start at the innermost loop.Set all other loops
to minimum values.
2. Conduct simple loop tests for the innermost
loop while holding the outer loops at their
minimum iteration parameter(e.g.,loop
counter)values.Add other tests for out-of
range or excluded values.
SOFTWARE ENGINEERING
White-box Testing —Loop Testing
—Nested Loops(2)
3. Work outward,conducting tests for the
next loop,but keeping all other outer
loops at minimum values and other
nested loops to “typical” values.
4. Continue until all loops have been tested.
SOFTWARE ENGINEERING
White-box Testing —Loop Testing
—Concatenated Loops
• Concatenated loops can be tested using
the approach defined above for simple
loops if each of the loops is independent
of the other. When the loops are not
independent,the approach applied to
nested loops is recommended.
SOFTWARE ENGINEERING
White-box Testing —Loop Testing
—Unstructured Loops
• Whenever possible,this class of loops
should be redesigned to reflect the use of
the structured programming constructs.
SOFTWARE ENGINEERING
测试方法和测试技术
—Black-box Testing
• 黑盒法是把测试对象看作一个黑盒，测
试时完全不考虑程序的内部的逻辑结构
与内部特性，只需根据需求规格说明书，
测试程序的功能或程序的外部特性。因
此黑盒法又称为功能测试或数据驱动测
试。常用的测试方法有：
等
价
分
类
法
边
值
分
析
法
错
误
推
测
法
因
果
图
法
输入
软件
输出
SOFTWARE ENGINEERING
测试方法和测试技术
—Black-box Testing
• Black-box testing focuses on the functional
requirements of the software.That is,black-box
testing enables the software engineer to derive
sets of input conditionals that will fully exercise
all functional requirements for a program.
• Black-box testing is not an alternative to whitebox techniques.Rather,it is a complementary
approach that is likely to uncover a different
class of errors than white-box methods.
SOFTWARE ENGINEERING
测试方法和测试技术
—Black-box Testing
• Black-box testing attempts to find errors
in the following categories:
1) Incorrect or missing functions;
2) Interface errors;
3) Errors in data structures or external
data base access;
4) Performance errors;and
5) Initialization and termination errors.
SOFTWARE ENGINEERING
测试方法和测试技术
—Black-box Testing
• Unlike white-box testing,which is
performed early in the testing
process,black-box testing terns to be
applied during later stages of testing.
Because black-box testing purposely
disregards control structure,attention is
focused on the information domain.
SOFTWARE ENGINEERING
测试方法和测试技术
—Black-box Testing
• Tests are designed to answer the following questions:
• How is functional validity tested?
• What classes of input will make good test cases?
• Is the system particularly sensitive to certain
input values?
• How are the boundaries of a data class isolated?
• What data rates and data volume can the system
tolerate?
• What effect will specific combinations of data
have on system operation?
SOFTWARE ENGINEERING
Black-box Testing
—Graph-Based Testing
• The first step in black-box testing is to
understand the objects that are modeled
in software and the relationships that
connect these objects.Once this has been
accomplished,the next step is to define a
series of tests that verify “all objects
have the expected relationship to one
another.”
SOFTWARE ENGINEERING
Black-box Testing
—Graph-Based Testing
• Stated in another way,software testing
begins by creating a graph of important
objects and their relationships and then
devising a series of tests that will cover
the graph so that each object and
relationship is exercised and errors are
uncovered.
SOFTWARE ENGINEERING
Black-box Testing
—Equivalence Partitioning
• Equivalence partitioning is a black-box
testing method that divides the input
domain of a program into classes of data
from which test cases can be derived.
• Equivalence partitioning strives to define a
test case that uncovers classes of
errors,thereby reducing the total number
of test cases that must be developer.
SOFTWARE ENGINEERING
Black-box Testing
—Equivalence Partitioning
• Test case design for equivalence
partitioning is based on an evaluation of
equivalence classes for an input condition.
• Equivalence classes may be defined
according to the following guidelines:
1) If an input condition specifies a range,one
valid and two invalid equivalence classes
are defined.
SOFTWARE ENGINEERING
Black-box Testing
—Equivalence Partitioning
2) If an input condition requires a specific
value,one valid and two invalid
equivalence classes are defined.
3) If an input condition specifies a member of
a set, one valid and one invalid equivalence
classes are defined.
4) If an input condition is Boolean,one valid
and one invalid class are defined.
SOFTWARE ENGINEERING
Black-box Testing
—Equivalence Partitioning
• Applying the guidelines for the
derivation of equivalence classes,test
cases for each input domain data item
could be developed and executed.Test
cases are selected so that the largest
number of attributes of an equivalence
class are exercised at once.
SOFTWARE ENGINEERING
Black-box Testing
—Boundary Value Analysis
• For reason that are not completely clear, a
greater number of errors tend to occur at the
boundaries of the input domain than in the
“center.”It is for this reason that boundary
value analysis(BVA) has been developed as a
testing technique.
• Boundary value analysis leads to a selection
of test cases that exercise bounding value.
SOFTWARE ENGINEERING
Black-box Testing
—Boundary Value Analysis
• Boundary value analysis(BVA) is a test
case design technique that complements
equivalence partitioning.Rather than
selecting any element of an equivalence
class, BVA leads to the selection of test
cases at the “edges” of the class. Rather
than focusing solely on input conditions,
BVA derives test cases from the output
domain as well.
SOFTWARE ENGINEERING
Black-box Testing
—Boundary Value Analysis
• Guidelines for Boundary value
analysis are similar in many respects
to those provided for equivalence
partitioning:
……
SOFTWARE ENGINEERING
Black-box Testing
—Boundary Value Analysis
两变量函数的健壮、最坏、边界值测试用例
SOFTWARE ENGINEERING
Black-box Testing
—Comparison Testing
• There are some situations in which the
reliability of software is absolutely critical.In
such applications redundant hardware and
software are often used to minimize the
possibility of error.
• When multiple implementation of the same
specification have been produced,test cases
designed using other black-box techniques are
provided as input to each version of software.
SOFTWARE ENGINEERING
Black-box Testing
—Comparison Testing
• When redundant software is developed,
separate software engineering teams develop
independent versions of an application using
the same specification. In such situations,each
version can be tested with the same test data
to ensure that all provide identical output.
Then all version are executed in parallel with
real-time comparison of results to ensure
consistency.
SOFTWARE ENGINEERING
Black-box Testing
—Comparison Testing
• If the output from each version is the
same,it is assumed that all implementations are correct.If the output is different,
each of the applications is investigated to
determine if a defect in one or more
versions is responsible for the difference.In
most cases,the comparison of outputs can
be performed by a automated tools.
SOFTWARE ENGINEERING
黑盒测试与白盒测试优缺点比较
黑盒测试
优
点
①适用于各阶段测试
②从产品功能角度测试
③容易入手生成测试数据
缺
点
①某些代码得不到测试
②如果规格说明有误，
则无法发现
③不易进行充分性测试
白盒测试
①可构成测试数据使特定程
序部分得到测试
②有一定的充分性度量手段
③可或较多工具支持
①不易生成测试数据(通常)
②无法对未实现规格说明的
部分进行测试
③工作量大，通常只用于单
元测试，有应用局限
性
质
是一种确认技术，回答
“我们在构造一个正确
的系统吗？”
是一种验证技术，回答
“我们在正确 地构造一个系
统吗？” SOFTWARE ENGINEERING
Testing for Specialized
Environments and Application
•
•
•
•
Testing GUIs
易用性测试
Testing of C/S Architectures
Testing Documentation and Help
Facilities
SOFTWARE ENGINEERING
Testing GUIs
• Graphical user interfaces(GUIs) present
interesting challenges for software engineers.
Because of reusable components provided as
part of GUI development environments,the
creation of the user interface has become less
time-consuming and more precise.At the
same time,the complexity of GUIs has grown,
leading to more difficulty in the design and
execution of test cases.
SOFTWARE ENGINEERING
Testing GUIs
• Because modern GUIs have the same
look and feel,a series of standard tests
can be derived.
• For Windows
• For pull-down menus and mouse operations
• For Data entry
SOFTWARE ENGINEERING
易用性测试
• 易用性测试没有一个量化的指标，主观性较
强。
• 调查表明，当用户不理解软件中的某个特性
时，大多数人首先会向同事、朋友请教。要
是再不起作用，就向产品支持部门打电话。
只有30%的用户会查阅用户手册。
• 一般认为，如果用户不翻阅手册就能使用软
件，那么表明这个软件具有较好的易用性。
SOFTWARE ENGINEERING
Testing Documentation
and Help Facilities
• 文档测试主要检查文档的正确性、完备性和可理解性。
• It is important to note that testing must also extend
to the third element of the software configuration—
documentation.
• Documentation testing can be approached in two
phases.The first phase,formal technique
review,examines the document for editorial
clarity.The second phase,live test,uses the
documentation in conjunction with the use of the
actual program.
SOFTWARE ENGINEERING
Summary
• The primary objective for test case
design is to derive a set of tests that have
the highest likelihood for uncovering
errors in the software.To accomplish this
objective,two different categories of test
case design techniques are used: whitebox testing and black-box testing.
SOFTWARE ENGINEERING
Summary
• White-box tests focus on the program
control structure.Test cases are derived
to ensure that all statements in the
program have been executed at least
once during testing and that all logical
condition have been exercised.
• (Basic path testing,Condition and data
flow testing,Loop testing)
SOFTWARE ENGINEERING
Summary
• Black-box tests are designed to uncover
error in functional requirements without
regard to the internal workings of a
program. Black-box testing techniques
focus on the information domain of the
software,deriving test cases by partitioning the input and output domain of a
program in a manner that provides
thorough test coverage.
SOFTWARE ENGINEERING
Summary
• Experienced software developer often say,
“Testing never ends,it just gets transferred
from you(the software engineer) to your
customer.Every time your customer uses the
program,a test is being conducted.”
• By applying test case design,the software
engineer can achieve more complete testing
and thereby uncover and correct the highest
number of errors before the “customer tests”
begin.
SOFTWARE ENGINEERING
Software Testing Strategies
• A strategy for software testing integrates
software case design methods into a
well-planned series of steps that result in
the successful construction of software.
• Testing and debugging are different
activities,but debugging must be
accommodate in any testing strategy.
SOFTWARE ENGINEERING
Verification and Validation
• Software testing is one element of a
broader topic that is often referred to as
verification and validation(V&V).
Verification refers to the set of activities
that ensure that software correctly
implements a specific function. Validation
refers to a different set of activities that
ensure that the software that has been built
is traceable to customer requirements.
SOFTWARE ENGINEERING
Verification and Validation
• Verification:
Are we building the product right?
• Validation:
Are we building the right product?
SOFTWARE ENGINEERING
Verification and Validation
• It is important to note that verification and
validation encompass a wide array of SQA
activities that include formal technical review,
quality and configuration audits, performance
monitoring,simulation, feasibility study, documentation review, database review,algorithm
analysis,development testing,qualification testing,
and installation testing.Although testing plays an
extremely important role in V&V,many other
activities are also necessary.
SOFTWARE ENGINEERING
Organizing for Software Testing
• The software developer is always
responsible for testing the individual
units(modules)of the program.
• In many cases,the developer also
conducts integration testing.
• Only after the software architecture is
complete does an independent test group
become involved.
SOFTWARE ENGINEERING
Organizing for Software Testing
• The developer and the independent test
group work closely throughout a
software project to ensure that thorough
tests will be conducted.While testing is
conducted,the developer must be
available to correct errors that are
uncovered.
SOFTWARE ENGINEERING
A Software Testing Strategy
模块
模块测试
模块
模块测试
……
模块
模块测试
测试过
的模块
经装配好
的软件 确认测试
确认过
的软件
组装测试
系统测试
其他系
统元素
可运行
的系统
软件试运行、验收
SOFTWARE ENGINEERING
A Software Testing Strategy
• Initially,tests focus on each module
individually,assuring that it functions
properly as a unit.Hence,the name unit
testing.
• Unit testing makes heavy use of whitebox testing techniques, exercising
specific paths in a module’s control
structure to ensure complete coverage
and maximum error detection.
SOFTWARE ENGINEERING
A Software Testing Strategy
• Next,modules must be assembled or
integrated to form the complete software
package. Integration testing addresses the
issues associated with the dual problem of
verification and program construction.
Black-box test case design techniques are
the most prevalent during integration,
although a limited amount of white-box
testing may be used to ensure coverage of
major control paths.
SOFTWARE ENGINEERING
A Software Testing Strategy
• After the software has been integrated
(constructed),validation criteria
(established during requirements
analysis) must be tested. Validation
testing provides final assurance that
software meets all functional,behavioral,
and performance requirements. Blackbox testing techniques are used
exclusively during validation.
SOFTWARE ENGINEERING
A Software Testing Strategy
• The last high-order testing step falls
outside the boundary of software
engineering and into the broader context
of computer system engineering. Software,
once validated, must be combined with
other system elements (e.g.,hardware,
people).system testing verifies that all
elements mesh properly and that overall
system function/performance is achieved.
SOFTWARE ENGINEERING
Criteria for Completion of Testing
• When are we done testing—how do we
know that we’ve tested enough?
• You’re never done testing,the burden
simply shifts from you (the developer) to
your customer.
• You’re done testing when you run out of
time or you run out of money.
SOFTWARE ENGINEERING
Software Testing Strategies
• Specify product requirements in a
quantifiable manner long before testing
commences.
• State testing objectives explicitly.
• Understand the user of the software and
develop a profile for each user category.
• Develop a testing plan that emphasizes
“rapid cycle testing.”
SOFTWARE ENGINEERING
Software Testing Strategies
• Build “robust” software that is designed
to test itself.
• Use effective formal technical reviews as
a filter prior to testing.
• Conduct formal technical reviews to
assess the test strategy and test cases
themselves.
• Develop a continuous improvement
approach for the testing process.
SOFTWARE ENGINEERING
测试步骤
单元测试
集成测试
有效性测试
系统测试
α测试
培训和试运行
β测试
接收测试
运行和维护
正式发布软件
软件改版
SOFTWARE ENGINEERING
Unit Testing
• 单元测试一般认为并不包括于测试阶段
而是包括于编程阶段。因此单元测试计
划一般由模块编写人员制定，而单元测
试一般也由模块编写人员进行。
编程
其他测试……
(同步)单元测试
SOFTWARE ENGINEERING
Unit Testing
• Unit testing focuses verification effort on
the smallest unit of software design—the
module.
• The relative complexity of tests and
uncovered errors is limited by the
constrained scope established for unit
testing.The unit test is normally white-box
oriented,and the step can be conducted in
parallel for multiple modules.
SOFTWARE ENGINEERING
Unit Testing
• After source-level code has been developed,
reviewed,and verified for correct syntax,unit
test case design begins.
1. The module interface is tested to ensure that
the information properly flows into and out of
the program unit under test.
2. The local data structure is examined to ensure
that data stored temporarily maintains its
integrity during all steps in an algorithm’s
execution.
SOFTWARE ENGINEERING
Unit Testing
3. Boundary conditions are tested to ensure that
module operates properly at boundaries
established to limit or restrict processing.
4. All independent paths(basic paths)through the
control structure are exercised to ensure that
all statements in a module have been executed
at least once.
5. And finally,all error handling paths are tested.
• Checklist ……
SOFTWARE ENGINEERING
Unit Testing
driver
Module to be tested
stub
……
stub
Unit test environment
SOFTWARE ENGINEERING
Unit Testing
• Because a module is not a standalone
program,driver and/or stub software
(unit test environment) must be develop
for each unit test.
• Drivers and stubs represent overhead.
That is,both are software that must be
developed but that is not delivered with
the final software product.
SOFTWARE ENGINEERING
Unit Testing
• If drivers and stubs are kept simple,
actual overhead is relatively low.
Unfortunately,many modules cannot be
adequately unit tested with “simple”
overhead software.In such case,complete
testing can be postponed until the
integration test step(where drivers and
stubs are also used).
SOFTWARE ENGINEERING
Unit Testing
• 驱动模块是模拟主程序或者调用模块的功能，处于
被测试模块的上层，所以驱动模块只需要模拟向被
测模块传递数据，接收、打印从被测模块返回的数
据的功能，较容易实现。
• 而桩模块用于模拟那些由被测模块所调用的下属模
块的功能，由于下属模块往往不只一个，也不只一
层，由于模块接口的复杂性，桩模块很难模拟各下
层模块之间的调用关系，同时为了模拟下层模块的
不同功能，需要编写多个桩模块，而这些桩模块所
模拟的功能是否正确，也很难进行验证。
• 综上，驱动模块的设计显然比桩模块容易。
SOFTWARE ENGINEERING
测试步骤
单元测试
集成测试
有效性测试
系统测试
α测试
培训和试运行
β测试
接收测试
运行和维护
正式发布软件
软件改版
SOFTWARE ENGINEERING
Integration Testing
• Integration testing is a systematic
technique for constructing the program
structure while conducting tests to
uncover errors associated with
interfacing. The objective is to take unit
tested modules and build a program
structure that has been dictated by
design.
SOFTWARE ENGINEERING
Integration Testing
• There is often a tendency to attempt
non-incremental integration; that is,to
construct the program using a “big bang”
approach.All modules are combined in
advance.
correction is difficult
SOFTWARE ENGINEERING
Integration Testing
• Incremental integration is the antithesis
of the big bang approach.The program
is constructed and tested in small
segments,where errors are easier to
isolate and correct;interfaces are more
likely to be tested completely;and a
systematic test approach may be applied.
SOFTWARE ENGINEERING
Integration Testing
— Incremental Integration
Top-Down
Integration
Incremental
integration
Depth-First
Breadth-First
Bottom-Up
Integration
SOFTWARE ENGINEERING
Integration Testing—Incremental integration
—Top-Down Integration
• Top-down integration is an incremental
approach to construction of program
structure. Modules are integrated by moving
downward through the control hierarchy,
beginning with the main control module(main
program). Modules subordinate(and
ultimately subordinate) to the main control
module are incorporated into the structure in
either a depth-first or breadth-first manner.
SOFTWARE ENGINEERING
Integration Testing—Incremental integration
—Top-Down Integration
• The top-down integration strategy verifies
major control or decision points early in
the test process.
• The top-down integration approach (delay
tests until stubs are replaced by actual
modules) causes us to lose some control
over correspondence between specific tests
and incorporation of specific modules.
SOFTWARE ENGINEERING
Integration Testing—Incremental integration
—Bottom-Up Integration
• Bottom-up integration testing,as its
name implies,begins construction and
testing with atomic modules(i.e.,modules
at the lowest levels in the program
structure).
• As integration moves upward, the need
for separate test drivers lessens.
SOFTWARE ENGINEERING
非渐增式与渐增式比较
• 非渐增式是将所有的模块一次连接起来，简单、易
行，节省机时，但测试过程中难于查错，发现错误
也很难定位，测试效率低。
• 渐增式是将模块一个一个地连入系统，每连入一个
模块，都要对新系统进行测试。这种组装测试方案
比较非渐增式，容易查出错误及进行错误定位，有
利于查出模块接口部分的错误，因此测试效率高。
但渐增式较费机时。
• 比较两种组装测试方案，显然渐增式有利于实现测
试的目标，故通常采用渐增式进行组装测试。
SOFTWARE ENGINEERING
Integration Testing
—Incremental Integration
• There has been much discussion of the
relative advantages and disadvantages of
top-down versus bottom-up integration
testing.In general,the advantages of one
strategy tend to result in disadvantages
for the other strategy.
SOFTWARE ENGINEERING
顶下法和底上法比较
• 自顶而下增值
• 优点：能够尽早发现系统主控方面的问题。
• 缺点：无法验证桩模块是否完全模拟了下
属模块的功能。
• 自底而上增值
• 优点：驱动模块较容易编写桩模块，能够
尽早查出底层涉及较复杂的算法和实际的
I/O模块中的错误。
• 缺点：最后才能发现系统主控方面的问题。
SOFTWARE ENGINEERING
Integration Testing
—Incremental Integration
• Selection of an integration strategy
depends upon software characteristics
and sometimes,project schedule.In
general,a combined approach that uses a
top-down strategy for upper levels of the
program structure,coupled with a
bottom-up strategy for subordinate
levels may be the best compromise(折衷).
SOFTWARE ENGINEERING
Integration Test Documentation
• An overall plan for integration of the
software and a description of specific
tests are documented in a test
specification. The specification is a
deliverable in the software engineering
process and becomes part of the
software configuration.
• Test specification outline ……
SOFTWARE ENGINEERING
测试步骤
单元测试
集成测试
有效性测试
系统测试
α测试
培训和试运行
β测试
接收测试
运行和维护
正式发布软件
软件改版
SOFTWARE ENGINEERING
Validation(有效性) Testing
• At the culmination of integration testing,
software is completely assembled as a package;
interface errors have been uncovered and
corrected,and a final series of software tests—
validation testing—may begin.
• Validation can be defined in many ways,but a
simple definition is that validation succeeds
when software functions in a manner that can
be reasonably expected by customer.
SOFTWARE ENGINEERING
Validation(确认) Testing
• Reasonably expectations are defined in
the software requirements specification—
a document that describes all uservisible attributes of the software.The
specification contains a section titled
“Validation Criteria.” Information
contained in that section forms the basic
for a validation testing approach.
SOFTWARE ENGINEERING
Validation Testing
• Software validation is achieved through a
series of black-box tests that demonstrate
conformity with requirements.
• After each validation test case has been
conducted,one of two possible conditions exist:
1) The function or performance characteristics
conform to specification and are accepted,or
2) A deviation from specification is uncovered
and a deficiency list created.
SOFTWARE ENGINEERING
Validation Testing
• A deviation or error discovered at this
stage in a project can rarely be corrected
prior to scheduled completion.
• It is often necessary to negotiate with
the customer to establish a method for
resolving deficiencies.
SOFTWARE ENGINEERING
Validation Testing
—Configuration Review
• An important element of the validation
process is a configuration review.The
intent of the review is to ensure that all
elements of the software configuration
have been properly developed, are
catalogued, and have the necessary
detail to support the maintenance phase
of the software life cycle.
SOFTWARE ENGINEERING
Validation Testing
—Configuration Review
已集成的软件
要求
有效性
测试
管理批准
用户文件
设计文件
代码列表
配置复审
颁布的软件
测试文件
软件配置复审
SOFTWARE ENGINEERING
测试步骤
单元测试
集成测试
有效性测试
系统测试
α测试
培训和试运行
β测试
接收测试
运行和维护
正式发布软件
软件改版
SOFTWARE ENGINEERING
System(系统) Testing
• Ultimately,software is incorporated with
other system elements,and a series of system
integration and validation tests are conducted.
• System testing is actually a series of different
tests whose primary purpose is to fully exercise
the computer-based system.Although each test
has a different purpose,all work to verify that
all system elements have been properly
integrated and perform allocated functions.
SOFTWARE ENGINEERING
System(系统) Testing
•
•
•
•
Recovery(恢复) Testing
Security(安全性) Testing
Stress(压力) Testing
Performance(性能) Testing等
• 系统测试中存在的一个典型问题就是
“扯皮”。
SOFTWARE ENGINEERING
并行测试
• 并行（运行）测试（平行测试、双轨制
运行、试运行)就是同时运行新开发的系
统和将被它取代的旧系统（人工系统或
计算机系统），以便比较新旧两个系统
的处理结果。并行（运行）测试在开发
方的指导下主要由用户方承担。
• 双轨制运行的时间长短取决于项目的类
型。一般从半个月到三个月。
SOFTWARE ENGINEERING
Acceptance(验收) Testing
• When customer software is built for one
customer,a series of acceptance tests are
conducted to enable the customer to validate
all requirements.
• Conducted by the end user rather than the
system developer,an acceptance test can
range from an informal(非正式的) “test drive”
to a planned and systematically executed series
of tests.
SOFTWARE ENGINEERING
Acceptance(验收) Testing
• 该类测试经常采用实际数据进行测试，
由最终用户和开发单位共同完成，以最
终用户为主。
• 验收测试作为试运行（并行测试） 的最
后一步，一般都只是一个形式，时间也
比较短，经过验收后的软件将正式移交
给用户，系统进入维护期。
SOFTWARE ENGINEERING
测试步骤
单元测试
集成测试
有效性测试
系统测试
α测试
培训和试运行
β测试
接收测试
运行和维护
正式发布软件
软件改版
SOFTWARE ENGINEERING
Alpha(α) Testing
• The alpha test is conducted at the
developer’s site by a customer.The
software is used in a natural setting with
the developer “looking over the shoulder”
of the user and recording errors and
usage problems.Alpha tests are
conducted in a controlled environment.
SOFTWARE ENGINEERING
Beta(β) Testing
• The beta test is conducted at one or more
customer sites by the end user(s) of the software.
• The beta test is a “live” application of the
software in an environment that cannot be
controlled by the developer.
• As a result of problems reported during beta
testing,the software developer makes
modifications and then prepares for release of the
software product to the entire customer base.
SOFTWARE ENGINEERING
测试文档
• 测试必须按照软件需求和设计阶段所制
订的“测试计划”进行，其结果以“测
试分析报告”的形式提交。与软件测试
直接相关的文档主要有：“测试计划
（可细化为测试计划，测试设计说明，
测试用例说明和测试规格说明）”和
“测试分析报告（可细化为测试项传递
报告，测试日志，测试事件报告和测试
SOFTWARE ENGINEERING
总结报告）”。
测试文档
• “测试计划”包括整个软件的组装测试
和有效性测试，但不包括各模块的单元
测试，编制该文档的目的是提供一个对
该软件的总体测试安排，包括对每一项
测试活动的详细设计规定和调度顺序，
以及测试数据的整理方法和评价准则。
SOFTWARE ENGINEERING
测试文档
• 编制“测试分析报告”的目的是把每一项
测试的结果、发现以及分析写成文档，对
被测试软件说明经过验证的能力和缺陷，
并最终说明预定的开发目标是否达到？能
否交付使用？
• 这两份文档的格式要求可参见国家标准
GB8567《计算机软件产品开发文件编制
指南》和GB9386《计算机软件测试文件
编制规范》。
SOFTWARE ENGINEERING
调试和纠错
软件配置
回归测试
评价
错误
纠错
改正
测试
测试配置
测试计划文
档的一部分
可靠性
模型
预测的可靠性
SOFTWARE ENGINEERING
The Art of Debugging
• Debugging(调试) occurs as a consequence
of successful testing.That is,when a test
uncovers an error,debugging is the process
that results in removal of the error.
• 改错是个大悲大喜的过程，一天之内可以
让人在悲伤的低谷和喜悦的颠峰之间跌荡
起伏。最重要的是确认错误可以重现。
SOFTWARE ENGINEERING
The Art of Debugging
• The debugging process attempts to
match symptom with cause,thereby
leading to error correct.
• The correction of a bug can introduce
other error.
• 关于改错的几点建议：要有勇气；不可蛮
干；找出错误的根源；在改错之后一定要
马上进行回归测试。
SOFTWARE ENGINEERING
The Art of Debugging
• 排错（纠错）的过程可以定义为：从发
现错误存在的迹象（所以要求测试用例
必须有预期结果）开始，确定程序中可
疑错误的确切性质和位置，从而进行修
改错误的过程。测试与排错是相互联系
的。排错过程也需要花费很大的代价。
SOFTWARE ENGINEERING
The Art of Debugging
• 在对某个程序进行前应该进行的第
一件事是？
• 备份好该程序
• 修改、调试结束后该备份是否应该
被删除？
SOFTWARE ENGINEERING
The Art of Debugging
• 在软件排错过程中，可能遇到大大小小、
形形色色的问题，随着问题的增多，排
错人员的压力也随之增大，过分地紧张
致使开发人员在排除一个问题的同时又
引入更多的新问题。
• 修改完错误后必须想想同样的错误在别
的程序中有可能也存在吗？
SOFTWARE ENGINEERING
The Art of Debugging
• Unfortunately,there appears to be some
evidence that debugging prowess is an
innate(先天的) human trait.
• Heightened anxiety,and the unwillingness
to accept the possibility of errors,
increases the debugging difficulty.
SOFTWARE ENGINEERING
Debugging Approaches
• Regardless of approach that is taken,
debugging has one overriding objective:
to find and correct the cause of a
software error.
• In general,three categories for debugging
approaches may be proposed: (1)brute
force; (2)backtracking;and (3)cause
elimination.
SOFTWARE ENGINEERING
Debugging Approaches
1. Brute force:Using a “let the computer find
the error” philosophy,memory dumps are
taken,run-time traces are invoked,and the
program is loaded with WRITE statements.
2. Backtracking:Beginning at the site where a
symptom has been uncovered,the source
code is traced backward(manually)until
the site of the cause is found.
SOFTWARE ENGINEERING
Debugging Approaches
3. Cause elimination is manifested by induction
or deduction and introduces the concept of
binary partitioning.A “cause hypothesis” is
devised and the data are used to prove or
disprove the hypothesis.
4. Any discussion of debugging approach and
tools is incomplete without mention of a
powerful ally:other people!A final maxim for
debugging might be: “When all else fails,get
help!”
SOFTWARE ENGINEERING
Regression(回归) Testing
• Regression testing is the re-execution of some
subset of tests that have already been
conducted to ensure that changes have not
propagated unintended side effects.
• Regression testing is the activity that helps to
ensure that changes(due to testing or for
other reasons) do not introduce unintended
behavior or additional errors.
SOFTWARE ENGINEERING
Summary(小结)
• The objective of software testing is to
uncover errors.
• Each test step is accomplished through a
series systematic test techniques that
assist in the design of test cases.
• Unlike testing,debugging must be viewed
as an art.
SOFTWARE ENGINEERING
Summary (小结)
• 只有单元测试、组装测试和有效性测试属于
软件测试的范畴，这几类测试均包含“纠错”
和“回归测试”（在纠错结束后，按原有测
试用例再次进行测试）两个步骤。而系统测
试、并行测试和验收测试均由开发方和使用
单位共同完成，后三类测试中发现的软件问
题一般无法在合同规定的时间内进行修改，
经常作为备忘录的形式记录在案，或等待软
件改版时修改。
SOFTWARE ENGINEERING
本章内容讲授到此结束！
福州大学·软件学院·计算机教研室·王灿辉
SOFTWARE ENGINEERING