接口测试是项目测试的一部分，正如其名，它测试的主要对象是接口，是测试系统组件间接口的一种测试。接口测试主要用于检测外部系统与所测系统之间以及内部各系统之间的交互点。测试的重点是检查数据交互、传递、和控制管理过程以及系统间的相互依赖关系等。
接口测试一条请求，不同参数组合，可能就变成几十条用例，一不小心写几个接口，用例数就上百了，再没完没了的写下去就恶心了。怎么办？
在设计测试用例时候我们可以根据项目业务功能情况进行主次分析后，划分优先级，先正向思路，再反向，进行归类划分，最后有时间再考虑是否要编写那些优先级比较低的用例，必要的时候可以画下思维导图，思路清晰了再进行编写。
在执行的时候也按优先级情况进行执行，整个层次就分明了，用例的管理及维护也变得轻松起来。
1.测试用例的等级划分
下面是我在实际测试过程中总结的等级顺序：
1) 主体业务功能接口正常典型值用例的优先级为1（用于冒烟测试的用例）
2) 各模块主功能的正常典型值用例的优先级为2
3) 除了的正常典型值用例之外的正用例及所有异常用例的优先级为3
4) 可用性测试以及入参默认值以及开发做了限制处理的参数类型、开发自测容易发现的错误等测试的优先级为5，最低优先级
当然以上写下来你会发现还是好多啊，这时候应该思考下你设计的这些部分用例是否是真的有实际意义？有没有考虑到实际用户使用场景、需要？是否有可能会出现这种场景？程序员对于这些字段有没有做了限制，他们是不是保证不会犯这样那样的错误，如果他们已经做了控制保证不会出现你设计的哪几种异常情况，你还何必多此一举？四不四？
这时候你可能说，不对啊，测试的时候，我的上级就跟我说要根据测试方法组合一下，各种情况都测一下，你那是UI层测试吧。接口测试用例的设计不是业务层，不能纯根据数学的排列组合，还要根据实际情况做一下减法。
2.测试用例的筛选
So…我们需要对用例做一次筛选，接口测试属于更底层一点的测试，当然所有手工测试方法都用的上，但接口参数数据需对每个参数根据测试接口的实际的功能进行分析，需要符合业务逻辑的情况下进行逻辑组合排列，有些情况，本身通过代码的设计，做了些限制，错误是不会出现在UI层滴
根据测试方法以及上一篇博客写的关于数据设计写出用例，做一下如下筛选：
1) 剔除不重要的接口
2) 异常系用例根据是接口本身兼容异常情况还是有前端控制进行去留
3) 根据接口文档，实际业务情况，场景，接口要实现的功能进行选择
4) 开发协助再筛选一遍
3.测试原则
1) 基础配置，如域名，环境配置等，单独文件配置，方便不同环境测试，脚本维护
2) 明确接口实现什么样的功能，实际需要什么样的功能。是否一致
3) 接口测试数据太多，用数据驱动模式更有层次，且易维护
4) 要众多用例中选出冒烟测试用例及可用于性能测试的用例
5) 先单接口测试，在多接口业务测试
6) 测试完成后，需要清理脏数据
如何设计接口测试用例？
首先，明确出发点。和所有的测试一样，接口测试出发点是你要证明所测的程序是错误的。以这个出发点为导向，你的设计行为就会尽量朝这个方向发展，更易发现问题，不会出现大方向的偏差。
其次，选择好测试对象。对于一个系统做接口测试选择好的测试对象是接口测试关键。一个系统有无数的接口，每个接口如果分别测试，那将是很痛苦的一件事情，不光繁琐浪费，而且任何一个内部接口的变动，都将导致我们用例的不可用。
这里推荐把整个系统作为一个整体，选择整个系统提供给外部使用、交互的最外层接口作为你的测试对象，以此为测试对象的用例将有很好的健壮性，并且更高效。
另外，根据数据的流向，又可将这些最外层的接口分为两类：一类是数据进入系统的接口；一类是数据流出系统的接口。
进入系统的接口实际是我们用例的执行调用的接口。可通过变化参数对这些接口进行调用，模拟外部的使用；而流出的接口则是我们用例真正该验证的点。
数据从哪里流出，流出时的状态如何，此时系统又是什么状态都是我们所应该验证的。
最后感谢每一个认真阅读我文章的人，看着粉丝一路的上涨和关注，礼尚往来总是要有的，虽然不是什么很值钱的东西，如果你用得到的话可以直接拿走
这些资料，对于做【软件测试】的朋友来说应该是最全面最完整的备战仓库，这个仓库也陪伴我走过了最艰难的路程，希望也能帮助到你！凡事要趁早，特别是技术行业，一定要提升技术功底。希望对大家有所帮助…
