第3章 软件测试流程

模块 模块
单元 测试
集成 测试 已测模块 已测模 单元 测试 集成的 软件 确认 测试 系统 测试 测 试
单元 测试 单元 测试 模块
确认的 软 软件
模块
单元测试
单元测试是在软件开发过程中进行的最低级 别的测试活动，其测试的对象是软件设计的最小 单位。例如： ●传统的结构化编程语言中，比如C语言，单 元测试的对象一般是函数或子过程。 ●在像C++这样的面向对象的语言中，单元测 试的对象可以是类，或类的成员函数。 ●对Ada语言，单元测试可以在独立的过程和 函数上进行，也可以在Ada包的级别上进行。 ●单元测试的原则同样也可以扩展到第四代语 言(4GL)中，这时单元被典型地定义为一个菜单 或显示界面。
单元测试的任务


模块接口测试——对被测模块，检测数据能否正 确无误地进入和流出模块； 模块局部数据结构测试——检测模块在工作过程 中，其内部数据能否保持其完整性，包括内部数 据的内容、形式以及相互之间关系； 模块边界条件测试——检测在数据边界处，模块 能否正常工作； 覆盖测试——检测模块运行能否满足特定的逻辑 覆盖； 出错处理检测——检测模块出错处理是否有效。

单元测试的任务
2.判定覆盖:



设计若干测试用例，运行被测程序，使得程序中 每个分支的取真值和取假值至少一次，即判断真 假值均曾被满足。a=2，b=1 ，c=6（M,Q分支全 为真）和a=-2，b=-1 ，c=-3（M,Q分支全为假） 这两组测试用例可覆盖所有判定的真假分支。 【优点】：判定覆盖具有比语句覆盖更强的测试 能力。同样判定覆盖也具有和语句覆盖一样的简 单性，无须细分每个判定就可以得到测试用例。 【缺点】：往往大部分的判定语句是由多个逻辑 条件组合而成，若仅仅判断其整个最终结果，而 忽略每个条件的取值情况，必然会遗漏部分测试 路径。判定覆盖仍是弱的逻辑覆盖。
单元测试又称为模块测试，什么是模块？并 没有严格的定义，不过按照一般的理解，模块应 该具有以下的一些基本属性： ● 名字； ● 明确规定的功能； ● 内部使用的数据，或称局部数据； ● 与其它模块或外界的数据联系； ● 实现其特定功能的算法； ● 可被其上层模块调用，也可调用其下属模块进 行协同工作。

单元测试的任务
5. 条件组合覆盖：
设计足够的测试用例，使得所有可能的条 件取值组合至少执行一次。 【优点】 ：条件组合覆盖准则满足判定覆 盖、条件覆盖和判定/条件覆盖准则。 【缺点】 ：线性地增加了测试用例的数量。
ห้องสมุดไป่ตู้
单元测试的任务
6.路径覆盖：
设计所有的测试用例，来覆盖程序中的所 有可能的执行路径 。 【优点】 ：这种测试方法可以对程序进行 彻底的测试，比前面五种的覆盖面都广。 【缺点】 ：需要设计大量、复杂的测试用 例，使得工作量呈指数级增长，不见得把 所有的条件组合都覆盖。
举例-可能的输入／ 输出条件组合


R > 100 R <= 0 0 < R <= 100, P > 100 0 < R <= 100, P < R 0 < R <= 100, R <= P <= 100, RR = 50 0 < R <= 100, R <= P <= 100, RR = 49 0 < R <= 100, R <= P <= 100, RR = 10 0 < R <= 100, R <= P <= 100, RR = 9 0 < R <= 100, R <= P <= 100, RR = 5 0 < R <= 100, R <= P <= 100, RR = 4 0 < R <= 100, R <= P <= 100, RR = 1 0 < R <= 100, R <= P <= 100, RR = 0
单元测试的任务
举例-输 入 的 情 形
R > 100 0 < R < = 100 R <= 0 P > 100 R<= P <= 100 P<R

单元测试的任务
举例-输 出 情 形
N50 = 1 N50 = 0 4 > N10 >= 1 N10 = 0 N5 = 1 N5 = 0 4 > N1 >= 1 N1 = 0

单元测试的任务
举例-找零金额
分析规格中每一决策点的情形，以 RR1, RR2, RR3 表 示 计 算 要 找 50, 10, 5 元货币数时之剩余金额。 R > 100 R <= 0 P > 100 P<R RR1 >= 50 RR2 >= 10 RR3 >= 5

单元测试的任务
单元测试的任务
数据结构测试
目的:发现下面几类错误 1.不合适或不相容的类型说明； 2.变量无初值； 3.变量初始化或省缺值有错； 4.不正确的变量名（拼错或不正确地截断）； 5.出现上溢、下溢和地址异常。 除了局部数据结构外，如果可能，单元测 试时还应该查清全局数据（例如FORTRAN 的公用区）对模块的影响。
第三章 软件测试流程
概述 测试计划 测试设计 单元测试 集成测试 确认测试 系统测试 验收测试 评估测试
测试流程概述




