1：测试人员技术水平，不同人员设计用例，可能不同，比如等价类划分，不同人可能划分不同的区间，但最终结果都覆盖了需求，测试结果应该是相同的，除非，设计用例不够完全。所以人员技术培训应该为一个方面
2：测试人员职能划分问题，不同人员负责不同模块，还是不同人员都负责相同模块，不同模块可能出现类似问题，但是也应该为一条新bug，如果不同人员负责相同模块，他们发现相同BUG的概率就会提高很多。
3：测试内部评审，评审很重要，不同测试人员、部门在某个版本完成后会对用例进行评审，这个时候是修正用例的好时机，当发现设计的用例类似，发现相同问题的用例就可以剔除掉，精简用例，另外一个方面从不同人员考虑，设计者的用例不足，这个时候也可以进行完善，有效减少bug重复率
4：测试计划，测试管理者，在进行测试人员分配时候，是否分配合理，包括单独模块和公共模块的划分。
5：测试管理工具的使用 QC 个人感觉从以下几个方面着手：
1：测试人员技术水平，不同人员设计用例，可能不同，比如等价类划分，不同人可能划分不同的区间，但最终结果都覆盖了需求，测试结果应该是相同的，除非，设计用例不够完全。所以人员技术培训应该为一个方面
2：测试人员职能划分问题，不同人员负责不同模块，还是不同人员都负责相同模块，不同模块可能出现类似问题，但是也应该为一条新bug，如果不同人员负责相同模块，他们发现相同BUG的概率就会提高很多。
3：测试内部评审，评审很重要，不同测试人员、部门在某个版本完成后会对用例进行评审，这个时候是修正用例的好时机，当发现设计的用例类似，发现相同问题的用例就可以剔除掉，精简用例，另外一个方面从不同人员考虑，设计者的用例不足，这个时候也可以进行完善，有效减少bug重复率
4：测试计划，测试管理者，在进行测试人员分配时候，是否分配合理，包括单独模块和公共模块的划分。
5：测试管理工具的使用 QC 回复 9# Snowbing
灰常赞同你的观点。 回复 15# livexmm
是说无论几个测试都可重复用一个测试用例并且保证用例是及时更新成的意思吗？ 从三方面着手吧。
1、测试用例，是否做到定期更新和评审；
2、测试计划和管理，是否在前期进行充分的计划 ...
Lyangmeng 发表于 2012-6-25 14:25 http://bbs.51testing.com/images/common/back.gif
简单明了啦 标准化测试方法、有完善的测试用例就能减少对人的依赖 如果不是BUG本身的原因，就要从不同的测试角度去看待类型相近或者几乎相同的BUG
使用
关键词
等价类划分等方法 详尽的测试评估标准
人力允许的情况下，可指派不同人力执行相同测试，对比结果
以此督促测试人员有危机感，提升自身能力，对问题的敏感度 (非常规手段) 详尽的测试评估标准
人力允许的情况下，可指派不同人力执行相同测试，对比结果
以此督促测试人员有危机感，提升自身能力，对问题的敏感度 (非常规手段) 详尽的测试评估标准
人力允许的情况下，可指派不同人力执行相同测试，对比结果
以此督促测试人员有危机感，提升自身能力，对问题的敏感度 (非常规手段) 不同测试人员测试导致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率不会受到影响，最怕的是第三类情况，不管是通过定期的交叉测试，充分测试还是测试人员提高自身专业技能，一定要避免第三类情况发生。 新手，学习，飘过。 1、个人觉得每个人负责单独模块比较好，但是交叉模块最好2个人都测测，因为交叉模块将2个模块都涉及到了，但是2个模块关注的功能应该是各有偏重
2、提交bug时将模块划分好，如果提交的是公共模块的bug，可以在提交bug前线review下另一个童鞋已经提交的bug 回复 1# lsekfe
1、测试用例反应测试工程师的思维活动，是脑力劳动的价值体现---不同的人会产生不一样的思维路线 ，这个是能力大小的分水岭
2、执行测试是简单的重复劳动，相同的路线产生不一样的效果，这个取决于个人工作素养即职业道德
调和二者之间的关系，尽可能的降低bug率的上涨 个人认为避免人员测试开发自动化作业，另外Bug建立daily review，相同的bug可减少。测试案例的定义也很重要，明确各个人员的区块，整合区块由一人负责（一个广度看；一个深度看）；通过每天会议做bug确认；让Leader主持会议。 {:4_83:}学习咯 观点一、bug率=bug数/代码行数
观点二、bug率=bug数/功能点数？？ 观点一、bug率=bug数/代码行数
观点二、bug率=bug数/功能点数？？
页:
1
[2]
