自动化网站测试：有用的信号，还是虚假的安慰？
像 Google Lighthouse 这样的工具能在几秒内完成网站检测并给出一个分数。这确实很有用——但很容易误读分数的含义。高分并不总意味着网站质量好。以下是这些工具能做什么、不能做什么，以及如何从中获取真正价值的说明。
自动化测试工具的实际作用
Google Lighthouse、WebPageTest、WAVE 或 webaudits.org 上的 Audit 工具，会针对某个 URL 运行一系列自动化检查。它们测试的内容包括：
- 页面加载速度（或表观加载速度）
- 图片是否有 alt 文本
- 页面是否使用 HTTPS
- 是否满足特定无障碍规则
- 页面传输的数据量
- 基本 SEO 信号，如 meta 标签和标题结构
结果通常是一个分数——通常在 0 到 100 之间——按类别细分。看起来很权威，但问题在于它可能产生误导。
分数是代理指标，而非真相
有一个原则有时被称为古德哈特定律：当一个指标成为目标时，它就不再是一个好指标。 换句话说，针对分数进行优化，与改善分数本应反映的事物并不是同一回事。
这种情况在网站 Audit 中屡见不鲜。
开发者可以让一个页面在 Lighthouse Performance 上获得近乎满分，而真实用户访问时仍感觉很慢——因为该工具在受控实验室条件下测量指标，而非真实网络环境。一个页面可以在无障碍性上得 100 分，却对依赖屏幕阅读器的用户来说完全无法使用，因为许多真实的无障碍问题需要人工判断，而非自动化检测。Deque 的研究表明，自动化工具只能发现约 57% 的无障碍问题——其余部分需要人工测试。
高分是一个好兆头，但并不是保证。
这些工具真正无法检测的内容
自动化工具通过运行脚本来工作。它们能检查存在的内容和可测量的内容，但无法判断对用户真正重要的是什么。
以下是它们真实遗漏的内容：
可用性。 一个按钮可以足够大、色彩对比度充足，却仍令人困惑。工具无法判断用户是否理解界面。
内容质量。 文字是否有用、诚实或易读，超出了任何自动化检查的能力范围。
真实世界 Performance。 实验室测试使用固定条件。真实用户拥有不同的设备、网络连接、地理位置和浏览器状态。工具可能显示页面很快，但对你大多数真实访客来说加载却很慢。
深层无障碍性。 表单字段可以有标签（工具会检查），但描述方式可能对屏幕阅读器用户毫无意义（工具会遗漏）。
完整情境下的可持续性。 工具可以估算页面加载的碳足迹，但无法考虑页面的访问频率、是否替代了更高能耗的方案，以及服务器端发生了什么。
它们真正擅长的事
话虽如此，自动化工具仍然很有价值——尤其是在抱有正确预期的情况下使用。
反馈速度。 快速扫描可以在几秒内发现明显问题。无论是 Audit 自己的网站还是评估供应商的工作，这都很有用。
一致性。 工具每次应用相同的规则。这比人工审查更难实现。
发现回归问题。 定期运行相同的测试，你会注意到某次部署后是否有什么变差了。
开启对话。 对于非技术背景的客户，带有具体数据的工具报告，比抽象描述更容易引发关于优先级和取舍的讨论。
容易摘取的成果。 缺失的 alt 文本、未压缩的图片、没有 meta description 的页面、缺少 HTTPS、阻塞渲染的脚本——这些都是真实问题，工具能快速发现它们。
从客户的视角看
如果你在付费让人构建或维护网站，自动化 Audit 结果可以作为有用参考——但应将其视为起点，而非成绩单。
几点值得了解：
- 分数可以通过只关注工具测量的内容来刷高。要问实际改进了什么，而不仅仅是分数是多少。
- 不同工具给出不同结果。同一页面在 Lighthouse 上得 90 分、在另一个工具上得 60 分，并不矛盾——它们测量不同的内容。
- 要求提供随时间变化的对比，而不仅仅是一次性的数字。你付费的工作完成后，Performance 是否有所提升？
如果有人承诺满分 100，要对实现方式保持好奇。有些有助于提高分数的优化在真实世界中毫无益处，甚至是用一个问题换来另一个问题。
从开发者的视角看
工具速度快、成本低，且可自动化。将其纳入日常工作流程，而不仅仅是在上线前使用。
几个实用习惯：
- 在一致的环境中运行 Audit。 Lighthouse 结果因运行位置和方式而异。每次使用相同的设置（例如在部署流水线中使用 Lighthouse CI），使结果具有可比性。
- 不要孤立地修复问题。 在采取行动之前，先理解被标记的问题实际意味着什么。有些建议互相冲突，或对真实世界的影响可以忽略不计。
- 使用多种工具。 不同工具发现不同问题。结合 Lighthouse、WAVE 和人工审查，比任何单一工具都更接近真相。
- 尽可能与真实用户测试。 即使是小规模的可用性测试，也会发现任何自动化工具都无法发现的问题。
在有限预算下工作
并非每个网站都有资源进行完整 Audit、一轮用户测试，以及修复所有问题的开发冲刺。这没关系。关键是如何确定优先级。
一个有用的框架：哪些问题造成真实危害，哪些容易修复？
| 优先级 | 问题类型 | 示例 |
|---|---|---|
| 优先修复 | 高影响、低投入 | 缺失 alt 文本、无 HTTPS、断链 |
| 计划处理 | 高影响、较高投入 | 全站色彩对比度差、服务器响应慢 |
| 降低优先级 | 低影响、高投入 | 对用户无实际效果的微小分数提升 |
| 暂时跳过 | 低影响、低投入 | 仅影响分数而无其他效果的调整 |
从对真实用户最重要的事情开始。对于无障碍性，通常意味着确保核心功能（导航、表单、关键内容）在不使用鼠标和使用屏幕阅读器的情况下正常工作——再考虑边缘情况。对于 Performance，修复一张 4 MB 的图片比微调缓存头部更有价值。
预算紧张时，结构化的 Audit 可以帮助确定首先处理什么。webaudits.org 上的工具可以提供跨多个类别的概览——可持续性、Performance、安全性、SEO 和无障碍性——让你在决定投入精力的方向之前，先了解最大的差距在哪里。
如何处理 Audit 结果
Audit 报告只有在有人付诸行动时才有用。以下是一个简单的处理方法：
- 分类。 梳理发现的问题并分类：严重、重要和次要。
- 理解后再修复。 对每个问题，确保你理解其在实践中的含义。有些被标记的项目是真实问题，有些是误报，有些是真正的取舍。
- 估算投入。 时间有限的小团队需要知道哪些修复是快速见效的，哪些是需要投入的项目。
- 修复并验证。 做出更改后，重新运行 Audit。确保问题真正得到解决——而不仅仅是分数上升了。
- 养成习惯。 一次性 Audit 只是一个快照。定期检查能在新问题变得严重之前发现它们。
有用的工具，而非答案
自动化测试是一种输入。它比人工审查更快、更便宜。它能持续地发现特定类型的问题。但它测量的是可测量的内容，而非最重要的内容。
将其作为起点。结合人工测试、真实用户反馈和常识。对分数保持怀疑——包括高分。
目标不是更好看的数字，而是更好的网站。
关于自动化网站测试的常见问题
自动化测试工具会引发许多实际问题——尤其对于初次接触网站 Audit 的人。以下是最常见问题的解答。