在软件测试过程中,可以将度量分为两大类:
1)衡量测试效率和测试工作量 - 工作量指标
例如,测试效率评价、测试进度S曲线等.
2)从质量的角度表明测试的结果 - 结果指标
例如,缺陷数量、到达模式、系统崩溃和挂起的次数等.
测试过程S曲线
追踪测试过程也许是软件测试阶段管理中重要的追踪任务。建议的一种度量是测试过程一段时间内的S曲线。S曲线的X坐标代表时间单位,Y坐标代表测试用例数目或测试点数目。之所以称为S曲线,意味着数据随着时间而积累、并由于密集的测试活动而呈现出S的形状,造成一个坡度很大的测试斜面。图中必须包含下列信息:
1)每周(或天、小时)尝试的测试用例数目或测试点数目
2)每周计划的测试用例数目或测试点数目
3)每周成功完成的测试用例数目或测试点数目
这个度量的目的在于追踪测试进度,将其与计划进行比较,可以及时得到测试行为滞后的信息,从而尽早采取措施。众所周知,当进度压力非常大时,测试、特别是开发阶段的测试会受到很大影响。如果有一个合适的正式的测试进度度量,开发团队不容易忽视这个问题。从项目计划的角度来说,S曲线迫使团队更好的计划整个项目。
基于时间的缺陷到达
测试阶段的缺陷追踪和管理对所有的软件测试都是值得推荐的。
相对产品发布时间来说,缺陷到达何时达到峰值?当前版本的缺陷到达模式与前面的版本相比如何?达到的峰值是多少?在发布前缺陷到达是否降低到一个低而稳定的水平?以上这些问题都是缺陷到达度量的关键,对产品在领域中应用的质量有重要意义,因为这些问题都暗示着将来产品的质量。
比较好的缺陷到达模式应当是这样的:早期到达率较高,峰值到达的较早,在产品发布日期前到达率降低到一个较低的层次。
基于时间的缺陷积压
任何给定时间内遗留的测试缺陷定义为缺陷积压,简单来说,缺陷积压是到达的缺陷与修复的缺陷之间的累积数目之差。从测试进度的角度来说,缺陷积压的追踪和管理是非常重要的。
开发过程中大量的问题积压会妨碍测试进程
当产品将要发布给用户时,存在大量的缺陷积压意味着在开发周期已经发现的很多缺陷将在用户使用时重现。
但是,在开发过程中,降低缺陷积压不一定是优先级高的任务。
如果当前的重要开发活动是功能测试,管理缺陷积压不应当具有高的优先级,重点应当一直放在测试效率和测试执行上,鼓励大可能的发现缺陷。
如果当前阶段的主要目标是修复可能危害测试进程的重大缺陷上,不必把工作重点放在降低整个缺陷积压上
在测试将要结束时,重点应当放在大幅度降低缺陷积压上
推荐以下的全局测试管理方法:
1)当测试计划制订好,有效性已经通过审核并被接受,管理测试进度,从而尽早获得S曲线的早期上升斜面
2)监控缺陷到达,分析问题,从而获得如何采取改进行动的信息。不要认为的控制缺陷到达,这是与测试效率、测试进度和代码内在质量(代码中潜伏的缺陷数)都有关的。
3)加强管理缺陷积压的降低,力图达到预期目标,危害测试进程的已知缺陷应当赋予高的优先级