打开Chrome DevTools，试工切到Network面板，试工刷新页面，试工看着那一串请求像瀑布一样滚下来。试工这大概是试工我每天用得最多的“测试工具”——虽然它本来的名字叫开发者工具。很多人找Web测试工具，试工第一反应是试工去搜Selenium、JMeter，试工但真正干活的试工时候，浏览器自带的试工这套东西才是最高频的入口。元素审查、试工控制台报错、试工网络请求耗时、试工移动端模拟，试工全在里面。试工你说它是测试工具吗？官方不这么叫，但测试人员离了它基本没法干活。

说到自动化，Selenium还是绕不开的。WebDriver协议被W3C收编之后，它更像一个底层标准，而不是一个孤立的工具。我见过不少团队直接用Selenium写脚本，也见过用Katalon、Robot Framework包一层的。Selenium本身不复杂，麻烦的是环境——浏览器驱动版本对不上，CI里跑着跑着就挂了。后来Playwright和Puppeteer出来了，自带浏览器内核，省了驱动这档子事。Playwright的自动等待机制确实省心，不用到处写sleep，但它的生态比起Selenium还是薄一些，遇到冷门浏览器或者老系统，Selenium反而更稳。

接口测试这块，Postman几乎是默认选项。不过Postman越来越重了，登录、同步、团队协作，功能堆得像个IDE。轻量一点的可以用Insomnia，或者干脆用curl加shell脚本。真正跑在CI里的接口测试，很多团队用的是RestAssured或者pytest+requests。我之前待过一个项目，接口用例全写在Postman里，导出成JSON再用newman跑，维护起来挺痛苦的——断言写起来别扭，数据驱动也不方便。后来换成代码化的方案，虽然写的时候麻烦点，但版本管理和复用性好太多。

性能测试，JMeter是常青树。图形界面拖拖拽拽就能生成测试计划，但真正要压出有意义的场景，还是得写BeanShell或者用插件。JMeter的硬伤是GUI模式消耗资源，压测时得用命令行。k6这几年势头挺猛，用JavaScript写脚本，跑起来轻量，结果输出也干净。Locust用Python，分布式压测方便，但报告界面简陋。选哪个，看团队技术栈——让一群Java的人去写k6脚本，学习成本也是成本。

抓包工具里，Fiddler和Charles各占半壁江山。Fiddler只有Windows版，Charles跨平台但收费。Wireshark更底层，能看到TCP握手，但解HTTPS得配证书，日常测试用得少。我习惯用Charles，主要是Map Local功能太顺手了——把线上JS映射到本地改过的版本，不用重新部署就能验证前端修复。这个场景在测试环境不完整的时候特别有用。

单元测试框架和Web测试经常被分开聊，但前端项目里Jest、Vitest跑组件测试，后端用JUnit、pytest跑接口逻辑，这些也是Web测试的一部分。覆盖率报告一出来，哪些分支没走到一目了然。不过覆盖率数字好看不代表质量好，我见过追求100%覆盖写出一堆无意义断言的，维护成本比收益还高。

还有一类工具容易被忽略：无障碍测试。axe-core可以集成到Playwright或者Cypress里，自动扫描页面的ARIA属性、对比度问题。Lighthouse也带无障碍审计。国内项目里这块做得少，但出海产品或者政府项目，WCAG合规是硬指标。手动测的话，键盘Tab一遍走下来，问题基本就暴露了。

工具列不完，也没必要列完。关键是想清楚要解决什么问题——是回归太慢要自动化，还是线上出过事故要加监控，还是性能瓶颈找不到要压测。工具是手段，不是目的。我见过团队花两周搭了一套Cypress，结果用例就写了三条，后来没人维护，CI里那个job一直红着，大家默契地把它禁用了。那还不如老老实实写个checklist，每次发版前人工过一遍。