51Testing软件测试论坛

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

QQ登录

只需一步,快速开始

微信登录,快人一步

手机号码,快捷登录

查看: 5005|回复: 13
打印 上一主题 下一主题

[讨论] 作为测试部掌门人,该如何协助研发部门的同事去建立bug预防体系?

[复制链接]

该用户从未签到

跳转到指定楼层
1#
发表于 2019-4-14 12:11:11 | 只看该作者 回帖奖励 |倒序浏览 |阅读模式

最近公司招聘来了一个CTO敏捷方面的专家,刚到公司一周,就开始找研发、测试、运维等负责人开会,讨论如何实现软件缺陷预防。作为互联网公司大家都知道节奏快,压力大、文档不全,人手少,不像传统的软件企业或国有企业测试编制较多,测试时间足够。要求下周五必须交部门的讨论意见,感觉测试没什么好的idea,有没有朋友有类似缺陷预防的经验,指点一下方向也行,谢谢!


作为测试部掌门人,该如何协助研发部门的同事去建立bug预防体系?
分享到:  QQ好友和群QQ好友和群 QQ空间QQ空间 腾讯微博腾讯微博 腾讯朋友腾讯朋友
收藏收藏
回复

使用道具 举报

  • TA的每日心情

    2024-7-8 09:00
  • 签到天数: 943 天

    连续签到: 1 天

    [LV.10]测试总司令

    2#
    发表于 2019-4-15 10:30:55 | 只看该作者
    规范啊   代码规范 啊 以及要求规范啊  
    回复 支持 反对

    使用道具 举报

  • TA的每日心情
    慵懒
    2022-7-23 11:23
  • 签到天数: 316 天

    连续签到: 1 天

    [LV.8]测试军长

    3#
    发表于 2019-4-16 09:47:15 | 只看该作者
    建立规范的测试体系,文档规范、代码规范,邮件模板等等
    回复 支持 反对

    使用道具 举报

  • TA的每日心情

    2020-2-2 12:43
  • 签到天数: 630 天

    连续签到: 1 天

    [LV.9]测试副司令

    4#
    发表于 2019-4-16 09:59:47 | 只看该作者
    各种规范,测试的防御体系要考虑在拿到版本之前和拿到之后
    回复 支持 反对

    使用道具 举报

  • TA的每日心情
    开心
    2024-11-8 10:04
  • 签到天数: 473 天

    连续签到: 2 天

    [LV.9]测试副司令

    5#
    发表于 2019-4-16 10:10:22 | 只看该作者
    得建立良好的编程规范,参照阿里的java手册,另外就是设计的问题了
    回复 支持 反对

    使用道具 举报

  • TA的每日心情
    奋斗
    6 小时前
  • 签到天数: 1805 天

    连续签到: 4 天

    [LV.Master]测试大本营

    6#
    发表于 2019-4-16 10:17:32 | 只看该作者
    建立规范流程,比如真对开发的代码规范,然后还有测试提交规范与流程
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    8#
    发表于 2019-5-23 19:37:48 | 只看该作者
    测试报告 预警信息中, 之前经常出问题的点, 发布流程,自动化测试
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    9#
    发表于 2019-5-25 19:31:16 | 只看该作者
    确实有所启发
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    10#
    发表于 2019-5-25 19:31:35 | 只看该作者
    回复下都这么难
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    11#
    发表于 2020-5-19 08:59:55 | 只看该作者
    1.梳理以往发现的bug类型,发生原因,做好数据分析,提供给开发部门同事借鉴,吸取经验,在开发设计阶段就能根据这些经验规避出同样类型的错误。
    例如压力测试,边界测试,调用接口出问题,兼容性,健壮性这类的类型。开发设计阶段能考虑到这些因素的话,就会在设计阶段考虑到这些从而避免出现类似问题。
    2.建立开发编码规范,软件发布的规范,版本无效率的控制流程。保障提交给测试的版本的有效性,以免因为版本质量问题导致人力资源的浪费。
    3.在需求评审时,产品需求部门,开发部门和测试部门负责人一同讨论,在需求设计阶段就提出可能存在的隐形bug,三方从不同的角度来讨论产品需求,总比一方考虑的周全。
    4.在测试中期,尽量能避免产品需求的大变更,而引起开发比较大规模的改动代码,如果大变更需求会给项目带来时间的延迟,大变动风险也大,对开发测试来说也是人力资源的投入增加。
    5.保障开发和测试的时间,保障开发的质量和测试的质量。如果时间压缩的太紧,遗漏了问题到时候会花费更多的时间去修复bug.
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    12#
    发表于 2020-5-19 09:01:02 | 只看该作者
    辛苦打了半天的字,一发表就没了
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    14#
    发表于 2020-5-19 09:03:16 | 只看该作者
    怎么打了半天的字,不能回复成功啊
    回复 支持 反对

    使用道具 举报

    本版积分规则

    关闭

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

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

    GMT+8, 2024-11-21 22:46 , Processed in 0.075902 second(s), 22 queries .

    Powered by Discuz! X3.2

    © 2001-2024 Comsenz Inc.

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