度量项目质量优劣的六个维度及用例评价的质量维度
2012-10-09 10:36
302 查看
主要是从测试工作的角度,对几个测试相关的维度进行分析,说明它们是如何影响项目质量的。这6个维度是作者自己的总结,这六个维度也只是和功能测试有关,至于系统的性能、可靠性、可用性如何度量
首先,我们要明确一个概念,就是“严重bug”。这6个维度,有很多都和严重bug有关。严重bug指的是项目中,严重性是1级和2级的bug。注意,并不是优先级,而是严重性。严重性1级是“block”,指程序无法正常运行或者是测试无法正常进行,随便点两下,就报错;2级是major,指功能的各种错误,总之是用户不可接受的错误。3级大多是文案或者是易用性的问题,用户可以接受少量这种类型的bug。
好,下面开始讨论那六个维度,我会说明计算方法,以及它们的战略意义。
1、严重bug数 / 测试用例数
这个维度代表了一个项目的严重bug数量是否正常,让测试用例参与计算,是为了平衡规模不同的项目的数据。
2、第三轮测试出现的严重bug数 / 严重bug总数
目前我们的测试过程模型是“三轮测试”,三轮的目标分别是:发现bug、验证bug、稳定回归。如果在第三轮回归的时候,还出现大量严重bug,那肯定是不正常的,也会对质量构成巨大风险。这个数字应该要控制在一个很低的水平。
3、被reopen的严重bug / 严重bug总数
reopen指开发fix后,测试验证不通过,或者是已经close的bug又复发。这个维度也应该被控制在一个很低的水平,如果偏高,说明开发修复bug的效率偏低,代码不稳定,发布后出现bug的几率增加。
4、第二轮测试用例执行通过率
因为第二轮的目标就是修复bug,所以如果第二轮结束的时候,严重bug全部被修复,并且第三轮没有出现新的严重bug,那么可以说项目的质量是非常稳定的。这里判定第二轮用例通过与否的标准,就是看第二轮结束时,如果有严重bug没有关闭,那相关的测试用例就是failed。此外,3级bug如果没有关闭,除非有确定的用例与之对应,否则不会影响用例的通过率。
5、测试工作量(人月) / 测试用例数
这个维度代表投入的测试资源是否充足,这里的工作量,指的是从测试设计到测试执行的所有人月数。如果数字过低,说明测试资源紧张,无法保证测试质量;如果过高,说明有可能测试效率低,测试经理需要进行解释。
6、严重bug平均关闭时间(天)
bug 关闭时间,指bug从创建开始,到close为止,经过的时间,要精确到小数点后1位。只有状态是close的bug,才会计算关闭时间。平均关闭时间的计算方法也很简单,把所有closed严重bug求平均值即可。这个维度代表项目组解决bug的效率,如果时间太长,说明项目组对bug重视不够。
其实要度量项目的质量,还有很多维度要考虑,比如需求文档、设计方案、代码等等,不过我们还是先在测试的范畴进行讨论,欢迎大家对这些维度提改进建议,或者提出新的维度。
用例评价的质量维度
正确性:确保测试标题描述部分的内容正确性。
经济性:只为确定需要的目的设计相应的测试步骤。
可重复性:自我一致性,即不管谁执行此用例,结果一样。
适应性:既能适应短期需要,又能考虑长远需要。
可追踪性:用例能追踪到一个具体的需求
自我清理性:单个用例不会影响整个测试环境,即用例执行完了可以恢复原有的测试环境。
可测试性:用例的测试目的和操作在具体系统中是可实现的,可操作,可观察的。
指导性:用例的操作步骤能够指导执行人员完成测试,并准确判断结果是否正确
覆盖率:保障对需求的完全覆盖,“用例数/需求”达到质量目标
规范性:格式规范,且所有用例都符合统一的写作规范
有效性:用例发现问题的效率可用“百用例发现问题数”或“平均用例发现问题数”来度量
5C原则:Correct(准确)、Clear(清晰)、Concise(简洁)、Complete(完整)、Consistent(一致)
首先,我们要明确一个概念,就是“严重bug”。这6个维度,有很多都和严重bug有关。严重bug指的是项目中,严重性是1级和2级的bug。注意,并不是优先级,而是严重性。严重性1级是“block”,指程序无法正常运行或者是测试无法正常进行,随便点两下,就报错;2级是major,指功能的各种错误,总之是用户不可接受的错误。3级大多是文案或者是易用性的问题,用户可以接受少量这种类型的bug。
好,下面开始讨论那六个维度,我会说明计算方法,以及它们的战略意义。
1、严重bug数 / 测试用例数
这个维度代表了一个项目的严重bug数量是否正常,让测试用例参与计算,是为了平衡规模不同的项目的数据。
2、第三轮测试出现的严重bug数 / 严重bug总数
目前我们的测试过程模型是“三轮测试”,三轮的目标分别是:发现bug、验证bug、稳定回归。如果在第三轮回归的时候,还出现大量严重bug,那肯定是不正常的,也会对质量构成巨大风险。这个数字应该要控制在一个很低的水平。
3、被reopen的严重bug / 严重bug总数
reopen指开发fix后,测试验证不通过,或者是已经close的bug又复发。这个维度也应该被控制在一个很低的水平,如果偏高,说明开发修复bug的效率偏低,代码不稳定,发布后出现bug的几率增加。
4、第二轮测试用例执行通过率
因为第二轮的目标就是修复bug,所以如果第二轮结束的时候,严重bug全部被修复,并且第三轮没有出现新的严重bug,那么可以说项目的质量是非常稳定的。这里判定第二轮用例通过与否的标准,就是看第二轮结束时,如果有严重bug没有关闭,那相关的测试用例就是failed。此外,3级bug如果没有关闭,除非有确定的用例与之对应,否则不会影响用例的通过率。
5、测试工作量(人月) / 测试用例数
这个维度代表投入的测试资源是否充足,这里的工作量,指的是从测试设计到测试执行的所有人月数。如果数字过低,说明测试资源紧张,无法保证测试质量;如果过高,说明有可能测试效率低,测试经理需要进行解释。
6、严重bug平均关闭时间(天)
bug 关闭时间,指bug从创建开始,到close为止,经过的时间,要精确到小数点后1位。只有状态是close的bug,才会计算关闭时间。平均关闭时间的计算方法也很简单,把所有closed严重bug求平均值即可。这个维度代表项目组解决bug的效率,如果时间太长,说明项目组对bug重视不够。
其实要度量项目的质量,还有很多维度要考虑,比如需求文档、设计方案、代码等等,不过我们还是先在测试的范畴进行讨论,欢迎大家对这些维度提改进建议,或者提出新的维度。
用例评价的质量维度
正确性:确保测试标题描述部分的内容正确性。
经济性:只为确定需要的目的设计相应的测试步骤。
可重复性:自我一致性,即不管谁执行此用例,结果一样。
适应性:既能适应短期需要,又能考虑长远需要。
可追踪性:用例能追踪到一个具体的需求
自我清理性:单个用例不会影响整个测试环境,即用例执行完了可以恢复原有的测试环境。
可测试性:用例的测试目的和操作在具体系统中是可实现的,可操作,可观察的。
指导性:用例的操作步骤能够指导执行人员完成测试,并准确判断结果是否正确
覆盖率:保障对需求的完全覆盖,“用例数/需求”达到质量目标
规范性:格式规范,且所有用例都符合统一的写作规范
有效性:用例发现问题的效率可用“百用例发现问题数”或“平均用例发现问题数”来度量
5C原则:Correct(准确)、Clear(清晰)、Concise(简洁)、Complete(完整)、Consistent(一致)
相关文章推荐
- 从测试角度度量项目质量的7个维度
- 如何开展项目质量管理,初步探讨“度量”
- QS0004-2012 瞿氏标准(Qu's Standards)软件项目代码结构质量评价标准
- 软件项目质量管理与度量
- 软件项目质量管理与度量
- 如何看待项目开发过程中基于度量结果的绩效考评
- 你的ERP项目实施为啥质量高不了?
- 图像质量评价指标--大全
- 编写测试用例时参照实际项目还是需求文档?
- 评价Logistic回归模型优劣的两个重要参数AIC和BIC
- 质量保证的六个模式(4) - 客户代表质量模式
- 项目管理系列之质量管理(四)
- 一种H.264高清视频的无参考视频质量评价算法(基于QP和跳过宏块数)
- 软件项目质量管理经验谈
- 评价 Ant Design项目
- 流媒体视频质量评价(单刺激连续质量评价方法)
- 什么软件质量/如何评价软件的质量
- H.264 视频质量评价方法 (基于视频内容)
- 视频质量评价方法:VQM
- 集成开源系统实现自动化构建、代码质量评估、项目信息统计(1)——Jenkins安装