谈到自动化测试方面的误区，不少文章倾向于从人性、管理、职业规划等方面进行探讨。我这次专门从计划、设计、实现、维护等技术角度总结一下。

自动化的最终目标是什么？

很多人以为是像工业革命一样消灭手工劳动者，在这里等于手工测试人员。但是测试存在一个目前来看还算正确的、其他行业不多见的悖论：任何时候，你都不能准 确知道还有多少bug，就像警察不能准确知道还有多少贼一样。所以自动化的最终目标——目前来说——是解放尽量多的人手去进行更多的测试，除非有一种手段 能像《少数派报告》里面的预言少女一样预知所有的bug。因为永远有bug，有未知的bug，所以目前不存在能覆盖所有bug的手段，这意味着总需要人的 参与。现代化手段只是减少了而不是杜绝对人员的需求。所以如果认为自动化工作一做完就没活干，那你就大错特错了。正认为这些人闲下来，他们有空发现更难发 现的bug。这本来没什么大不了的，但是搁在计划阶段如果过分乐观，牛皮吹得太大的话，到后面就不容易圆回去了。因为按上面分析，自动化测试总有些地方是 力有不逮的，如果这些地方没有安排好人手时间，只要在这些地方出大问题，那你就玩完了。

能否/怎样自动验证？

这个问题每次复审测试计划的时候我都会问，针对每一个提出要实施自动化的地方。每个人、每个工具谈论自动化的时候都在说如何真实模拟用户使用产品的情况， 这很好，绝对需要关心。不过我得问一句：测试的最后结果是什么？如果你回答“各种使用产品的场景已经运行过“就嘎然而止的话，你就漏掉了一大块：最起码还 得加上“产品能工作/不能工作“！所以模拟用户使用产品的各种情况，只是解决上述问题的第一部分；如何得出测试通过/不通过的最终结论，才是解决问题第二 部分的基础部分，还有详细缺陷描述、上下文数据收集等没做到呢！

所以让机器像人一样使用产品，并没有解决全部问题，剩下的事情还有多少，这是需要视情况而定的。如果只是解决了第一个问题就认为万事大吉，那简直就是在赌运气——有些时候自动验证是小菜一碟，但很多时候不是。

令事情恶化的是，自动验证了产品的一些指标，并不能反映产品的真实质量。有时验证过的指标通过了，其实其他地方暴露了问题却没有检查：比如说界面说没有查 询结果，这是期望的，实际上查询请求根本没有发过去，不去检查底下做了什么的话是发现不了这种bug的；有时验证过的指标不通过，其实只是个小问题，大问 题需要通过别的指标暴露出来的：比如说返回结果跟预期的不一致，实际上该有的都有，只是没有排好顺序而已，但是被标记成重要的测试用例没有通过，把开发人员搞个鸡飞狗跳。

这个话题深入下去，那就涉及到白箱测试策略、逻辑推演、嗅探和代码注入以及布景伪造（environment mockup）等领域，但我想强调的只是，如果考虑自动化测试，自动验证绝对不是可忽略的问题。

整合现有还是自力更生？

这个话题用于辩论赛是最好不过的，它符合“没有定论“这个要求 。所以我只谈一下使用每种手段时的一些不正确的假设。

“现有的工具多少经过测试，质量比自己做的更有保证“。先不在“是不是更有保证”这个话题上钻牛角尖，我们先关注几个问题：整个测试方案里面哪些部分是关 键，质量不好会导致致命后果的？这些部分有专人保证质量吗？出事的时候反应时间和修复效果如何？如果这些问题的答案是“我充分了解”或者“没问题”，那我 也同意这个观点（我敢打赌，回答“不清楚”或者“很不妙”的人已经跑去重新考虑整个测试方案了）。

“整合现有的工具省时间和人力”。类似的几个问题：你能在这些工具中自由地调试产品的缺陷吗？整合方案能适应产品的演变吗？几个月后呢？几个版本后呢？有需要变动的话代价多少？（哗啦啦又跑掉一大队人了）

“自力更生好控制”。投入产出比如何？引用的技术可靠吗？如果你是开发者（之一），别人都觉得好控制吗？谁来测试你的自力更生成果？

“有些事情必须得自力更生“。剪裁现有工具难度如何？时间允许吗？

其实，纵观所有提出的问题，我想强调的一点是，自动化测试的开发跟产品开发一样，也是需要规划和管理的，回答这些问题也是自动化测试项目管理的一部分。

如何解决历史遗留问题？

折腾上个版本的自动化测试框架是新人最头疼的事情。但了解了一些事情之后，原先的事情就没那么令人头疼了。很多人忙于了解旧框架本身，其实世界一直在变，现在项目需要解决的问题才是关键。无论上个版本的东西多么辉煌，只有它适合现在的项目（的部分）才是有价值的。所以关于旧的自动化测试技术，了解什么能用得上，而不是了解它是什么，才是需要做的事情。就好像汽车修理工知道怎样拆旧车零件来修新车，并不需要他知道怎样造一辆出来或者知道怎样修好旧的那辆。

另一个极端是“旧的不好浪费，继续用“。“能用“这个结论是基于以前项目的情况的，现在能不能用，值不值得用得看现在的需求。人们要理发就是个很好的例子：总不能因为头发长出来要耗养分不好浪费，就一辈子都不剪吧？