谈自动化测试与CI中一些常见的谬见

现在对于自动化测试与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的时候往往会发现模块的接口定义或者理解有不一致，然后需要返工，甚至因此要改模块的内部设计。在各个模块都各自完成以后，想让他们在一起能工作，给客户提供一个完整的功能，往往还要等待很长的时间

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

具体来说，如果让尽可能多的测试都自动化了，那我们在降低反馈的成本上就走出了第一步，也是非常重要的一步。

但是大家要思考一下，反馈的速度，频率和反馈的价值是不是完全等同？

开发人员的开发过程其实就是一个不断犯错误，又不断纠正的过程。

比如说IDE会频繁告诉他们的一些语法错误，然后在编译链接的时候又会发现一些问题，然后在执行UT的时候又会发现一些问题，然后在后面的Smoke Testing，Function Testing，System Testing又会得到一些反馈，然后从最终的客户那里会得到更进一步的反馈。

随着软件技术的发展，比如更好的IDE，更好的UT，更好的自动化测试，开发人员在不断地降低得到反馈的成本，提高反馈的效率。但是，我们可以问问周边的开发人员，特别是那些资深的开发人员，在他们的开发生涯中，让他们印象最深的一个Bug，是怎么发现的？

我会怀疑让开发人员得到的一个印象很深的Bug，一个真正有价值的反馈，往往是一个好的测试人员给他的。

在我们的组织里，一个好的测试人员是很受开发人员尊重的，因为他不光光是发现产品Bug那么简单，他还不断地给开发人员提供有价值的反馈，不断地让开发人员以该更加周全思路来考虑问题，也促使开发人员不断地成长。

但是CI模式下完全依赖机器的执行，不强调人的介入的自动化测试，会是给开发人员提供反馈的唯一途径吗？

通过我们的经验来看：

1. 有些team抱怨这种模式的测试，我们也叫CRT( Continuous Regression Test)基本发现不了软件问题。

2. 个别Team的经验是CRT可以帮助他们发现很多问题，但估计和模块工作的领域有关，比如该模块本身就是问题比较多的模块。

3.即便是上述第2种情况的模块，也发现许多软件深层次的问题，比如一些设计上考虑不太周到的地方，往往也是一些Senior Tester才能发现的。

4.往往一个测试中发现的问题，在另外一些测试用例里面会被重复发现。意味着我们的测试用例发现问题的能力往往是有冗余的。

在这种情况下，再强调在CI的模式下要保证测试的全覆盖，我们来看一下会给我们带来什么。

首先，你的测试用例越加越多，你的测试周期势必越来越长，也就无法给他们提供及时的反馈。而CI的精华之一就是强调给开发人员提供及时的反馈。

其二, 如果你考虑并行测试的话，势必要增大测试设备的投入。在电信领域，测试设备往往是很贵的，往往比请几个测试人员还贵。当你的自动化测试不能持续给开发人员提供有价值和有深度的反馈，你还不断要求管理层给你加大测试的投入，往往也是不现实的。根据我们的经验，很多采用静态测试技术的自动化项目，往往都会碰到类似的问题。

所以CI天生是用来解决Integration的问题的，因为Integration给软件开发带来了很多的问题，是开发工作中很大的一个bottleneck，所以采取了Continuous Integration的方式去做。而Test Coverage则是测试中另外一个很难解决的问题，意指在测试阶段尽可能保证全面的测试覆盖，以避免软件Deploy到客户现场，被客户发现问题。CI作为一种很好的Practice，应该被我们很好地应用，但是如果片面追求CI的Test Coverage，反而有可能会丧失掉CI本身的优势。