测试用例写不好，上线就踩雷
做网络安全测试时，很多人觉得只要工具跑一遍，报告一出就完事。可真等到系统上线，某个权限绕过漏洞却被漏掉了，回头一查，发现测试用例里压根没覆盖这个场景。这种情况太常见了，问题往往不出在技术能力，而是测试用例本身就有缺陷。
用例覆盖不全，漏掉边界情况
比如一个登录接口，开发说只允许手机号登录，测试用例写了正常手机号、错误格式的字符串，看起来挺完整。但有没有试过超长字符串？或者用特殊字符拼接的输入？攻击者最喜欢这种地方下手。某次我们遇到一个系统，因为没测“+86”前缀加一堆空字符的情况，结果被用来绕过频率限制，一口气跑了上万次爆破。
边界值和异常输入必须纳入用例，尤其是涉及输入解析、正则匹配、协议处理的地方。
依赖顺序混乱，执行结果不稳定
一组测试用例里，A用例负责创建用户，B用例测试该用户的权限操作。但如果B不依赖A的结果，或者A失败了B还继续跑，结果就没意义。更糟的是，有些人把所有用例都写成独立运行，每次都要重新准备数据，效率低还容易因环境波动误报。
解决办法是明确用例之间的依赖关系，用前置条件标注清楚。例如：
用例ID: TC-1024
标题: 验证管理员可删除普通用户
前置条件: 用户admin已登录，目标用户test_user已存在
步骤: 调用DELETE /api/users/test_user，检查返回状态码
预期结果: 200 OK，数据库中test_user记录消失预期结果模糊，无法判断成败
见过最头疼的用例写着“检查系统是否正常”。什么叫正常？页面能打开算正常？响应没报错算正常？这种描述等于没写。预期结果必须具体到状态码、响应字段、日志条目甚至数据库变更。
比如CSRF防护测试，不能只写“验证不能跨站提交”，而要明确：“从外部域发起POST请求，携带合法参数但无CSRF Token，服务器应返回403，且后端未执行转账逻辑”。
忽略环境差异，本地通过生产翻车
开发环境用的是轻量防火墙，测试用例跑起来没问题。可一上预发布环境，WAF开始拦截非常规请求头，一堆用例直接失败。这时候才意识到，有些安全检测机制会影响测试行为。
写用例时就得考虑环境特性。比如在涉及请求头注入、XSS payload的测试中，提前确认WAF规则是否会影响结果判定，必要时在用例中标注“需关闭WAF或配置例外”。
用例更新滞后，文档与实际脱节
系统迭代快，接口字段变了，但测试用例还按老结构测。比如原本返回{"code": 0}代表成功，现在改成HTTP状态码控制，可旧用例还在检查code字段，导致误判漏洞不存在。
建议每次需求变更或修复漏洞后，同步评审相关测试用例。哪怕只是删掉一条过期的，也比留着误导人强。
过度依赖自动化，忽视手工探索
自动化脚本跑得飞快，一天能执行上千个用例。但有些攻击路径是脚本想不到的。比如某次发现，修改JWT中的alg字段为none，再配合空签名，居然能绕过鉴权——这种用例除非有人专门设计，否则自动化工具根本不会尝试。
自动化的价值在于重复验证，而真正的风险挖掘还得靠人。别把所有希望都寄托在脚本上，定期安排手工渗透式测试，补充用例库。