成为一名高级软件测试人员

«EKM.

成为一名高级软件测试人员

容:

•软件测试基础

•黑盒测试方法

•白盒测试方法

•软件缺陷管理

2

软件测试全景图

「本地化测试

7衣盒方法«卜符号执行

-国际化测试

L决策表一形式化方法

赖拉丧版要数据驱动-功能测试

-确认一等价类划分一基本路径

关犍词驱动-负载测试

-边界值分析

一正交实验方法-组合覆盖

1J-性能测试

测试脚本-因果图法

L测试套件一条件覆盖

-安全性测试

-错误推测法

测试;上具一测试环境-判定覆盖一恢复测试

-功能图

-语句覆盖-安装测试

0一测试数据-Ad-hoc法

自动化测试「代码审查一兼容性测试

测试执行黑盒方正、

手工测试方法白盒方法一可用性测试

•'-可靠性测谎

方法

发现涌走

k动态测试《

缺陷质量完整

产静态测试＜览证

一缺陷报告

源泉

一缺陷生命周期

阶段思想

一缺陷跟踪

/实施指导

一趋势分析Xa

一测试策略一质量文化

一分布分析-需求审查

一客户需求

—缺陷清除率—设计审查一测试风险

一资源/进度一质量保证

—质量评估—单元测试

一测试计划一测试现实

I-缺陷而防-集成测试

一实验室一测试原则

（回归一系统测谎

一测试团队一测试驱动

-验收测谎

冒烟测试一测试覆盖一成熟度模型

BVT/SVT一。测试

—测激报告

L测试

一模板

或伴的试基本疏速j

需求分析说明书

1）项目规划阶段：负责从单元测试到系

统测试的整个测试阶段的监控。概要设计说明15

2）需求分析阶段：确定测试需求分析、

系统测试计划的制定、评审后的管理。详细设计说明书

其中，测试需求分析是对产品生命周期

中测试所需求的资源、配置、及评审；__________i__________

系统测试计划是依据软件的需求规格说源程序代码

明书，设计测试用例与测试的实施等。

__________1__________

3）概要设计与详细设计阶段：确保单元单元测试

测试、集成测试和系统测试计划完成。

▼

4）编码阶段：该阶段主要由开发人员自集成测试

己负责部分的代码测试。在较在的项目

中，将由专人进行编码阶段的测试任务。

系统测试

5）测试阶段：实施单元、集成、系统、

验收测试，并提交相应的测试报告。__________X__________

验收测试

*

耿伴旃试模型二T74

•v模型

•强调了在整个软件项目开发中需要经历的若干个测试

级别，并与每一个开发级别对应；忽略了测试的对象

不应该仅仅包括程序，没有明确指出对需求、设计的

测试

5

软件以4试模型一2/4

•w模型

•补充了V模型中忽略的内容，强调了测试计划等工作的先

行和对系统需求和系统设计的测试；与V模型相同，没有

对软件测试的流程进行说明

6

■

二瓶伴试模或二3/4

•H模型

・强调测试是独立的，只要测试准备完成，就可以执行测试

7

孰伴的试模迪:4/4

•x模型

8

试模型小结号

•V模型

•是软件开发瀑布模型的变种，主要反映测试活动与分析和设计的关系；局

限性：把测试作为编码之后的最后一个活动，需求分析等前期产生的错误

直到后期的验收测试才能发现

•W模型

•在V模型的基础上，增加千开发阶段的同步测试，形成w模型；测试与开发

同步进行，有利用尽早的发现问题

•局限性：仍把开发活动看成是从需求开始到编码结束的串行活动，只有上

一阶段完成后，才可以开始下一阶段的活动，不能支持迭代，自发性以及

变更调整

•H模型

•在H模型中，软件测试过程活动完全独立，贯穿于整个产品的周期，与其他

流程并发地进行，某个测试点准备就绪时，就可以从测试准备阶段进行到

测试执行阶段；软件测试可以进行尽早的进行；软件测试可以根据被测物

