0532-58820295

测试质量评估与度量之如何把握软件产品的质量?

发布时间:2021-9-1
来源:

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

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

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

  发布之前

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

  ● Bug

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

  ● 测试通过率

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

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

  ● 测试覆盖率

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

  ● 信心

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

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

  发布之后

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

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

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

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

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

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

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

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

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

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

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

  2. 架构设计方案评审

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

  4. 代码的review的机制

  5. 测试用例评审

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

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

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

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

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

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

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


更多新闻

专业测试,请联系我们!
0532-58820295