测试质量评估与度量

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

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

那么，如何把握软件产品的质量？

发布之前

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

Bug

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

测试通过率

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

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

测试覆盖率

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

信心

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

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

发布之后

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

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

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

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

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

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

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

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

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

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

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

2. 架构设计方案评审

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

4. 代码的review的机制

5. 测试用例评审

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

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

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

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

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

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

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

个人认为

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

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

作者：拜托拜托

原文链接：https://www.cnblogs.com/starlight-yang/p/10237936.html