由【测试过程分析的15个常用度量元】而起
上一篇 /
下一篇 2008-01-21 14:23:43
/ 个人分类:测试质量
以下这个表格摘自:http://www.sawin.cn/doc/QM/Test/TheEdge422.htm 感谢原创作者。
序号 | 优先级 | 度量对象 | 度量元 | 度量单位 | 采集周期 | 采集/计算方法 | 分析方法 | 作用 |
1 | 1 | 用户发现的各类型的缺陷 | 缺陷个数 | 个 | 交付阶段 | 直接统计 | 80-20分析:对缺陷类型按缺陷个数排序,找出客户发现的最多的20%的缺陷类型 | 分析客户的关注点是什么?为什么客户能发现这些类型的缺陷,为什么我们没有测试出来?定义改进措施 |
维护阶段 |
2 | 1 | 软件模块 | 缺陷密度 | 个/KLOC | 系统测试阶段 | 缺陷个数/代码规模 | 80-20分析:对所有模块的缺陷密度进行排序比较,找出缺陷密度最大的20%模块 | 找出质量最差的模块,采取改进措施 |
3 | 1 | 遗留的缺陷 | 缺陷个数 | 个 | 系统测试阶段 | 上阶段遗留的缺陷个数+本阶段发现的缺陷个数-本阶段解决的缺陷个数 | 和阶段出口准则对比 | 里程碑评审决策的依据 |
4 | 1 | 各级别严重程度的缺陷 | 缺陷个数 | 个 | 系统测试阶段 | 直接统计 | 和项目目标对比 | 判断是否达到测试结束与产品发布准则 |
5 | 1 | 回归测试活动 | 缺陷个数 | 个 | 系统测试阶段 | 直接统计 | 趋势线分析:横坐标为某次回归测试,纵坐标为缺陷个数,建立拟合曲线,判断收敛性 | 针对每次回归测试活动,进行收敛分析,作为发布决策的依据 |
6 | 2 | 代码走查 | 代码走查的效率 | 个/小时 | 编码阶段 | 代码走查发现的缺陷个数/代码走查的工作量 | 和项目目标对比 | 比较评审与测试的效率,以确定二者投入工作量的比例 |
7 | 2 | 单元测试 | 测试效率 | 个/小时 | 编码阶段 | 单元测试发现的缺陷个数/单元测试的工作量 | 和项目目标对比 | 建立单元测试的性能基线,预测单元测试投入的工作量 |
8 | 2 | 系统测试 | 测试效率 | 个/小时 | 系统测试阶段 | 缺陷个数/测试工作量 | 和项目目标对比 | 建立测试活动的投入产出模型,用以估计为了达到项目的质量目标而需要的测试工作量 |
9 | 2 | 系统测试 | 系统测试用例相对逻辑规模的密度 | 个/功能点 | 系统测试阶段 | 系统测试用例个数/需求的规模 | 和项目目标对比 | 判断系统测试的充分性 |
10 | 2 | 系统测试 | 系统测试用例相对物理规模的密度 | 个/KLOC | 系统测试阶段 | 系统测试用例个数/代码规模 | 和项目目标对比 | 判断系统测试的充分性 |
11 | 3 | 测试发现各类型的缺陷 | 缺陷个数 | 个 | 编码阶段 | 直接统计 | 80-20分析:对缺陷类型按缺陷个数排序,找出最多的20%的缺陷类型 | 根据类型的分布,查找错误的原因,定义编码或设计的改进措施 |
系统测试阶段 |
12 | 3 | 单元测试 | 缺陷密度 | 个/KLOC | 编码阶段 | 单元测试发现的缺陷个数/代码规模 | 和项目目标对比 | 建立单元测试的性能基线,用以制定项目的质量目标 |
13 | 3 | 单元测试 | 单元测试用例相对物理规模的密度 | 个/KLOC | 编码阶段 | 单元测试用例个数(或断言的个数)/KLOC | 和项目目标对比 | 判断单元测试的充分性 |
14 | 3 | 集成测试 | 集成测试用例相对物理规模的密度 | 个/KLOC | 集成阶段 | 集成测试用例个数/KLOC | 和项目目标对比 | 判断集成测试的充分性 |
15 | 3 | 系统测试 | 测试用例的有效性 | % | 系统测试阶段 | 依据测试用例发现的缺陷个数/所有的缺陷个数 | 和项目目标对比 | 评价测试用例的有效性,判断是否需要提高测试用例的设计技术 |
以上这些度量项,对于测试管理者来说应该都不陌生,全部整理到一起,真的还是蛮齐全的了。测试品质保证的乐趣,其实很多就在这些关键度量元素间。其一,这样的分析显然是颇具科学意义的,统计学嘛;其二,真正能通过管理这些度量项达到提高质量的效果,那是一件很美妙的事情。我个人而言,比较有实用感触的是1,2,3,5,15这几项,上了底色。
1---客户反馈缺陷,即漏测。其实这是一个很直观的质量保证结果,本人非常崇尚用这个指标衡量测试人员的结果绩效。虽然漏测的原因不单单在于测试的疏忽,但终究能在很大程度上体现测试的质量。且通过对这个指标的线性观察,发现一些潜在的可能在未来会反馈回来的问题,我们还能亡羊补牢,出补丁提前堵漏。
2---模块缺陷密度。往往找到缺陷最多的地方也是潜在缺陷最多的地方。这个规律几乎是千真万确。就跟越是担心会出问题的时候一般都是会出问题的,类似。这个在测试过程中或者发布之后拿来分析都很有意义。
3---遗留缺陷。仅仅看一个绝对的数字并无太大意义,它的意义在于与之前拟定的交付标准做比对,假若在标准之内就放行,不在标准之内那就卡住。另外,被允许的遗留缺陷一般也是下一阶段启动任务之时开发任务的首要任务之一。
5---趋势分析。这是一个质量活动如期完成的强力证明工具,当然要真正看到收敛才对。
15--测试用例有效率。这个指标更大意义的是规范测试活动,其次才是提高测试用例的质量。想要统计出有效率,有个前提就是测试集驱动测试,即你开展每一轮测试之前,根据测试需求建立好测试集,并且集里面的测试用例也都已经确定好,之后照着逐一测试。很多测试人员说测试用例只不过是我用来熟悉需求的产物,等我拿到被测对象,我根本就不看测试用例就刷刷的往下测。殊不知,人的记忆往往是有漏洞的,当你脱离测试用例来测试,你就是在走向随机测试,大家想想随机的活动有没有可把握性?
简单评论之后,我再加一个度量项,尤其是在这提倡测试先行的年代。---需求review阶段发现的需求issue数/整个测试过程中发现的需求Issue的总数,这个指标体现测试人员在需求熟悉阶段对需求透析程度,透析度越深往往对促进需求精致化的贡献度越大,对测试用例的有效性的贡献也越大。我们毕竟不希望到了测试执行阶段才来不停的质疑需求这里有问题那里有问题。
收藏
举报
TAG:
测试质量