的不同而分层次进行

•X模型：

•X模型也是对V模型的改进,X模型提出针对单独的程序片段进行相互分离的

编码和测试,此后通过频繁的交接，通过集成最终合成为可执行的程序。

9

■—，h1TzJ_二一，二~1-_._

联伴测试一般步骤二1/2

口获取需求、功能设计、详细设计规格和其它必须文档

2、获取预算和时间安排需求

3、确定项目相关人员和他们的责任，汇报需求，必须的标准和过程（如

蔽术过

程、变更过程等）

4、确认应用高风险的部分，设定优先级，确定测试的范围和限制

力确定测试的方法一一单元测试、集成测试、功能测试、负荷测试、可

南性测

试等

6、确定环境需求（软件/硬件/通信等）

7、确定测试用具环境（记录/回放工具、覆盖率分析器、测试跟踪、问

期跟踪等

等）

8、确定测试输入需求

9、确定任务，任务责任和相应的工作量

1。、设定时间安排估计、时间表、里程碑等

IO

测试一般步骤二2/2

U、确定输入的等价类、边界值分析、错误类

12、准备测试计划文档和需要的评审

13、写测试用例

14、对测试用例进行必须的评审

巧、准备测试环境和测试用具，获取需要的用户手册/参考文

电/配置指导/安装

指导，建立跟踪过程，日志和存档过程，获取测试数据

16、获取和安装软件版本

17、执行测试

18、评价和汇报测试结果

19、跟踪问题和修改

20、如果需要进行再测试

21、在整个生命周期内维护和修改测试计划、测试用例、测

试环境和测试用具

11

_x—~「，，，，♦…1-•_*^•*A--,,.j一磔一

■1^^^5333333^=

•单元测试

•开发者编写的一小段代码，用于检验被测代码的一个很小的、很明确的功能是否正确

•冒烟测试

•在每日构建完成后，对系统的基本功能进行简单的测试

•集成测试

•将所有模块按照概要设计说明书和详细设计说明书的要求进行组装

•确认测试

•确认测试又称有效性测试。在模拟的环境下，运用黑盒测试的方法，验证被测软件是

否满足需求规格说明书列出的需求

•系统测试

•与硬件、网络、外设、支撑软件、数据以及人员结合在一起，在实际或模拟环境下，

对计算机系统进行测试

•验收测试

•以用户为主的对核心业务流程进行的测试

•回归测试

•软件维护阶段对软件修改后进行的测试

12

测试方法一

•黑盒测试-也称功能测试或数据驱动测试，它是在已知

产品所应具有的功能，通过测试来检测每个功能是否都

能正常使用，主要有等价类划分、边值分析、因果图、

错误推测等测试方法。

•白盒测试-也称结构测试或逻辑驱动测试，它是知道产

品内部工作过程，可通过测试来检测产品内部动作是否

按照规格说明书的规定正常进行，按照程序内部的结构

测试程序，检验程序中的每条通路是否都有能按预定要

求正确工作

•灰盒测试-介于二者之间，关注输出对于输入的正确性,

同时也关注内部表现

13

«EKM.

策略一

•功能测试，界面测试，兼容性测试，分布测试

•性能测试，可靠性测试，负载测试，容量测试，压力

测试，可用性测试

•易用性测试，安全测试，配置测试，故障恢复测试，

加密测试

•数据库测试，值域测试

•安装测试，卸载测试，可移植性测试，文挡测试，版

本验证测试，裸机测试。

14

变更申请＞变更评市变更批准

制定项目测试计划

是否批准拒绝变更

设计测试用例

变更实施

验证效果

构建测试环境

回归测试

执行测试

验收测试

15

1、标题

2、确定软件的版本号

3、修订文档历史，包括作者、日期和批示

4、目录表

5、文档的目的和适合的读者群

6、测试的目的

7、软件产品概述

8、相关文档列表，例如：需求、设计文档、其他测试计划

等

