现在对于自动化测试与CI往往有一些很常见的谬见，包括一些专门从事相关工作的人都未必清楚。在实际的工作中感触颇深，所以想撰文讨论一下。

　　第一，自动化测试就是给CI服务的，或者自动化测试不太能发现问题。

　　持有这种观点的人，建议他们去看看Google或者Microsoft的相关测试研究的文章，或者GTAC（ Google Test Automation Conference），也许可以拓宽我们考虑这个问题的思路。

　　他们的测试对象是搜索引擎，海量的数据库信息，或者提供的各种服务，比如Google Map，Navigation。他们研究的是搜索引擎对于海量的数据库处理起来是否有效，搜索结果是否准确 。

　　下面举几个例子：

　　比如Google会提供一种 ‘Auto Completion'的功能，你只要在搜索框里敲入一个词，google会根据与这个词的相关性大小，以及该关键词被搜索的热度，自动补全一些关键词，并提示给你。这样，你就可以参考或者直接用别人的搜索条件。那大家有没有考虑过，这种功能应该如何测试呢？

　　还有导航系统，怎么确保从A点到B点找出来的路径都是正确的呢？而不是说你要找一个当地的餐馆，导航却告诉你要来一次跨国旅行呢？

　　面对这些海量的测试数据，并且基本上也无法预先给不同的测试数据定义好期望的测试结果。所以他们无法采用我们这样的静态的自动化测试，而且通常Manual Testing也无法帮助他们解决问题， 他们必须采用动态的大规模的自动化测试，或者叫计算计辅助测试。

　　他们的做法就是采取一种叫HBT（ Heuristics Based Testing）的技术，测试工程师找出一些测试是否成功的判断法则，而不是像传统的自动化测试一定要明确规定静态的期望结果，并把这种判断规则用代码实现。

　　通过这种方法，再加上一些并行的测试技术，他们也许一天可测上千万个case，并且在一种判断法则已经不太能有效地发现问题的时候，可以随时调整或者寻找新的判断成功与否的法则。

　　而寻找 “测试是否成功的判断法则”，也就是常说的Test Oracle的时候，则很类似传统手工测试做manual exploratory testing的过程。测试人员做手工测试的时候，不是重复地去敲键盘，点鼠标，而是寻找系统的失效模型，然后利用自动化测试技术实现，并把这个失效模型放大到尽可能大的范围。 这部分工作，往往是测试工作中最有意思，最有创造性，往往也是最考测试人员功力的。

　　我曾经看过一个他们的例子，Microsoft 的Principal Test Engineer写的，他们用这种方法，一天执行了2200万个测试用例，发现了20多个可能的问题，然后和相关stakeholder讨论。

　　从上面的例子可以看到，Test Automation其实完全不受限于CI这种模式的下的测试，完全可以借助自动化测试的手段来做Exploratory Testing.

　　第二：CI中的测试一定要保证测试的全覆盖。

　　首先，测试的全覆盖本来就是一个伪命题，从来也没有一种测试可以做到全覆盖。测试人员要解决的是在测试设备有限，测试人员有限，测试时间也有限的情况下，如何能够让组织在测试的投入上，达到最高的ROI。

　　然后回到CI，我们来看一下CI的目的到底是什么。

　　在传统的开发模式下，软件组织在Integration的时候往往会发现模块的接口定义或者理解有不一致，然后需要返工，甚至因此要改模块的内部设计。在各个模块都各自完成以后，想让他们在一起能工作，给客户提供一个完整的功能，往往还要等待很长的时间。

　　既然集成这么麻烦，那我们就提倡尽早集成，尽快测试，以期待尽快发现问题。同时开发人员在实现代码的时候，如果能够尽快给他们的实现提供反馈，这对他们避免在后来的开发中犯同样的错误，也是非常重要的。如果这种反馈的成本比较低，那我们就可以让这种反馈尽可能频繁。