分析目前市面上普遍使用的接口自动化框架，实现原理都大同小异，几乎都分为如下几个模块：
1、 数据分离，测试数据的读取；
2、 业务逻辑处理，数据流进的业务代码；
3、 断言，判断执行结果；
4、 报告输出。
其中的难点分为如下几个：
1、 测试人员代码熟练度；
2、 框架适用性，如何设计使其符合大部分需求；
3、 数据库的连接，断言数据为数据库数据；
4、 请求报文中单独某字段需要多次加解密；
以下来通过我做过的项目来分析一个简易框架如何实现自动化，使用技术包括maven、java、testng、mybatis、Apache poi……
大致层级目录如下：
一、数据分离
1、 目的
通常我们接口测试，需要大量的测试数据来支撑，这些数据也不可能一成不变，接口做了调整之后对应的测试数据可能就会作废或者需要维护。为了能让我们减小维护成本，提高数据复用率，我们需要进行数据分离，即业务逻辑和测试数据的分离。
2、 优势
数据维护方便；可代替测试用例；执行效率高，出现问题易于定位；
3、 实现
（1）、可以参考测试用例编写模板
如上模板，编写测试用例时，可直接使用该模板进行用例的编写，规范统一模板，只需要维护概莫即可。如果遇到测试数据变更，及时打开excel更换对应数据即可。
（2）、数据读取
为了方便操作excel属性，新建一个excel实体类，方便存储excel相关数据；
数据从excel读取出来之后，可以通过一个map来存储，当然也可以用别的来读存，比如list、二维数组等等，看自己熟练程度。我这里使用map<String,List>存储，excel中次序赋值给map的key，将每行数据赋给List，利用List的有序性来存储测试数据。
通过一个双层for循环，将excel所有数据返回到表格的实体类中，其中包括表格的长度、宽度、测试的接口名、ip端口、具体数据、表格sheet页签，根据自己的需求可以随意扩展，我这边提供的方法，未做复杂校验，初始简单方法。
二、业务逻辑
不是所有接口都能直接get或者post请求的，很多接口依赖性较强，系统耦合性较高，会依赖其他一个或者多个接口返回的数据重新组合封装报文来进行请求。
我们可以使用testng中的beforetest的特性，将被测接口所需要用到的其他请求或者逻辑，写入该setup方法中。在excel中有一列数据是前置条件的请求参数，则可以通过参数化读取到该数据，进行前置条件执行。
公司业务代码略。。。。
业务逻辑处理中有一种较为特殊，就是模拟app客户端的请求，客户端请求服务器，一般对外的应用都进行了传输加密，一般非银行金融行业的传输加密使用的是AES或者RSA等公用方法进行加密，只需要找到对应的公用方法即可完成加密解密工作，需要注意的是，在调用加密方法的时候，需要用到的加密模式类似“AES/CBC/PKCS5Padding”、"RSA/ECB/PKCS1Padding"等需要与开发保持一致。
三、数据迭代
数据读取到map中之后，通过将每个key值对应的list循环赋给add到新List<Object>中去。
迭代器迭代出的结果如下图，从excel读取的内容与参数一一对应，在@Test类中需要设定与之对应的参数将实际的参数传递到方法中去。（如不清楚dataprovider的特性自行查阅相关资料）。
四、断言
对应使用的httptool需要重新封装HTTPClient的相关方法，此类封装方法网上资料较多，不做赘述。通过上面的参数请求后的response解析到你想要获取的信息，与“期望结果”作比较，即可判断正确与否。
PS：如果需要与数据库做断言，推荐使用mybatis，后面文章会单独介绍mybatis的用法。
五、报告输出
报告输出testng自身就带一套简单报告，丑是丑了点，但是也挺直观好用的。
作为一名测试工程师，当然要精益求精，通过不断摸索找到了一款颜值和实用性并存的报告模板——ExtentReport，把这样一份图形结合的测试报告放在你的邮件里，想必也是有些赏心悦目。（具体实现代码整理完后贴出来，这里就不贴出来凑行数了）