第18章 基于经验的测试技术

目录

一、主要内容

1、错误猜想法

2、探索性测试

3、基于检查表的测试

二、错误猜测法

1、概念

2、软件错误类型

三、估算错误数量模型

1、Seeding模型估算法

2、Hyman估算法

3、Shooman模型估算法

四、探索性测试

1、概念

2、目的

3、分类

4、探索性测试风格

5、探索性测试的相关方法

（1）局部探索性测试法

（2）全局探索式测试法

6、探索性测试的优势

7、探索性测试的局限

五、基于检查表的测试

1、概念

2、构建检查表

3、支持测试类型

4、主要检查点

六、基于文档检查表的测试

1、可用性

2、内容

3、标识和标示

4、完备性

5、正确性

6、一致性

7、易理解性

---

一、主要内容

1、错误猜想法

2、探索性测试

3、基于检查表的测试

二、错误猜测法

1、概念

• 也叫作错误推算法
• 是基于测试人员对以往测试项目中的一些经验来测试在程序中有什么错误；
• 在测试程序时，人们可以根据经验或直觉推测程序中可能存在的各种错误，从而有针对性地编写检查这些错误的测试用例的方法。

2、软件错误类型

1. 软件错误指软件产品中存在的导致期望的运行结果和实际运行结果间出现差异的一系列问题，这些问题包括故障、失效、缺陷。
2. 软件故障是指软件运行过程中出现的一种不希望或不可接受的内部状态。
3. 软件失效是指软件运行时产生的一种不可接受的外部行为结果。
4. 软件缺陷是存在于软件之中的那些不希望或不可接受的偏差。

• 软件需求错误
  • 软件需求不合理
  • 软件需求不全面、不明确
  • 需求中包含逻辑错误
  • 需求分析文档有误
• 功能和性能错误
  • 需求规格说明中规定的功能实现不正确、存在未实现或冗余的情况
  • 性能未满足规定的要求
  • 为用户提供的信息不准确
  • 异常情况处理有误
• 软件结构错误
  • 程序控制流或控制顺序有误
  • 处理过程有误
• 数据错误
  • 数据定义或数据结构有误
  • 数据存取或数据操作有误
• 软件实现和编码错误
  • 编码错误或按键错误
  • 违反编码要求和标准（语法错误、数据名错误、程序逻辑有误）
• 软件集成错误
  • 软件的内部接口或外部接口有误
  • 软件各相关部分在时间配合、数据吞吐量等方面不协调

三、估算错误数量模型

1、Seeding模型估算法

2、Hyman估算法

3、Shooman模型估算法

四、探索性测试

1、概念

• 是基于创造性、经验的测试方法。测试人员基于现有相关的知识、测试项、前期的探索以及相关软件行为和故障类型的启发，自发的设计和执行测试的测试方法。探索性测试强调测试设计和测试执行的同时性

• 探索性测试的最大特色是在对测试对象进行测试的同时学习测试对象并设计测试,在测试过程中运用获得的关于测试对象的信息设计新的更好的测试
• 适用于被测对象复杂且难以理解的情况

2、目的

• 帮助测试人员更好的理解需求，在理解软件需求的基础上针对功能进行快速的评估

3、分类

• 自由式探索性测试
• 基于场景的探索性测试
• 基于策略的探索性测试
• 基于反馈的探索性测试
• 基于会话的探索性测试

4、探索性测试风格

• 预感
  • 基于以往的经验，例如以往的缺陷、故障等进行测试
• 模型
  • 基于架构图、状态表、故障模型等进行测试
• 示例
  • 基于特定的用例、场景、干扰等进行测试
• 不变性
  • 测试变更会不会对应用程序产生影响
• 干扰
  • 寻找中断、转移程序路径的方法
• 错误处理
  • 程序对错误处理是否正确
• 故障排除
  • 就是故障的分析
• 小组洞察
  • 头脑风暴、小组成员的讨论、配对测试等
• 规范
  • 主要是基于主动阅读对标用户的相关文档，启发探索

5、探索性测试的相关方法

（1）局部探索性测试法

主要是可以辅助测试人员针对测试中出现的细节问题做出及时性的决定

