51Testing软件测试论坛

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

QQ登录

只需一步,快速开始

微信登录,快人一步

手机号码,快捷登录

查看: 8024|回复: 19
打印 上一主题 下一主题

[原创] 大家都如何做测试缺陷分析工作的?

[复制链接]

该用户从未签到

跳转到指定楼层
1#
发表于 2010-12-26 10:23:05 | 只看该作者 回帖奖励 |倒序浏览 |阅读模式
大家都如何做测试缺陷分析工作的?有经验的朋友介绍一下经验了,谢谢啦!!
分享到:  QQ好友和群QQ好友和群 QQ空间QQ空间 腾讯微博腾讯微博 腾讯朋友腾讯朋友
收藏收藏
回复

使用道具 举报

该用户从未签到

2#
发表于 2010-12-27 14:32:22 | 只看该作者

给你看张截图,应该对你有所帮助!

本帖子中包含更多资源

您需要 登录 才可以下载或查看,没有帐号?(注-册)加入51Testing

x
回复 支持 反对

使用道具 举报

该用户从未签到

3#
 楼主| 发表于 2011-5-18 10:46:39 | 只看该作者
还有人有好的建议吗?
回复 支持 反对

使用道具 举报

  • TA的每日心情

    2019-12-27 13:32
  • 签到天数: 15 天

    连续签到: 1 天

    [LV.4]测试营长

    4#
    发表于 2011-5-18 10:53:13 | 只看该作者
    缺陷管理的目的是控制软件bug的增长,在不同版本控制在1个稳定的数值内,当达到1个稳定的bug增长和修复率是缺陷管理的成功标准。可以借助缺陷管理工具中的甘比图。这个是比较简单办法。
    1.风险控制
    风险控制首先需要做到记录下高发的bug功能点,对上个版本未修复的bug进行记录。
    风险对比管理:定1个标杆,比如 v1.1版本的内容就拿v1.0版本做参照物。bug增长,当同类型bug反复出现就需要引起关注。
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    5#
    发表于 2011-6-16 10:34:58 | 只看该作者
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    6#
    发表于 2011-6-16 13:53:54 | 只看该作者
    回复 支持 反对

    使用道具 举报

  • TA的每日心情
    开心
    2021-6-9 14:08
  • 签到天数: 1 天

    连续签到: 1 天

    [LV.1]测试小兵

    7#
    发表于 2011-6-30 06:20:18 | 只看该作者
    不知道楼主想知道测试中的缺陷分析还是测试结束后的缺陷分析,在我公司有一个“过BUG”的过程,就是测试员和开发聚在一起对提交的BUG进行沟通和交流,尽量让两方解决达成一致。
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    8#
    发表于 2011-7-13 13:47:01 | 只看该作者
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    9#
    发表于 2011-7-25 14:38:50 | 只看该作者
    回复 支持 反对

    使用道具 举报

  • TA的每日心情
    开心
    2021-6-9 14:08
  • 签到天数: 1 天

    连续签到: 1 天

    [LV.1]测试小兵

    10#
    发表于 2011-7-25 20:27:30 | 只看该作者
    回复 9# ruirui。


        电话的效果不如当面沟通的好
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    11#
    发表于 2011-7-26 11:25:21 | 只看该作者
    2#截图说的就已经非常全面了,至少我是这么认为的.
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    12#
    发表于 2011-7-29 21:25:17 | 只看该作者
    本帖最后由 chenxubest 于 2011-7-29 21:27 编辑

    我对二楼不满意,没一点专点水准,空谈 看看这里,这才是叫度量
    (原创)(三)作为测试负责人测试过程监控中关注的度量数据
    http://blog.sina.com.cn/s/blog_6fbdee570100p71k.html
    共分为三个系列
    导读我们将从,测试人员,开发人员,项目及过程管理,三个角度来分析
    另外再付两个分析
    BUG龄期的分析探讨
    http://blog.sina.com.cn/s/blog_6fbdee570100rrhv.html
    (原创)测试趋势6曲线解读
    http://blog.sina.com.cn/s/blog_6fbdee570100rkgq.html
    回复 支持 反对

    使用道具 举报

  • TA的每日心情
    无聊
    2020-12-8 11:20
  • 签到天数: 605 天

    连续签到: 1 天

    [LV.9]测试副司令

    13#
    发表于 2011-8-3 10:37:05 | 只看该作者
    回复 7# 千里


        赞一个。。。以前我们也是一样的
    回复 支持 反对

    使用道具 举报

  • TA的每日心情
    开心
    2021-6-9 14:08
  • 签到天数: 1 天

    连续签到: 1 天

    [LV.1]测试小兵

    14#
    发表于 2011-8-4 07:28:57 | 只看该作者
    回复 13# joykao


        这种办法的好处就是让一些存在分歧的BUG早一点得到沟通和解决
    回复 支持 反对

    使用道具 举报

  • TA的每日心情
    无聊
    2020-12-8 11:20
  • 签到天数: 605 天

    连续签到: 1 天

    [LV.9]测试副司令

    15#
    发表于 2011-8-4 16:31:47 | 只看该作者
    回复 14# 千里


        agree withyou
    回复 支持 反对

    使用道具 举报

  • TA的每日心情
    奋斗
    2020-10-12 15:25
  • 签到天数: 3 天

    连续签到: 1 天

    [LV.2]测试排长

    16#
    发表于 2011-8-17 14:06:38 | 只看该作者
    华为也是采用这样的方式
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    17#
    发表于 2011-8-18 10:34:09 | 只看该作者
    我赞同二楼crazy715 和七楼千里的观点,在我自己实际的测试工作中,每一份测试报告中都要求系统未关闭BUG的缺陷状态和缺陷严重性的数量统计,例如:系统未关闭BUG总计:103个,其中New:27个,Open:10个,Fixed:13个,FixLater:10个,Reopen:25个,Question:18个;其中Urgent:19个,High:46个,Medium:21个,Low:17个。
    一般情况下,测试组会组织一次BUG讨论会议,专门针对Question和Reopen的问题进行讨论,最终确定这些BUG的处理方式。
    回复 支持 反对

    使用道具 举报

  • TA的每日心情

    2014-10-28 14:05
  • 签到天数: 1 天

    连续签到: 1 天

    [LV.1]测试小兵

    18#
    发表于 2011-8-23 12:22:37 | 只看该作者
    Test Leader 、team member、开发某个模块的负责人 在一起,每天下午开个会,大家对提的每一个defect进行分析,看这个defect是由于什么原因造成的,或者这个defect 是不是真的defect。对于High 和Critical 的defect 需要开发人员马上解决
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    19#
    发表于 2011-9-5 11:12:14 | 只看该作者
    那这个是针对新项目的还是运维类项目?
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    20#
    发表于 2014-11-24 10:32:22 | 只看该作者
    正在做这方面,公司的bug填写的不规范,统计起来比较头疼。
    回复 支持 反对

    使用道具 举报

    本版积分规则

    关闭

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

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

    GMT+8, 2024-11-24 16:42 , Processed in 0.078983 second(s), 26 queries .

    Powered by Discuz! X3.2

    © 2001-2024 Comsenz Inc.

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