引言：

不知不觉中成为一名测试攻城狮已将近7年之久，在这期间做过不少API接口测试。最早接触的API接口在项目中称之为（webservice)，期间走了不少弯路。也收获了不少的经验，现分享下在测试的路上走过的坑。

第一阶段小白初体验：

初始接触API是在11年，第一次接触API接口一脸的懵逼，很茫然不知如何下手测试，对http网络协议也不了解。后来由研发同学提供对应接口web界面，测试时进入对应接口界面，在textbox输入对应参数值提交后查看返回值。但刚幵始一脸懵逼，返回值也不清楚是否正确，每次都是把研发同学叫过来直接看结果。严重耽误了效率,后来不断的自我反思，在研发同学的不断讲解API知识。不断前行最终自己可以独立测试，虽然中间过程也比较坑。比较囧(在这里特别感谢研发的同学非常耐心的讲解API知识，也非常感谢大芽同学的帮助）

第二阶段菜鸟阶段

经过不断的摸索和不断学习API知识，提高自己。从http网络协议入手，到一次网络请求的工作过程。如下图

HTTP网络协议，目前常用的请求类型：POST；GET；PUT等。目前用的比较多的是POST,GET这2种。一般涉及到写操作使用POST请求，只是读操作使用GET请求。

通过不断测试API接口和阅读API接口开发文档，总结经验设计API功能测试用例。例如初始时设计发表评论接口：设计Case如下

1. 有Userid，有评论内容；

2. 无Userid，有评论内容；

3. 有Userid，无评论内容；

4. 无Userid，无评论内容；

5. 有Userid,有评论内容（查询数据库，是否存储一致）；

6. 有Userid,评论内容等于限制数7.有Userid,评论数大于限制数。

用例设计完成，剩下的就是执行用例。不断的总结经验，根据发现的Bug，补充自己的测试用例。在测试过程中发现了Bug,尽量描述全。把请求的参数，以及返回的参数全贴到Bug描述里面，这样研发在复现Bug，也很节省时间。这样也是提高了大家的工作效率。使用Excel比较不错，设计用例时候排列组合就好。

第三阶段工具运用：

在繁重的测试过程中发现这种由研发提供的web界面方式效率比较低下，回归测试时非常不便捷。测试数据每次都要重新输入，增加了大量的重复工作。每次回归测试都需要消耗大量的时间，主要是测试数据的管理在WEB页面没办法保存。通过网上查找和同事咨询，引入了接口测试工具SoapUI。在SoapUI中创建API的项目，添加对应API接口。创建API接口测试用例，把测试数据配置好就可以了。在执行测试任务时，执行对应的API接口测试用就可以了。使用SoapUI后重复输入的工作解放了出来。提高了非常不错的工作效率，节省了不少工期.

第四阶段菜鸟业务提升

在测试过程发现自己设计的用例，数量上太过于庞大。而且大多数用例都是用来测试接口本身，反而忽略了接口本身的业务。

例如login接口，设计功能用例：

1. 有帐号，有密码；

2. 有帐号，无密码；

3. 无帐号，无密码；

4. 无帐号，无密码；

5. 有帐号，有密码（登录用户，与数数据库校验一致）。

但实际的用户可不单单一类用户，按照注册来分可以分为新注册用户，老用户。按照权限来分比如京东，分为普通会员，铜牌会员、银牌会员、金牌会员、钻石会员。所以实际测试需要测试这2大类用户登录。这个时候需要提炼出实际业务测试用例，实际的业务有的是不单调一个接口，是多个接口组成。中间还涉及到B接口需要从A接口获取参数。

设计业务用例：

1. 新注册会员登录；

2. 普通会员（老用户）登录；

3. 铜牌会员登录；

4. 银牌会员登录；

5. 金牌会员登录；

6. 钻石会员登录；

7. 非注册用户登录。

确定了测试用例，剩下的就按照测试用例执行就可以了。

作者：collar

原文链接：https://www.cnblogs.com/collar/p/6402726.html