自动化测试、功能测试、性能测试

刚入行做测试，最容易把几个词搅在一起：功能测试和自动化测试好像是一回事，性能测试又总被当成「跑得慢就测一下」。结果需求谈不拢、用例写跑偏、工具也选错。这篇按「测什么、谁来跑、什么时候跑」三个维度把三者的边界拆开，给出判断标准和上手动作，让你拿到一个测试任务时知道该归到哪一类。

刚入行做测试，最容易把几个词搅在一起：功能测试和自动化测试好像是一回事，性能测试又总被当成「跑得慢就测一下」。结果需求谈不拢、用例写跑偏、工具也选错。这篇按「测什么、谁来跑、什么时候跑」三个维度把三者的边界拆开，给出判断标准和上手动作，让你拿到一个测试任务时知道该归到哪一类。

先记住一句话：功能、性能说的是「测什么」，手工、自动化说的是「怎么测」。这是两组互相交叉的分类，不是并列的三个东西。搞混这一层，后面所有讨论都会打结。

三者到底在测什么：按「被测对象」划边界

功能测试

看行为对不对：给一组输入，输出符不符合预期，不关心跑多快、是不是脚本在跑。

性能测试

看同样的行为代价多少：响应时间、吞吐、资源占用，前提是功能已经正确。

自动化测试

看由谁执行：脚本、框架、CI 里跑的用例都算，它可以是功能，也可以是性能。

这张表想说的是：一个用例可以同时是「自动化 + 功能」，也可以是「自动化 + 性能」。判断一个任务属于哪类，先问它验证的是正确性还是速度，再问它是谁执行的，两个问题分开答，别叠在一起。如果你需要查具体工具和模型资料，可以去 工具目录（/tools） 看看各家是怎么分类的。

什么时候该自动化，什么时候别硬上

• 适合自动化：回归频繁、步骤稳定、输入输出可断言、需要反复跑的用例。
• 不适合自动化：界面还在大改、需求三天一变、结果要人判断好不好看（排版、语气、主观体验）。
• 判断顺序：先问这条用例未来还会不会跑，再问断言能不能机器判定。
• 成本要算清：写脚本、维护脚本、修误报都是成本，人手紧、迭代快的团队手工回归往往更划算。

1. 第一步：数回归次数翻一下最近几次上线的回归清单，同一条用例被重复执行过几次。只跑过一次的，先别写脚本。
2. 第二步：检查断言可行性把预期结果写下来，看能不能用相等、包含、阈值这类机器判断表达。写不出来的，先归手工。
3. 第三步：算维护成本估一下界面或接口改版时这条脚本要改几行。改起来比重新点一遍还费劲的，就不值得自动化。
4. 第四步：设退出条件给脚本定个标准，比如连续几次误报就要人复核，避免堆一堆没人信的用例。

这里说的「不适合」，不是永远不自动化，而是这个阶段先用手工探路。等界面稳定、需求收敛、断言能写清楚，再把这批用例转成脚本，顺序反了就是白写。团队越小、迭代越快，这个判断越重要，别拿自动化当面子工程。

性能测试的前置条件：别在功能没稳的时候测

性能测试最常踩的坑，是功能还在改就急着压测。这时候压出来的问题，一半是功能本身的 bug，你没法定性到底慢在哪。先把功能跑通、结果稳定，再进入性能环节，这是硬前提。

• 先有明确指标再开测：响应时间上限、目标并发数、可接受的错误率，指标来自业务预期而不是工具默认值。
• 环境要对齐：本机压出来的数和线上差得远，压测环境、数据量、网络链路要尽量接近生产，差别写进结论备注。
• 区分压测意图：摸底找瓶颈、验证容量上限、回归对比版本差异，目标不同，脚本和观察点也不同。
• 先量基线：用 接口测速（/tools/speed-test） 这类工具先把单次请求的延迟跑出来，再看并发下的变化，不然数字没法解释。

还有一点常被忽略：性能测试也要自动化，但它的「自动化」是工具驱动的持续压测，不是把功能用例脚本化。两者都叫自动化，目标和产物完全不同。想对比不同服务商的实测数据，可以去 排行榜（/rankings） 看当时的结果，别用记忆里的旧数字做判断。

拿到一个测试任务，按这个顺序归类

1. 第一步问「验证什么」是行为正确性、速度容量，还是执行方式？答案决定任务归到哪一类。
2. 第二步问「跑几次」只跑一次看结果偏手工功能测试；反复跑且断言固定，就可以考虑自动化。
3. 第三步问「错了会怎样」错一次就出事故的路径优先补自动化回归；影响可控的补手工抽查。
4. 第四步定观测项功能测试记输入输出和实际结果，性能测试记延迟分位、错误率、资源曲线，别混在一张表里。
5. 第五步选工具归类之后再挑框架和平台，先定类型再选工具，反过来容易被工具牵着走。

这个顺序的关键在于：每一步的答案会排除掉一些选项。比如第四步定完观测项，你自然就知道该用功能用例管理工具还是压测平台，不用再纠结。归类清楚了，跟产品、开发对齐需求也顺畅得多。

分不清该用哪种测试，往往不是工具问题，是没先问清楚「这次要验证什么」。