去年某电商平台的软件一次促销活动中，攻击者通过篡改商品ID参数，测试测试以0.01元的安全价格批量下单了价值数十万的电子产品。事后复盘，软件开发团队在功能测试阶段验证了“正常ID能正确返回商品信息”，测试测试却从未尝试过“如果ID被改成负数、安全超长字符串或SQL注入片段，软件系统会怎样”。测试测试这个案例暴露了一个普遍现实：安全测试在多数团队里仍是安全功能测试的附庸，而非独立且必须的软件环节。

功能测试问的测试测试是“系统能不能按预期工作”，安全测试问的安全是“系统会不会按攻击者的预期工作”。前者验证正确路径，软件后者专门寻找非预期路径。测试测试比如登录功能，安全功能测试确认正确密码能进入、错误密码被拒绝；安全测试则要试：连续错误密码会不会锁定账户？锁定逻辑能否被绕过？登录请求里塞入SQL语句，后端是直接报错还是执行了？这些场景功能测试用例里通常不写，因为写用例的人默认用户会“好好输入”。

我见过一个内部管理系统，功能测试全绿，上线三天后被爬虫拖走了全部用户手机号。问题出在分页接口——开发用limit offset实现，但没校验offset的最大值。攻击者把offset设为0、limit设为100000，一次请求就拿到十万条记录。这个漏洞不需要什么高深技术，一个curl命令就能验证。安全测试的难点往往不在技术深度，而在于测试人员是否愿意“不按常理出牌”。

工具能帮上忙，但别指望自动化扫一遍就完事。OWASP ZAP或Burp Suite的主动扫描能发现一些常见问题，比如缺失的HTTP安全头、反射型XSS。可业务逻辑漏洞——比如越权查看他人订单、优惠券叠加使用、支付金额篡改——扫描器基本无能为力。这些需要人工分析数据流，构造特定请求。我习惯在测试环境用Burp的Repeater手动改包，把用户ID从自己的改成别人的，看返回是403还是200。如果是200且返回了数据，那就是一个越权漏洞。简单，但有效。

安全测试应该什么时候做？不是上线前一周才拉个安全团队扫一遍。那太晚了。需求评审时就要问：这个功能涉及敏感数据吗？权限模型怎么设计？设计阶段画数据流图，标出信任边界——比如从公网到DMZ、从DMZ到内网数据库。每个跨边界的调用都是潜在攻击面。编码阶段用SAST工具扫源码，比如Semgrep或CodeQL，能提前发现硬编码密钥、不安全的反序列化。测试阶段再结合DAST和手动渗透。上线后还得有RASP或WAF做运行时防护。安全测试是贯穿始终的，不是某个阶段的插入项。

人员意识比工具更关键。一个测试工程师如果不知道1' or '1'='1是什么意思，给他再好的工具也白搭。反过来，哪怕只有curl和浏览器开发者工具，只要理解“输入不可信”原则，也能挖出不少问题。我见过测试同学用Chrome的Network面板修改请求体里的userId字段，发现能查看别人购物车——这就是最朴素的安全测试。不需要等安全团队排期，自己就能干。

最后说一个反直觉的点：安全测试报告里，“未发现漏洞”往往比“发现漏洞”更危险。因为那可能意味着测试覆盖不够、攻击面没摸清，或者测试人员自己放弃了。一份诚实的安全测试报告应该写清楚：测了哪些接口、用了什么方法、哪些场景没覆盖、剩余风险是什么。漏洞数量不是KPI，风险透明才是。