常用测试设计方法

---

1、按照开发阶段划分

（1）单元测试(模块测试)

• 测试对象：针对软件设计的最小单位——程序模块进行正确性检验的测试功能。
• 测试目的：检查每个程序单元能否正确实现详细设计说明中的模块功能、性能、接口和设计约束等要求

（2）集成测试(组装测试)

• 测试对象：程序单元或部件的接口
• 测试阶段：在单元测试的基础上，将所有的程序模块进行测试
• 测试目的：检验程序单元或部件的接口关系，逐步集成为符合概要设计要求的程序部件或整个系统

（3）确认测试(有效性测试)

• 测试目的：是在模拟环境下，验证软件的所有功能和性能及其它特性是否与用户的预期要求一致。
• 一般是正向测试，不作为正式的测试环节，有时候也会把确认测试称为冒烟测试。

（4）系统测试

• 测试目的：在真实的系统运行的环境下，检查完整的程序系统能否和硬件、外设、网络和系统软件、支持平台等等正确配置、连接，并且最终满足用户的所有需求。
• 全面的：系统所有功能的测试、模拟所有软件用户的操作
• 全方位的：和硬件系统的配置、和系统软件的配置、和其它软件的关系

（5）验收测试

• 测试目的：按照项目任务书或合同、供需双方约定的验收依据文档对整个系统的测评与评审

根据验收测试主体的不同分为以下三类：

• α测试：把用户请到公司内部进行测试使用，由一个用户在开发环境下进行的测试，也可以是公司内部的用户在模拟实际操作环境下进行的测试（开发人员和测试人员不参与）
• β测试：软件的需求方在不同场所进行测试。
• λ测试：介于开发商和需求方间的第三方组织的测试

α测试与β测试的区别：

• α测试的环境是受开发商控制的,用户的数量相对比较少,时间比较集中。
• β测试的环境是不受开发商控制的, 用户数量相对比较多,时间不集中。
• α测试先于β测试执行。通用的软件产品需要较大规模的β测试，测试周期比较长

2、按照代码运行划分

根本区别：在于是否运行代码

（1）静态测试

• 定义：静态测试不实际运行被测软件，而只是静态地检查程序代码、界面或文档中可能存在的错误的过程。
• 代码测试：主要测试代码是否符合相应的标准和规范。
• 界面测试：主要测试软件的实际界面与需求中的说明是否相符。
• 文档测试：主要测试用户手册和需求说明是否符合用户的实际需求。

（2）动态测试

• 定义：通过运行被测程序来检查运行结果与预期结果的差异，并分析运行效
  率和健壮性等指标；一般是分为三部分：构造测试用例、执行程序、分析程序的输出结果。

3、按照软件特性划分

（1）功能测试

• 测试目的：检查实际软件的功能是否符合用户的需求
• 测试类型：逻辑功能测试、界面测试、易用性测试、安装/卸载测试、兼容性测试

（2）性能测试

• 测试目的：检查软件中的某一功能在指定的时间、空间条件下，是否使用正常
• 软件性能主要包括：时间性能和空间性能

（3）安全性测试

• 测试目的：验证安装在系统内的保护机制能否在实际应用中对系统进行保护，不受各种因素的干扰

4、其他测试

（1）回归测试

• 测试内容：对软件的新版本测试时，重复执行之前某一个版本的测试用例
• 测试目的：<1>验证之前版本产生的所有缺陷是否已经全部修复 <2>确认这些修复后的缺陷没有引发新的缺陷

（2）冒烟测试

• 测试目的：对一个软件新版本进行系统大规模的测试之前，先验证一下软件的基本功能是否实现，是否具备可测性，有时正向测试的时候也会被称为确认测试

（3）随机测试

• 测试内容：测试人员基于经验和直觉的测试，发现一些边缘性的错误

（4）猴子测试

• 测试内容：没有任何的主观意识和想法参与测试
• 测试目的：让一些意想不到的操作造成错误结果

5、黑盒测试与白盒测试

1、黑盒测试

• 黑盒测试(功能测试)：这种方法把被测软件看成黑盒，在不考虑软件内部结构和特性的情况下测试软件的外部特性。黑盒测试是在程序界面处进行测试，它只是检查程序是否按照需求规格说明书的规定正常实现。

（1）等价类划分法

• 原理：把程序的输入域划分成若干部分，然后从每个部分中选取少数代表性数据作为测试用例

等价类划分原则：

• 划分为有效等价类和无效等价类
• 根据取值范围或值的个数、值的集合
• 根据需要遵守的规则
• 一条用例尽可能多的满足有效等价类
• 一条用例覆盖一条无效等价类

等价类划分步骤：

• 分析需求，确定输入数据类型
• 使用规则划分有效和无效等价类
• 设计用例覆盖有效等价类
• 设计用例覆盖无效等价类

（2）边界值分析法

• 原理：如果输入条件规定值的范围，则应取刚到边界值的值以及刚刚超过的值