二相关的标准或合法需求

10、可跟踪性需求

11、相关的命名规范和标识符规范

12、整个软件项目组织和人员/联系信息/责任

16

13、测试组织和人员/联系信息/责任

14、假设和依赖关系

巧、项目风险信息

16、测试优先级和焦点

17、测试范围和限制

1%测试提纲一一对测试过程的一个分解，通过测试类型、特点、

而能性、过

程、系统、模块等

20、测试环境设置和配置问题

21、数据库设置需求

22、概述系统日志/错误日志/其他性能，有助于描述和汇报问题的

屏幕捕获工具

等

23、有助于测试者跟踪问题根源的具体软硬件工具的论述

24、测试自动化的可能性和概述

17

25、使用的测试工具，包括版本、补丁等

26、使用的项目测试度量

27、报告需求和测试可传递性

28、软件入口和出口准则

29、初始的理性测试阶段和标准

3。、测试终止和重新开始的标准

贝、人员安排

32、测试地点

不、用到的测试外的组织，他们的目的、责任、可传递性

联系人和协作问题

34、相关的财产、分类、安全性和许可证问题

35、公开的一些问题

36、附录一一词汇表、缩略语等

•一个测试用例就是一个文档，描述输入、动作、或者时

间和一个期望的结果，其目的是确定应用程序的某个特

性是否正常的工作。

■测试用例就是将软件测试的行为活动，做一个科学化的

组织归纳。

•开发测试用例的过程有助于在应用的需求和设计过程中

发现问题。

・测试用例是测试工作的指导。

19

为向需要测钛用前1

软件测试是有组织性、步骤性和计划性的，为了能将软件

测试的行为转换为可管理的、具体量化的模式，需要创建

和维护测试用例。

•在开始实施测试之前设计好测试用例，避免盲目测试并提高测试效率，

减少测试的不完全性；

•测试用例的使用令软件测试的实施重点突出、目的明确；

•根据测试用例的多少和执行难度，估算测试工作量，便于测试项目的时

间和资源管理与跟踪；

•减少回归测试的复杂程度

•在软件版本更新后只需修正少量的测试用例便可展开测试工作，降低工

作强度、缩短项目周期；

•功能模块的测试用例的通用化和复用化则会使软件测试易于开展，并随

着测试用例的不断细化其效率也不断攀升；

•根据测试用例的操作步骤和执行结果，可以方便地书写软件测试缺陷报

告；

•可以根据测试用例的执行等级，实施不同级别的测试；

•为分析软件缺陷和程序模块质量提供依据；

•便于大型软件测试项目外包测试指导基础；2

口测试用例编号ID•测试输入条件

ID类型标题测试步骤期望的结果说明

001登录输入正确密用户在登录界面输入正确的密程序提示登录成

码码后，按回车键功

002登录输入错误密用户在登录界面输入错误的密程序提示输入密

码码后，按回车键码错误，请重新

输入

003登录不输入的空用户在登录界面没有输入任何程序提示用户没程序应该告知

密码密码使密码为空后，按回车键有输入密码，请用户没有输入

输入密码，而不是

密码错误

21

甬例管理I

设计用倒

用羯更新

22

•软件测试基础

•黑盒测试方法

•白盒测试方法

•软件缺陷管理

23

黑盒测试又称功能测试、数据驱动测试或基于规

格说明书的测试，是一种从用户观点出发的测试。

测试人员把被测程序当作一个黑盒子。

输A--------------输出

24

主要驯到的错用臭类型

1)不正确或遗漏的功能；

2)接口、界面错误；

3)性能错误；

4)数据结构或外部数据访问错误;

5)初始化或终止条件错误等等

局限性：用黑盒测试发现程序中的错误，必须在所

有可能的输入条件和输出条件中确定测试数据，来

检查程序是否都能产生正确的输出。但这是不可能

的，因为穷举测试数量太大，无法完成。

25

二黑盒测试局限性

用黑盒测试发现程序中的错误，必须在所有可能的

