思考自动化测试--分层测试（三）

由于多种原因吧，自动化测试刚开始发展，都想去做手工测试代替，都想做黑盒的覆盖测试。结果，自动化测试维护成本过高，稳定性也不好，但是执行效率，回归起来又不错。越来越多的人在思考如何更好的做自动化测试。尤其是在敏捷开发盛行的年代，自动化测试已经成了软件开发测试过程中，重要的组成部分，那么到底怎么做自动化测试收效最高呢。目前较为流行的方式--分层测试。
我比较推荐分层测试的金字塔说法：分层测试就是构建高效的测试金字塔，不同层次的测试可以用尽量低的成本防御不同类型的风险。
说法慢抽象的，先来看个实例图，再做慢慢解释：

测试金子塔

上面我们先看到了金字塔了，然后我以比较常见的web项目做例子来解释分层测试。诚如上面说的如果我们单纯做黑盒的自动化测试，其实就是在UI这个层次上，不断开发维护脚本，结果可能带来的风险就是人员的无限投入，却很难得到比较好的测试效果。而这个金子塔的意思就是将应用，分成不同层次的自动化测试，比方说UI就是通过界面进行端对端测试，一般是黑盒测试；service一般针对接口，服务，比方说如果你用REST方式构建web的话，那么可以对REST接口进行测试，还有比方说直接对HTTP接口进行测试，对webservice接口进行测试；而Unit这个包含的比较多了，简单的说在web应用的dao，service，controller，model这些可以写类似junit的单元测试，javascript，css也可以做前段的单元测试。这这个金子塔就说的，根据层次划分，不同层次的测试量不同， 越是在塔尖的，测试开发维护都比较复杂，那么测试的量就越小，而下层的单元测试则可进行比较高的覆盖测试。
简单的说，分层自动化测试，就是把我们单一看着UI的功能自动化测试，将自动化测试扩展到不同的软件层次上，进行测试。
这种测试方式，相比于传统的自动化测试，会有几个改变：

• 将开发拉入测试：其实测试工作也是开发一个很重要的工作内容，传统的开发测试分的很细的方式，不利于分层测试，像单元测试，还是需要开发多多投入。
• 将测试引入开发：分层的测试，需要对被测系统的开发结构有认识，至少你要知道你覆盖了多少了吧，甚至开发大致怎么实现的，不然UI前面对那些接口也不知道那很难评估测试结果的。
• 最好跟持续集成配合使用：重复利用自动化测试的执行成本低的效率，在工程集成完毕前后，更加自动地执行测试，及时的反馈测试结果，从而更好地提高测试效率。
• 使用Mock来实现分层测试，因为是分层那么就可能有隔离一些模块或者外系统，那么就可以用Mock来模拟这些隔离的模块，进行测试。
• 需要合理的评估测试覆盖，不同层次的测试程度都需要合理的评估，这个范围的控制是保证分层测试测试质量的最核心的规划，这个才是成功关键。

综上所述，分层自动化测试是追求覆盖的传统自动化测试的一种修正，充分利用自动化测试的优点，尽量规避自动化测试的缺点。当然分层测试也有些要注意的问题：

• 测试重复：分层可能对测试是重复的，在上层测过了，下层还继续测。从测试角度上说是重复测试，但是从整个流程看测试的话，不同层次的测试，属于过程的不同阶段，比方说单元测试，可以在编译后进行测试，在集成前就可以发现问题，而UI的自动化测试则更加滞后一点，功能不同效果不同，测试的重复还是可以忍受的。
• 测试遗漏：这个就很需要对测试覆盖的规划能力，而且这里要说明的一点，自动化测试不能或者很难做到全覆盖测试。手工测试还是不能放下的，而手工做到全覆盖是有必要的。
• 测试复杂度，分层测试需要工具比较多，人员能力比较强，要控制那么多工具进行测试，还要对业务，甚至开发有了解，还要开发人员参与进来，投入也不小。

不管分层测试有多少难度，他是目前解决自动化测试开发维护的一个比较好的方案。如果要大规模使用自动化测试，我想分层的思想应该是不容忽视的。