软件工程之开发与测试对缺陷重现条件的常见误解

 

版本声明：转载请注明出处。未经允许，禁止商业用途。

俗话说，监听则明，偏听则暗。遇到分歧不能轻易相信一面之词，要听两家之言。关于一个bug的重现条件，开发工程师和测试工程师可能有不同的理解。原因何在？我既做过开发工程师也做过测试工程师。我从开发和测试两个角度来看这个问题。

首先从开发角度来看：

1、开发经理看到bug报告，常误以为bug很容易暴露，对测试质量深表不满。实际上，在软件工程实践中，经常会出现这样的情况。测试工程师测出bug时，开发简单看了一下，确认是bug，测试也可以重现，所以就请测试先提bug。过了几天或者一两周，开发自己按照bug报告中的描述，却重现不出bug。测试重新搭建环境，按照bug报告中的描述，却能重现bug。经过一番对比，最终会发现开发的操作和bug描述的微小差异。认真尝试重现的开发人员，只因为微小差异就导致bug不能重现。更何况，开发经理只是简单浏览一下bug报告，遗漏了多少细节。要知道在开放性操作空间中，每多一个重现的必要条件，bug的暴露难度就上升了数倍，甚至更多。更何况是可能遗漏了不只一个条件。

2、开发工程师在修复bug时，关注的是错误代码所在的位置。一旦发现了错误代码，心里想着的是如何修复？而不是想着如何通过代码总结bug重现条件。实际上看到代码来总结bug重现条件未必容易，更何况开发工程也没有动力用心来总结。因为代码执行不是一个点，而是一条路径，路径上的每个判定，都可能存在和外部条件和软件状态的映射。即使为了定位bug，开发从外部的触发条件开始一步步分析代码的执行路径，他也不可能用心去总结所经过的所有判定与外部重现条件的关系。当bug定位出来了，如果有人问他，重现条件，他更可能会告诉你离错误代码最近的判定所对应的外部条件。可只有这个条件是不够重现bug的。但是开发工程师并不关心。

再从测试角度来看：

1、如果能够找到一个缺陷重现的充分条件，通常测试工程师已经很开心了。要去掉所有非必要的条件，非常耗力，也并非必要。因为发现缺陷，是为了能够解决并且有效验证缺陷。如果开发已经能够解决，测试也可以有效验证，这就足够了。当测试工程师费了很大功夫搭建了一个很大的网络环境，发现了缺陷，他通常首先是高兴，但是然后可能就是痛苦，因为开发常会要求他简化环境，比如能在一两台设备的环境中重现它。痛苦也得接收，因为不能被修复的缺陷，也就没有多少发现的意义了。但是如果一定要求测试工程师，将每个bug都精简到一个非必要的条件都不剩，他会一定会发疯。所以测试人员的缺陷报告中通常都有非必要的条件。