这些年来，自动化测试越来越受到软件测试行业的重视，呈现"蔚然成风"之势。当然，我也时不时听到或看到一些资深的测试专家对自动化测试的质疑。我理解他们的想法。因为自动化测试从来都不是银弹，它并不能解决所有的痛点。
对于测试的一部分痛点，例如回归测试，持续测试，代码质量守护等，自动化是有帮助的；对于另一部分痛点，例如需求理解，用例设计，软件缺陷定位和分析等，自动化往往爱莫能助。
即使是面对前一部分痛点，自动化测试也不是灵丹妙药。在我看来，自动化测试是一把双刃剑。运用得当，自动化测试可以给项目带来好处；运用不当，自动化测试也可以成为项目的拖累。
这能够解释行业里的一个常见现象，那就是刚开始引入自动化测试时，大家干劲十足；实践一段时间后，又因为自动化测试难以维护，有效性低等各种原因而慢慢冷落或抛弃它。
打造成功的，可持续的自动化测试，并不是一件容易事。概括地说，需要做好两方面工作，一是坚持正确的实践，二是避免错误的实践。
人们把针对共性问题的，经过实践检验广泛被证明为有效的经验做法称之为"模式"。反之，那些普遍被证明有反作用的做法则是"反模式"。今天我们就来聊聊容易将自动化测试引入失败之路的一些"反模式"。
一，依赖未经充分测试的外部组件。一个完整的测试环境或测试系统，通常由被测软件(software under testing, SUT)，基础设施(硬件，操作系统，测试依赖库，SUT运行所依赖的平台等)和测试用例三部分组成。测试的基本方法是利用测试基础设施和测试用例来发现SUT中存在的缺陷。
这个方法依赖一个基本假设，那就是测试用例和测试基础设施是相当可靠的，例如操作系统，权威的第三方工具等，而SUT是不可靠的。如果测试出现失败，那么极有可能发现了SUT的缺陷。
然而，如果基础设施中存在一个未经充分测试的外部组件，无论它是测试库的依赖，还是SUT的依赖，都会破坏这一基本假设。一旦测试过程中发现的问题有相当部分是外部组件导致的，测试的稳定性和价值都将大打折扣。
依赖未经充分测试的外部组件还有一个不好的地方，那就是这个外部组件往往处于活跃开发中，因此自动化测试系统的开发将受制于这个外部依赖的开发。这意味着我们可能无法较早地准备好自动化测试系统，以实现TDD或ATDD(验收性测试驱动开发)。
避免未经充分测试的外部依赖的有效办法是Mock。无论是单元测试还是集成测试，明确了SUT之后，SUT运行所依赖的处于开发中或者质量不可靠的外部组件都应该尽可能Mock掉。当然，Mock需要一定的开发成本，但是从长期时间窗口看，这种成本往往是值得的。
二，执行速度慢。单纯的自动化测试，意义是有限的。基于自动化测试，在开发环节针对开发提交的代码，或者在交付环节针对持续集成构建的软件包，进行持续测试并提供测试反馈才是一件有价值得多的事情。
然而，持续测试存在一个隐含的要求，那就是时效性高。因为无论在开发环节还是交付环节，时间都是很紧迫的。并且，开发或交付一般是并发的，导致持续测试的频率高，负荷重。主客观两方面都不允许一个缓慢的自动化测试存在。
提升自动化测试速度的技术手段有很多，例如并行测试，选择性测试等。一个容易被忽视的手段是Design For Testing，即让开发者为加速测试做一点额外开发工作。例如，将软件超时参数设置成可配，在测试环境中可以将它配置为比生产环境小得多的值，从而在保证代码逻辑被覆盖的前提下，提升运行速度。
三，需要频繁手动适配。自动化测试的优势是能够大大减少持续测试或者回归测试中的人工成本。然而，如果自动化测试用例需要频繁手动适配，例如针对依赖的配置文件的变化修改测试用例，那么自动化测试的维护成本将难以降低，灵活性也会受影响。
避免频繁手动适配一般有两种思路。一是从用例设计上，避免对容易发生变化的全局性配置文件产生依赖，而只依赖部分比较稳定的配置；二是开发自动适配技术，在每次依赖发生变化时，自动识别依赖对用例的影响，并自动进行用例适配。
四，"胡子眉毛一把抓"。从本质上说，自动化测试也是一种形态的软件开发。自动化测试的成本也包括两部分，开发成本和维护成本。了解软件开发成本理论的人应该知道，相比开发成本，软件的维护成本占大头。
自动化测试中常见的一个误区是追求100%的自动化测试覆盖率。提高覆盖率，确实能够提高测试的有效性，然而其带来的成本增长是不容忽视的。长期的自动化测试维护工作，包括适配，优化，自身缺陷修复等，可能消耗掉测试团队有限人力的大半。
"一股脑儿"自动化掉所有的用例，不如分下"轻重缓急"，有选择性地自动化那些优先级高的部分用例。这里的优先级定义比较关键，需要结合用例的重要性，用例发生频率，用例出现故障时产生的负面影响程度和范围等因素综合考虑。
以上四点就是我个人总结的自动化测试常见的"反模式"，它们分别是: 依赖未经充分测试的外部组件，执行速度慢，需要频繁手动适配，"胡子眉毛一把抓"等。在实践中，它们常常是造成自动化测试项目走向失败的原因。
这些"反模式"是自动化测试的"stop doing list"。个人认为，为了打造一个可持续成功的自动化测试项目，我们应该尽可能避开这些错误的做法。
本文内容不用于商业目的，如涉及知识产权问题，请权利人联系博为峰小编(021-64471599-8017)，我们将立即处理