• 6 ≤ x ≤12，则测试中x的边界值选取哪几个数据进行测试？
  答：上点：6，12 ；离点：5，13； 内点：9
• 6＜x ≤ 12，则测试中x的边界值选取哪几个数据进行测试？
  答：上点：6，12 ；离点：7，13； 内点：9
• 6 ≤ x＜12，则测试中x的边界值选取哪几个数据进行测试？
  答：上点：6，12 ；离点：5，11； 内点：9
• 6＜x＜12，则测试中x的边界值选取哪几个数据进行测试？
  答：上点：6，12 ；离点：7，11； 内点：9

边界值分析法步骤：

• 分析需求，确定输入数据类型
• 使用规则划分有效/无效等价类
• 确认上点、离点、内点
• 设计测试用例覆盖有效等价类
• 设计测试用例覆盖无效等价类

（3）判定表法

• 适用于多条件的内容组合与结果分析

判定表的组成：(使用条件：所有的条件桩在表中的位置和顺序互不影响；所有的动作桩的顺序不会因为条件顺序的变化而产生不同)

• 条件桩：列出了问题的所有条件
• 动作桩：列出了问题规定可能采取的操作
• 条件项：列出条件项中的各种情况下的真假值
• 动作项：列出在条件项中的各种取值情况下应该采取的动作
  
  判定表法步骤：
• 列出所有的条件桩和动作桩
• 分析条件的组合数量，即条件项（全组合：若有n个条件，每个条件有m种情况，则最后一共有m^n个条件项）
• 填写动作项
• 合并、简化相似规则或者相同动作，排除一些不可能的情况

例：订购单的检查：
（1）若金额超过500元，又未过期，则发出批准单和提货单
（2）若金额超过500元，但过期了，则不发批准单
（3）若金额未超过500元，则不论是否过期都发出批准单和提货单，在过期的情况下还需要发出通知单

条件桩	1	2	3	4
金额（是否超过500）	1	1	0	0
订单过期（是否过期）	1	0	1	0
动作桩
批准单	0	1	1	1
提货单	1	1	1	1
通知单	0	0	1	0

优化：可以合并2和4，得出结论：不管金额的高低，只要未过期，就会发送批准单和提货单

（4）因果图法

• 适合多种输入条件组合的测试方法

因果图：
1.条件与结果的关系

• 恒等：条件A成立，结果B一定成立
• 非：条件A成立，结果B一定不成立
• 或：条件A、B、C中只要有一个成立，结果D一定成立
• 与：条件A、B、C都成立，结果D才成立

2.在因果图中加上约束条件

• 原因之间的约束：
• 互斥（Eclusive）：条件A、B不同时成立，最多只有一个成立
• 包含（Include）：条件A、B、C至少有一个成立
• 唯一（Only）：条件A、B有且只有一个成立
• 要求（Request）：条件A成立，要求条件B必须先成立
• 结果之间的约束：
• 屏蔽（Mask）：结果A出现，结果B一定不出现
  

因果图法步骤：

• 分析所有可能的输入、输出
• 找出输入条件的组合、约束关系和输出条件的因果关系，
• 画出因果图
• 把因果图转换成判定表
• 把判定表对应到每一个测试用例

（5）场景法

• 适用于解决业务流程清晰的系统或者功能
• 基本流：软件功能按照正确的事件流实现的一条正确流程。通常一个业务仅存在一个基本流，且基本流只有一个起点和一个终点
• 备选流：除了基本功能流程之外的各支流，包含多种不同情况
  

例：ATM机取款
基本流：插卡、输入密码、选择取款服务、选择取款金额、ATM出钞
备选流：

• 1.卡片不是银行卡
• 2.卡片不是对应银行的卡
• 3.密码输错一次
• 4.密码输错两次，第三次输入正确
• 5.密码输错三次，账号冻结
• 6.选择存款服务
• 7.选择转账服务
• 8.选择查询服务
• 9.选择修改密码服务
• 10.选择100、1000、其它金额
• 11.账户金额不足
• 12.账户取款金额达到当日取款上限
• 13.账户取款金额达到当日取款机取款上限
• 14.ATM机没钱
• 15.ATM机网络未连接
• 16.ATM机停电
  场景设计:
  场景1：基本流、备选流1
  场景2：基本流、备选流2
  …
  每个场景都是一个测试用例，需要对所有测试用例重新复审，去掉多余的测试用例

2、白盒测试

• 白盒测试(结构测试)：这种方法把被测软件看成白盒，根据程序的内部结构和逻辑设计来设计测试实例，对程序的路径和过程进行测试。

（1）语句覆盖

• 设计测试用例，使得程序中每条语句至少被执行一次
• 语句覆盖率 = 至少被执行一次的语句数量 /可执行的语句总数
• 尽可能使得语句覆盖率达成100%
• 局限性：不能准确判断运算中的逻辑关系错误

例题：某个程序如下图流程图：

测试用例设计：

测试数据	覆盖语句
x=3,y=1,m=2	1、4
x=3,y=-2,m=-2	2、3、4

