参数没校验全，线上出问题才后悔
上周同事小李上线了个新接口，本地测了几个正常情况，自动化测试也跑过了，结果一上生产，用户传了个空字符串进来，服务直接500了。查来查去，发现是自动化测试里压根没覆盖到这个参数为空的校验场景。
这种情况太常见了。我们写的自动化测试，往往只关注“能走通”，却忽略了“异常也能兜住”。特别是参数校验这一块，一旦漏掉边界情况，线上故障就容易找上门。
哪些参数最容易被漏掉？
不是所有参数都一样重要。比如一个用户注册接口，手机号、密码这些必填项通常不会忘，但像“邀请码”这种可选字段，很多人就懒得写校验逻辑，测试也就跟着跳过。还有类型错误的情况，比如期望传数字，结果前端传了字符串，后端没做类型转换或拦截，也会出问题。
再比如时间格式。你写测试时用的是标准 ISO 格式，但用户可能传 '2024-13-45' 这种明显错误的时间，系统如果没拦住，后续处理就会崩。
怎么确保校验覆盖全面？
光靠人脑想场景不靠谱。建议在自动化测试里加一层“参数风暴”策略：对每个接口的每个参数，自动生成一组异常输入，包括：
- 空值（null、空字符串）
- 超长字符串
- 非法类型（比如该是数字的传字母）
- 边界值（比如最小值减1，最大值加1）
- 特殊字符（如 <>&\"\'）
把这些作为基础用例模板，套到所有接口上，覆盖率立刻提升一大截。
用代码示例说明更清楚
比如有个创建订单的接口，接受 amount 字段：
def test_create_order_amount_validation():\n # 正常情况\n assert create_order(amount=100) == 200\n\n # 异常情况：amount 为负数\n assert create_order(amount=-1).status == 400\n\n # amount 为 0\n assert create_order(amount=0).status == 400\n\n # amount 为字符串\n assert create_order(amount="abc").status == 400\n\n # amount 超大数值\n assert create_order(amount=999999999999).status == 400\n\n # 缺失 amount 参数\n assert create_order().status == 400这几条跑下来，基本就把 amount 的坑都踩完了。别嫌麻烦，少一条，线上就可能多一个报警。
别让“看起来通过”骗了你
有时候测试用例返回 200，你以为没问题，其实接口内部把异常吞掉了，比如捕获了异常但没抛出去，日志也没打。这时候测试虽然“通过”，实际根本没有校验逻辑。
解决办法是，在测试中加断言：检查响应体里有没有明确的错误码，或者通过 mock 检查是否调用了正确的校验函数。
自动化测试不是为了跑绿灯，而是为了挡住不该放过的错。参数校验这块，宁可多写几条，也别让漏网之鱼溜到线上。
","seo_title":"自动化测试参数校验覆盖不足怎么办","seo_description":"详解自动化测试中参数校验覆盖常见的遗漏点和补救方法，避免因参数验证不全导致的线上故障。","keywords":"自动化测试,参数校验,测试覆盖,接口测试,异常处理,测试用例"}