测试计划 根据用户需求报告中关于功能要求和性能指标的规格说明 书，定义相应的测试需求报告，使得随后所有的测试工作 都将围绕着测试需求来进行。同时，适当选择测试内容， 合理安排测试人员、测试时间及测试资源等。 测试设计 测试设计是指将测试计划阶段制订的测试需求分解、细化 为若干个可执行的测试过程，并为每个测试过程选择适当 的测试用例，保证测试结果的有效性。 测试执行 执行测试开发阶段建立的自动测试过程，并对所发现的缺 陷进行跟踪管理。测试执行一般由单元测试、组合测试、 集成测试以及回归测试等步骤组成。 测试评估 结合量化的测试覆盖域及缺陷跟踪报告，对于应用软件 的质量和开发团队的工作进度及工作效率进行综合评价。
单元测试的任务
接口测试

接口测试一般用于多系统间交互开发，或 者拥有多个子系统的应用系统开发的测试。 接口测试适用于为其他系统提供服务的底 层框架系统和中心服务系统，主要测试这 些系统对外部提供的接口，验证其正确性 和稳定性。接口测试同样适用于一个上层 系统中的服务层接口，越往上层，其测试 的难度越大。接口测试在淘宝的应用是一 个自下而上的发展过程。

单元测试的任务
由于每个模块在整个软件中并不是孤立的，在对
每个模块进行单元测试时，需要考虑它和周围模块的
单元测试的任务
边界条件测试-举例

假 设 商 店 货 品 价 格 (R) 皆 不 大 於 100 元（且为整数），若顾客付款在 100 元 内 (P) ， 求 找 给 顾 客 之 最 少 货 币 个（张） 数 ？ （ 货 币 面 值 50 元 (N50) ， 10 元 (N10) ， 5 元 (N5) ， 1 元 (N1) 四 种 ）
单元测试的任务
4.判定－条件覆盖：
设计足够的测试用例，使得判断条件中的 所有条件可能至少执行一次取值，同时， 所有判断的可能结果至少执行一次。 测试用例要满足如下条件：1.所有条件可能 至少执行一次取值；2.所有判断的可能结果 至少执行一次。 【优点】 ：能同时满足判定、条件两种覆 盖标准。 【缺点】 ：判定/条件覆盖准则的缺点是未 考虑条件的组合情况。
单元测试的任务
3.条件覆盖：



设计若干测试用例，执行被测程序以后要使每个判断中每 个条件的可能取值至少满足一次。 判断M表达式:设条件 a>0 取真 记为 T1 ；假F1 条件 b>0 取真 记为 T2 ；假F2 判断Q表达式:设条件 a>1 取真 记为 T3 ；假F3 条件 c>1 取真 记为 T4 ；假F4 我们用条件覆盖设计的思想就是让测试用例能覆盖T1、 T2、T3、T4、F1、F2、F3、F4 【优点】：增加了对条件判定情况的测试，增加了测试路 径。 【缺点】：条件覆盖不一定包含判定覆盖。例如，我们刚 才设计的用例就没有覆盖判断M的Y分支和判断Q的N分支。 条件覆盖只能保证每个条件至少有一次为真，而不考虑所 有的判定结果
单元测试的任务
举例-测试用例设计

1. 货品价格 = 101 2. 货品价格 = 0 3.货品价格 = -1 4. 货品价格 = 100, 付款金额 = 101 5. 货品价格 = 100, 付款金额 = 99 6. 货品价格 = 50, 付款金额 = 100 7. 货品价格 = 51, 付款金额 = 100 8. 货品价格 = 90, 付款金额 = 100 9. 货品价格 = 91, 付款金额 = 100 10. 货品价格 = 95, 付款金额 = 100 11. 货品价格 = 96, 付款金额 = 100 12. 货品价格 = 99, 付款金额 = 100 13. 货品价格 = 100, 付款金额 = 100
边界条件测试-测试用例的原则

单元测试的任务



一、如果输入条件规定了值的范围，则应该取刚达到这个 范围的边界值，以及刚刚超过这个范围边界的值作为测试 输入数据； 二、如果输入条件规定了值的个数，则用最大个数、最小 个数、比最大个数多1格、比最小个数少1个的数做为测试 数据； 三、根据规格说明的每一个输出条件，使用规则一； 四、根据规格说明的每一个输出条件，使用规则二； 五、如果程序的规格说明给出的输入域或输出域是有序集 合（如有序表、顺序文件等），则应选取集合的第一个和 最后一个元素作为测试用例； 六、如果程序用了一个内部结构，应该选取这个内部数据 结构的边界值作为测试用例； 七、分析规格说明，找出其他可能的边界条件。