输入条件和输出条件中确定测试数据，来检查程序

是否都能产生正确的输出。但这是不可能的，因为

穷举测试数量太大，无法完成。

假设一个程序P有输入量X和Y及输出量Z。在字长为32位的计算机上

运行。若X、Y取整数，按黑盒方法进行穷举测试：

可能采用的测试数据组：

232X232=264

如果测试一组数据需要1毫秒，一年工作365X24小时，完成所有测

试需5亿年。

X

PZ

26

•等价类划分方法

•边界值分析方法

•因果图方法

•场景法

•正交实验设计方法

•判定表驱动分析方法

•错误推测方法

・功能图分析方法

27

•有效等价类-是指对于程序的规格说明来说是合理的、有意义的输

入数据构成的集合

•无效等价类-是指对于程序的规格说明来说是不合理的、没有意义

的输入数据构成的集合

•确定等价类的原则

1.在输入釜件规定了取值范围或值的个数的情况下，则可以确立一个有

效等价赛和两个无效易价类。

I辟情脑藕瞥霰翻蕊鹫玉瀛程何”的条件的情

3.耍篡叁需集是一个布尔量的情况下，可以确立一个有效等价类和一个

4.在规3了看入数据的一组值（假定n个），并且程序要对每一个输入

值分别处理的情况下，可以确立n个有效等价类和一个无效等价类。

■翳赢播辞糕翻娥知嬲靛翁效叫

6・髓智翻勰甄驾畲羸窝爵墙欧方式不同的情况E

28

边界值分析

•根据经验法则，大量的错误是发生在输入或输出范围的

边界上，而不是发生在输入输出范围的内部.因此针对各

种边界情况设计测试用例，可以查出更多的错误。

•使用边界值分析方法设计测试用例，首先应确定边界情

况。通常输入和输出等价类的边界，就是应着重测试的

边界情况.应当选取正好等于，刚刚大于或刚刚小于边界

的值作为测试数据,而不是选取等价类中的典型值或任

意值作为测试数据.

29

边界值选择的1式®r1/6

原则1:如果输入条件规定了值的范围，则应取刚达到这

个范围的边界的值，以及刚刚超越这个范围边界的值作为

测试输入数据。

•例如，如果程序的规格说明中规定：“重量在1。公斤

至5。公斤范围内的邮件，其邮费计算公式为…工作

为测试用例，我们应取及5。，还应取

10.01,49・99,9・99及5。・。1等0

30

边界值选择的康员42/6

原则2:如果输入条件规定了值的个数,则用最大个数，最

小个数，比最小个数少一，比最大个数多一的数作为测试

数据。

•例如，一个输入文件应包括1〜255个记录，则测试用例

可取1和255，还应取o及256等。

31

边界值选择留硬则3/61

原则3：将原则1）和2）应用于输出条件，即设计测试

用例使输出值达到边界值及其左右的值。

•例如，某程序的规格说明要求计算出“每月保险金扣

除额为o至116525元“，其测试用例可取0.00及1165.24、

还可取一0.01及1165.26等。

•再如一程序属于情报检索系统，要求每次”最少显示1

条、最多显示4条情报摘要”，这时我们应考虑的测试

用例包括I和4，还应包括。和5等。

32

边界值选择弱康则牛6i

•原则4：如果程序的规格说明给出的输入域或输出域是

有序集合，则应选取集合的第一个元素和最后一个元素

作为测试用例。

•原则5：如果程序中使用了一个内部数据结构，则应当

选择这个内部数据结构的边界上的值作为测试用例。

•原则6：分析规格说明，找出其它可能的边界条件。

33

•下列那组数据为对日期2000/1/1〜2005/12/31的边界值

测试用例()

(A)非闰年的2月30/31日(B)非闰年的2月28/eg日

(C)所有年份的12/13日(D)每月的巧日

34

由桌国

•定义：一种利用图解法分析输入的各种组合情况，从而

