08 基于经验的测试技术

Posted on Wed, 25 Dec 2024 17:07:09 +0800 by LiangMingJian

1.错误猜测法 #

1.1 错误猜测法的概念 #

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

1.2 软件错误类型 #

• 软件需求错误。
• 功能和性能错误。
• 软件结构错误。
• 数据错误。
• 软件实现和编码错误。
• 软件集成错误。

1.3 错误数量估算模型 #

1.3.1 Seeding模型估算法 #

1.3.2 Hyman估算法 #

1.3.3 Shooman模型估算法 #

2.探索性测试 #

2.1 探索性测试的概念 #

• 探索性测试是基于创造性、经验的测试方法。
• 在探索性测试中，测试人员基于现有的知识、测试项、前期的探索以及相关软件行为和故障类型的启发，自发的设计和执行测试。
• 探索性测试强调测试设计和测试执行的同时性，在对测试对象进行测试的同时学习测试对象并设计测试，在测试过程中运用获得的关于测试对象的信息设计新的更好的测试。
• 探索性测试适用于被测对象复杂且难以理解的情况。
• 探索性测试的特征是：即兴发挥，快速实验，动态调整。

2.2 探索性测试的内容 #

• 预感：基于以往的缺陷，探索新的变化。
• 模型：架构图、气泡图、状态表、故障模型等。
• 示例：用例、特性演练、场景等。
• 不变性：测试变更不会对应用程序产生影响。
• 干扰：寻址中断或转移程序路径的方法。
• 错误处理：检查错误处理是否正确。
• 故障排除：错误分析（简化、澄清或加强错误报告，当缺陷修复后测试差异）。
• 小组洞察：头脑风暴、相关成员小组讨论、配对测试。
• 规范：主动阅读，对照用户手册，启发式探索。

2.3 探索性测试的分类 #

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

2.4 探索性测试的优势 #

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

2.5 探索性测试的局限 #

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

3.基于检查表的测试 #

3.1 概念 #

• 基于检查表的测试是基于检查点，检查表的测试方法。
• 检查点是用户基于经验，对重要内容的了解，对软件错误的原因和方式的理解以及过往的项目经验总结的测试条件。
• 检查表是检查点的集合，测试人员在测试时，依据检查表的内容，针对每一检查点对软件进行比对测试。

3.2 代码测试的检查点 #

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

3.3 文档测试的检查点 #

• 可用性：是否提供纸质或电子介质的文档
• 内容：功能是否可以被测试或验证
• 一致性：文档中的表述不应自相矛盾
• 标识和标示
  • 文档的封面、页眉/页脚或其他地方应具有唯一性标识
  • 文档中应包含供方的名称和地址信息
• 完备性
  • 文档是否包含使用软件必须的信息
  • 文档是否清晰陈述软件产品所有功能及用户能调用的所有功能
  • 文档是否对软件运行过程中的差错和缺陷进行说明
  • 文档是否包括执行应用管理职能所有必要的信息
• 正确性
  • 文档中包含的信息是否恰当且适合目标用户阅读使用
  • 文档中包含的信息是否正确，没有歧义
• 易理解性
  • 文档中出现的术语可以被理解
  • 文档是否包含清晰的组成文档清单或覆盖范围说明