51Testing软件测试论坛

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

作者: lsekfe 时间: 2012-6-19 14:12
标题: 如何弱化因不同测试人员测试而引发的BUG率上涨的现象？(12-07-02）（获奖名单已公布）
本周的问题为“如何弱化因不同测试人员测试而引发的BUG率上涨的现象？”
此话题由会员qrz2000提供，如果你也有问题想提出来和大家一起讨论，请点击此处>>

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

[attach]79628[/attach]

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

作者: 土土的豆豆 时间: 2012-6-19 14:49
不同测试人员有不同的测试方法、策略和技巧，好比开发人员也有自己的开发模式、习惯等。
但是，在正确的管理与指导下，还是可以规避重复的劳动力。
这里要注意的是bug率！
包括bug数量和bug类型~
我们很容易发生以下情况：
1. 测试人员重复测试相同模块
2. 测试人员重复测试相交模块
3. 测试人员测试不同模块，而携带出相同/相似的问题
……
针对这些情况，我们采取以下措施，就可以较大程度减少重复bug：
1. 测试经理安排不同的功能模块给不同测试工程师
2. 测试经理安排相交模块部分给一位测试工程师
3. 测试经理/测试需求人员在开始执行测试前仔细分析测试需求，尽量安排相似业务点功能模块给一位测试工程师
综上，这样可以大幅度减少重复bug数，即bug率。
不过有点需要注意，对于不同业务模块、功能点的类似bug，若属于不同功能模块，哪怕再相似或者雷同，仍应该视作两个bug来对待。毕竟，这体现出各个模块下的质量和完成情况，也应该计入总bug数中。
个人愚见，不足之处，请指正。谢谢！

作者: rocking220 时间: 2012-6-19 15:44
如果可以解决这四点，基本就没有问题了：
1.对Bug的同意管理，任何测试人员都可以实时的在Bug管理器中找到相应的问题是否已经被人报过，以及对Bug的处理状态，就可以最大程度的避免duplicate Bug的出现。
对Bug的处理以及comment，可以避免一些观念问题，比如有些功能是需求里面要求的，可能有些测试人员会认为是Bug，但是这是客户的要求不是Bug，就没有必要提交Bug了。
2.测试计划的制定，对产品有个较详细的测试计划，测试用例尽可能的覆盖所有的模块，以及最后做regression的覆盖。
3.任务的分发，让测试人员覆盖到所有的测试计划中的测试用例（时间允许的话），测试用例也可以交替覆盖，尽可能的覆盖所有的模块，有异议的地方，可以通过评审的方式交流，尽量一个方法贯彻到底，不要出现一个人一个方法，一个人一种覆盖点，这样会遗漏很多问题。
4.提高测试人员素质，可能一个测试人员测试过后，其他人员测试时还是有很多很明显的问题，那就只有换人了。

作者: jiazurongyu 时间: 2012-6-20 09:35
由自己思路开始讲
1.首先需要知道问题在哪里。是测试用例未更新？人员疏忽？还是一直是不健康的缺陷曲线？然后对症下药。
1.1健全的测试计划，按计划执行。哪怕有变更，优先达成计划内容然后再处理变更项。
2.用例生成采用高效的功能拆分，置顶向下。小组1由宽度，小组2由深度，来达到同时间段的交叉覆盖。规避杀虫剂驳论。
3.划分安全区，高发区。
4.采集数据时注意有效缺陷数量和最近几期阻塞未执行的。
5.完善的变更记录，关注功能模块重复变更项。测试部可以派人去收集。
6.内部没有恶意的竞争。缺陷数量和非同人的重复提交不作为考核项。

作者: okyiliang 时间: 2012-6-20 11:18
1.用QC软件管理bug。测试人员分模块进行测试。并把发现的bug都提入QC。
2.测试完自己相同的模块后，测试人员调换模块进行测试。把发现的bug提入QC之前同另一位测试人员沟通。如果有就不再提入QC，因为说的比提到QC快。如果没有就提入QC，这样虽然浪费了点测试人员的时间，但节省了测试提重复bug的时间，也节省了开发看bug的时间。
3.测试人员也需要沟通，这样也可以加强测试人员的沟通能力。

作者: archonwang 时间: 2012-6-20 13:25
个人觉得，这首先是一个测试设计问题。

在实施过程中造成的偏差大部分是因为定义不明确造成的。假设实施过程完全按照用例定义来做，则不会出现这类情况。所以从源头上说，是个设计问题。

但是在国内大多数公司在系统常规的测试上，都是重实施（测试执行），轻测试设计的。这也加剧了这种情况。

作者: femir 时间: 2012-6-20 13:46
方案编写的时候基本把所有测试点都考虑进来，方案写好后，测试组内评审，评审修改后交由开发具体负责人在评审，最后收集所有的意见修改后定稿，就依据次方案写用例，基本保证功能点覆盖，至于UI和其他的小的问题写成CheckList，即便是不同的人来测试也不会有大的功能点的问题，我是这样做的，个人意见

作者: zhuzhengy 时间: 2012-6-20 14:13
回复 2# 土土的豆豆

BUG率??
我想问下大佬。何为BUG率，有标准吗？
现在大家的说法与理解都不相同。
求解。
观点一、bug率=bug数/代码行数
观点二、bug率=bug数/功能点数？？

作者: Snowbing 时间: 2012-6-20 14:34
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-20 15:12
本帖最后由 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.建立统一、符合公司现有情况的测试流程与管理规范，使所有的测试工作处于一个可控的状态下

作者: shirley_wu123 时间: 2012-6-20 21:06
这种现象出现，首先应该是要反思一下测试用例设计是否明确测试思路是否清晰，为何换一个测试人员测试就会出现不同的bug，是不是测试用例设计时没有明确测试的方法步骤，导致不同的测试人员使用不同的测试路径。要是测试用例设计时清晰明确的指出测试的步骤和方法，细化不同的测试路径和给出对应的预期结果，那么测试不同的测试人员执行出来的效果应该是一样的。

作者: ruizengyang 时间: 2012-6-21 11:42
本帖最后由 ruizengyang 于 2012-6-21 11:43 编辑

不管是借助于测试工具还是具备一套完整的管理体系方法，测试的最终回归在于测试人员，人在测试活动中起着最重要的作用。先抛开技术方面，个人觉得在现在的团队工作中发扬teamwork精神是最重要的，在完善的技术支持和管理体系下面，充分发扬团队精神或许更能起到事半功倍的效果。（新手发帖，不足之处还望见谅，谢谢！）

作者: 粟粉 时间: 2012-6-21 17:24
我觉得可以两者结合起来。在测试前管理者合理的分配测试工作，测试后把测试发现的bug合理管理好，这样可以达到很好的效果。

作者: c198527s 时间: 2012-6-22 14:46
回复 10# TesterChen

分析的相当有条理性：先找因，再求果

作者: livexmm 时间: 2012-6-25 14:21
本帖最后由 livexmm 于 2012-6-25 14:27 编辑

想了想，如果测试人员变更导致BUG数量增加主要也就2个原因：
1.提交了重复的BUG报告。
这主要和任务分配，缺陷管理等有关系。
任务分配出现的问题一般是测试用例审核不严格，导致用例有效性下降，从而测试部门本身对自己的用例没有信心，最终导致换个人测试就要换用例。最后结果么就是测试了重复的模块，如果缺陷管理也不过关么就会出现提交重复BUG的情况。
解决办法：
·增加用例的审核力度，加强用例的可用性、合理性与可重复性。
·加强缺陷管理。这是建立在测试用例合理可用的情况下，确保每一个缺陷都有对应的来源于测试依据。像很多测试工具（比如CQ）都有这种测试思路，不要因为图方便而让自己增加更多的工作量。

2.软件确实有这些BUG。
这里也包含一些无效BUG的情况我放在一起说。
一般情况下测试是无止境的，总归能测出各种缺陷，这个主要是和测试阶段和测试方式有关。
比如你的软件经过了严格的功能测试，能够保证所有的功能有效并且没有任何业务逻辑上的缺陷。但是说不定一个简单的画面验证就能发现画面上输入金额的地方能够输入汉字。
如果2个测试人员，一个进行了很严格的功能测试，而忽略的画面测试的话，那自然换个人就能测出一堆问题。从测试原则上来说这确实没错，但是从开发计划上来说这就是无法忍受的。开发或者领导就会认为测试部门没有认真测试，而测试人员却觉得很冤枉。
解决办法：
想减少这方面的BUG最好能先分清楚该软件不同的测试阶段，由此来分配测试任务。尽早的规划出自己的测试目标，并且在测试用例和测试计划中体现。
所以负责设计测试计划的人一定需要对软件工程有一定理解。这样在设计自己的测试计划时心里才有谱，哪些测试我们需要做，哪些不需要做。根据开发模式还得考虑在哪个阶段做哪些测试。
举个例子，比如开发部门刚把一个软件的基本功能做好，想让测试部门测试一下功能方面的问题，然后画面就随便做了个让测试能先用起来。结果测试部门重点测了画面，发现一堆问题。你说这些缺陷开发会认吗？
如果能够很清楚的分清楚该阶段我们应该做什么类型的测试，还出现换个人就发现大量BUG，那就得好好检讨一下自己是否有认真的审核了之前哪个测试人员设计的测试用例了。

作者: Lyangmeng 时间: 2012-6-25 14:25
从三方面着手吧。
1、测试用例，是否做到定期更新和评审；
2、测试计划和管理，是否在前期进行充分的计划等；
3、bug管理，bug审核和统一管理。

作者: 大龙哥哥 时间: 2012-6-25 14:27
回复 9# Snowbing

比较实际。

作者: giftoflife 时间: 2012-6-25 17:25
解决方法：
1.在进行测试计划和分配时，分配给不同的测试人员的模块间的耦合性较低，聚合性较高。
2.测试进行中，测试人员每提一个bug都与其他人确认是否重复提bug。
3.测试管理工具很重要，例如QC，测试人员每提一个bug,都要查看有没有类似的bug。这个是在方法2没有使用的情况下，用来做替换方法的。
4.测试一版后，所有测试人员做次整体交流，哪些bug出现，哪些解决了。养成沟通的好习惯。
5.测试出相同的bug是很正常的现象，为保证测试不会出现死角，测试开始前写测试用例，根据用例的模块，来分配测试任务。

作者: huoxingyinzi 时间: 2012-6-25 22:28
产生原因：
1.测试人员个人能力和经验问题引起的
2.软件过程管理问题引起
3.测试本身问题引起
解决方法：
1.新人培训，熟悉业务知识和掌握软件测试方法，查看已经发现的bug，通过问题策略的方法引导测试人员发现问题
2.培养测试人员的测试思维和勤奋找bug的精神，如果由于某些测试人员本身的问题，那么这个问题弱化的问题就只能转为管理上去激进，或者无法解决，可以考虑换人
3.软件过程管理决定了bug的率的上涨，改进软件过程管理，公司的软件过程模型，需求分析、评审过程、各个模块代码质量、质量管理等等
4.加强测试需求分析，测试设计覆盖率，测试流程管理、bug管理流程的改进，测试人员的管理等等

作者: 守夜天使 时间: 2012-6-26 10:49

1.用QC软件管理bug。测试人员分模块进行测试。并把发现的bug都提入QC。
2.测试完自己相同的模块后，测试人 ...
okyiliang 发表于 2012-6-20 11:18

同意5楼观点，我们目前也是这么做的。

作者: 爱简单 时间: 2012-6-26 11:35
现在公司测试的就我们两个，一般就是一个人测完之后，由开发修复，复测，之后再由另一个测试人员进行测试

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

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

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

作者: jianviper 时间: 2012-6-27 12:46
回复 9# Snowbing

灰常赞同你的观点。

作者: baby101029 时间: 2012-6-27 21:11
回复 15# livexmm

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

作者: baby101029 时间: 2012-6-27 21:14

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

简单明了啦

作者: msnshow 时间: 2012-6-27 22:13
标准化测试方法、有完善的测试用例就能减少对人的依赖

作者: walkontesting 时间: 2012-6-28 09:37
如果不是BUG本身的原因，就要从不同的测试角度去看待类型相近或者几乎相同的BUG
使用
关键词
等价类划分等方法

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

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

作者: Tester_Joe 时间: 2012-6-29 13:49
不同测试人员测试导致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率不会受到影响，最怕的是第三类情况，不管是通过定期的交叉测试，充分测试还是测试人员提高自身专业技能，一定要避免第三类情况发生。

作者: 微微逛过来 时间: 2012-6-29 14:44
新手，学习，飘过。

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

作者: cold_wh01 时间: 2012-7-2 11:13
回复 1# lsekfe

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

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

作者: okyiliang 时间: 2012-7-4 16:21
{:4_83:}学习咯

作者: sdlfjwew1 时间: 2012-8-16 17:43
观点一、bug率=bug数/代码行数
观点二、bug率=bug数/功能点数？？

作者: sdlfjwew1 时间: 2012-8-16 17:44
观点一、bug率=bug数/代码行数
观点二、bug率=bug数/功能点数？？

欢迎光临 51Testing软件测试论坛 (http://bbs.51testing.com/)