接口该如何测？
在讲如何盖楼之前，要先理解一下这个问题：接口到底该怎么测？（刚好有童鞋在群里问起，就在这里稍微说明下）给你个接口URL，在浏览器或工具中发起请求，得到一个返回结果，接口请求的过程就这么简单，那么如何测试呢？要注意哪些细节？通常接口测试的关注点可以包含下面几个部分：
1、接口请求参数部分：参数部分其实就对应用户环境的各种操作场景，针对接口的参数，可以设置各种用例及组合用例，简单的举个栗子：比如一个查询起始日期参数，就可以设置成今天、昨天、明天、跨月、跨年、边界日期（1970-01-01、0000-00-00、2月29、12月31等）、日期格式验证（yyyy-MM-dd、yyyyMMdd、yyyy/MM/dd、yyyy_MM_dd等）、非法日期验证（特殊字符、null、空格等）等几十种用例。
2、接口的返回结果部分：返回结果的验证，前面已有文章详细说明，如有需要可以参看前几个章节的文章，这里就不赘述了。
3、接口的协议、版本兼容等，这里就属于接口兼容性测试的范畴，比如请求协议，可以是HTTP或HTTPS（通常支持HTTPS的都会兼容HTTP，反之不成立），接口版本是否遵循向下兼容原则等。
测试设计
很多人不知道接口测试如何下手，其实是不知道如何做接口测试设计……上面提到了接口请求参数可以设计组合成多种用例，那么接口测试的用例该如何设计？
做过功能测试的相信都会写过测试设计，自动化测试也需要做测试设计，但这里的测试设计不需要像功能测试的测试用例那么详细，参考功测试设计的用例大纲那种粒度即可（通常用xmind脑图写）。也举一个浅显的例子吧，比如按日期查询这个很常见的功能（假如接口url类似：http://api.test.com/query?startDate=&endDate=），对应的接口用例如何设计？下面用脑图简单发散了一下：
测试设计是测试工程师的基本功，如果觉得写这个还有困难的话，那就要补补基本功了，多写几次测试用例练习下测试思维，基本上问题就不大了。
用例组织
测试设计好了以后，我们要将设计转换成一条条用例数据，这些用例数据放在哪里？这通常要分情况而定，没有很教科书式的答案，按自己喜欢也行，总之，循序原则：便于维护和管理，所以通常可以将用例数据放在：
代码中，不推荐，除非是很简单的用例数据；
文本文件中，同样是适合比较简单的用例数据，通常是存一个字段比较好（key-value形式）；
json文件中，比较推荐，可以存储多个字段，解析也方便快捷，便于维护，但数据不太直观，不便于结果的回写；
excel文件中，推荐，可以存储多个字段，数据直观，便于结果和状态的回写，但读写解析相对来说要麻烦些；
mysql数据库中，推荐，推荐用轻量级的数据库，可以存储多个字段，数据直观，便于结果和状态的回写，读写解析也简单，但存在数据库维护成本；
上面列举了常用的方式，大家可以根据自己的需要和喜好去选择，反正怎么方便怎么用，下面我贴一张我之前项目中用到的excel用例结构出来：
测试方法管理
上面用例组织好了之后，编写对应的测试方法代码，请求的参数和url从用例数据中读取即可，如需要回溯测试，可以将实际请求的url及结果等信息回写到excel或DB中。然后这些测试方法代码该如何管理？这个问题相信大家都知道了吧，直接用现成的测试框架Junit或TestNG，推荐TestNG，为啥？具体原因可以去搜我之前分享过的关于Junit和TestNG对比的文章（怕有人找不到还是贴一下：因为 TestNG 在参数化测试、依赖测试以及套件测试（组）方面功能更加强大。TestNG 意味着高级的测试和复杂的集成测试。它更加的灵活，特别是对大的套件测试。另外，TestNG 也涵盖了 JUnit4 的全部功能。那就没有任何理由去使用Junit了）。
ok，这一章节就写这么多吧，没有贴代码了，因为这些都是要靠自己实践才能掌握的东西，唯一可能要代码提示的地方，我觉得可能就是对json、excel或mysql读写的解析代码了，如果需要，请给我留言，后面补上（网上一搜也一大把，所以推荐自己动手）。
上文内容不用于商业目的，如涉及知识产权问题，请权利人联系博为峰小编(021-64471599-8017)，我们将立即处理。
