测试用例的价值与体系（软件测试入门）

1.测试用例概念：

• 测试用例(Test Case)是为特定的目的而设计的一组测试输入、执行条件和预期的结果的文档
• 通过大量的测试用例来检验软件的运行效果
• 它是指导测试工作进行的依据

 

2.测试用例价值 

• 指导测试的实施
• 规划测试数据的准备
• 编写测试脚本的"设计规格说明书"
• 评估测试结果的度量基准
• 分析缺陷的标准

3.测试用例学习路线：

4.黑盒测试-等价类 

等价类划分法

• 等价类划分是一种重要的、常用的黑盒测试方法
• 不需要考虑程序的内部结构，只需要考虑程序的输入规格即可
• 它将不能穷举的测试过程进行合理分类，从而保证设计出来的测试用例具有完整性和代表性
• 用户所有可能输入的数据，划分成了若干个子集，然后从每一个子集当中选取少数具有代表性的数据作为测试用例
• 在有限的测试资源的情况下，用少量有代表性的数据得到比较好的测试效果 

 

 

等价类分类 

• 有效等价类:指符合《需求文档》，输入合理的数据集合
• 无效等价类:指不符合《需求文档》,输入不合理的数据集合

 

 

等价类划分原则（重点）

• 规定输入的取值范围或个数时，划分一个有效和两个无效
• 规定了输入的集合或规则必须要遵循的条件，则划分一个有效和一个无效
• 输入条件是一个布尔值,则划分为一个有效和一个无效
• 输入条件时一组数据，并且每一个输入的值做不同的处理，则划分若干个有效和一个无效
• 输入条件规定了必须要遵循的某些规则下，则划分为一个有效和若干个无效
• 不是所有的等价类都有无效等价类

等价类设计步骤 

• 1.先划分等价类:找出所有可能的分类
• 2.确定有效等价类:需求中的条件
• 3.确定无效等价类:与条件相反的情况，再找到特殊情况
• 4.从各个分类中挑选测试用例数据

等价类划分方法

在确立了等价类之后，可按下表的形式列出所有划分出的等价类表

• 输入条件
• 有效等价类
• 无效等价类 

 

 

 

5.黑盒测试-边界值分析法

• 大量的软件测试实践表明，故障往往出现在定义域或值域的边界上，而不是在其内部
• 为检测边界附近的处理专门设计测试用例，通常都会取得很好的测试效果
• 边界值分析法是一种很实用的黑盒测试用例方法，它具有很强的发现故障的能力
• 边界值分析法是作为对等价类划分法的补充，测试用例来自等价类的边界

6.黑盒测试-因果图

因果图法是一种利用图解法分析输入的各种组合情况，从而设计测试用例的方法

它适合于检查程序输入条件的各种组合情况        

• “因”—―输入条件
• “果”――输出结果

因果图适用场景

• 描述多种条件的组合
• 产生多个动作

因果图中的基本符号

• 恒等:若原因出现，则结果出现;若原因不出现，则结果也不出现
• 非:若原因出现，则结果不出现;若原因不出现，则结果出现
• 或:有多个原因。若几个原因中有一个出现，则结果出现;若几个原因都不出现，则结果不出现
• 与:有多个原因。若几个原因都出现,则结果才出现;若其中一个原因不出现，则结果不出现 

 

因果图中的约束条件

• 互斥E:a、b、c只能有一个成立，但是可以都不成立
• 包含I:a、b、c中至少有一个成立
• 唯一O:a、b、c有且仅有一个成立
• 要求R:如果a成立，则要求b必须也成立，其他的不约束
• 屏蔽M:如果a成立的时候，强制b不成立，其他的不约束 

 

 

 

因果图法基本步骤

• 找出所有的输入条件（因)
• 找出所有的输出条件(果)
• 明确所有输入条件之间的制约关系以及组合关系
• 明确所有输出条件之间的制约关系以及组合关系
• 找出什么样的输入条件组合会产生哪种输出结果
• 把因果图转换成判定表
• 为判定表中的每一列表示的情况设计测试用例

 

举例：

 

 

 

 

 

 

7.黑盒测试-判定表

• 等价类和边界值是好朋友
• 因果图和判定表是好朋友

因果图只是一种辅助工具，通过分析最终得到判定表，再通过判定表编写测试用例

画因果图非常麻烦，影响测试效率，可以直接写判定表，进而编写测试用例 

判定表的组成

• 条件桩:问题的所有条件·
• 动作桩:问题的所有输出
• 条件项:针对条件桩的取值
• 动作项:条件项的各种取值情况下的输出结果 

判定表设计步骤

• 1.列出所有的条件桩和动作桩
• 2.确定规则数:条件取值个数^条件数
• 3.填入条件项
• 4.填入动作项。得到初始判定表
• 5.简化判定表 

 

 

 

 

 

 简化：

 