• 5个部分
  • 输入、状态、代码路径、用户数据、执行环境
• 不能应用测试用例的整体设计过程

（2）全局探索式测试法

可以辅助测试人员在实际开始测试之前建立起一个全局的目标，确定对软件进行探索性测试的整体的方向，以便系统化的方式组织测试工作，从而尽量覆盖软件的复杂程度及特性

• 决定了总体探索策略和产品特性的测试方法
• 用于指导整体的测试过程，帮助测试人员设计整体的测试策略

6、探索性测试的优势

• 在测试设计不充分的情况下，探索性测试可以基于之前类似的测试和结果进行测试
• 在早期需求模糊或系统不稳定时，探索性测试可以不受限制的在短时间内对产品质量进行反馈
• 当发现缺陷时，探索性测试可以快速向开发人员提供针对缺陷的严重程度、涉及范围和变化的反馈
• 探索性测试可以作为脚本测试的一个重要补充，以检测出脚本测试不能监测到的缺陷

7、探索性测试的局限

• 探索性测试无法对被测对象进行全面性测试，测试结果一般不易度量，不能确保发现最重要的软件缺陷
• 脚本测试可以在需求收集阶段编制测试用例，根据用例的执行来发现缺陷，而探索性测试缺少预防缺陷的能力
• 对于已经确定了测试类型和执行顺序的测试来说，直接编写测试脚本并执行比进行探索性测试更有意义
• 依赖测试人员的领域知识和测试技术，探索性测试不容易协调及调整，导致测试效率低下，缺乏条理

五、基于检查表的测试

1、概念

• 通过设计对应的相应的检查点，便于去检查软件对于该检查点的情况来验证软件的一种测试方法

2、构建检查表

• 基于经验
• 对用户重要内容的了解
• 对软件错误的原因和方式的理解
• 检查项源于以往的经验总结且有效、可测试量

3、支持测试类型

• 各种类型测试

4、主要检查点

• 格式规范性
  • 嵌套的IF语句是否正确的缩进
  • 注释是否准确并有意义
  • 使用的标号是否有意义
  • 代码与开始时的模块模式是否一致
  • 整体上是否遵循全套的编程标准
• 入口和出口的连接
  • 初始入口和最终出口是否正确
  • 跨模块调用时，是否完整的传递所需的参数
  • 是否正确地设置了被传送的参数值
  • 是否对关键的被调用模块的意外情况进行处理
• 程序语言的使用
  • 使用的动词是否合适
  • 模块中是否使用完整定义的语言的有限子集
  • 跳转语句是否适当
• 存储器使用
  • 首次使用域之前是否经过正确的初始化
  • 规定的域是否正确
  • 每个域是否有正确的变量类型声明
• 判断加转移
  • 正确的条件是否经判断
  • 用于判断的是否是正确的变量
  • 转移目标是否正确并能被至少执行一次
• 性能
  • 每个逻辑是否实现了最佳编码
  • 是否提供正式的错误/例外的子程序
• 可维护性
  • 清单格式是否有助于提高可读性
  • 标号和子程序是否符合代码的逻辑意义
• 逻辑性
  • 全部设计是否都已实现
  • 代码实现是否与设计一致
  • 循环语句是否能够其设定的次数
• 可靠性
  • 是否确认外部接口采集的数据
  • 是否遵循可靠性编程要求

六、基于文档检查表的测试

1、可用性

• 是否提供纸质或电子介质的文档

2、内容

• 功能是否可以被测试或验证

3、标识和标示

• 文档的封面、页眉/页脚或其他地方应具有唯一性标识
• 文档中应包含供方的名称和地址信息

4、完备性

• 文档是否包含使用软件必须的信息
• 文档是否清晰陈述软件产品所有功能及用户能调用的所有功能
• 文档是否对软件运行过程中的差错和缺陷进行说明
• 文档是否包括执行应用管理职能所有必要的信息

5、正确性

• 文档中包含的信息是否恰当且适合目标用户阅读使用
• 文档中包含的信息是否正确，没有歧义

6、一致性

• 文档中的表述不应自相矛盾

7、易理解性

• 文档中出现的术语可以被理解
• 文档是否包含清晰的组成文档清单或覆盖范围说明