开发人员提出不能重现的缺陷是测试人员的责任
他们的观点如下：1，不能重现的缺陷他们没有责任去修
2， 不能重现的缺陷完全是测试人员的责任，
大家认为上述观点对不对？如果不对，有没有一些比较权威的资料或者权威人士做的ppt之类的材料可以反驳上述观点的？谢谢大家 当然不对
如果是一般的逻辑性错误，如某种特定的数据组合输入必然导致某种错误的输出，这样的错误都是可以重现的。
如果错误的产生，与资源有关，比如说内存泄露，内存泄露到某种程度的时候，才会导致错误，而且导致的错误还不确定，这样的错误就很难重现。遇到这种错误，测试人员将错误进行记录，并说明错误很难或者无法重现，开发人员应该根据错误信息，自己检查是否程序错误，如果无法定位，错误应该继续有效，等后续进一步观察。
应该共同解决这个问题，而不是将问题简单的推给测试人员，这本身就是一种不负责任的做法。 一个解决问题的办法是记录下这个不可重现缺陷，依严重程度决定是否留待日后处理。如果不处理，而日后没有客户投诉，正好节省研发的人力物力。
---这个在现代测试技术中叫做good enough software, not 100% bug fixed (impossible) but be acceptable. 当发生不可重新的问题时，最好保留问题现场给开发人员，如果开发人员暂时找不出问题的原因所在，那么测试人员记录下此问题，进一步找规律。但不能将责任推给测试人员 这个应该可以分为几种情况：
1. 测试这边100%出现，开发1%都没有重现， 这要首先考虑开发跟测试的平台是否保持一致？
2. 测试不是100%出现，开发从来没有重现，请测试人员做好记录，最好有trace/log信息，便于开发人员分析，或者可以重新烧录版本，在一个干净的环境下测试。。 先解决体制问题，再分清职责，开发人员的工作不仅是开发、修复bug，同时也包含分析bug的重任。
目前来说，可以解决这个问题的方法楼上已有很明确的方法，我这里再罗嗦下：
1、缺陷记录是否完整？
2、有没有Tracking和Log？
3、不能重现的bug是多数还是少数？如果多数，请检查开发环境和测试环境，如果少数，保留现场，并确认该问题并非数据问题。 非常不同意.
不重现不一定代表没有缺陷.
要结合系统运行环境来重现缺陷.(测试和开发人员的运行环境是不同的.) 个人看法:
无论是什么错误都好,只要出现了,特别是致命的问题,就算出现一次也好(当然不能是故意制造的),开发和测试都有负责;
测试的应该尽量回忆当时的环境和重现步骤,开发也应该通过代码走查或者凭经验等思考有可能出现的原因,着重向深层次去寻找原因!
为什么???
道理很简单,我们的项目或者产品最终不是给开发的或者测试的使用的,我们面向的是用户;哪你能说用户具体的环境吗?
而且,工作的态度应该是对事而不是对人!共同解决问题,才能团结测试和开发! 这么荒唐的问题，呵呵。。。
回复 #2 海龙 的帖子
同意看法 原帖由 海龙 于 2005-11-28 13:18 发表当然不对
如果是一般的逻辑性错误，如某种特定的数据组合输入必然导致某种错误的输出，这样的错误都是可以重现的。
如果错误的产生，与资源有关，比如说内存泄露，内存泄露到某种程度的时候，才会导致错误 ...
非常同意你的看法，^_^ 原帖由 海龙 于 2005-11-28 13:18 发表 http://bbs.51testing.com/images/common/back.gif
当然不对
如果是一般的逻辑性错误，如某种特定的数据组合输入必然导致某种错误的输出，这样的错误都是可以重现的。
如果错误的产生，与资源有关，比如说内存泄露，内存泄露到某种程度的时候，才会导致错误，而 ...
赞同~! mark:) 本帖最后由 sangurance 于 2011-11-4 11:39 编辑
只要是缺陷，包括错误和异常，不管是否能重现，都应该记录下来，并告知开发；有很多缺陷是偶发性的，不是那么容易就能重现的，比如在特定的环境，内存溢出到一定程度触发了某种场景。。。当然，作为测试人员来说也应该有这种意识，尽量做好截图什么的工作，把出现的现象（要有可能也描述清楚自己的操作）和开发讲清楚，作为缺陷先提出来，不要怕将来会invalid而不提，同时也希望开发多理解。 如此简单，如荒唐的问题还用问……
出现过问题，说明问题是真实存在的，不能重现，只能说明触发此问题的机制、事件、规律等不确定，开发写的代码肯定存在问题，只是需要确定问题的触发事件而已。不过做为测试人员理应该尽量重现问题，找到触发问题的根源或者规律，最终目标是保证产品的质量，而不是找茬……
如果为了推卸责任，想怎么说都可以…… 只要是产品的缺陷，那么开发有责任进行分析。不管当前缺陷是否能够重现。
页:
[1]
