一、错误猜想法
（一）概念
- 错误推算法
- 基于测试人员对以往测试项目中一些经验测试程序中的错误
- 测试程序时，人们可根据经验或直觉推测程序中可能存在的各种错误，然后有针对性地编写检查这些错误的测试用例的方法
（二）软件错误类型
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、易理解性
- 文档中出现的术语可以被理解
- 文档是否包含清晰的组成文档清单或覆盖范围说明