8.黑盒测试-场景法

 

场景法用例设计步骤

• 根据需求规格说明，画出功能模块流程图;
• 根据流程图,描述出程序的基本流及备选流;
• 根据基本流和备选流生成不同的场景,构造场景列表;
• 对每一个场景生成相应的测试用例;
• 对生成的所有测试用例重新复审，去掉多余的测试用例;
• 测试用例确定后，为每一个测试用例确定测试数据值

 

 

画流程图

 

 

 确定基本流

• 1.进入淘宝首页
• 2.浏览商品
• 3.进入单品页
• 4.选择商品规格和数量
• 5.加入购物车
• 6.前往购物车
• 7.选择商品
• 8.结算,进入确认订单页
• 9.提交订单
• 10.付款成功
• 11.等待收货
• 12.确认收货

确定备选流 

• 备选流1:加入购物车时，不选择商品规格和型号，返回基本流第4步
• 备选流2:加入购物车时,商品库存不足，返回基本流第4步
• 备选流3:加入购物车时，未登录，登录后返回基本流第3步
• 备选流4:加入购物车后，继续选购，返回基本流第4步
• 备选流5:加入购物车，未选择商品,结算，返回基本流第7步
• 备选流6∶支付失败，返回基本流第8步
• 备选流7:未选择商品加入购物车，退出购物，结束

构造场景 

• 场景1:登录后成功购物(基本流)
• 场景2:未选择商品规格和型号就添加购物车（基本流+备选流1)
• 场景3:选择的商品库存不足（基本流+备选流2)
• 场景4:未登录添加购物车（基本流+备选流3)
• 场景5:商品添加购物车后继续购物(基本流+备选流4)
• 场景6:进入购物车，未选择商品直接结算（基本流+备选流5)
• 场景7:支付过程出错（基本流+备选流6)
• 场景8:没有添加商品到购物车（基本流+备选流7)

 

9.黑盒测试-基于模型的测试方法 （了解即可）

Model-based Testing介绍

基于模型的测试是基于模型的设计的应用，用于设计和可选地执行工件以执行软件测试或系统测试。模型可用于表示被测系统(SUT)的期望行为，或表示测试策略和测试环境。

Model-based Testing 中的模型

描述SUT 的模型通常是对SUT 所需行为的抽象、部分表示。从这种模型派生的测试用例是与模型在同一抽象级别上的功能测试。这些测试用例统称为抽象测试套件。抽象测试套件不能直接针对SUT执行，因为该套件处于错误的抽象级别。可执行的测试套件需要从相应的抽象测试套件派生而来。可执行测试套件可以直接与被测系统通信。这是通过将抽象测试用例映射到适合执行的具体测试用例来实现的。在一些基于模型的测试环境中，模型包含足够的信息来直接生成可执行的测试套件。在其他情况下，抽象测试套件中的元素必须映射到软件中的特定语句或方法调用，以创建具体的测试套件。这被称为解决“映射问题”。

Model-lased Testing 中的testing

测试可以通过不同的方式从模型中导出。因为测试通常是实验性的并且基于启发式，所以没有已知的单一测试推导的最佳方法。通常将所有与测试派生相关的参数合并到一个包中，该包通常被称为“测试需求”、“测试目的”甚至“用例”。这个包可以包含关于模型中应该关注的那些部分的信息，或者完成测试的条件（测试停止标准)。

因为测试套件源自模型而不是源代码，基于模型的测试通常被视为一种形式的黑盒测试。复杂软件系统的基于模型的测试仍然是一个不断发展的领域。

基于模型的测试方法

