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