设计测试用例的方法，它适合于检查程序输入条件的各

种组合情况。

•利用因果图生成测试用例的基本步骤

】•分析软件规格说明描述中哪些是原因，哪些是结果，并给

每个原因和结果赋予一个标识符。

2.分析软件规格说明描述的语义。找出原因和结果之间、原

因和原因之间的关系，根据这些关系，画出因果图。

3.在因果图上用一些记号表明约束或限制条件。

4.把因果图转换为判定表。

5.把判定表的每一列拿出来作为依据，设计测试用例

「囱桌图基本符喜和约束符号

约束符号

®--------------®

恒等

O＜、

唯一''⑥

基本符号约束符号

36

有一个处理单价为5角钱的饮料的自动售货机软件测试用例的设

计。其规格说明如下：若投入5角钱或1元钱的硬币，押下

K橙汁』或K啤酒』的按钮，则相应的饮料就送出来。若售

货机没有零钱找，则一个显示K零钱找完］的红灯亮，这时

在投入1元硬币并押下按钮后，饮料不送出来而且1元硬币也

退出来；若有零钱找，则显示K零钱找完工的红灯灭，在送

出饮料的同时退还5角硬币。

原因：

售货机有零钱找、投入1元硬币、投入5角硬币、押下橙汁按

钮、押下啤酒按钮

结果：

售货机K零钱找完》灯亮、退还1元硬币、退还5角硬币、送

出橙汁饮料、送出啤酒饮料

多货机有零钱找售货机"零钱找完"灯亮

Q)1、_2_/1)

投入】元硬币②退还1元硬币

投入5甬硬币该找5角找问5甬硬币

押下按钿

押下橙汁按钮送出悔汁饮料

押下啤酒按钿送出啤酒饮料

38

•定义-一般包含基本流和备用流，从一个流程开始，通

过描述经过的路径来确定的过程，经过遍历所有的基本

流和备用流来完成整个场景

•基本流-就是正常的，正确场景

•备选流-一般指中断操作的

39

•正交表

•定义-是研究多因素多水平的一种设计方法，它是根据

正交性从全面试验中挑选出部分有代表性的点进行试验,

这些有代表性的点具备了“均匀分散，齐整可比”的特

点，正交试验设计是一种基于正交表的、高效率、快速、

经济的试验设计方法

•构成

•Runs正交表的行数，即实验的次数

•Factors正交表的列数，即因素数

•Levels水平数，任何单个因素能够取得的值的最大个数

•形式

行数（水平数因素数）（A）

•LLrunslevelsfactors

A

•L4（23）3个变量，每个变量2个取值，得到4个用例

40

7

L8（2）：

41

用立女表设正统j试用例为安琳

1.有哪些因素（变量）

2.每个因素有哪几个水平（变量的取值）：用等

价类划分出来的

3-选择一个合适的正交表

4-把变量的值映射到表中

5-把每一行的各因素水平的组合做为一个测试用

例

6.加上你认为可疑且没有在表中出现的组合

42

茹择正交室^

取行数最少的一个，情况分三种

1.因素数（变量）、水平数（变量值）相符

2.因素数不相同:取因素数最接近但略大的实际值的表

3.水平数不相同：

♦:♦有五个因素（变量）A、B、C>D和E。两个因素

有两个水平（变量的取值）、两个因素有三个水平,

一个因素有六个水平。行数取最少的一个（行数

取最少的一个（L49（78）、L18（3660

43

•定义：判定表是分析和表达多逻辑条件下执行不同操作

的情况的工具

•构成

•条件桩(ConditionStub)：列出了问题的所有条件。通常认

为列出的条件的次序无关紧要

•动作桩(ActionStub)：列出了问题规定可能采取的操作。

这些操作的排列顺序没有约束

•条件项(ConditionEntry)：列出针对它左列条件的取值。

在所有可能情况下的真假值

•动作项(ActionEntry)：列出在条件项的各种取值情况下应

该采取的动作

44

45

