• 陆续接触接口自动化也有点时间了，从最开始的以为拿 jmeter 发个请求就很牛逼（功能测试出身不要嘲笑俺～）到现在也可以自己规划和设计自动化测试觉得很容易也很不容易（废话可忽略...）
• 第一次发帖主要想分享下我们的接口自动化是怎么做的，文件，用例，测试数据怎么管理，结果怎么验证，还有一些自己 yy 的东西，很多帖子也有写这些，但是感觉对如何做成一个项目而不是一个例子的描述还是很少的，因为自己以前也是做功能测试的每次看完总会想如果自己还在以前的水平看完了以后做一个例子是没问题，但是如何真正高效的应用到工作中去还是很困惑，例如那么多接口我要怎么放，每个接口的验证可能也都不一样，到底要验到什么程度，需要自己加写什么类型的关键字等，反正很多的困惑～希望这篇可以給还在摸索的小伙伴提供更多的信息和灵感～
• 我们是基于 robotframework 做的接口自动化，使用的 requestslib 库，至于这些怎么安装，怎么写一个请求发送出去，我就不写了...自己搜下很多很多～选这个只是因为当初正好在学习这个工具，始终觉得工具够用就行，重要的是不要忘记写脚本的目的始终还是为了能发现已经存在的 bug 才好，下面进入正题

先看下我们的项目目录：

不要吐槽我取的名字...

KEYWORDS: 存放各种关键字
－ Business_Keys: 按照产品分类存放需要测试的接口以供后面 test case 和创建流程类关键字来调用；
其中单个接口的关键字放在 api 文件夹下（接口参数完全可以根据用例自定义传入）；
流程类的接口关键字放在 combo_api 下（部分是多个接口的组合，部分是某个参数较多的接口仅对外暴露少量的请求参数方便在 test case 中调用走个流程的，例如处理一个用户单子封成只需要传入用户 id 就好，其他参数都有默认值）
－ NoBusiness_Keys: 和接口无关的关键字，主要调用到 lib 文件夹下自定义方法
各种断言关键字
数据转换关键字
需要查询数据库或者 redis 的关键字（例如：随机获取一个在线状态下的用户）
其他和业务无关的关键字（例如：获取一个随机的手机号码，获取当前日期，时间，生日等）

RESOURCE:存放资源文件

File: 存放图片等文件，供图片上传这些接口使用
Properties: 叫配置好像有点不合适…其实就是放了被测接口公共参数的默认值,每次发送请求时候会将公共参数拼接起来
Schema: 接口返回值的基本结果对比开始我们自己写了方法，后面直接用了 jsonschema（http://json-schema.org/），这边就是存放模版的位置
Sql:給某些 test case 用来创建数据的 sql 脚本（数据好插入好删除，轻松不留痕）

RunTestSuite.bat: 为什么是 bat 呢。。因为我们放 windows 上跑的，这个主要是起测试脚本，然后调用一个 python 脚本生成一个统计的简易报告，robot framework 有高大上的报告，但是排错感觉并不方便，因此自己做了一个简易报告直接插入到邮件里面，主要就是返回了请求内容和返回值内容以及希望结果，一目了然有木有～（有点长图截不全）

结构大概就是这样～

如何添加一个用例

• 每个接口都是一个 test suite,例如万能的首页，我们給他添加一个 test case 叫 “指定固定省市”
• 用例内容无非是发起请求，拿到结果，做验证，对验证这快可能因为我自己做了 3 年多功能测试，所以对校验要全面这快比较执着，而不希望仅仅浮在表面，因此校验比较重，也正是因为一直本着俺要发现 bug 的目的做校验，因此对这快的关键字做了很多次优化，希望可以既满足我希望全面的需求，又要满足添加时快，方便的需求

我们的小规则：

1. 对接口的参数尽量不要写死，能随机尽量随机（随机，或者随机从数据库取），我固执的觉得更容易发现问题哈
2. 接口请求的地方会看到一个用户的帐号密码参数，可能大家觉得不理解，大部分接口如果需要用户 id 都是通过 token 来传（以前我们也这么干！），在实际写用例过程中发现，找 token 太麻烦，懒......但是帐号密码我记得很清楚（因为测试环境密码都一样的哈），因此我将接口下层调用的一个 postapi 的关键字优化了下（见下图），拿到帐号密码后去请求这个用户的 token，然后在拼接其他参数和公共参数，发起接口请求，这样妈妈就再也不用烦找 token 的事情了。。。缺点：如果登录接口挂了，其他接口都不能跑了，但是登录接口都挂了开发不是应该赶紧的修吗,不然都没法做功能测试了！

• 对结果的验证这快够全面，最好的证明就是每个迭代的发现的 bug 数量～（不知道应该怎么写了，反正都是本着我手测接口咋验证的这个脚本就尽量覆盖那些点）

怎么跑？

• 用例我们就区分了 2 类 tag，一类是希望一小时跑一次的（这些用例多是查询类接口，我们从数据库随机找数据出来跑的，因此希望多跑），还有一类就是一天跑一次，因为测试环境的发布权在我们手上所以对于发布这快我们都很清楚，因此就不需本着防火防盗防开发的目的频繁的跑了，大家根据自己需求来就好

怎么写？

• 大部分公司的接口自动化脚本应该是在项目完结之后开始进行的吧，我们现在是接口文档出来就开始写，自动化和手测接口同步进行的，因此写的过程中也会提交 bug，基本上在进入封测前我们的用例可以全部写完，等到封测就可以运行起来了！不过这个还是要有人，现在项目多了我们基本是 1.5 个人在一段时间内全职加脚本

个人觉得这样子组织的优点是对返回结果的校验比较全面，添加用例比较快（在 combo api 中的关键字可以大幅度加快我们用例的添加速度），缺点是...个人觉得层次是不是多了点熟悉需要点时间，另外校验的关键字也封的比较重（原本需要好几步写出来的都给封成一步做完，这样就不如一步一步做起来好理解～）

好像写的也不是很清楚～大家随便看看吧也不知道能不能帮助到大家～

求工作～有老板收留吗...