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

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

　　第一，自动化测试就是给CI服务的，或者自动化测试不太能发现问题。51Testing软件测试网FXul%NgJ

4Joo Kz1cco0　　持有这种观点的人，建议他们去看看Google或者Microsoft的相关测试研究的文章，或者GTAC（ GoogleTestAutomation Conference），也许可以拓宽我们考虑这个问题的思路。51Testing软件测试网qbn#Mj

51Testing软件测试网u/as2f"^!xr:m'w^

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

z9x
K q:[7n-G051Testing软件测试网$PI6UR x$k
`!}9e8Ky

　　下面举几个例子：

Ct
kg(yq0

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

EGq%k ^:]ge _051Testing软件测试网$S*Pr$Y6SF&t

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

{j_;Z4I#T$qP051Testing软件测试网+g7r!| IAs

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

W*n9`S|S5p0

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

M@Wg GA$Xk2OR051Testing软件测试网/Q)Gl4S3f:J.{ V4}

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

51Testing软件测试网0jKD8S0f{

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

)H;S~Fw_O9N!v |0　　我曾经看过一个他们的例子，Microsoft 的Principal Test Engineer写的，他们用这种方法，一天执行了2200万个测试用例，发现了20多个可能的问题，然后和相关stakeholder讨论。51Testing软件测试网3AP3Ns:aV^8G

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

)a0Y].B
r/G&js0

a_9k"l6{0　　第二：CI中的测试一定要保证测试的全覆盖。

S(Ce?1MR8?0

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

)fW6WhS"zi051Testing软件测试网l`6zCQ2OXM[L'H

　　然后回到CI，我们来看一下CI的目的到底是什么。51Testing软件测试网4_WQt xO

51Testing软件测试网FX,}-B ~*V

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

51Testing软件测试网5A/i k-h"P3q }

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

6tnOp_4GK7G`0

c;|:s9ns/^0具体来说，如果让尽可能多的测试都自动化了，那我们在降低反馈的成本上就走出了第一步，也是非常重要的一步。51Testing软件测试网w9t'O}#a2]yg5Z

51Testing软件测试网)r6Re6_ V%]&^$Z

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

3`:L|'g X r051Testing软件测试网!HR~BA1\d

　　开发人员的开发过程其实就是一个不断犯错误，又不断纠正的过程。51Testing软件测试网&Z"gkN+xjzMW

51Testing软件测试网(`tdbFo |

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

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

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

]-^%M#o,U)u5^C051Testing软件测试网5G2PWg x5U`\&]

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

51Testing软件测试网 M$? oC3Z'RANW/O

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

51Testing软件测试网XI"j9yw1z0MW

　　通过我们的经验来看：51Testing软件测试网LR P#\"os$_b

51Testing软件测试网;C5Dkt5_cb.Rzy

　　1. 有些team抱怨这种模式的测试，我们也叫CRT（ Continuous Regression Test）基本发现不了软件问题。51Testing软件测试网.iVV^j
zU

51Testing软件测试网ZI,t#C ZA pd'K

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

wf0\R0Lm&B*S051Testing软件测试网vA7^{vnwX e

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

]Q*v5l`F0

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

?,lP?'M:dG1G051Testing软件测试网bl,VqF'p

　　在这种情况下，再强调在CI的模式下要保证测试的全覆盖，我们来看一下会给我们带来什么。51Testing软件测试网 Q%[3|4]'F9z#N:ba3u

51Testing软件测试网4]4FHF2F*e^

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

1n([g T;a3b051Testing软件测试网0YU2{8Za

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

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