•错误推测法:基于经验和直觉推测程序中所

有可能存在的各种错误,从而有针对性的设

计测试用例的方法。

•错误推测方法的基本思想:列举出程序中所

有可能有的错误和容易发生错误的特殊情况,

根据它们选择测试用例。

46

费谟蕤测法-第

•测试一个对线性表（比如数组）进行排序的

程序，可推测列出以下几项需要特别测试的

情况：

1）输入的线性表为空表；

2）表中只含有一个元素；

3）输入表中所有元素已排好序；

4）输入表已按逆序排好；

5）输入表中部分或全部元素相同

47

例方法的琮杳策哈

Myers提出了使用各种测试方法的综合策略:

1)在任何情况下都必须使用边界值分析方法。经验表明

用这种方法设计出测试用例发现程序错误的能力最强。

2)必要时用等价类划分方法补充一些测试用例。

3)用错误推测法再追加一些测试用例。

4)对照程序逻辑，检查已设计出的测试用例的逻辑覆盖

程度。如果没有达到要求的覆盖标准，应当再补充足

够的测试用例。

5)如果程序的功能说明中含有输入条件的组合情况，则

一开始就可选用因果图法。

48

•对于参数配置类的软件，要用（）选择较少的组合

方式达到最佳效果？

（A）等价类划分（B）因果图法

（C）正交试验法（D）场景法

49

•软件测试基础

•黑盒测试方法

•白盒测试方法

•软件缺陷管理

50

「为何进行白食统j试

假设此时开发工作已结束，程序

送交到测试组，没有人知道代码

中有一个潜在的被0除的错误。

若测试组采用的测试用例的执行

路径没有同时经过x=0和y=5/x进

行测试，显然测试工作似乎非常

完善，测试用例覆盖了所有执行

语句，也没有被0除的错误发生。

51

•白盒测试也称结构测试或逻辑驱动测试，是针对被测

单元内部是如何进行工作的测试。它根据程序的控制

结构设计测试用例，主要用于软件或程序验证。

•白盒测试法检查程序内部逻辑结构，对所有逻辑路径

进行测试，是一种穷举路径的测试方法。但即使每条

路径都测试过了，仍然可能存在错误。因为：

＞穷举路径测试无法检查出程序本身是否违反了设计规范

即程序是否是一个错误的程序。

＞穷举路径测试不可能查出程序因为遗漏路径而出错。

A穷举路径测试发现不了一些与数据相关的错误。

节^瓷旃试原则

白盒测试主要是检查程序的内部结构、逻辑、循环和路

径。需要遵循的原则有：

•保证一个模块中的所有独立路径至少被测试一次。

•所有逻辑值均需测试真(true)和假(false)两种情况。

•检查程序的内部数据结构，保证其结构的有效性。

•在上下边界及可操作范围内运行所有循环。

53

;由盒测试方法

•静态测试VS,动态测试

•单元测试

•代码检查

•同行评审

•技术评审

54

静态的试和筋态刎试一

□静态测试-不运行程序的测试，包括代码检查、静态结

构分析、代码质量度量，文档测试等等。它可以由人工

进行，充分发挥人的逻辑思维优势，也可以借助软件工

具自动进行。

□动态测试-需要执行程序的测试，也是我们用得最多的

一种测试，通过运行程序找到问题，包括功能确认与接

口测试、覆盖率分析、性能分析、内存分析等。

55

测试覆盖率j-'—

・测试覆盖率：用于确定测试所执行到的覆盖项的百分

比。其中的覆盖项是指作为测试基础的一个入口或属

性，比如语句、分支、条件等。

•测试覆盖率可以表示出测试的充分性，在测试分析报

告中可以作为量化指标的依据，测试覆盖率越高效果

越好。但覆盖率不是目标，只是一种手段。

■测试覆盖率包括功能点覆盖率和结构覆盖率：

A功能点覆盖率大致用于表示软件已经实现的功能与软件

需要实现的功能之间的比例关系。

