自动化测试中的“分层思想”

自动化测试中的分层思想可以分两个方面来理解：

一

测试策略上的分层：测试金字塔

测试金字塔由敏捷开发专家Mike Cohn提出，是希望解决传统UI自动化测试中的一些雷区，比如：执行速度慢，稳定性差，受测试环境影响较大，测试框架复杂，开发及维护成本高等。

但单元测试和集成测试也存在一些问题，比如：

单元测试测试脚本执行速度快，但测试数据都是假的(全靠mock)，涉及的测试用例太多，很难完全覆盖，不是单靠测试团队能搞定的；

集成测试可以很大程度上避免上面两种测试的问题，但测试数据依然是假的(call/stub)

软件最终呈现给用户的是UI层，所以即便UI自动化问题很多，测试人员也无法放弃UI自动化测试，这样在项目中，金字塔中三种测试的比例如何划分称为分层自动化测试，《google 测试之道》中介绍，对于google产品，70%的投入为单元测试，20%为集成及接口测试，10% 为UI层的自动化测试

二

测试工程上的分层：代码重用

在自动化测试的工程中，测试脚本中的代码(关键字,keyword等，下同)一般包括3部分：

测试业务逻辑代码

支撑代码

测试数据

测试工程的分层，主要是解决以下问题：

当测试逻辑与一大堆支撑代码混在一起时，测试逻辑隐藏在支撑代码中，难以理解及修改。 要添加新测试步骤/用例，通常需要重读这些支撑代码才能找到需要修改的代码，效率低。

业务逻辑间通常会有耦合关系，某个业务或模块功能的轻微变化，会影响到相关所有测试脚本都要修改。

维护开销大。一个测试工程会对系统的某个部分进行多组测试，每组测试间可能存在重复的代码。这些重复代码被不同工程师在不同的脚本中完成和维护，工程师能力的差异就会导致测试代码的质量参差不齐，稳定性差。

解决以上问题的方法是采用软件工程中重用的思想，针对支撑代码进行分层，比如分为高中低3层：

高层：公司级可重用代码,这些代码一般与具体业务无关，但工具本身并不提供，比如：特殊字符串处理，JSON处理，控件操作封装等；

中层：项目级可重用代码，这些代码在本项目各个模块中可以重用，一般是对各个模块主要功能或流程的封装，比如登陆功能，订单功能等。其他模块的自动化测试用例可以使用这些代码简单的解决脚本中模块间相互依赖的问题；

低层：模块级可重用代码，这些代码在某一个模块中可以重用。

底层的代码如果被大范围使用，可逐步上升到高层