引言：
不知不觉中成为一名测试攻城狮已将近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.非注册用户登录。
确定了测试用例，剩下的就按照测试用例执行就可以了。
