自动化测试、性能测试、安全测试

刚接手测试的人常卡在同一个地方：需求说要「测一下」，但到底是写脚本回归、压一遍接口，还是查权限和注入，完全没概念。更麻烦的是三类测试的目标、工具和产出物都不一样，混着做既费力又说不清结果。这篇按「解决什么问题、什么时候该上、不用它的场景」把三者拆开对照，最后给一个按项目阶段排的落地顺序。

刚接测试的人最常卡在一句话上：需求说「测一下」，但到底该写脚本回归、压一遍接口，还是查权限和注入，脑子里没有分类。这三类测试的差别其实不在工具，而在它们回答的问题根本不一样。

自动化回答「同样的流程能不能不用人再跑一遍」，性能回答「人多起来扛不扛得住」，安全回答「规则会不会被人绕过去」。目标不同，评判标准、产出物、什么时候上都不一样。混着做，最后既说不清结果，也说不清哪一步该先做。

三类测试到底在解决什么问题

先记住一条：自动化不会替你发现全新问题。它只保证你已经知道对的地方，下次改代码时还是对的。指望靠脚本找出没想过的边界情况，方向就错了。性能和安全反过来，它们的主要价值恰恰是暴露你没预料到的情况。

有并发预期时，第一步不是直接调大压力，而是先量基线。到接口测速（/tools/speed-test）看当时的延迟和吞吐数字，把它当作后续对比的起点，否则你没法判断优化有没有效果。

第一步：手工走通主流程把稳定的操作步骤逐条记下来，包括输入、预期结果、异常提示。这套步骤既是自动化脚本的输入，也是性能脚本的基础，没有它就无从写脚本。
第二步：按业务风险排自动化挑出错代价最高的几条先自动化，比如登录、下单、数据提交。跑通一条再补下一条，不要一上来追求覆盖率数字。
第三步：功能稳定后再压接口压之前先确认限流和超时阈值，再分档加压。口径不清楚容易误判，可以到基础设施术语速查（/ai-dict/category/infra）对齐定义。
第四步：补安全用例从越权和输入校验入手，每轮发版前跑固定的几条。不做全面渗透，那是另一套工作量和授权流程。

顺序的核心逻辑是：手工步骤没固化成文档，后面两类测试都没有可信输入。很多团队跳过第一步，结果脚本写出来跟实际业务对不上，压出来的数字也不知道在压什么。

测试类型	合格产出物	不合格的信号
自动化	无人值守跑完并给出失败清单，失败能定位到具体步骤	只报错退出，看不出哪一步挂了
性能	分档数据：正常量、峰值量、超限量的响应与错误率，以及瓶颈层	只给一个「通过」或「有点慢」
安全	带复现步骤的问题清单，写清影响范围和修复建议	没复现路径的问题描述

三类测试都要留版本对应关系：这一轮测的是哪个代码版本、哪套环境配置。否则下一轮结果不一致时，你分不清是代码变了还是环境变了，排查会拖很久。

安全测试还有一点常被忽略：能不能做、做到什么程度，取决于有没有授权。没拿到书面范围就上手扫，本身就是风险。初学者先从自己负责的模块和只读检查入手，别越界。

一个人做测试，三类都要会吗？

不用同时精。先按业务风险排序：没有对外接口和并发压力的项目，把自动化跑顺就够用；有用户数据和登录体系，就把安全用例补上。性能测试通常等项目有明确并发预期再深入，否则容易做出没人看的报告。

自动化测试能替掉手工测试吗？

替不掉。自动化擅长的是「同样的流程反复跑」，判断界面好不好看、流程顺不顺、异常提示是否清楚这些事还是得人来做。比较实际的分工是手工先探路并写清步骤，稳定之后把其中重复度最高的那几条交给脚本。

性能测试和压力测试是一回事吗？

说法上常混用，实操里区分的是目的：一类是测出系统在预期负载下的表现，另一类是不断加量找崩溃点。做之前先明确你要的是哪个答案，否则参数设错，跑出来的数字没法解释，也没法指导优化。