经理也会制造错误

　　我期望一个高水平的覆盖率。有时候经理也需要一个覆盖率。但有时这两者之间稍有不同。

　　假设一个经理要求一定程度的覆盖率，可能是要求百分之八十五作为一个完成指标。但是该产品还没有完成，所以你不能交工，除非你达到了百分之八十五的覆盖率。

　　该方法的问题在于人们是按照他们测量的结果来优化性能的。你可以通过研究覆盖条件，挑一个看上去最容易实现的，编写快速的测试，反复进行这个过程直到实现百分之八十五的覆盖率。这要比将覆盖条件看作是指向测试设计缺陷的线索来说快的多。它之所以快是因为考虑测试设计可能会导致“冗长的”测试，而这些测试对于提高覆盖率根本没用。它们只能用来发现错误。

　　那人们该选那条做法呢？是花费大量的时间写更好的测试，就像那些能实现高覆盖率的测试一样，还是写快速的测试？

　　或许这些情况能从侧面给出答案：当我和一些组织谈论覆盖的时候，这些组织认为百分之八十五的覆盖率应该是完成指标。我有时候会问，很多人是如何实现更高的大概百分之九十的覆盖率的？通常有些人承认能达到，但更多的人集中在百分之八十五左右。难道我们能相信这些人仅仅是因为碰巧达到了百分之八十五的覆盖率，却不能找到其它值得写的更好的测试用例吗？或者他们刚开始写了一系列的测试，得到了相应的覆盖结果，然后不断的测试程序直到他们正好实现了超过百分之八十五的覆盖率，最后如释重负地完成了一项并不有趣的工作吗？

　　我并不是在唠叨指责这些开发人员和测试人员。我已经说过使用好覆盖是很难的，即使对于我来说。对于最优秀的人来说很容易掌握覆盖技术，将它作为一种精神支柱，一种可以替代思维的自动的帮助，而不是促进它的发展。

　　我要说一说经理们。

　　提供适当的动机激励来提高员工在公司工作的兴趣是他们的工作，或者应该至少要避免消极因素的发生。覆盖的数字(像很多数字那样)是非常危险的，因为它是客观的但是不完全的。它们常常曲解了合理的行为。孤立的使用它们就像只基于GPA的高低来雇佣某个人一样是很不明智的。

　　合理地使用覆盖同样可以避免其它测试错误，也就是说根本不用它。我经常看到有人热情的寄希望于覆盖率的实现上，最后，这儿就有一堆的方法来处理测试时遇到的困境。但是一年过去了，覆盖工具并没能帮助实现这些乌托邦式的理想。所以，他们就认为这肯定是毫无用处的。接着测试机构又开始狂热地开始寻求其它方向的突破。

版权声明：51Testing软件测试网及相关内容提供者拥有51testing.com内容的全部版权，未经明确的书面许可，任何人或单位不得对本网站内容复制、转载或进行镜像。51Testing软件测试网欢迎与业内同行进行有益的合作和交流，如果有任何有关内容方面的合作事宜，请联系我们。