背景
最近接口测试做的多了，略有一点思想，总结一下
怎么做
我之前专门写过接口测试的文章，也对比过好多现有的工具，发现现有的工具并不是非常好用，至少扩展性不好。所以自己写才是最好的。方法嘛有很多，用Java、Python都行，最近在用RobotFramework，感觉都差不多，只要能实现定制化，都没问题。
测试脚本怎么规划
文章标题是测试脚本的规划，那就专门说说这个。
以前的代码都是一个人玩，所以怎么玩都行，换工作之后需要协作，那么就和以前不一样了，至少我觉得，现在的脚本结构还是不错的。
公共方法
公共方法指的是所有项目都能使用的方法，比如网络连接，文件操作，数据库连接等等。这种方法所有项目都需要使用，就可以全部抽象出来成为资源，然后调用就行了。
当然，不仅仅是这些，某些特定的项目内，也一样会有公共方法，但是这些方法仅仅在这个项目内通用，出了项目就没用了，比如你把这个项目需要用的数据库查询，修改等专门封装成方法，那么就只能是项目的公共方法。
当然，项目公共方法在足够抽象时，也是能够上升到全局的公共方法的，主要看组织者对于这块的规划。说白了，公共方法的主要目的就是减少代码的重复，以及写脚本的效率。
项目个体
每个项目都应该做一些清晰的划分，以便以后的拓展，迭代总是难免的，每次迭代都要花大量时间来修改脚本，那么写代码测试的意义就不大了。我认为应该有这么几块要划分出来的。主要有这么几块：
- 业务模块
- 报文构建模块
- 基础报文模块
- 环境模块
- 公告方法
- 冒烟部分
冒烟测试是每个项目都会有的，而且在回归的时候必定要回归冒烟测试。属于业务模块部分
- 业务部分
所有的业务测试部分就应该放在这里了，测试用例写的各种场景，在这里应该都要能提现出来。属于业务模块部分。
- 调试部分
这部分我放置的都是业务的拆分调试的脚本，毕竟业务流总是会有各种环境因素导致不通，单步拆分是非常有必要的。属于业务模块部分
- 项目资源部分
这里应该是整个脚本结构的地基，之前的脚本都应该从项目资源部分调取方法，所以这块的构建需要非常清楚。
基础报文模块。这块用来组件基础的报文，需要包括报文的所有字段，已经某些字段的常量的定义。比如一个接口有30个字段，有一些字段是非必选的，有一些字段是常量，在构建基础报文时就可以确定的，还有一些是业务字段，需要根据不同的业务场景来传值。在构建基础模块时就要注意这些字段，必选和非必选要能很好的区分开来，有时候需要只要测非必选参数即可，有时候全部参数都要拿来测。常量必须要确认清楚，这部分定义好之后是不做更改的。业务字段要保留默认值，在报文构建模块要对这些字段做业务场景的修改。
报文构建模块。这部分也是非常关键的，在这里需要构建成业务场景的报文，那么这部分必须要有这么几个哦功能。首先，要能从基础报文模块中获取基础报文。然后，能够动态的修改和删除所有的报文（不用增加功能，因为基础报文就应该把所有字段定义好）。最后，要能够往服务器发送报文。
环境模块。这块主要是用来定义脚本的执行环境。最好定义成可传参的方式，在构建的时候区分环境。
公共方法。这部分没啥说的，项目使用的方法都放到这里。
总体结构
根据上面来看，总体结构大概是这样的
|____所有项目的公共方法
|____项目1
| |____业务模块
| |____基础模块
| |____公共方法
|____项目2
| |____业务模块
| |____基础模块
| |____公共方法
...
总结
以上是现阶段的接口测试脚本规划，目前来看，还是比较清晰的。画一张图来表示一下吧。
就像盖房子一样，项目中好的公共方法抽象到总的公共方法中，抽象的越多，相当于地基打的越牢靠，业务模块的可扩展性才能强大，在快速迭代中才能够减少工作量，提升效率。