（2）判定覆盖

• 也叫分支覆盖，设计测试用例，使得程序中的每个判断的“真”和“假”都至少被执行一次；即程序中的每个分支至少执行一次
• 判定覆盖率 = 每个判定的真假值至少出现一次 / 判定结果的总数
• 满足判定覆盖一定满足语句覆盖
• 局限性：判定覆盖会忽略条件中取或的情况

例题：某个程序如下图流程图：

测试用例设计：

• if(x>0 && y>0)判定：记为P1
• if(m<0)判定：记为P2

测试数据	P1	P2
x = 3,y=1,m=2	T	F
x=-3,y=-1,m=-2	F	T

（3）条件覆盖

• 设计测试用例，使得判定中的每个条件至少有一次取真值，有一次取假值
• 条件覆盖率 = 每个条件真假值至少出现一次/条件结果的总数
• 条件覆盖不能保证判定覆盖

例题：某个程序如下图流程图：

测试用例设计：

• if(x>0 && y>0)判定：记为P1
• if(m<0)判定：记为P2
• x>0：记为C1
• y>0：记为C2
• m<0：记为C3
• 需要满足C1、C2、C3均取真、取假

测试数据	C1	C2	C3	P1	P2	路径
x=2,y=-1,m=-1	T	F	T	F	T	a->c->d->f
x=-2,y=3,m=1	F	T	F	F	F	a->c->e->f

（4）判定条件覆盖

• 设计测试用例，使得被测试程序中的每个判断本身的判定结果（真假）至少满足一次，同时，每个逻辑条件的可能值（真假）也至少被满足一次，即同时满足100%判定覆盖和100%的条件覆盖的标准
• 判定条件覆盖率 = 每个判定真假值和条件真假值至少出现一次 / (判定结果的总数+条件结果的总数)
• 满足判定条件覆盖一定满足判定覆盖、条件覆盖、语句覆盖
• 局限性：判定覆盖会忽略条件中取或的情况

例题：某个程序如下图流程图：

测试用例设计：

• if(x>0 && y>0)判定：记为P1
• if(m<0)判定：记为P2
• x>0：记为C1
• y>0：记为C2
• m<0：记为C3
• 需要满足C1、C2、C3均取真、取假

测试数据	C1	C2	C3	P1	P2	路径
x=2,y=1,m=1	T	T	F	T	F	a->b->e->f
x=-2,y=-3,m=-1	F	F	T	F	T	a->c->d->f

（5）条件组合覆盖

• 设计测试用例，使得被测试程序中的每个判定中条件结果的所有可能组合至少执行一次
• 条件组合覆盖率=条件组合至少出现一次的数量/条件组合的总数
• 条件组合覆盖满足判定覆盖、条件覆盖、判定-条件覆盖、语句覆盖
• 不能保证所有路径被执行

例：假设代码中有判定2个，条件3个（判定1有2个条件，判定2有1个条件），则判定1 的条件组合为4个，判定2的条件组合为2个
设计测试用例执行5个条件组合，则条件覆盖率=5/(4+2) = 83%

例题：某个程序如下图流程图：

测试用例设计：

• if(x>0 && y>0)判定：记为P1
• if(m<0)判定：记为P2
• x>0：记为C1
• y>0：记为C2
• m<0：记为C3
• 需要满足C1、C2、C3均取真、取假

测试数据	C1	C2	C3	P1	P2	路径
x=3,y=0,m=-1	T	F	T	F	T	a->c->d->f
x=-3,y=1,m=3	F	T	F	F	F	a->c->e->f
x=-3,y=0,m=-1	F	F	T	F	T	a->c->d->f
x=3,y=2,m=2	T	T	F	T	F	a->b->e->f

（6）路径覆盖

• 设计测试用例，覆盖程序中所有可能的路径
• 路径覆盖率 = 至少被执行过一次的路径数/总的路径数
• 不适合包含路径过多的程序

例题：某个程序如下图流程图：

测试用例设计：

• if(x>0 && y>0)判定：记为P1
• if(m<0)判定：记为P2
• x>0：记为C1
• y>0：记为C2
• m<0：记为C3
• 需要满足C1、C2、C3均取真、取假

测试数据	路径
x=3,y=3,m=-1	a->b->d->f
x=3,y=3,m=1	a->b->e->f
x=3,y=0,m=-1	a->c->d->f
x=-3,y=2,m=1	a->c->e->f

6、总结

	单元测试	集成测试	确认测试	系统测试	验收测试
测试 技术	黑盒、白盒	黑盒、白盒、灰盒	黑盒、白盒	黑盒、白盒	黑盒、白盒
代码 运行	动态、静态	动态、静态	动态、静态	动态、静态	动态、静态
软件 特性	功能、性能、安全	功能、性能、安全	功能、性能、安全	功能、性能、安全	功能、性能、安全
其他 测试			冒烟测试	回归测试	随机测试/猴子测试
测试 手段	手工、自动化	手工、自动化	手工、自动化	手工、自动化	手工、自动化