灵性设计之测试-做有意义的测试（UT&IT）

（转载）灵性设计之测试-做有意义的测试（UT&IT）

UT是保证产品质量的一种手段，但绝不是唯一手段，甚至不应该是很重要的手段，有很多的开发人员在UT上花了大量的功夫，把UT 的test case 写的非常细，结果发现到了测试人员手里还是一大堆bug, 似乎没有很明显的质量提升，为什么？难道UT没有意义了吗？

我们用一个例子来分析这个问题，有一段程序，它应该有10个条件分支，类似if-else这样的，假如你在设计时或者写代码时只处理了8个分支，而你不知道其余的2个分支，所以你写UT的test case时也只会为有代码处理的8个分支写，而不可能会为另外2个分支去写，因为你不可能知道有这2个分支的存在。也就是说你如果一开始逻辑设计错了，那么到你写UT的test case时也不可能知道错误所在，那么即便你为8个分支中的每一个分支写了10个test case, 总共有80个test case, 够多了吧，但是很遗憾，因为你的UT test case永远也不会覆盖到另外2个分支的逻辑。当然你那80个test case能保证你那8个分支的代码质量。

从这个例子我们可以看到如果我们能把精力分点出来用在发现另外2个分支的逻辑上，也许你根本不需要写够80个test case, 10个就够了。问题不是出在你的test case写的好不好，而是你的关注点不够，UT让你只关注你代码已有逻辑的部分，而代码以外的你没有去关注，所以你永远不知道。如果我们站得更高一点，站到这段程序之外，从整个组件之外，从整个user case的角度，从更大的范围来看的话，你就一定能发现另外2个分支，而集成测试Integration test就是为此而生的。只有你的关注点变了，才会发现更多的bug，更多的以前没有考虑到的问题。但很可惜的是我们现在所谓的集成测试也只是关注了各个大的模块或组件之间的集成而已，只是把模块之间调通就万事大吉了，所以一般也只是在最后一段时间才开始做。

那么可以看到UT和集成测试之间很容易出现了真空地带，而且最要命的是没有人对真空地带负责，因为从组织结构上来说，开发人员只负责基于需求来开发，测试人员也只基于需求来开发，架构师也不会为具体的业务逻辑负责，而需求制定者也不可能对此负责，那么我们过于强调明确分工的组织结构决定了我们注定会出现真空地带。我们姑且不去探讨怎么修正组织结构，我们也不管应该做的这种测试叫做什么，它是比UT粒度大一点又涵盖现有的集成测试的一种测试，所以还是叫集成集成比较好一点。当然这种集成测试更广义一些，不一定只是做代码的测试，它也应该包括对设计对架构对需求的测试，这些方面往往比代码的测试更重要，道理就如同南辕北辙一样简单，如果方向都错了，你代码写得再漂亮也最终会成为一堆垃圾。

同样的道理也适用于我们测试人员做的功能测试，还有其它的系统性的测试，如性能测试。花更多的时间去测试软件与需求是否匹配，业务逻辑是否充分考虑到了各种意外exception，远比只关注软件里面的某块代码的正确性更重要。我们的精力有限，我们的成本也有限，所以我们一定要做有意义的测试，及时调整我们的测试目标会比我们多测试几个test case更重要。

另外TDD也是来处理这种情况的，因为以往的UT都是些代码的人自己写的，自己写一段代码验证自己的逻辑，当然不会有问题，所以TDD倡导在写代码之前根据use case写UT,这样就可以避免逻辑不对或全。但是问题是这种办法实际操作起来过于复杂，尤其在提倡代码重构的今天，当代码重构一遍，UT也得不断的改变，还是无法保证UT符合最初的use case。所以既然做不到或者是需要很大的effort去做，你们还不如另辟蹊径，从集成测试方面去弥补这种不足，而且关键是意识一定要到位，要知道测试重点是什么，而不是为了测试而测试，很多时候并不是我们的方法论出了问题，而是实现的人出了问题。

原文地址