我不再教团队写 XPath：一次关于自动化测试“可持续性”的判断
很多团队都会经历一个阶段：
自动化脚本越写越多，但真正愿意维护的人却越来越少。
表面看，这是技术问题；
但站在管理和交付的角度看，它更像是一个责任分配问题。
一、我不是否定 XPath，而是不再把它作为“起点”
XPath 本身并没有错。
它精准、表达力强，在单点问题上非常有效。
但问题在于：
当 XPath 成为团队学习自动化测试的第一课时，事情就开始偏了。
我见过太多新人，进入自动化测试的第一步，不是理解业务流程，
而是在 DOM 结构里“猜”一个元素能不能活过下次前端改版。
这并不是一个可持续的起点。
二、维护成本不是技术债，而是组织债
在真实项目中，自动化测试失败，往往并不是因为用例逻辑错误，
而是因为页面发生了完全合理的变化。
比如：
- 前端组件升级
- 页面结构调整
- 样式或层级重构
这些变化，本身并不代表产品质量问题，
但它们却会瞬间让一批脚本失效。
当这种情况反复出现，团队会自然形成一种隐含共识：
自动化测试，是“有人盯着”的系统。
一旦需要长期人肉兜底，它就不再是资产，而是负担。
三、如果一条用例只能由写它的人维护，那它就不是资产
这是我后来反复验证过的一个判断。
如果一条自动化用例：
- 只能由原作者理解
- 只能由原作者维护
- 一旦环境变化就需要人介入
那它的生命周期，其实和手工测试差别并不大。
真正可规模化的自动化测试，
应该降低的是参与门槛，而不是提高技巧门槛。
从管理视角看，这是在决定：
自动化测试是“专家依赖”，还是“组织能力”。
当一个新同事加入团队，他应该先学会：
- 业务路径是什么
- 验证目标是什么
而不是先学会写 XPath。
四、工程上的转变：从“怎么点”到“想做什么”
后来我开始有意识地调整自动化测试的重心。
不是让大家写更复杂的定位，
而是尽量让用例表达停留在：
- 用户做了什么
- 我想验证什么结果
至于“具体怎么点”，
不应该成为每一条用例都要重复承担的负担。
在工程层面，这意味着：
- 用例描述应优先于定位细节
- 执行系统需要具备一定的容错能力
- 不稳定性应该由系统吸收，而不是由人兜底
五、自动化测试的难点，从来不在“会不会写”
而在于：
出了问题，谁负责？
如果每一次页面调整，都需要人工介入修脚本，
那无论脚本写得多优雅，
它都很难成为真正的工程资产。
我不再教团队写 XPath，
并不是否认它的价值，
而是希望把团队的精力，
投入到那些更不容易失效的事情上。
这是我目前对 Web 自动化测试的判断。
它未必适用于所有团队，但在规模化之前，值得被认真对待。
