软件测试完后，还有BUG，是测试人员的问题吗？

达芬奇密码提问于 2018-06-20 14:24

• 金和OA办公系统2018-10-17 17:44

  个人认为，这个问题不一定，这个要具体问题具体分析：

  首先，产品发布了出现bug，就是测试的问题了；

  其次，产品没有发布，存在bug：

          1、bug测试出来，开发没有修改好，或者引起了新的bug，这就是开发的问题；

          2、bug没测试出来，那就是测试的问题；

  以上都是个人观点。

• 把生命浪费在美好事物上2018-06-20 14:40

  推荐我厂李丹同学的一篇文章，讲述了测试是如何推动开发质量改进的，希望对题主有帮助。原文如下：

  引言
  

  曾经， 我以为
  作为一名测试工程师， 提交bug就是我的本职工作。 bug提的多，说明我牛。
  直到有一天，我跟了一个烂项目（别慌， 是前任公司 ），逾期未交付， 做砸了~ 虽然我们测试团队报了上千个bug，可依然阻止不了项目的失败。
  我的总监（负责开发和测试团队）在绩效考核时，评价我的工作：“bug报的多，并不能代表什么，只能说明开发质量烂”，“项目失败了，虽然不是你的原因，但按照个人贡献，我只能给你打个Meet（合格）。”
  站在大boss的角度，是希望这个产品是成功的，高质量的。而线下bug多，都只是内耗。
  那，我， 一名测试工程师，我能推动开发质量的改进吗？
  有幸，在项目中，基于PDCA质量管理理念， 做了一次实践。
  

  
  
  

  1. 计划Plan

  1.1 分析现状
  

  项目负责人:
  为什么测试员都已经报了这么多bug，还是会有很多线上问题？
  整天在救火， 还怎么好好的做新需求啊！
  究竟是开发代码质量差，还是测试员覆盖不全啊？
  
  开发:
  我需求都没开发完，你们就催着提测，催着上线。
  哪有时间保证质量啊？ 加班997， 都没时间和老婆生孩子了， 还要被责怪，我委屈啊委屈。
  
  测试:
  这bug都好low哦！ block我测试了。
  这个bug 怎么还没改好啊？都打回2次了。
  啊？ 怎么最后一轮还有bug啊！不开心。
  可是，还是得硬着头皮上线。
  宝宝心里虚啊！
  
  项目负责人:
  是时候整顿下了。
  
  1.2 分析原因
  既然是由bug引起的一场战乱，那咱就从bug着手。 于是，有了一周一次的bug回溯。
  
  分析哪些bug？
  

  • 线上的bug
  • 线下Critical 和 Major 的bug
  • 罗列出可以通过开发自测解决的bug

  
  分析什么？由谁分析？ 怎样分析？
  

  • 每周挑选5个左右。
  • 分析 root cause, 以及落地改进方案。
  • 线下的bug改进方案由开发分析，线上的由开发和测试共同给出。
  • 每周周会，在测试发言环节，和所有人分享，其他所有人会进行补充并优化落地改进方案。

  
  bug回溯示例：
  

  
  
  1.3 制定计划
  落地改进包括两点：技术改进和流程改进。流程改进包含以下内容：
  

  • 简单粗暴的bug请开发加强自测。
  • 开发加强 code review
  • 测试加强业务异常以及系统异常测试
  • 其他流程上的改进。

  
  其他流程上的改进包含以下内容：
  

  • 对需求进行细化
  • 对接口进行详细定义和异常处理
  • hotfix 流程改进
  • 提测前客户端与服务器进行联调
  • 测试阶段进行bugbash
  • 整理并维护上线checklist

  
  2. 执行Do
  问题都已经暴露出来， 改进方案也有了。那么如何确保证这些改进真正地落实了。
  纵观整个改进方案，最难落实的应该就是开发自测和代码评审.
  开发先哭了，我们加班加点，周末无休， 需求都赶不完。还让我们自测，让我们代码评审。 我们也知道好处多多，but 时间啊， 时间啊~~
  头儿发话了： 需求是一定要赶的（竞品太多），但是质量也得抓。
  他捋了捋性感的胡须：“这样吧！下期需求，你们把自测和评审的时间都评估进去。随着你们对项目的逐渐深入， 对需求的评估能力应该会更加准确的。 到时候自测没做，可不能以时间为借口了哦！”
  会哭的孩子有奶吃， 时间终归是有了。
  那么怎么来监控开发自测和代码评审的过程呢? 毕竟这2个流程都是贯彻始终、持之以恒的事情！
  
  2.1 开发自测的监控
  我可能不用太关注开发冒烟通过率和完成度。流于形式的冒烟测试意义都不太大。
  我主要跟踪的是bug。每个版本统计易自测的bug数（所谓易自测，说的狠一点，就是低端bug，哦，请原谅我是一个刀子嘴豆腐心的人）
  说实在的，开发小哥们都是三观正、有理想的。谁愿意让人家指指点点bug多代码烂呢？
  之前真的是流程的问题， 真的是流程的，流程的问题~
  
  2.2 代码评审的监控
  gitlab自带code review 功能。
  跟踪者可以通过Activity 模块下的Comments 查看到所有评论。
  

  
  
  可以每周统计一次数据， 包括评论条数、内容、修复情况。
  示例：
  

  
  现阶段统计还属于人肉操作， 同时也正在研究专业的代码评审的工具Gerrit，应该会让整个代码评审的工作更加规范一些， 也便于统计。
  
  3. 检查Check
  
  检查是对执行后效果的评估，是伴随着实施过程自始至终的，不断收集数据的过程。
  

  
  版本时长: 计算开发开始--测试结束的时间。
  总开发人日： 所有的开发人员在这个版本中投入的人日总和。
  关注的指标： 总bug数除以总开发人日。
  实践2个半月后，统计了近7个版本的指标， 大家可以看到，最后2个版本，指标降下来。
  开发负责人： 质量好了，不用总是背锅了。
  测试： 郁闷，找不到bug了（其实有找到几个old bug）
  项目负责人： 测试找不到bug， 我也还是担心啊！
  我：测试期间找不到bug，同样的测试资源，只会比以前更心细。 测试深度更深。 对测试环节，请放心~~~
  
  4. 实践总结 Action
  以上流程核心： 以bug回溯的方式来推动开发自测、代码评审以提高提测质量，进而提高产品质量。并且，不断收集晾晒数据。
  开发鼓励坚持以这样的方式做质量改进。原因如下：
  

  • 质量是真的在变好。提测后，发现的总bug数少了很多。
  • 开发把测试阶段修改bug的时间解放出来，可以做其他更有价值的事情。
  • 上线前所有人比以前更有底气了。
  • 整个团队规范性、自信心、士气、更好了。

  经过这次实践，我对钱老师所言是认同的 嫌测试周期太长，试试开发自测吧！
  因为整个产品开发阶段， 越早消灭bug，成本越低。 这就是为什么开展用例评审、开发自测的必要性！
  
  附1： 图中的改进体系是PCDA的落地版。 经实践，现阶段对于网易**项目是行之有效的。
  

  
  
  原文：PDCA 质量环之实践-----测试推动开发质量的改进