»结构覆盖率包括语句覆盖率、分支覆盖率、循环覆盖率、

路径覆盖率等等。

56

«EKM.

覆盖法

根据覆盖目标的不同和覆盖源程序语句的详尽程度，逻

辑覆盖又可分为：

•语句覆盖

*判定覆盖

*条件覆盖

*判定/条件覆盖

•组合覆盖

*路径覆盖

57

各种返辑覆■诿的定义1/歹

1）语句覆盖：选择足够多的测试用例，使得程序中的

每个可执行语句至少执行一次。

2）判定覆盖：通过执行足够的测试用例，使得程序中

的每个判定至少都获得一次“真”值和“假”值，

也就是使程序中的每个取“真”分支和取“假”分

支至少均经历一次，也称为“分支覆盖”。

3）条件覆盖：设计足够多的测试用例，使得程序中每

个判定包含的每个条件的可能取值（真/假）都至少

满足一次。

58

各种返辑覆建法的定义2/歹

4）判定/条件覆盖：设计足够多的测试用例，使得程序

中每个判定包含的每个条件的所有情况（真/假）至

少出现一次，并且每个判定本身的判定结果（真/假）

也至少出现一次。、

＞满足判定/条件覆盖的测试用例一定同时满足判定覆盖和条

件覆盖。

5）组合覆盖：通过执行足够的测试用例，使得程序中

每个判定的所有可能的条件取值组合都至少出现一

次。

＞满足组合覆盖的测试用例一定满足判定覆盖、条件覆盖和判

定/条件覆盖。

6）路径覆盖：设计足够多的测试用例，要求覆盖程序

中所有可能的路径.

59

a

voidDoWork(intx,inty,intz)

_X>3&&z<lj>

