哪些数据可以更好地监控测试执行进度

前段时间开展了“构建全方位的测试管理体系”公开课,课堂中和学员探讨了如何对测试执行进度进行监控的问题。本文将讨论的内容进行整理,供大家参考。

测试执行进度的监控,所谓的监控实际包含了两层含义,“监”指的是监督Monitoring,简单层面可以理解为在测试过程中收集各种数据并进行分析,得到当前的测试状态,而“控”指的是控制Control,当监督过程中收集与分析数据得到当前状态,并与计划中的目标进行比较,假如两者之间的偏差超过了计划中定义的管理阈值,此时就需要采取行动进行控制。

测试执行进度的监控,是为测试目标服务的,例如:评估软件版本是否可以及时发布?当前的软件产品质量如何等?本文主要从5个角度进行讨论:

1、产品风险

2、测试Tests

3、缺陷

4、覆盖率

5、信心

一、产品风险

测试过程中经常采用基于需求的测试策略和基于风险的测试策略,因此通过收集产品风险相关的信息,就可以帮助确定当前的测试执行进度状态。假如采用基于风险的测试策略,那么测试过程中会识别产品风险,然后通过测试分析与设计阶段分别得到对应的测试条件和测试用例,假如在测试执行过程中发现缺陷,由于确保了测试的可追溯性(具体的可追溯性概念,可参考文章:测试过程中的可追溯性要求),因此就可以确定哪个风险得到了缓解,哪个风险变成了真实发生的事件。

从测试执行进度的角度,可以通过产品风险对应的测试用例状态,进行定性和定量的剩余风险分析,以确定是否满足测试计划中对风险的阈值要求。与产品风险相关的主要例子包括:

1)与产品风险关联的测试用例执行通过的百分比,即哪些产品风险通过测试得到了缓解;

2)与产品风险关联的测试用例执行失败的百分比,即哪些产品风险没有得到缓解,变成了需要采取行动的事件(剩余风险的情况,可以参考下图);

3)未完全测试的产品风险百分比;

4)按照风险级别划分的覆盖的风险百分比;

5)初次产品风险分析后再识别的产品风险百分比(用于判断前期风险识别和分析的有效性);

二、测试Tests

测试Tests通常也是作为测试执行进度监控的重要组成部分,也是出口准则定义中的重要考虑项,例如:要求执行的测试用例通过率必须达到95%。同样的,通过“产品风险”中提到的可追溯性要求,不管是具体需求还是产品风险,最终会设计对应的测试用例进行覆盖,根据其执行的实际状态评估其是否实现或得到缓解。因此针对测试Tests也可以进行通过或失败进行监控,同时,也经常会对执行情况进行分析。与测试Tests相关的主要例子包括:

1)不同状态测试Tests的统计数据,例如:已计划的、已实施的、已运行的、通过的、失败的、无法执行的(被阻塞的)和不执行等;

2)回归测试和确认测试的状态,包括未通过的回归测试和确认测试的趋势;

3)计划的测试周期与实际的测试周期;

下面分别是测试执行率和测试通过率的跟踪数据的例子:

三、缺陷

根据发现的缺陷对测试执行进度进行监控,也是一个重要的手段。其相关的数据主要包括(下图是两个例子):

1)已发现的缺陷总数与已修复的缺陷总数的趋势图;

2)失效的平均时间间隔和失效出现率;

3)按不同缺陷分类的统计数据,例如:功能模块或组件、缺陷发现和移除阶段、优先级/严重程度、根本原因、拒绝或重复的报告等;

4)从报告缺陷到修复缺陷所花的时间趋势;

四、覆盖率

基于前面提到的可追溯性要求,我们就可以针对不同的对象进行覆盖率的数据收集和分析,例如:

1)需求覆盖率;

2)产品风险覆盖率;

3)环境配置覆盖率;

4)代码覆盖率;

五、信心

信心主要来自两个层面,一方面可以参考前面4个维度的客观的度量指标进行评估,而另一方面,可以来自负责该功能测试的测试人员的主观判断。

上面提到的5个维度,可以为测试人员,特别是测试经理监控测试执行进度提供很好的视角。当然,具体采用的维度和数据,还是要根据测试周境进行调整,重要的是适合你的要求。另外,测试过程中数据收集和分析,必定要以大家对相关度量理解一致的基础之上,以便大家可以同样理解和报告当前的状态。同时,根据测试级别的不同,所选择的数据也会不一样。这是在实际过程中需要注意的。记住:收集和分析数据都是为你的目标服务,而不是为了收集而收集。

你可能感兴趣的:(哪些数据可以更好地监控测试执行进度)