1. 冒烟测试
2. 校验业务场景【重要】
3. 再校验关键字段的，边界值（最大，最小）
4. 看返回的字段，是否符合需求
5. 为空校验，一些关键参数，必填项肯定是要校验一下，比如，客户表，客户名，手机号，如果这两个字段的数据，都没有，那么后面的业务逻辑，可能会异常，所以，该校验还是要校验必填的
6. 对于数字，金额，是否可以为 0（购买数量），是否可以小于 0（金额）

提醒：

1. 类型校验，基本上没必要，输入，字段是数字类型，你输入个字符串，其实没有必要测试，因为前端那边几乎不可能传一个字符串，除非是通过接口测试工具调用的

类型校验这个，看特性组吧，有时候还是需要的

①接口测试是否需要针对必填参数验证？感觉必填参数校验，有一个脚本就够了
需要，而且很必要，P0 用例。具体在测试执行上，如果接口的必填参数很多逐个验证很麻烦，可以按场景去写需要的脚本，爱怎么搞就怎么搞，能测好不就达成目标了么

②接口测试数据，是否要枚举，比如：长度、特殊字符、中文
异常场景用例设计主要看测试时间，如果时间非常充裕，可以测得细一点，比如你说的各种异常情况枚举。如果时间相对紧迫，没条件这样去搞，那就要例行筛选优先级，适当砍用例。当然，更好的做法是直接看研发的代码，比如代码里都写清楚了，每个接口调用前都会有参数校验逻辑，校验逻辑已经统一把这些异常情况做过处理，那就可以大大简化这些用例，只要你在一个接口字段上验证过，就没必要再到处重复了。

不写测试用例，直接测

先看需求，再看接口类型，对外提供的接口和内部使用的接口，测试策略和方案也不一样。

具体测试来说，先进行正向业务覆盖，把需求中的场景和隐含的正向场景都提取出来一一覆盖。再进行异常覆盖，必填参数验证算异常覆盖的一种。
其他测试根据需求和测试策略来。

接口测试数据，是否要枚举？——普通参数，划分等价类，比如特殊字符、中文，有时候他们是等价的，有时候又不同，根据实际处理逻辑来。（参数是枚举类型，一定要枚举，一般正常场景测试都会覆盖完所有枚举类型，如果发现枚举没有覆盖完，检查下场景覆盖是否有漏掉）

目前做法
新接口测试：基本都是通过手动调接口，手动传参数，不会用太多枚举，基本就业务主流程
旧接口回归：一条用例能通就行，不验证业务逻辑，code=正常就行

现在更多是结合客户端测试为主，接口测试为辅。