面对测试人员测到的bug时

搞it的，都要经历过测试。编码的时候要自测，完成后自测通过以后还要交给测试人员进行测试。既然要测试，就离不开bug。发现了bug，开发人员，就又的在本地，进行检查。然后自测，自测通过后，又交由测试人员测试。如此循环往复，知道测试人员没有测出bug为止，这就算成功了。

 

这里说的bug其实有很多种。我觉得主要又分为功能性的bug（即功能没有达到需求所要求的），和非功能性的bug。

功能性的bug，往往要求我们重新编码，重新思考逻辑处理。相对来说这类bug更好定位，看看需求就能知道。而非功能性bug，这定位起来，常常比较难，非经验丰富的开发人员，一般不能很快定位到——特别是对于新手来说，要是没有别人指点一下，估计是怎么也想不出来。

 

功能性的bug，就没什么好说的了。无非就是改改代码。但非功能性的bug往往是不需要改代码的。但开发人员往往去想不到，或者是根本不会去往“这里”去想，他们老觉得肯定不会是“这里”出力问题，“这里”这么简单。其实往往是最简单的地方，人们才最容易忽视，最容易视而不见！

 

我刚工作的时候就经常出现这种非功能性的bug，老是老半天也找不传来。测试人员一测到bug，我就以为是程序逻辑问题，就重新看代码，分析代码。但仔细分析了以后，发现不程序没有问题，而且，在自己机子上测试，一点问题也没有；但在测试人员那却会有问题。所以，没有办法，跑过去对测试人员说：“我看了代码，没有问题。”测试人员反问：“没有问题，怎么在我这会出现这种bug啊？”自己也确实不知道，只能说：“我在我机子上也测了，怎么也没有出现你这样的问题，我也不知道！”。然后测试人员说，那你去问问项目经理吧。我跑过去跟项目经理说了一下情况，说代码没有问题，并且在我机子上测试没问题，但在测试人员机子上就有问题。人家跑到测试人员那里去看一下，然后ping一下域名，发现ip不对。说是host配置问题。人家测试人员还不相信，包括我也不相信哦。我觉得，测试人员肯定在测试之前就已经在host文件中做好了域名映射了（映射到局域网的测试环境）。测试人员也说。我在host里面有了这个映射啊。项目经理就说，不信，你打开host文件看看。一搜文件中的确有那个域名的映射，但被注释掉了。哎，——也证明了的确不是代码那边出了问题。原来一个这么简单的问题，搞了我是苦思冥想找不到解，还折腾了我快一天。搞得人不爽，不说；面子也丢尽了！

 

所以大家在开发好系统，交给测试人员测试是，被他们测到bug时，先不要急着去找代码的问题。先想想是不是测试人员那边哪里的配置不对。——这样的话往往会事半功倍。大家搞it的都知道。一个系统交给测试人员去测试的前提是，开发人员在自己机子上都测试通过了。但这不是说bug就不会是因为代码的问题引起的。我只是告诉大家这个思路。能让大家多方面去想问题，而不是仅仅囿于代码方面。

 

所以在面对测试人员测到的bug，而这些bug明显不是由于代码问题造成是，应该

1：先检查测试人员的网络，看看网络是不是通的。

2：查看测试人员对测试系统的配置是否正确。

 

比如我们在升级我们公司山寨系统的时候，我们的一个测试人员测试环境测试的时候，发现上传一张图片后，图片显示不出来。跟我说了以后，我叫她把这张图片的url发给我，我在我机子上访问了一下，一点问题也没有。然后就怀疑她网络是不是有问题，我就在测试人员的机子上ping了一下图片的域名，显现图片域名的ip是外网。所以一下就问题找到了，是测试人员的机子上没有在host文件中配置图片服务器的映射。以至于找到我们公司正式环境的图片服务器上去了，所以在那个测试人员的机子上当然就显示不出那张上传的图片了。

 

 

这两个是最基本的。也往往是自己最容易忽视的，老以为测试人员自己知道这些要求。特别是新人更要往这方面想，要不然你可能真的是会“踏破铁鞋都无觅处”！所以大家以后碰到被测到bug的时候，要多想想其他方面的原因，不要老以为是代码的问题！哪怕是最简单的地方也不要放过，多试一试。