如何弱化因不同测试人员测试而引发的BUG率上涨的现象？(12-07-02）（获奖名单已公布）

lsekfe

本周的问题为“如何弱化因不同测试人员测试而引发的BUG率上涨的现象？”
此话题由会员qrz2000提供，如果你也有问题想提出来和大家一起讨论，请点击此处>>

如果你也有问题想提出来和大家一起讨论，请点击此处>>
说不定下期讨论的问题就是由你提出的哦，请快快参与吧！

获奖名单
奖项	获奖名单	奖励	答案链接
一等奖	livexmm	50移动充值卡	15#

sdlfjwew1

观点一、bug率=bug数/代码行数
观点二、bug率=bug数/功能点数？？

sdlfjwew1

观点一、bug率=bug数/代码行数
观点二、bug率=bug数/功能点数？？

okyiliang

{:4_83:}学习咯

yj.xing

个人认为避免人员测试开发自动化作业，另外Bug建立daily review，相同的bug可减少。测试案例的定义也很重要，明确各个人员的区块，整合区块由一人负责（一个广度看；一个深度看）；通过每天会议做bug确认；让Leader主持会议。

cold_wh01

回复 1# lsekfe


1、测试用例反应测试工程师的思维活动，是脑力劳动的价值体现---不同的人会产生不一样的思维路线 ，这个是能力大小的分水岭
2、执行测试是简单的重复劳动，相同的路线产生不一样的效果，这个取决于个人工作素养即职业道德
调和二者之间的关系，尽可能的降低bug率的上涨

hellominefriend

1、个人觉得每个人负责单独模块比较好，但是交叉模块最好2个人都测测，因为交叉模块将2个模块都涉及到了，但是2个模块关注的功能应该是各有偏重
2、提交bug时将模块划分好，如果提交的是公共模块的bug，可以在提交bug前线review下另一个童鞋已经提交的bug

微微逛过来

新手，学习，飘过。

Tester_Joe

不同测试人员测试导致bug率上涨，原因有下面几个：1. bug误报：由于测试人员对于业务，环境等的不熟悉，误报了由于配置不当而引发的问题。
这类问题尤其出现在新员工，实习生身上，因为对于业务不熟悉，配置不熟悉，引发了bug率上涨；

2. bug重复提交：的确是bug，但是由于测试交叉模块，测试人员比较多，版本比较多等等，就会出现同一个bug在不同阶段由不同人重复提交，从而引发bug率上涨；

3. bug被发现：的确是bug，但是由于种种原因，测试人员在当前才发现了这些bug，从而引发bug率上涨，这个是最不能被接受的原因；

针对这些原因，解决方法其实有很多：
1. 通过培训，让测试人员尽快掌握业务熟悉环境，会大大避免bug误报的情况，当然测试人员自己要有意识自觉自发的去学习掌握业务，提高自身素养；
2. bug重复提交，一般都是在交叉模块测试时发现或者时间久了大家对于老bug记忆不清。测试人员自身在提交bug的时候应该有意识地去bug库进行关键字查找，如果已经被提交，就应该在老bug上添加备注以说明该bug在当前版本仍旧被发现；

3. 如果是第3个原因导致bug率上涨，这个问题就比较严重了，特别是在项目后期突然爆发了很多bug，不管是开发还是测试，大家都是无法接受的。要解决这个问题，除了测试人员要有良好的专业素质和技术外，时间的充裕程度也很重要，要让测试有充分的时间进行测试；

总而言之，不管是第一类还是第二类，其实都可以通过cancel bug的方法进行避免，就算由于误报或重复提交了bug，都可以在bug库中cancel掉这些无效bug，这样bug率不会受到影响，最怕的是第三类情况，不管是通过定期的交叉测试，充分测试还是测试人员提高自身专业技能，一定要避免第三类情况发生。

peace315

详尽的测试评估标准
人力允许的情况下，可指派不同人力执行相同测试，对比结果
以此督促测试人员有危机感，提升自身能力，对问题的敏感度 (非常规手段)

peace315

详尽的测试评估标准
人力允许的情况下，可指派不同人力执行相同测试，对比结果
以此督促测试人员有危机感，提升自身能力，对问题的敏感度 (非常规手段)

peace315

详尽的测试评估标准
人力允许的情况下，可指派不同人力执行相同测试，对比结果
以此督促测试人员有危机感，提升自身能力，对问题的敏感度 (非常规手段)

walkontesting

如果不是BUG本身的原因，就要从不同的测试角度去看待类型相近或者几乎相同的BUG
使用
关键词
等价类划分等方法

msnshow

标准化测试方法、有完善的测试用例就能减少对人的依赖

baby101029

从三方面着手吧。
1、测试用例，是否做到定期更新和评审；
2、测试计划和管理，是否在前期进行充分的计划 ...
Lyangmeng 发表于 2012-6-25 14:25

    简单明了啦

baby101029

回复 15# livexmm


     是说无论几个测试都可重复用一个测试用例  并且保证用例是及时更新成的意思吗？

jianviper

回复 9# Snowbing


    灰常赞同你的观点。

sunstear

个人感觉从以下几个方面着手：
1：测试人员技术水平，不同人员设计用例，可能不同，比如等价类划分，不同人可能划分不同的区间，但最终结果都覆盖了需求，测试结果应该是相同的，除非，设计用例不够完全。所以人员技术培训应该为一个方面
2：测试人员职能划分问题，不同人员负责不同模块，还是不同人员都负责相同模块，不同模块可能出现类似问题，但是也应该为一条新bug，如果不同人员负责相同模块，他们发现相同BUG的概率就会提高很多。
3：测试内部评审，评审很重要，不同测试人员、部门在某个版本完成后会对用例进行评审，这个时候是修正用例的好时机，当发现设计的用例类似，发现相同问题的用例就可以剔除掉，精简用例，另外一个方面从不同人员考虑，设计者的用例不足，这个时候也可以进行完善，有效减少bug重复率
4：测试计划，测试管理者，在进行测试人员分配时候，是否分配合理，包括单独模块和公共模块的划分。
5：测试管理工具的使用 QC

sunstear

个人感觉从以下几个方面着手：
1：测试人员技术水平，不同人员设计用例，可能不同，比如等价类划分，不同人可能划分不同的区间，但最终结果都覆盖了需求，测试结果应该是相同的，除非，设计用例不够完全。所以人员技术培训应该为一个方面
2：测试人员职能划分问题，不同人员负责不同模块，还是不同人员都负责相同模块，不同模块可能出现类似问题，但是也应该为一条新bug，如果不同人员负责相同模块，他们发现相同BUG的概率就会提高很多。
3：测试内部评审，评审很重要，不同测试人员、部门在某个版本完成后会对用例进行评审，这个时候是修正用例的好时机，当发现设计的用例类似，发现相同问题的用例就可以剔除掉，精简用例，另外一个方面从不同人员考虑，设计者的用例不足，这个时候也可以进行完善，有效减少bug重复率
4：测试计划，测试管理者，在进行测试人员分配时候，是否分配合理，包括单独模块和公共模块的划分。
5：测试管理工具的使用 QC

li_feibo

当测试关联模块发现bug时，我们会先和测试人员沟通，是否已经提交该bug，或者查看下bug管理系统，如果还没记录，就记录到bug管理系统。