（1.c）所以对于某些问题熟视无睹，看不到这个问题，因而没有报告

　　（1.d）且如果被测功能是自己开发的，可能想顺手修掉，没写报告

　　2）项目组成员对于被测试的功能并不太了解，

　　（2.a）因此更倾向于报告那些UI上与逻辑不相关的问题，这类问题误报率本身就低

　　（2.b）因为报告的（2.a）类问题很多，占用了大量时间，因此没有足够时间去测试那些更为复杂的逻辑，因此误报少

　　（2.c）心中没有预期的行为，也就没有办法判断是否是缺陷，报告得少，所以误报的也少

　　针对以上每个解释，我尝试寻找更多与解释一致或者不一致的其它数据。

　　此次活动我们没有限制大家是试用自己开发的模块还是别人开发的模块，但从缺陷报告人和缺陷所属模块来看大家还是测试自己开发的模块居多。所以从这个数据来看，项目组成员应该对于被测试的功能非常了解。经过和某些开发人员的进一步沟通，他们反馈在自己的模块报告的问题比较少的原因是（1.b）和（1.c）。我想（1.a）应该是不需要数据就能够成立的一个合理猜想。所以只有（1.d）难以得到数据的证实，但根据平时工作的情况，相信即使有，其比例也不高。所以我认为（1.a）（1. b）（1.c）可以视为合理的解释。对于（1.b）和（1.c），如果想改善的话，我想交叉测试是有益的。另外，对于测试人员，也需要提醒特别小心“杀虫剂”效应，避免对于长期已知的问题丧失了辨别能力。

　　但是，要如何解释在同一个自己熟悉的模块，测试人员误报率高于非测试人员误报率呢？不是测试人员专业性更高，应该误报率更低么？也许从一个方面来看，除非是明显的程序实现错误，开发人员误解自己程序行为的可能性较小，因而误报率较低。从另一个方面来看，在同样面对一个不确定的问题时，测试人员抱着更强烈的暴露问题的意愿，“宁可错杀一千，不可放过一个”，模棱两可时会选择先报告，而开发人员也许更多地选择先放一放。但这一点还需要找更多的非测试人员去了解是否属实。

　　当然，我也看到虽然大部分人体验的是自己开发的模块或者是与自己模块联系较紧密的模块，但有些人也在别人的模块报告了不少问题或者建议，符合第2种解释。在第2种解释中，因为此次活动中超过50%的有效缺陷都是UI上与逻辑不相关的问题，所以该数据支持了假设（2.a）。因为活动时间本身不长，报告缺陷又要耗费一定的时间，所以也支持假设（2.b）。根据和一些项目组成员沟通，他们认为按照平日工作中的感觉，假设（2.c）在自己和团队成员中还是成立的。这在一个侧面提醒我们平时要多做跨模块的知识分享和储备。比如，跨模块轮岗、跨模块代码走读、交叉测试、结对测试等。

　　2、与数据多样性相关的缺陷数

　　我预计因为更多的人员参与测试，在数据选择上自然地应该有更多的多样性，所以发现数据相关缺陷的可能性应该较高。但实际结果只有2%。可能的原因有哪些呢？

　　1）数据相关的缺陷已经很少了

　　2）数据相关的缺陷不少，但没有被发现

　　（2.a）对于最应该能发现与数据多样性相关缺陷的需求分析人员，因为他们中的几人遇到了和环境相关的问题阻碍了测试的进程，所以没有报告出足够多的数据多样性相关的问题

　　（2.b）对于整个团队，尤其是此次活动中占多数的广大开发人员，可能大家对于数据的敏感度还有待提高。比如，看到一个集装箱号是否能反应到应该显示11位而非10位？

　　我查找了一下这个版本测试人员在内部测试时在数据多样性方面报告的缺陷比例，为21%。这个数据与这次活动的2%相差很大。因为按照ODC分析法，我相信版本的质量属性不会在短时间内自觉地发生本质改善，所以在数据多样性方面应该还有更多的缺陷有待发现。因此我倾向于相信假设（2）而非假设（1）。因为近期需求分析人员无暇再继续测试，所以没有办法证实假设（2.a）。假设（2.b）与前期内部测试的结果中数据多样性缺陷占到21%比较符合。为了改善这一情况，需求分析人员需要多提供真实业务数据作为参考。比如，需求评审时可以多尝试”Specification by Example”，而这些example不仅仅有逻辑的抽象，更是用真实的数据表达了真实的业务场景。

　　按照类似的思路，我和小组成员对其它各组数据背后的原因进行了各种假设和进一步的数据分析。明确了主要原因后，也制定了相应的改进计划。有了它们，我感到我更能坦然地面对这98个缺陷、问题和建议了。有了它们，我相信下一次我们的“狗粮”升级版会更好吃的！

版权声明：本文出自 zdlzx 的51Testing软件测试博客：http://www.51testing.com/?56882

原创作品，转载时请务必以超链接形式标明本文原始出处、作者信息和本声明，否则将追究法律责任。