有效测试的 50 条建议 - 管理测试的执行（47~50）

第 47 条：明确定义测试执行周期的开始和结束

不管是哪个测试阶段，为软件测试执行周期定义准入标准和准出标准都是非常重要的。
准入标准：

• 所有的单元测试和集成测试已经成功完成；
• 软件的生成（编译）过程没有任何错误；
• 软件版本通过了冒烟测试；
• 配套文档（发行通知）已经完成，文档内容涉及软件版本的新功能和修改的内容；
• 缺陷已经修正并且准备重新测试；
• 源代码已经存储在版本控制系统中；

部分准出标准：

• 已经执行了用来确定系统满足指定的功能性和非功能性需求的测试过程；
• 在测试结果中记录的所有的 1 级、2 级、3 级（导致运行中断的、紧急的、高优先级的）软件问题都已经解决；
• 报告的所有的 1 级和 2 级软件问题都已经解决；
• 在测试结果中记录的所有 1 级和 2 级软件问题都已经解决，同时报告的 90% 的 3 级问题也已经解决；
• 软件发货时可能上存在已知的低优先级缺陷（当然也会有若干未知缺陷）；

开发和测试必须商定好准入和准出标准。用户验收测试是测试计划中非常重要的因素。
系统发行时可以有一些缺陷，这些缺陷可以在以后的版本或者补丁中加以解决。对测试结果的分析有助于确定哪些缺陷必须马上修正，哪些缺陷可以以后再解决。

• 在回归测试中，从前运转正常的功能中发现缺陷的比例有多大？缺陷修正工作破坏以前运转正常功能的频率有多高？
• 缺陷修正失败的频率有多高？
• 随着测试阶段的继续，新缺陷的发现率其走势如何？随着测试工作的进行，缺陷发现率应该呈下降趋势。

第 48 条：隔离测试环境和开发环境

测试环境和开发环境分离是为了避免测试期间的严重疏忽和无法追踪软件的变化。
没有独立的测试环境面临的一些问题：

• 环境的变化。开发没通知测试的情况下，部署环境、修改配置、添加数据等。
• 版本管理困难。开发版本和测试版本的冲突。
• 操作环境的变化。不同条件下环境配置的冲突。

在有限预算下，建立独立测试环境的方法：

• 降低性能和容量。
• 使用活动硬盘。
• 建立一个共享的测试实验室。

第 49 条：实现缺陷追踪生命周期

为系统环境评估选择一个恰当的缺陷追踪工具是非常重要的。
每个测试组必须用一个详细的过程完成缺陷报告工作，其中包括如下步骤：
1，分析和记录缺陷条目
下面是缺陷文档中应包含的属性示例：

• 主标题
• 正在测试的工作版本
• 操作系统和配置
• 附件
• 再现性
• 重现错误的步骤
• 返测失败
• 分类
• 解决方案

在报告缺陷时，应保持固定的粒度，每个报告只覆盖一个缺陷。
2，划分优先级
优先级分类方法：

• 导致运行中断
• 紧急：非常重要，需马上给予关注
• 高级：事件重要，应在紧急事件处理之后尽快解决
• 中级：事件重要，但解决需要一定时间，所以可以用较长的时间解决
• 低级：事件不重要，可在时间和资源允许的情况下解决
• N/A：没有适用的优先级，比如变更需求和增加需求

3，重复出现
一般做法是：审查以前的缺陷报告来研究已经实现的修正，但用一个新的缺陷报告来引用以前的这一 “已关闭但是相关” 的缺陷报告。

4，关闭

在软件生命周期的各个阶段都有可能发现缺陷，按照在生命周期中发现缺陷的阶段对每个缺陷进行分类。

第 50 条：追踪测试工作的执行

在测试执行周期中，有关进度的度量包括：
1，测试过程执行情况 = 已经执行的测试过程数量/测试过程总数。
这个度量本身并不能反映应用程序的质量，它提供的信息只能反映测试工作的进度。更有效的测量进度的方法要包括已经执行的测试过程步骤数量，具体到步骤一级来测量测试过程的执行状态是一个更精细的进度度量。
追踪测试过程执行的最好方法是制作一个包含正在测试的版本的标识符、所有测试过程的名字列表、为每个测试过程分配的测试人员以及完成比例的矩阵，每天更新。

2，缺陷持续时间 = 从发现缺陷到改正缺陷的时间跨度。
缺陷持续时间用于验证缺陷是否被及时的解决，利用缺陷持续时间的数据，测试组可以进行趋势分析。如果开发人员不及时修正缺陷，那么这在项目中会引发连锁反应。

3，从缺陷纠正到返测的时间 = 从缺陷被修正并且在新版本中发布的时间到缺陷被返测的时间跨度。
此时间度量，提供了一种衡量测试组的返测缺陷速度。

4，缺陷趋势分析 = 在测试生命周期内，随着测试工作的进行，发现缺陷的数量的趋势变化。
当测试阶段日益临近结束时，趋势应该是在变好，也就是发现的缺陷越来越少。

5，修改的质量 = 修改后剩余的缺陷数量（在以前已经工作正常的功能上新引入的或者重新出现的缺陷）。
这个度量也称为重现率，它测量的是缺陷修正工作给以前运转正常的功能带来的新缺陷，或者破坏了以前运转正常功能的百分比。如果这个值很高，那一定要让开发知道这一问题。

6，缺陷密度 = 一个需求中发现的缺陷总数/为这个需求执行的测试过程数量。
缺陷密度表示：某一特定的功能部分货这需求中，平均每一个测试过程所发现的缺陷数。如果某个功能部分缺陷密度很高，那么需要通过下面问题分析其原因：

• 功能是否非常复杂，并且因此预计缺陷密度会比较高
• 功能的设计或实现是不是有问题
• 是否低估了它的难度，所以没有为这个功能分配足够的资源

本文章援引《Effective software testing》一书内容，为个人读后笔记，特此声明