接口自动化测试（九）：测试用例管理

前面的系列文章已经将接口（API）自动化测试的理论和基础请求框架、数据验证等知识面介绍完了，这就好比已经给你砖和钢材木板等基础物料，那么怎么用这些基础物料去搭建高楼大厦呢？

接口该如何测？

在讲如何盖楼之前，要先理解一下这个问题：接口到底该怎么测？（刚好有童鞋在群里问起，就在这里稍微说明下）给你个接口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，反之不成立），接口版本是否遵循向下兼容原则等。

测试设计

测试设计

测试设计是测试工程师的基本功，如果觉得写这个还有困难的话，那就要补补基本功了，多写几次测试用例练习下测试思维，基本上问题就不大了。

用例组织

测试设计好了以后，我们要将设计转换成一条条用例数据，这些用例数据放在哪里？这通常要分情况而定，没有很教科书式的答案，按自己喜欢也行，总之，循序原则：便于维护和管理，所以通常可以将用例数据放在：

代码中，不推荐，除非是很简单的用例数据；

文本文件中，同样是适合比较简单的用例数据，通常是存一个字段比较好（key-value形式）；

json文件中，比较推荐，可以存储多个字段，解析也方便快捷，便于维护，但数据不太直观，不便于结果的回写；

excel文件中，推荐，可以存储多个字段，数据直观，便于结果和状态的回写，但读写解析相对来说要麻烦些；

mysql数据库中，推荐，推荐用轻量级的数据库，可以存储多个字段，数据直观，便于结果和状态的回写，读写解析也简单，但存在数据库维护成本；

上面列举了常用的方式，大家可以根据自己的需要和喜好去选择，反正怎么方便怎么用，下面我贴一张我之前项目中用到的excel用例结构出来：

用例结构

测试方法管理

上面用例组织好了之后，编写对应的测试方法代码，请求的参数和url从用例数据中读取即可，如需要回溯测试，可以将实际请求的url及结果等信息回写到excel或DB中。然后这些测试方法代码该如何管理？这个问题相信大家都知道了吧，直接用现成的测试框架Junit或TestNG，推荐TestNG，为啥？具体原因可以去搜我之前分享过的关于Junit和TestNG对比的文章（怕有人找不到还是贴一下：因为 TestNG 在参数化测试、依赖测试以及套件测试（组）方面功能更加强大。TestNG 意味着高级的测试和复杂的集成测试。它更加的灵活，特别是对大的套件测试。另外，TestNG 也涵盖了 JUnit4 的全部功能。那就没有任何理由去使用Junit了）。

ok，这一章节就写这么多吧，没有贴代码了，因为这些都是要靠自己实践才能掌握的东西，唯一可能要代码提示的地方，我觉得可能就是对json、excel或mysql读写的解析代码了，如果需要，请给我留言，后面补上（网上一搜也一大把，所以推荐自己动手）。