如何弱化因不同测试人员测试而引发的BUG率上涨的现象？(12-07-02）（获奖名单已公布）
本周的问题为“如何弱化因不同测试人员测试而引发的BUG率上涨的现象？”此话题由会员qrz2000提供，如果你也有问题想提出来和大家一起讨论，请点击此处>>
如果你也有问题想提出来和大家一起讨论，请点击此处>>
说不定下期讨论的问题就是由你提出的哦，请快快参与吧！
获奖名单
奖项获奖名单奖励答案链接
一等奖livexmm50移动充值卡15#
不同测试人员有不同的测试方法、策略和技巧，好比开发人员也有自己的开发模式、习惯等。
但是，在正确的管理与指导下，还是可以规避重复的劳动力。
这里要注意的是bug率！
包括bug数量和bug类型~
我们很容易发生以下情况：
1. 测试人员重复测试相同模块
2. 测试人员重复测试相交模块
3. 测试人员测试不同模块，而携带出相同/相似的问题
……
针对这些情况，我们采取以下措施，就可以较大程度减少重复bug：
1. 测试经理安排不同的功能模块给不同测试工程师
2. 测试经理安排相交模块部分给一位测试工程师
3. 测试经理/测试需求人员在开始执行测试前仔细分析测试需求，尽量安排相似业务点功能模块给一位测试工程师
综上，这样可以大幅度减少重复bug数，即bug率。
不过有点需要注意，对于不同业务模块、功能点的类似bug，若属于不同功能模块，哪怕再相似或者雷同，仍应该视作两个bug来对待。毕竟，这体现出各个模块下的质量和完成情况，也应该计入总bug数中。
个人愚见，不足之处，请指正。谢谢！ 如果可以解决这四点，基本就没有问题了：
1.对Bug的同意管理，任何测试人员都可以实时的在Bug管理器中找到相应的问题是否已经被人报过，以及对Bug的处理状态，就可以最大程度的避免duplicate Bug的出现。
对Bug的处理以及comment，可以避免一些观念问题，比如有些功能是需求里面要求的，可能有些测试人员会认为是Bug，但是这是客户的要求不是Bug，就没有必要提交Bug了。
2.测试计划的制定，对产品有个较详细的测试计划，测试用例尽可能的覆盖所有的模块，以及最后做regression的覆盖。
3.任务的分发，让测试人员覆盖到所有的测试计划中的测试用例（时间允许的话），测试用例也可以交替覆盖，尽可能的覆盖所有的模块，有异议的地方，可以通过评审的方式交流，尽量一个方法贯彻到底，不要出现一个人一个方法，一个人一种覆盖点，这样会遗漏很多问题。
4.提高测试人员素质，可能一个测试人员测试过后，其他人员测试时还是有很多很明显的问题，那就只有换人了。 由自己思路开始讲
1.首先需要知道问题在哪里。是测试用例未更新？人员疏忽？还是一直是不健康的缺陷曲线？然后对症下药。
1.1健全的测试计划，按计划执行。哪怕有变更， 优先达成计划内容然后再处理变更项。
2.用例生成采用高效的功能拆分， 置顶向下。小组1由宽度，小组2由深度，来达到同时间段的交叉覆盖。规避杀虫剂驳论。
3.划分安全区，高发区。
4.采集数据时注意有效缺陷数量和最近几期阻塞未执行的。
5.完善的变更记录，关注功能模块重复变更项。测试部可以派人去收集。
6.内部没有恶意的竞争。缺陷数量和非同人的重复提交不作为考核项。 1.用QC软件管理bug。测试人员分模块进行测试。并把发现的bug都提入QC。
2.测试完自己相同的模块后，测试人员调换模块进行测试。把发现的bug提入QC之前同另一位测试人员沟通。如果有就不再提入QC，因为说的比提到QC快。如果没有就提入QC，这样虽然浪费了点测试人员的时间，但节省了测试提重复bug的时间，也节省了开发看bug的时间。
3.测试人员也需要沟通，这样也可以加强测试人员的沟通能力。 个人觉得，这首先是一个测试设计问题。
在实施过程中造成的偏差大部分是因为定义不明确造成的。假设实施过程完全按照用例定义来做，则不会出现这类情况。所以从源头上说，是个设计问题。
但是在国内大多数公司在系统常规的测试上，都是重实施（测试执行），轻测试设计的。这也加剧了这种情况。 方案编写的时候基本把所有测试点都考虑进来，方案写好后，测试组内评审，评审修改后交由开发具体负责人在评审，最后收集所有的意见修改后定稿，就依据次方案写用例，基本保证功能点覆盖，至于UI和其他的小的问题写成CheckList，即便是不同的人来测试也不会有大的功能点的问题，我是这样做的，个人意见 回复 2# 土土的豆豆
BUG率??
我想问下大佬。何为BUG率，有标准吗？
现在大家的说法与理解都不相同。
求解。
观点一、bug率=bug数/代码行数
观点二、bug率=bug数/功能点数？？ 1. 强度业务知识的积累，避免因为业务逻辑不了解导致的By Design的Bug
2. 每个人分配不同的测试模块，这样就在一定程度上避免了重复的bug。
3. 在每日工作结束下班前的30分钟，可以开个Bug review 会议，就今天这个组报的Bug过一遍，这样大家都知道了有哪些Bug，碰到类似的问题就不会报Bug了
4. 每日早晨仍有个小小会议，看看昨天报的Bug哪些是不解的，什么原因。通过这个了解业务逻辑。
5. 对每个人的绩效考核增加重复Bug个数，这样大家在报Bug的时候都会先去搜搜Bug库里是否有类似Bug，避免过多重复。
6. 如有新人接手测试，务必做好相关培训及各种流程，并新人在熟悉阶段报Bug能让有经验的同事帮着看看，避免不能重现，重复的Bug或者业务不清楚引起的bug. 本帖最后由 TesterChen 于 2012-6-29 15:30 编辑
如何弱化因不同测试人员测试而引发的BUG率上涨的现象？
个人认为产生的原因主要包括以下几点：
1.测试人员不知Bug已经报告，导致Bug重复报告
2.新入测试人员对需求理解不清晰，或不同测试人员之间需求理解不一致，导致Bug误报
3.同一时间参与测试的人员较多，测试功能存在重叠的部分，导致Bug重复报告
4.前期的测试人员测试不到位，大量的缺陷未被发现
5.测试流程、测试管理不规范、不到位
处理对策：
1.建立Bug管理库（Jira、Mantis...），让Bug可追溯，测试人员在不能确认一个缺陷是否报告的时候，可以在Bug库中进行查询
2.对新入员工进行必要的业务知识、项目需求培训，在对被测试项目、对业务有了一定的了解后再介入测试；同时可以采取对新入测试人员工作前期Bug不直接入库的形式，先将发现的Bug发给相关测试负责人进行确认后，再行录入
测试人员参加需求评审，确保需求理解的一致性
3.尽量不要安排多个人同时对同一功能进行测试，如果有需要测同时安排多人对同一功能进行测试，那么试人员在报告缺陷时一方面要与其他测试人员沟通，另一方面要查找Bug系统中是否对此问题已经报告，避免重复报告
4.一方面要对测试人员的测试技能进行提升，同时对测试人员的业务技能进行培训。提高测试人员的整体技能水平
5.建立统一、符合公司现有情况的测试流程与管理规范，使所有的测试工作处于一个可控的状态下 这种现象出现，首先应该是要反思一下测试用例设计是否明确测试思路是否清晰，为何换一个测试人员测试就会出现不同的bug，是不是测试用例设计时没有明确测试的方法步骤，导致不同的测试人员使用不同的测试路径。要是测试用例设计时清晰明确的指出测试的步骤和方法，细化不同的测试路径和给出对应的预期结果，那么测试不同的测试人员执行出来的效果应该是一样的。 本帖最后由 ruizengyang 于 2012-6-21 11:43 编辑
不管是借助于测试工具还是具备一套完整的管理体系方法，测试的最终回归在于测试人员，人在测试活动中起着最重要的作用。先抛开技术方面，个人觉得在现在的团队工作中发扬teamwork精神是最重要的，在完善的技术支持和管理体系下面，充分发扬团队精神或许更能起到事半功倍的效果。（新手发帖，不足之处还望见谅，谢谢！） 我觉得可以两者结合起来。在测试前管理者合理的分配测试工作，测试后把测试发现的bug合理管理好，这样可以达到很好的效果。 回复 10# TesterChen
分析的相当有条理性：先找因，再求果 本帖最后由 livexmm 于 2012-6-25 14:27 编辑
想了想，如果测试人员变更导致BUG数量增加主要也就2个原因：
1.提交了重复的BUG报告。
这主要和任务分配，缺陷管理等有关系。
任务分配出现的问题一般是测试用例审核不严格，导致用例有效性下降，从而测试部门本身对自己的用例没有信心，最终导致换个人测试就要换用例。最后结果么就是测试了重复的模块，如果缺陷管理也不过关么就会出现提交重复BUG的情况。
解决办法：
·增加用例的审核力度，加强用例的可用性、合理性与可重复性。
·加强缺陷管理。这是建立在测试用例合理可用的情况下，确保每一个缺陷都有对应的来源于测试依据。像很多测试工具（比如CQ）都有这种测试思路，不要因为图方便而让自己增加更多的工作量。
2.软件确实有这些BUG。
这里也包含一些无效BUG的情况我放在一起说。
一般情况下测试是无止境的，总归能测出各种缺陷，这个主要是和测试阶段和测试方式有关。
比如你的软件经过了严格的功能测试，能够保证所有的功能有效并且没有任何业务逻辑上的缺陷。但是说不定一个简单的画面验证就能发现画面上输入金额的地方能够输入汉字。
如果2个测试人员，一个进行了很严格的功能测试，而忽略的画面测试的话，那自然换个人就能测出一堆问题。从测试原则上来说这确实没错，但是从开发计划上来说这就是无法忍受的。开发或者领导就会认为测试部门没有认真测试，而测试人员却觉得很冤枉。
解决办法：
想减少这方面的BUG最好能先分清楚该软件不同的测试阶段，由此来分配测试任务。尽早的规划出自己的测试目标，并且在测试用例和测试计划中体现。
所以负责设计测试计划的人一定需要对软件工程有一定理解。这样在设计自己的测试计划时心里才有谱，哪些测试我们需要做，哪些不需要做。根据开发模式还得考虑在哪个阶段做哪些测试。
举个例子，比如开发部门刚把一个软件的基本功能做好，想让测试部门测试一下功能方面的问题，然后画面就随便做了个让测试能先用起来。结果测试部门重点测了画面，发现一堆问题。你说这些缺陷开发会认吗？
如果能够很清楚的分清楚该阶段我们应该做什么类型的测试，还出现换个人就发现大量BUG，那就得好好检讨一下自己是否有认真的审核了之前哪个测试人员设计的测试用例了。 从三方面着手吧。
1、测试用例，是否做到定期更新和评审；
2、测试计划和管理，是否在前期进行充分的计划等；
3、bug管理，bug审核和统一管理。 回复 9# Snowbing
比较实际。 解决方法：
1.在进行测试计划和分配时，分配给不同的测试人员的模块间的耦合性较低，聚合性较高。
2.测试进行中，测试人员每提一个bug都与其他人确认是否重复提bug。
3.测试管理工具很重要，例如QC，测试人员每提一个bug,都要查看有没有类似的bug。这个是在方法2没有使用的情况下，用来做替换方法的。
4.测试一版后，所有测试人员做次整体交流，哪些bug出现，哪些解决了。养成沟通的好习惯。
5.测试出相同的bug是很正常的现象，为保证测试不会出现死角，测试开始前写测试用例，根据用例的模块，来分配测试任务。 产生原因：
1.测试人员个人能力和经验问题引起的
2.软件过程管理问题引起
3.测试本身问题引起
解决方法：
1.新人培训，熟悉业务知识和掌握软件测试方法，查看已经发现的bug，通过问题策略的方法引导测试人员发现问题
2.培养测试人员的测试思维和勤奋找bug的精神，如果由于某些测试人员本身的问题，那么这个问题弱化的问题就只能转为管理上去激进，或者无法解决，可以考虑换人
3.软件过程管理决定了bug的率的上涨，改进软件过程管理，公司的软件过程模型，需求分析、评审过程、各个模块代码质量、质量管理等等
4.加强测试需求分析，测试设计覆盖率，测试流程管理、bug管理流程的改进，测试人员的管理等等 1.用QC软件管理bug。测试人员分模块进行测试。并把发现的bug都提入QC。
2.测试完自己相同的模块后，测试人 ...
okyiliang 发表于 2012-6-20 11:18 http://bbs.51testing.com/images/common/back.gif
同意5楼观点，我们目前也是这么做的。
页:
[1]
2