(

intk=o,j=o;c

if((x>3)&&(z<io))执行语句块1

{k=x*y-i;

j=sqrt(k);

〃语句块

)1e

if((x==4)||(y>5))

执行语句块2

{j=x*y+io;}〃语句块2

j=j%3；〃语句块3卜-----

执行语句块3

61

~~'三j_^,~j-^~-.........,*..一,

寿荀覆盖

要实现DoWork函数的语句覆盖，只需设计一个测试用

例就可以覆盖程序中的所有可执行语句。

•测试用例输入为：{x=4、y=5、z=5}

•程序执行的路径是：abd

语句覆盖可以保证程序中的每个语句都得到执行，但发

现不了判定中逻辑运算的错误，即它并不是一种充分的

检验方法。例如在第一个判定((x>3)&&(zvio))中把“&&”

错误的写成了“||"，这时仍使用该测试用例，则程序仍

会按照流程图上的路径abd执行。可以说语句覆盖是最

弱的逻辑覆盖准则。

62

判定覆/工7$^^一

要实现DoWork函数的判定覆盖，需要设计两个测试用

例。

•测试用例的输入为：{x=4、y=5、z=5}；{x=2、y=5、2=5}

•程序执行的路径分别是：abd；ace

上述两个测试用例不仅满足了判定覆盖，同时还做到语

句覆盖。从这点看似乎判定覆盖比语句覆盖更强一些，

但仍然无法确定判定内部条件的错误。例如把第二个判

定中的条件y>5错误写为y<5,使用上述测试用例，照样

能按原路径执行而不影响结果。因此，需要有更强的逻

辑覆盖准则去检验判定内的条件。

63

列克覆盖2/2

还可以把判定覆盖准则扩充到多出口判断（如Case语句）

的情况。因此判定覆盖更为广泛的含义应该是使得每一

个判定获得每一种可能的结果至少一次。

Er匀

•下面程序有关某国个人所得税的征收标准，以下测试

用例能满足判定覆盖测试用例的是()

If(income<2ooo)i=o;o

Elseif(income<=3ooo)i=o.O5；

Elseif(income<=5ooo)i=o.io;

Elsei=o.2；

(A)income(2000,3000,5000,5001)

(B)income(2000,32001,4999,5000)

(C)income(1999,2999,5000,5001)

(D)income(2999,2000,4999,5000)

65

在实际程序代码中，一个判定中通常都包含若干条件。

条件覆盖的目的是设计若干测试用例，在执行被测程序

后，要使每个判定中每个条件的可能值至少满足一次。

对DoWork函数的各个判定的各种条件取值加以标记。

对于第一个判定（（x>3）&&（zvio））：

•条件x>3取真值记为Ti,取假值记为-Ti

•条件ZV1O取真值记为T2,取假值记为42

对于第二个判定（（x==4）||（y>5））：

•条件x==4取真值记为T3,取假值记为43

•条件y>5取真值记为T4,取假值记为-T4

66

根据条件覆盖的基本思想，要使上述4个条件可能产生

的8种情况至少满足一次，设计测试用例如下：

测试用例执行路径覆盖条件覆盖分支

T1、T2、

x=4、y=6、z=5

abdT3、T4bd

-T1、-T2、

x=2、y=5、z=15acece

-T3、-T4

上面这组测试用例不但覆盖了4个条件的全部8种情况,

而且将两个判定的4个分支b、c、d、e也同时覆盖了，

即同时达到了条件覆盖和判定覆盖。

一条件覆盖3/3

虽然前面的一组测试用例同时达到了条件覆盖和判定覆

盖，但是，并不是说满足条件覆盖就一定能满足判定覆

盖。如果设计了下表中的这组测试用例，则虽然满足了

条件覆盖，但只是覆盖了程序中第一个判定的取假分支

c和第二个判定的取真分支d,不满足判定覆盖的要求。

测试用例执行路径覆盖条件覆盖分支

-T1、T2、

x=2、y=6>z=5acdcd

-T3、T4

T1、-T2、

x=4、y=5、z=15acdcd

T3、-T4

68

:书一

判断/条件覆^172

判定/条件覆盖实际上是将判定覆盖和条件覆盖结合起

来的一种方法，即：设计足够的测试用例，使得判定中

每个条件的所有可能取值至少满足一次，同时每个判定

的可能结果也至少出现一次。

根据判定/条件覆盖的基本思想，只需设计以下两个测

试用例便可以覆盖4个条件的8种取值以及4个判定分支:

测试用例执行路径覆盖条件覆盖分支

-T1、T2、

x=2、y=6>z=5acdcd

-T3、T4

T1、-T2、

x=4、y=5、z=15acdcd

T3、-T4

69

:书一

一■一。

一判断/条件覆震272K

从表面上看，判定/条件覆盖测试了各个判定中的所有

条件的取值，但实际上，编译器在检查含有多个条件的

逻辑表达式时，某些情况下的某些条件将会被其它条件

所掩盖。因此，判定/条件覆盖也不一定能够完全检查

出逻辑表达式中的错误。

如：对于第一个判定(x>3)&&(z<io)来说，必须x>3和

zvio这两个条件同时满足才能确定该判定为真。如果

x>3为假，则编译器将不再检查zoo这个条件，那么即

使这个条件有错也无法被发现。对于第二个判定

(x==4)||(y>5)来说，若条件x==4满足，就认为该判定为

真，这时将不会再检查y>5,那么同样也无法发现这个

条件中的错误。

70

二组合覆盖1/2

组合覆盖的目的是要使设计的测试用例能覆盖每一个判

定的所有可能的条件取值组合。

对DoWork函数中的各个判定的条件取值组合加以标记:

1)x>3,z<io记做T1T2,第一个判定的取真分支

2)x>3,z>=io记做T1-T2,第一个判定的取假分支

3)x<=3,z<io记做-T1T2,第一个判定的取假分支

4)x<=3,z>=io记做-T1-T2,第一个判定的取假分支

5)x==4,Y>5记做T3T4第二个判定的取真分支

6)x==4,Y<=5记做T3-T4，第二个判定的取真分支

7)X!=4,Y>5记做-