产品质量评估与度量

不管产品规模是大还是小,结构简单还是复杂,质量评估都不是一件容易的事情。

尽管很难,但质量评估仍然是必需的,因为关系到版本是否能够发布、测试工作是否有效、测试投入是否有价值等。

那么,如何把握软件产品的质量?

发布之前

产品发布之前可以对如下指标进行评估

● Bug

Bug数量、Bug趋势图、Bug分布图等,有利于我们对问题的归纳总结。

● 测试通过率

包括计划的测试用例执行进度、通过的测试用例数目、失败的测试用例数目、被阻塞的测试用例数目等。一般要求达到95%以上。

我们还利用一次通过率去衡量开发的质量,这里不做详细的阐述。还可以延伸到模块通过率,来衡量系统某一具体功能模块的稳定性。

● 测试覆盖率

包括业务覆盖率(核心业务场景)、测试类别(性能、安全测试等)。业务覆盖率必须全部覆盖,根据产品的性质,考虑性能指标、安全指标是否需要100%达标。

● 信心

测试负责人对所测版本及需求的主观感受。作为需求及版本的第一手用户,测试员对其有比较敏感的判断。

延伸到我们经常提的:测试总结或者版本发布公告,应该包含但不限于上述提到的几项指标。

发布之后

软件产品发布之后一般面向的是项目(面向测试发布的制品进行一轮验证),亦或者是客户(直接部署到正式环境,面向客户使用)。

针对发布后的评估,根据项目或者客户现场发现的问题数量/(测试发布时发现的问题数量+客户现场发现的问题数量)*100%

一般统计周期是三个月,一般控制在10%以内算正常,当然也要看问题的严重等级。

 

那么,又该如何更合理的度量产品质量呢?

常见的有千行代码错误率,CMMI级别也定义了每一级的错误率:

有的公司也逐渐从CMM1升级到了CMM3,量化的指标比较能够直观的反应一些问题,不至于问起来质量好坏都是,我觉得应该可以。

但也有不少诟病:代码冗余;为了CMMI定级而去冲指标。

所以,我们也不能完全依赖千行代码错误率去评判和衡量产品质量的好坏,测试度量的目标还是提高产品质量。

从研发阶段和效率价值金字塔看,自底向上,越早参与测试发现问题,后期的投入就越少,产品质量就越稳定。

自底向上,我们可以做哪些工作来保障产品质量呢:

1. 需求的评审:测试参与

2. 架构设计方案评审

3. 代码模块设计,包的依赖的规划,接口的设计的review

4. 代码的review的机制

5. 测试用例评审

6. 使用代码检测工具,自动发现问题

7. 使用自动化测试,自动检测历史功能及模块完整性

8. 完善测试流程,增加性能、安全等未涉及领域测试

9. 漏洞Review分析,测试总结

当然上述每项,单独做起来都是需要耗时耗力的,前期还要有专人负责牵头保障效果与执行监督。

产品质量不是测试出来的,需要上游产品设计、开发编码、架构设计等环节以及下游运维、实施、维护等环节共同保障。

单纯依赖测试去保障研发出来的产品,只是冰山一角,更多的问题需要大家共同去关注,协同保障产品质量。

 

个人认为

完全依赖一些量化的指标去评判产品质量的好坏、测试质量的好坏是不够的,重点是数据背后的问题,管理者要重视起来,找到问题的根源并有意识的去提升。

这样产品质量才能持续稳步的提升。

posted @ 2019-01-30 16:14  拜托拜托  阅读(1873)  评论(0编辑  收藏  举报