接口测试一条请求，不同参数组合，可能就变成几十条用例，一不小心写几个接口，用例数就上百了，再没完没了的写下去就恶心了。怎么办？
在设计测试用例时候我们可以根据项目业务功能情况进行主次分析后，划分优先级，先正向思路，再反向，进行归类划分，最后有时间再考虑是否要编写那些优先级比较低的用例，必要的时候可以画下思维导图，思路清晰了再进行编写。
在执行的时候也按优先级情况进行执行，整个层次就分明了，用例的管理及维护也变得轻松起来。
1
测试用例的等级划分
下面是我在实际测试过程中总结的等级顺序：
1) 主体业务功能接口正常典型值用例的优先级为1（用于冒烟测试的用例）
2) 各模块主功能的正常典型值用例的优先级为2
3) 除了的正常典型值用例之外的正用例及所有异常用例的优先级为3
4) 可用性测试以及入参默认值以及开发做了限制处理的参数类型、开发自测容易发现的错误等测试的优先级为5，最低优先级
当然以上写下来你会发现还是好多啊，这时候应该思考下你设计的这些部分用例是否是真的有实际意义？有没有考虑到实际用户使用场景、需要？是否有可能会出现这种场景？程序员对于这些字段有没有做了限制，他们是不是保证不会犯这样那样的错误，如果他们已经做了控制保证不会出现你设计的哪几种异常情况，你还何必多此一举？四不四？
这时候你可能说，不对啊，测试的时候，我的上级就跟我说要根据测试方法组合一下，各种情况都测一下，你那是UI层测试吧。接口测试用例的设计不是业务层，不能纯根据数学的排列组合，还要根据实际情况做一下减法。
2
测试用例的筛选
So…我们需要对用例做一次筛选，接口测试属于更底层一点的测试，当然所有手工测试方法都用的上，但接口参数数据需对每个参数根据测试接口的实际的功能进行分析，需要符合业务逻辑的情况下进行逻辑组合排列，有些情况，本身通过代码的设计，做了些限制，错误是不会出现在UI层滴
根据测试方法以及上一篇博客写的关于数据设计写出用例，做一下如下筛选：
1) 剔除不重要的接口
2) 异常系用例根据是接口本身兼容异常情况还是有前端控制进行去留
3) 根据接口文档，实际业务情况，场景，接口要实现的功能进行选择
4) 开发协助再筛选一遍
3
测试原则
1) 基础配置，如域名，环境配置等，单独文件配置，方便不同环境测试，脚本维护
2) 明确接口实现什么样的功能，实际需要什么样的功能。是否一致
3) 接口测试数据太多，用数据驱动模式更有层次，且易维护
4) 要众多用例中选出冒烟测试用例及可用于性能测试的用例
5) 先单接口测试，在多接口业务测试
6) 测试完成后，需要清理脏数据
联系客服
