现阶段而言，功能的自动化主要用于以下功能场景：
1. 特定功能场景：主要是指不同输入产生不同输出单一功能的场景。例如规则引擎、版本升级等
2. 系统功能回归：主要是对功能已定型部分做自动化处理，例如对旧版本的兼容、当前版本不做更新的部分等
针对特定场景如何用分层做自动化
规则引擎功能描述：拿用户信息与已有用户信息做比对，以判定用户的优劣程度。
规则引擎架构：
通过系统架构我们可以分析出，规则引擎的功能主要有两个部分组成：1.推送预埋数据完成数据清洗；2.请求待验证数据完成规则命中的判定。该类型测试可使用数据驱动来做测试，具体实现如下：
1. 设计预埋数据与待验证数据
2. 推送预埋数据，将清洗后数据与预期数据比对
3. 请求待验证数据，将规则命中情况与预期命中情况比对
测试过程中，如果出现清洗数据与预期不一致，直接提出问题即可；如果数据清洗没有问题，但是规则出问题，只需确认待验证的请求数据是否正确即可确认问题所在。
针对系统功能回归如何做分层自动化
在系统功能回归方面，可以采用UI自动化或者接口自动化两种方式来做。相比较而言，UI自动化对项目稳定性及人机交互要求要高，因此在我们项目中主要采用接口自动化来验证后台服务的正确性。后台服务接口主要分为两类：查询接口，信息提交接口。整个业务流程其实就是查询接口与信息提交接口的一个排列组合。功能回归的架构设计可以按照下边这个思路来：
以上篇注册流程为例，整个过程主要涉及以下几个接口：
1. 图形码获取接口：获取图形验证码
2. 图形码验证接口：校验提交验证码，验证通过发送短信
3. 短信验证接口：校验提交短信，验证通过可提交密码信息
4. 密码提交接口：提交密码信息，完成注册
在这个过程中，还会使用到redis和MySQL数据库。基础服务用来实现接口请求的发送与响应数据的获取、数据库数据的获取；接口实现用来实现4个接口；案例流程，对4个接口做排列，同时通过一些自定义接口获取所需数据，例如图形码内容的获取；测试数据中的请求数据由注册用户名和密码构成，预期结果可以用来保存注册结果或者某个接口返回的预期结果用来断定案例是pass还是fail，配置数据用来保存后台服务地址、数据库连接等信息。
这样做的好处：
1.测试环境与测试数据可以随时更新
2.接口变更后只需更新案例流程的实现
3.功能新增，只需新增接口实现与案例即可
关于分层测试的概念，就介绍到这里。这里只是跟大家提一个测试思路，具体如何实现还是结合自己项目来做。
