51Testing软件测试论坛

 找回密码
 (注-册)加入51Testing

QQ登录

只需一步,快速开始

微信登录,快人一步

手机号码,快捷登录

查看: 4375|回复: 4
打印 上一主题 下一主题

[讨论] 衡量软件质量提高的标准

[复制链接]

该用户从未签到

跳转到指定楼层
1#
发表于 2010-5-5 18:35:12 | 只看该作者 回帖奖励 |倒序浏览 |阅读模式
最近在讨论这个话题,比如这个release比上个的defect减少,但这样只是个大概的提法,具体到多少又该采取什么标准呢?
还有其他方面希望大家多多列举
分享到:  QQ好友和群QQ好友和群 QQ空间QQ空间 腾讯微博腾讯微博 腾讯朋友腾讯朋友
收藏收藏
回复

使用道具 举报

  • TA的每日心情
    奋斗
    2018-2-28 18:04
  • 签到天数: 40 天

    连续签到: 1 天

    [LV.5]测试团长

    2#
    发表于 2010-5-11 14:44:41 | 只看该作者
    如果有比较好的标准和规范以及良好的执行监督,那么可以使用需求符合度等指标来定义
    从代码质量上衡量,仅仅是多少个bug并不能说明什么问题。
    回复 支持 反对

    使用道具 举报

  • TA的每日心情
    奋斗
    2022-5-8 19:23
  • 签到天数: 137 天

    连续签到: 1 天

    [LV.7]测试师长

    3#
    发表于 2010-5-13 21:45:38 | 只看该作者
    这个的确很难做,前不久,我们做过一次以BUG数做为项目质量的参考,开发人员意见都很大
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    4#
    发表于 2010-5-14 10:46:27 | 只看该作者
    我想到两方面:
    一是bug要分严重级别,每个级别bug的数量的减少可能更说明问题。更关注最严重问题的标准?
    一是多个版本的bug跟踪曲线可能比单纯数量更说明问题。
    具体到比如一次测试的bug数到多少质量才算提高我觉得恐怕是没办法提的,bug的差异性还是很大的。
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    5#
    发表于 2010-5-18 22:02:44 | 只看该作者
    可以从这几个角度考虑一下:
    1、不同阶段以不同严重程度的 bug 数量来衡量;
    2、不要用每一个 release 来总结,而是以测试循环为单位来总结;
    3、提早确定里程碑 release 的 bug 数量指标并公示。
    回复 支持 反对

    使用道具 举报

    本版积分规则

    关闭

    站长推荐上一条 /1 下一条

    小黑屋|手机版|Archiver|51Testing软件测试网 ( 沪ICP备05003035号 关于我们

    GMT+8, 2024-11-26 18:42 , Processed in 0.067781 second(s), 27 queries .

    Powered by Discuz! X3.2

    © 2001-2024 Comsenz Inc.

    快速回复 返回顶部 返回列表