一、错误猜想法

（一）概念

• 错误推算法
• 基于测试人员对以往测试项目中一些经验测试程序中的错误
• 测试程序时，人们可根据经验或直觉推测程序中可能存在的各种错误，然后有针对性地编写检查这些错误的测试用例的方法

（二）软件错误类型

1、软件需求错误

• 软件需求不合理
• 软件需求不全面、不明确
• 需求中包含逻辑错误
• 需求分析的文档有误

2、功能和性能错误

• 需求规格说明中规定的功能实现不正确、存在未实现或冗余的情况
• 性能未满足规定的要求
• 为用户提供的信息不准确
• 异常情况处理有误

3、软件结构错误

• 程序控制流或控制顺序有误
• 处理过程有误

4、数据错误

• 数据定义或数据结构有误
• 数据存取或数据操作有误

5、软件实现和编码错误

• 编码错误或按键错误
• 违反编码要求和标准(语法错误、数据名错误、程序逻辑有误)

6、软件集成错误

• 软件的内部接口或外部接口有误
• 软件各相关部分在时间配合、数据吞吐量等方面不协调

（三）估算错误数量的方法

1、Seeding模型估算法

• N：未知错误数
• Nt：人为向程序中添加的错误数
• n：经t个月的排错工作以后，排错程序中原有的错误的数量
• nt：经t个月的排错工作以后，排错人工插入的错误数量
• 问题：由于排错人员无法确定程序中出现错误的数量和内容，导致新添加的错误与原有错误重复，导致结果不一定准确
• 主要应用于软件的测试阶段

2、Hyman估算法

• 设置A、B两个测试人员相互独立地对某个软件进行测试
• A组：发现错误数为i
• B组：发现错误数为j
• A、B两组共同测试出的错误数为k

3、Shooman模型估算法

• 一种通过估算错误产生的频度来保证软件的可靠性的方法(主要体现为MTTF)
• K：为经验常数
• ET：是测试之前程序中的原有故障总数
• It：是程序长度(机器指令条数或简单汇编语句条数)
• t：是测试(包括排错)的时间
• EC(t)：是在0-t期间内检出并排除的故障总数
• 公式中的K及ET可通过两次以上不同的相互独立的功能测试进行估算得到
• 估算ET值和K较为困难，可能导致实验数据存在误差
• 主要应用于软件的开发阶段

二、探索性测试

（一）概念

• 基于创造性、经验的测试方法。测试人员基于现有相关知识、测试项、前期探索及相关软件行为和故障类型的启发，自发设计和执行测试的测试方法。
• 强调测试设计和测试执行的同时性
• 最大特色是学习、运用
• 适用于被测对象复杂且难以理解的情况

（二）目的

• 帮助测试人员更好理解需求，并针对功能进行快速评估。

（三）分类

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

（四）探索性测试风格

• 预感
• 模型
• 示例
• 不变性
• 干扰
• 错误处理
• 故障排除
• 小组洞察
• 规范

（五）探索性测试的相关方法

1、局部探索性测试法

辅助测试人员针对测试中出现的细节问题做出及时性的决定。

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

2、全局探索式测试法

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

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

（六）优势和局限

1、优势

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

2、局限

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

三、基于检查表的测试

（一）概念

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

（二）构建检查表

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

（三）支持测试类型

• 各种测试类型

四、基于代码检查表的测试

（一）主要检查点

1、格式规范性

• 嵌套的IF语句是否正确地缩进
• 注释是否准确并有意义
• 使用的标号是否有意义
• 代码与开始时的模块模式是否一致
• 整体上是否遵循全套的编程标准

2、入口和出口的连接

• 初始入口和最终出口是否正确
• 跨模块调用时，是否完整地传递所需的参数
• 是否正确地设置了被传送的参数值
• 是否对关键的被调用模块的意外情况进行处理

3、程序语言的使用

• 使用的动词是否合适
• 模块中是否使用完整定义的语言的有限子集
• 跳转语句是否适当

4、存储器使用

• 首次使用域之前是否经过正确的初始化
• 规定的域是否正确
• 每个域是否有正确的变量类型声明

5、判断和转移

• 正确的条件是否经判断
• 用于判断的是否是正确的变量
• 转移目标是否正确并能够被至少执行一次

6、性能

• 每个逻辑是否实现了最佳编码
• 是否提供正式的错误/例外子程序

7、可维护性

• 清单格式是否有助于提高可读性
• 标号和子程序是否符合代码的逻辑意义

8、逻辑性

• 全部设计是否都已实现
• 代码实现是否与设计一致
• 循环语句是否能够执行其设定的次数

9、可靠性

• 是否确认外部接口采集的数据
• 是否遵循可靠性编程要求

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

1、可用性

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

2、内容

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

3、标识和标示

• 文档的封面、页眉/页脚或其他地方应具有唯一性标识
• 文档中应包含名称、版本及发布日期的软件产品标识
• 文档中应包含供方的名称和地址信息

4、完备性

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

5、正确性

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

6、一致性

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

7、易理解性

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