最近评论
正在载入评论列表...
12.2 步骤2：定义度量目标
“你无法控制你不能度量的东西”，这是Tom DeMarco的著作《控制软件项目》一书中的名言，在这本书中他描述了如何组织和控制一个软件项目，这个项目在时间和投资规划上都是可度量的。控制是经理保证风险最小化的范围。一旦发现计划偏离应及早报告，这样可以帮助我们尽快做出响应。DeMarco书中的另外一句名言，“唯一不可原谅的失败就是没有从过去的失败中得到教训”，这句话强调了评估和度量的重要性。测量是对过去成果的记录，可以定量地预计将来成果。
12.2.1 任务1：定义度量标准
作为测试开发项目，软件测试有很多交付物：测试计划、测试设计、测试开发和测试执行等。这个任务的目的就是应用度量标准来控制测试过程。度量标准是系统的某个数量方面的一个可测量的指标，有如下特征。
l 可测量——从定义上来说，度量点必须是可测量的才可以成为度量标准。如果不可测量的话，我们就没有办法使用管理手段来控制它。
l 独立性——度量标准应该独立于人为的影响。除了改变产生该度量标准的事件，没有任何其他办法可以改变该度量标准。
l 责任性——对原始度量标准数据的任何分析和解释都是建立在该数据本身上的，因此，我们必须保存好原始数据和分析过程的有条理的审计轨迹。
l 精确性——精确性是精度的一个函数。精确性的关键在于在文档中明确地把度量标准规定为数据收集过程的一部分。如果度量标准是可变的，我们可以当作一个范围来测量。
度量标准可以是一个“结果”或者“预测”。“结果”度量标准用来测量已经完成的事件或者过程。举例来说：执行一个业务事务的实际耗时或者一个项目的总花费。“预测”度量标准是一个早期预警的度量标准，与之后的结果有密切联系。例如，通过统计回归分析，我们可以在终端数量还没有测量之前，预计出当越来越多的终端加入到系统中时系统的反应时间。“结果”或者“预测”度量标准可以同时是导出度量标准。导出度量标准是通过计算或者图像技术、由一个或多个度量标准导出的。
收集测试度量标准的动机是让测试过程更加有效率。这个目标是通过仔细分析度量标准数据，并且采取适当的方法修正出现的问题来实现的。首先要定义度量标准的关注目标。下面是一些例子。
l 缺陷分析——每个缺陷都应该分解为如下问题的回答：根本原因是什么、如何发现的、何时发现的、谁发现的等。
l 测试效率——测试进行得如何，例如投入的回报率如何？
l 开发效率——开发人员处理缺陷的进度如何？
l 测试自动化——花费了多少精力在测试自动化上？
l 测试成本——在测试方面花费了多少资源和时间？
l 测试状态——另外一个重要的度量标准是状态跟踪，或者说我们现在处于测试过程的什么阶段？
l 用户参与——有多少用户参与到了测试中？
12.2.2 任务2：定义度量要点
表12-6中列出了一些度量要点，这些要点有的和上一个任务中选择的综合度量有关，有些和能够改进测试过程的行为有关。同时也展示出了度量要点的来源或者出处。
表12-6 度量要点
|
度量标准 |
度量要点 |
来 源 |
|
缺陷分析： |
缺陷起因的分布 |
直方图，帕思托图 |
|
按时间统计的不同原因的缺陷数目 |
多线图 |
|
|
按时间统计的不同发现方法的缺陷数目 |
多线图 |
|
|
不同模块的缺陷分布 |
直方图，帕思托图 |
|
|
不同优先级的缺陷分布（紧急、高、中、低） |
直方图 |
|
|
不同功能区域的缺陷分布 |
直方图 |
|
|
不同环境（平台）的缺陷分布 |
直方图，帕思托图 |
|
|
不同类型的缺陷分布（架构、连接、一致性、数据库完整性、文档、图形用户界面、安装、内存、性能、安全性、标准和惯例、压力、易用性、错误的修复） |
直方图，帕思托图 |
|
|
不同发现人员的缺陷分布（外部用户、内部用户、开发人员、质量保证人员及其他人员） |
直方图，帕思托图 |
|
|
不同发现方式的缺陷分布（技术评审、走查、JAD、原型、审查、测试执行） |
直方图，帕思托图 |
|
|
不同重要性的缺陷分布（高、中、低） |
直方图 |
|
|
开发效率： |
开发人员修复缺陷的平均时间 |
总的修复时间÷修复的缺陷数量 |
|
测试自动化： |
手动测试和自动测试的比例 |
手动测试工作量÷总的测试工作量 |
|
测试成本： |
不同原因的成本分布 |
直方图，帕思托图 |
|
不同应用程序的成本分布 |
直方图，帕思托图 |
|
|
测试占总成本的比例 |
测试成本÷系统总成本 |
|
|
按时间统计的测试总成本 |
线图 |
|
|
定位一个缺陷的平均成本 |
测试总成本÷发现的缺陷数目 |
|
|
预期测试成本和实际成本的比较 |
对照 |
|
|
通过需求评审定位一个需求缺陷的平均成本 |
需求评审成本÷需求评审阶段发现的缺陷数目 |
|
|
通过设计评审定位一个设计缺陷的平均成本 |
设计评审成本÷设计评审阶段发现的缺陷数目 |
|
|
通过代码评审定位一个代码缺陷的平均成本 |
代码评审成本÷代码评审阶段发现的缺陷数目 |
|
|
通过测试执行定位一个缺陷的平均成本 |
测试执行成本÷测试执行阶段发现的缺陷数目 |
|
|
按时间统计的测试资源数目 |
线图 |
|
|
测试效率： |
维护过程中发现的缺陷的百分比 |
维护过程中发现的缺陷数目÷发现的缺陷总数 |
|
测试发现缺陷的百分比 |
测试过程中发现的缺陷数目÷发现的系统缺陷总数 |
|
|
测试的平均效率 |
测试数量/发现的系统缺陷总数 |
|
|
需求评审回报价值 |
需求评审过程中发现的缺陷数目÷需求测试成本 |
|
|
设计评审回报价值 |
设计评审过程中发现的缺陷数目÷设计测试成本 |
（续）
|
度量标准 |
度量标准要点 |
来 源 |
|
程序评审回报价值 |
程序评审过程中发现的缺陷数目÷程序测试成本 |
|
|
测试执行回报价值 |
测试执行过程中发现的缺陷数目÷测试成本 |
|
|
测试变更的效果 |
测试变更的数目÷可归于变更的问题数量 |
|
|
人们对于测试效率的评价 |
主观评价（1~10） |
|
|
测试人员检验修正的平均时间 |
总的测试人员检验时间÷需要检验的缺陷总数 |
|
|
按时间统计的缺陷数量 |
线图 |
|
|
按时间统计的缺陷累计数量 |
线图 |
|
|
按时间统计的不同应用程序缺陷数量 |
多线图 |
|
|
测试范围： |
语句执行百分比 |
执行的语句数目÷语句总数 |
|
逻辑路径执行百分比 |
执行的逻辑路径数目÷逻辑路径总数 |
|
|
验收标准经过测试的百分比 |
经过测试的验收标准÷验收标准总数 |
|
|
按时间统计的需求测试数量 |
线图 |
|
|
按时间统计的语句执行数量 |
线图 |
|
|
按时间统计的数据元素使用数量 |
线图 |
|
|
按时间统计的判断语句执行数量 |
线图 |
|
|
测试状态： |
按时间统计的等待执行的测试数量 |
线图 |
|
按时间统计的测试执行数量 |
线图 |
|
|
没有发现缺陷的测试数量 |
线图 |
|
|
按时间统计的被修正的缺陷数量 |
线图 |
|
|
用户参与： |
用户测试的百分比 |
用户测试时间÷测试总时间 |
图书导读
