不可重现的bug如何处理

不 可 重 现 的 bug 如 何 处 理 一、一定要提交！ 1 记得有这么个缺陷，以后再遇到的时候可能就会了解发生的原因。 2 尽力去查找出错的原因，比如有什么特别的操作，或者一些操作环境等。 3 程序员对程序比测试人员熟悉的多，也许你提交了，即使无法重新，程序员也会了解 问题所在。 4 无法重现的问题再次出现后，可以直接叫程序员来看看问题。 5 对于测试人员来说，没有操作错误这条.既然遇到，就是问题。即使真的操作错了，也 要推到程序员那里，既然测试人员犯错误，用户也可能会犯同样的错误。错误发生的时候， Tester 最大。 二、程序不是测试人员写的，出问题也不是测试人员的原因。 至于无法重现，可能的原因很多，因为测试人员看到的只是程序的外部，无法深入程序内 部，所以把责任推给测试人员是不对的。 测试人员的任务只是尽力重现问题，而不是必须重现！ 三、下次再遇到的时候，拉他们来看就可以了。 因为问题如果无论如何无法重现，程序员确实也没有什么好的解决方法。 而且此类问题即使程序员说修改了，测试员也没有好的方法去验证是不是。 四、你可以告诉程序员，测试过程是没有错误的。 测试人员只是检查程序中可能存在的问题，虽然测试人员使用一定的手段方法努力去覆盖 所有的情况，但这些都是理论的推测。在实际中，可能因为人员、环境、配置等种种原因 出现各种各样的问题，在测试人员这里发现问题是公司内部的事情，程序发到外面可就是 公司的形象问题了。 需要让程序员理解，测试人员是帮助他们的，不是害他们的。 客户那里发现问题比测试员发现问题结果要严重的多。 五、测试部门是独立与开发部门的呀，真的打交道，也是经理对经理。 在我们这里，工作上面的事情，和程序员相互只能商议解决，并没有谁高谁低。 问题无法重现，也要提出，程序员那里可以回复无法再现。问题放在那里，等到再次出现 的时候，就立刻叫程序员过来查看。 实在没有再次出现，最后可以写到报告中，说出现了什么现象，但无法再现（比较严重的 问题才如此处理，小问题经理之间商量商量可能就算了）。 至于测试人员必须重现 bug，你杀了我好了，我每次测试项目都有无法重现的问题，很多 我能找到大概的原因，有些根本无法重现（仅仅出现一次）。 这种事情是无法避免的，并不能说测试人员无法重现问题，就是工作不到位（哼，程序有 bug，是否可以说程序员工作不到位的呀）。 六、测试部门要独立，最好不受开发的制约。其实真正要重视，就应该有否决的权利。 我们公司就是项目承包，要拿最后的项目尾款，就要测试部签字通过，这样就避免了很多 的问题。 其实只要自己尽到心就可以了，管别人怎么说呢。 七、我们使用的状态有： 程序员处理的状态（由测试员提交的 Action）：等待处理的，再次出现的。 测试员处理的状态（由程序员提交的 Action）：已经修改的，暂不修改的，系统限制的， 使用错误的，无法再现的。测试员可以修改记录。 经理处理的状态（由测试员提交 Action）：管理员处理的。经理还可以删除记录。 按照比较标准的说法，其实对于缺陷还应该有“等待确认的” 、“已经确认的”和“ 重复提交的” 的状态，我们为了省事，统一使用了“等待处理的” 。 最后结项的时候，缺陷的状态对我们来说有两种，“已经关闭的” （由测试员或经理确认） 和“暂不修改的”（比如下一个版本处理等）。 呵呵，状态多，有些烦琐，特别是程序员很多的时候都不清楚应该回复什么状态，但我个 人觉得对测试人员来说，这些状态比较清晰明了，容易处理。 八、一个叫 doer_ljy(可战)的网友回复了一些内容，我个人认为不很妥当，就回复了一些内 容，绿颜色的是 doer_ljy(可战) 的内容： 关于“无法重现”我看是有这么个问题存在。 首先如果你在测试之前有严格的测试计划，就很难出现“无法重现” 这种现象。“无法重现”的 意思是不知道怎么操作才能再次看见这个 BUG。那么这个 BUG 多半是“ 计划外”的。 不清楚你是否是测试人员。“计划外” 这个词，对测试员来说应该不存在。 测试用例的粒度 一直是个在讨论中的问题，测试人员很难有时间和精力写出包含内容、数据、步骤等等全 部操作一切的测试用例（说白了，只要一个长手识字的人，按照测试单做，就能发现所有 的问题，呵呵，有软件蓝领的感觉了）。即使真的有，意义也不大，测试很多的时候，是 发散性的思维，带点创造性，想事先考虑完全，很难。所以更多时候，是在测试过程中逐 步对用例等进行完善，所以说“计划外” 最好不要提。 说说我现在测试的一个项目，有一个业务，首先查询出人员，有个“全选” 按钮，“全选”后， 再用鼠标一个一个取消选择，这个时候进行业务办理的时候，就会提示“没有选择人员” ， 至今为止一切都正常，但是这个时候再次点选人员进行业务处理，仍然会提示“没有选择人 员”，这就是一个缺陷了。这个问题我想一般人都不会在测试用例中考虑到吧，因为发生的 条件很苛刻：不用“全选”按钮的时候不会发生；全选后点击 “取消全选”按钮再办理业务不会 发生；全选全消后，先点击人员再办理业务也不会发生。 其次，成熟的测试人员及时无法再现 BUG，也能准确的描述出 BUG 发生之前几个步骤的 操作方法，测试用例情况。这些对开发人员分析 BUG 原因很重要。所谓的 BUG 发现环境。 呵呵，看来我不是成熟的测试人员。手工测试，比较熟练的时候，和打字可以说差不多， 应该进行到哪里，心中是有数的，但让我完全从头到尾的重复，不容易呀。写测试缺陷报 告单的时候，也只是说明操作步骤和发生的现象。其实无法重现的问题，既然说“无法重现” ，也就是测试人员已经对这个现象进行了多次的验证，一般从程序外部来说，测试人员的 操作比程序员要熟练的。 最后，我不同意测试人员不假思索把发现的“问题” 直接推给编码人员的做法。毕竟是大家 合作，目标是一致的。测试人员总是处在 BUG 发生的第一现场，应该帮助分析出现问题 的原因。确认是不是自己的此时 Miss. 测试人员提交任何一个问题，都会经过反复的验证，如果容易重现，早就提出来了。绝对 不是在推脱责任，还是那句话，对程序的结构，做的人当然比不做的人要清楚。另外，除 非程序员询问，否则我不会给程序员提出修改分析和建议！测试人员的任务是发现问题， 解决问题是程序员的事情。这么做可能会影响程序员思考问题的思路；而且测试人员做的 多了，程序员不但不感激，可能反而会反感（好像程序员对测试人员有好印象的不多）。 再说两个我这两天遇到的问题。第一个就是我们的程序有一个锁定数据的功能。锁定后， 在其它的业务，此数据将不能再使用。我当时发现这个功能无效，而且经过了几次的验证 都不行，我当然就提出了。但是程序员那里说此功能好使，我再验证的时候，就没有问题 了，这个问题当时可以重现（但是我不可能遇到问题就拉程序员来看吧），后来却没有了， 只能放在那里，最后关闭掉。第二个就是在一个界面中，录入有顺序要求，必须先选择一 个 ListBox（必填）再进行 Edit 的录入，但一次操作我没有选择 ListBox 就录入的 Edit， 也正常保存了。后来无论我怎么操作此问题都没有出现（不够成熟呀），我就放弃了，也 没有提交记录（为了避免麻烦）。 测试人员的时间是有限的，进度给的都很少，一般连用例都没有时间写，还要去花很多时 间验证“无法重现”的问题？反正 10 分钟如果试验不出来，我就会放弃。严重的就提交，不 影响的就当不知道。 下面是其它一些人的观点： doublefalse(散诸怀抱)：如果不能重现的 bug 确实比较麻烦，但最好在测试过程中注意干 净环境、正确的操作、相同的数据源，只要真的有问题，一定能否复现的。呵呵，多试试！ ！我们以前一直有客户反映入库的数据经常有无关数据，但在家里测试没有问题，后来 才发现是汉字编码错位，这样同样的字，错位后就变成另外的东西了。 liuxiaoyuzhou(蟀哥)：遇到过同样的问题! 主要是记住 BUG 出现的环境!测试的时候这是关 键!在我们这里不能从现的 BUG,是测试人员的工作不到位!我们这里程序员比测试人员说话 有力度!郁闷呀! ericzhangali(另一个空间)：首先一定要提交 bug；其次不要企图 RD 一定去解这个 bug； 某些时候还得关闭这个 bug。如果 RD 认为是测试错误，（不明白什么叫测试错误，是不 是说他从测时要告诉你千万不要怎么怎么做，否则后果自负啊，）那也没什么办法，如果 沟通解决不了，爱咋认为就咋认为吧。 darkcat_c(错了重来)：没有 bug 是不可以重现的，bug 本事是建立在标准的规程上所出现 的异常，如果你按 test case 步骤做的话不太可能出现此类 bug。作为测试人员一定要具备 良好的记忆能力，一旦出现一些不知如何产生的 bug，至少你要知道刚才你大致进行了那 些操作。良好的分析能力，尽管你只是测试，但你应该全面的了解程序的架构，和一些重 要的内部细节，不然你这个测试就是不合格的。定位 bug 是开发的事情，而重现一个 bug 是测试的本职工作，不要把所有的事情推给开发，不然你的确比开发要低一等。（编者按： 这种话，不愿意去辩驳，标准开发人员的看法，也许应该让他们也来做做测试） liyan_1014(雁子)：我觉得应该是这么处理： 1、一定提交 bug，必须由负责 bug 的 tester 详细描述测试操作步骤，bug 发生的症状， 并将 bug 发生的具体环境也描述清楚；