网站性能测试：页面从几十到上千后，哪些测试工作必须从手工改为脚本化
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /29fabb78a7f7.html
📄
网站性能测试：页面从几十到上千后，哪些测试工作必须从手工改为脚本化
页面数量跨过某个门槛后，手工逐页测速会从“可靠”变成“不可靠”：样本覆盖不全、复测时间不一致、结论无法回溯。判断标准不是页面总数，而是“同一类页面是否出现多种实现、是否由不同人维护、是否需要在每次发布后重复验证”。只要满足其中两条，手工测试就该让位给脚本化流程。
先看一个假设情境：从 40 页到 1200 页
假设一个站点最初只有 40 个页面，模板统一，编辑每次改版后手动打开首页、分类页、详情页各一个，用浏览器开发者工具看加载时间，记在表格里。这套做法在小规模下成立，因为页面之间的差异小，一个样本能代表一整类。
当站点扩展到 1200 页，问题开始出现：详情页由三套不同模板生成，图片来自两个不同的存储位置，部分页面嵌入了第三方组件。此时再手工测三个样本，测到的只是“最干净的那一版”，另外两套模板的问题不会被发现。更麻烦的是，每次发布后要重复这套动作，人力成本随发布频率线性上升，而覆盖度反而下降。
这个情境的关键不是“页面变多了”，而是“同类页面不再同质”。手工测试的隐含前提是样本可代表整体，一旦这个前提被打破，继续手工做就是在一个错误假设上投入时间。
哪些性能测试工作不再适合手工
以下三类工作，在规模化后手工做的边际价值会迅速下降：
- 重复性基线采集。每次发布后对同一批页面重新测首屏时间、可交互时间。手工测的误差来自网络波动、缓存状态、机器负载，同一页面两次结果可能相差很大，无法判断是代码变化还是环境噪声。脚本化加固定环境能把变量压到可比较的范围。
- 多模板覆盖测试。当详情页、列表页、活动页各有多套实现时，手工只能测到少数几套。需要按模板类型分组，每组固定抽若干 URL，由脚本批量跑，才能发现“某一套模板整体偏慢”这类问题。
- 发布前的回归对比。手工测试很难做到“和上一版同一条件对比”。脚本化可以保存每次结果，发布后直接比对新旧数据，把“感觉变慢了”变成“某个资源体积增加了”。
反过来，以下工作仍适合手工做，不要急着自动化：首次探索一个新页面的性能瓶颈、判断某个第三方组件的实际体验、确认一个异常是否只在特定设备或网络下出现。这些任务依赖人的判断，脚本只能执行预设动作。
一个可操作的判断动作：先做模板分组
在决定是否脚本化之前，先做一件事：把站点页面按“生成方式 + 主要资源来源”分组。假设分完后得到 6 组，其中 3 组各有超过 100 个页面，另外 3 组各不到 20 个。
这个分组结果直接决定下一步：页面多且同质的那 3 组，适合固定样本、脚本批量测、结果存档；页面少或差异大的那 3 组，继续手工测更划算，因为写脚本和维护脚本的成本可能高于手工。分组不是一次性工作，模板改版后需要重新核对，否则脚本测的可能是一套已经不存在的页面结构。
这个动作的结果会影响后续决策：如果分组后发现某一组页面数量虽多但访问量极低，那么优先测的是“数量 × 访问占比”高的组，而不是页面数最多的组。性能测试的资源应该跟着用户实际到达的页面走。
脚本化之后，哪些判断仍然不能交给脚本
脚本能稳定输出数字，但不能替你判断数字是否重要。例如脚本报告某类页面首屏时间从 1.8 秒变成 2.3 秒，这个变化是否值得处理，取决于这类页面的访问占比、用户在该页面的下一步动作、以及变化是否来自一次有意的功能增加。
另一个边界是：脚本测的是“加载”，不是“用户是否找到内容”。一个页面加载很快但主要内容需要点击展开，脚本不会报告这个问题。抓取、索引和排名是不同环节，性能测试只覆盖其中一部分体验信号，不能把加载数字直接当成获取效果的结论。
因此合理的分工是：脚本负责重复、覆盖和对比，人负责定义样本、解释异常、决定是否值得改。把脚本结果直接当成“必须优化”的清单，会把时间花在数字波动上，而不是用户能感知的问题上。
规模化后手工测试唯一还该保留的位置
保留一个手工环节：每次大改版后，由一个人用真实设备、真实网络打开关键路径上的几个页面，记录主观感受和脚本没覆盖到的异常。这个环节的价值不在于数字，而在于发现“脚本没测但用户会遇到”的问题，比如弹窗遮挡、按钮点不到、内容加载顺序错乱。
这个手工环节的样本要少而固定，并且和脚本结果对照看。如果手工发现的问题脚本完全没有反映，说明脚本的测试项需要补充；如果手工感受和脚本数字长期一致，说明脚本的覆盖是可信的。到这里，网站性能测试的分工才算稳定下来：脚本管重复和覆盖，人管定义和判断。