• 基于模型的测试(英语:Model-based Testing)属于软件测试领域的一种测试方法。按照此方法，测试用例可以完全或部分的利用模型自动产生。以上所说的模型通常是指对被测系统(SUT,system under test）某些（通常是功能性的）方面的描述。
• 模型一般都是对被测系统预期行为动作的抽象描述。这些测试用例的集合就是抽象测试套件(abstract test suite)。抽象测试套件不可以直接执行于需测试的系统，因为，他们不在同一抽象级别。
• 测试套件（test suites）是由模型生成，而不是由源代码生成。因此，基于模型的测试又常常被当作黑盒测试的一种形式。但从某种层面来说，这并不十分准确。毕竟，基于模型的测试是与源代码级的测试覆盖率，以及对代码的功能测试都有着很大的关系。

MBT在微软的实践案例

十多年来，Microsoft已成功地将基于模型的测试(MBT)应用到其内部开发过程中。MBT已被证明是一种成功的技术，适用于各种内部和外部软件产品。多年来它的采用率稳步上升。相对而言，
它在测试界很受欢迎，尤其是与其他在测试范围内“正式”方面的方法相比。 

Spec Explorer

Spec Explorer是一个Microsoft MBT工具,它扩展了 Visual Studio，为创建行为模型提供了一个高度集成的开发环境，以及一个用于检查这些模型的有效性并从中生成测试用例的图形分析工具。我们相信这个工具是促进 MBT 作为一种有效技术在IT行业中的应用、缓解自然学习曲线并提供最先进的创作环境的转折点。

GraphWalker an open-source mode-hased testing tool

GraphWalker实战

GraphWalker安装与部署

GraphWalker 流程

• 创建模型
• 生成抽象测试套件
• 映射可执行测试套件
• 执行测试

GraphWalker日后在做研究 （测试前沿技术，要求很高）

10.白盒测试

• 根据待测产品的内部实现细节来设计测试用例
• 白盒测试的执行手段是可以涵盖单元测试、集成测试
• 使用代码覆盖率作为白盒测试的主要度量指标

代码覆盖率常见概念

• 语句覆盖:每行代码都要覆盖至少一次
• 判定覆盖:判定表达式的真假至少覆盖一次
• 判定/条件覆盖:判定覆盖与条件覆盖都必须覆盖
• 条件组合覆盖:判定表达式中的所有条件组合都需要覆盖
• 分支覆盖:控制流中的每条边都要被覆盖一次
• 路径覆盖:所有的路径都要尽量覆盖
• 指令覆盖:一行代码会被编译为多条指令，尽可能的覆盖所有指令
• 方法覆盖:每个方法至少要被覆盖一次
• 类覆盖:每个类至少被覆盖一次 

 

覆盖率统计的工具（java）

• emma
• cobertura
• jacoco

流程覆盖：

• 利用代码执行流代表流程
• 流程覆盖用路径覆盖率表达
• 对流程进行裁剪获得一个适合业务的小规模的业务子集
• 流程覆盖率=测试经过的路径/业务子集路径 

精准化测试

• 代码调用链与黑盒测试用例的关联
• 根据代码变更自动分析影响范围
• 黑盒测试过程中借助代码流程覆盖数据指导探索式测试
• 利用线上数据推导有效测试用例
• 代码流程分析与覆盖率统计 

 

11.测试用例基础概念 

• 测试用例示例
• 测试用例的组成
• 测试用例的优先级
• 测试用例设计工具

 

测试用例的组成 

• 用例编号
• 模块
• 测试点（测试标题)
• 优先级
• 前提条件
• 测试步骤
• 期望结果(预期结果)
• 实际结果

测试用例的优先级 

• 测试用例根据重要性分成一定的等级
• P0
• P1
• P2
• P3

 

测试用例设计工具

• 思维导图
• excel 

 

 

• 测试用例设计
• 设计方法的选择
• 测试用例编写步骤
• 需求分析
• 测试用例编写
• 测试用例的粒度
• 测试用例评审 

设计方法的选择

• 任何情况下，都需要采用等价类划分法，将无限测试变成有限测试
• 在规定了数据范围的情况下，必须采用边界值分析法
• 如果需要关注它的主要功能和业务流程、业务逻辑是否正确实现，考虑使用场景法
• 如果含有输入条件的组合情况，考虑选用因果图和判定表法
• 采用错误推断法再追加测试用例 

测试用例编写步骤

• 划分功能模块
• 正向功能验证
• 单个功能项验证
• 功能之间交互验证
• 隐形需求

需求分析 

测试用例的粒度 

1. 测试用例可以写的很简单，也可以写的很复杂
2. 最简单的测试用例是测试的纲要,仅仅指出要测试的内容
3. 测试用例写的过于简单，则可能失去了测试用例的意义
4. 测试用例写得过于复杂或详细,会带来两个问题: 效率问题, 维护成本问题

测试用例评审

• 测试用例的本身的描述是否清晰，是否存在二义性
• 测试用例内容是否正确,是否与需求目标相一致
• 测试用例的期望结果是否确定、唯一
• 测试用例是否覆盖了所有的需求
• 测试用例是否具有可执行性
• 是否从用户层面来设计用户使用场景和业务流程的测试用例
• 场景测试用例是否覆盖最复杂的业务流程
• 用例设计是否包含了正面、反面的用例 

面试测试测试用例设计 

面试形式

• 自有产品功测试用例设计
• 常用应用测试用例设计

 

测试策略概念

在特定环境约束之下，描述软件开发周期中关于测试原则、方法、方式的纲要，并阐述了它们之间如何配合，以高效地减少缺陷、提升质量。 

测试策略的关注重点

• 测试的目标是什么?
• 测试可能存在的风险是什么?
• 测试的对象和范围是什么?
• 如何安排各种测试活动?
• 如何评价测试的效果?

测试手段

• 黑盒测试
• 白盒测试
• 动态测试
• 静态测试
• 手工测试
• 自动化测试