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

自动化的终目标是什么？

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

能否/怎样自动验证？

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

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

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

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