• 产品质量评估与度量


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

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

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

    发布之前

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

    ● Bug

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

    ● 测试通过率

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

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

    ● 测试覆盖率

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

    ● 信心

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

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

    发布之后

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

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

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

     

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

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

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

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

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

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

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

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

    2. 架构设计方案评审

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

    4. 代码的review的机制

    5. 测试用例评审

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

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

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

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

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

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

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

    个人认为

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

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

  • 相关阅读:
    delphi中屏蔽浏览器控件右键菜单
    书目:一些
    数据库ADONETDataAdapter对象参考
    数据库ADONET排序、搜索和筛选
    易语言数据类型及其长度
    易语言数据类型的初始值
    数据库ADONET使用DataAdapter对象
    ADONET使用DataSet处理脱机数据
    数据库ADONETOleDbParameter对象参考
    在项目中添加新数据集
  • 原文地址:https://www.cnblogs.com/panda-sweets/p/10237936.html
Copyright © 2020-2023  润新知