软件测试：测试自动化仅仅是测试工具吗？

很多开发、甚至测试人员，都把测试自动化理解成测试工具，同时很多人也认为测试自动化仅仅是辅助测试，提高测试效率，解放测试人力，让机器做那些重复、繁琐、枯燥的事情。测试更关键的还是测试分析与设计，是测试思想，因此测试自动化的发展还远远比较弱。即使有的公司有专门的测试工具团队，但这些工具团队的员工也没有多少测试实战经验。

首先，我们看看测试自动化是如何产生的。这里假设一个场景，一个新的团队开发一个全新的产品，第一个版本，由于测试完全没有积累，第一个版本所有的测试用例都是手工用例，运气比较好，版本顺利交付，而且客户越来愈多。世界是变化的，不同的客户需求不同，同时交付的版本也就越来愈多。领导提出更高的要求，必须在规定的进度内交付版本。手工测试适应不了时代，测试要提高测试效率，思考如何现有的测试用例让机器去做。于是，测试人员中，有一个或几个，开始研究，寻找或者开发工具，于是自动化就从这里开始了。

自动化是把现有测试用例让机器去做，是需要用到一些工具。这个可能是大多数同学对自动化的理解，即使在大公司，这种认识也普遍现象。这种认识错吗？当然不能算错，只是它不完全对，但这是非常的不完整。

我们再接着上面的例子，随着公司业务发展越来快，产品越来越多，不同的产品，需要不同的测试自动化技术，比如API测试、组件测试、协议测试、基于WEB的测试，单靠测试团队和小工具难以支撑越来愈多测试需求。因此专门的测试部、测试工具部都相应成立，分工更加精细化。可惜，21世界最缺的是什么，是人才啊！做测试的，没有开发经历是实情，有也是凤毛菱角，会开发的不愿意做测试，做测试的已经转不动开发。测试工具部的人从哪里来，只有招那些本身也许没有测试经验，甚至没有开发经验的同学加入。世界从此就没有那么平静了。也许有人看过，网上有一篇博文，工具部开发出害死人的工具出来的帖子。有点扯远了。说到这里，成立的工具部为测试而做的就是开发测试工具，更加坚定了测试自动化是工具的论调了。

那自动化的作用主要哪些作用？以下几点是普遍的观点。

（1）自动化可以提升测试效率。测试用例一旦自动化掉了，再次执行基本不怎么花时间和人力，对继承特性的测试，相比手工测试效率提升是很明显的。

（2）自动化可以快速进行回归，尽早暴露问题。敏捷项目中，领导期望开发出的代码，立即可以测试完成，及时得到质量反馈。对于已经发现的问题，可以快速进行回归。实际情况，对于继承特性和问题单回归，一般预留时间比较少。

（3）自动化可以增加版本覆盖率，增加项目利益干系人对质量的信心。版本规模比较大的时候，手工做全覆盖测试，几乎是无法想象的。记得很多年前，对版本进行一次全覆盖测试，一年才做两三次。现在几乎要天天要做到全覆盖测试。测试有一个经验，没有经过测试的特性，应用肯定出问题。

自动化常见的困惑有哪些？

（1）自动化前期投入比较大，成本非常大，自动化投入值不值？新的项目，往往基于进度的要求，开始测试没有精力去做自动化，等到版本发布后或快发布的时候，再开始把测试用例自动化掉。对于不需要经常测试的特性，很多人认为不需要自动化。比如可维护性、配置类的。但在敏捷时代，这个有观念有所变化，敏捷要求达到每日构建，每日测试。没有自动化，是行不通的。

（2）自动化总是滞后的，周边对自动化需求永远无止境，总是认为自动化做得不够。项目开始时，测试先做测试分析与设计，等测试用例出来或者测试完成之后，才开始投入自动化，这个自动化策略就是滞后的，前面项目的自动化还没做完，新的项目又来了，所以测试永远是疲于本命。自动化的策略选择，导致了这个现状。

（3）测试人员比较看不起自动化，认为那是开发该有的技能，测试人员过多投入自动化，容易不会做测试了。尤其是，测试人员几乎都认为新员工不能做自动化。这个观点，我觉得很意外，认为自动化不是测试认为必备技能。测试人员大概不晓得，第一批测试人员可是从开发演变过来的，没有自动化能力的测试人员，总会感觉自己悬在空中。

（4）自动化难度比较大。有些自动化难度是非常大的，比如界面类、复杂协议接口、中间件类的。造成这一困境的原因，测试能力不足，测试没有丰富的经验。

（5）自动化环境维护工作量巨大。这个和上面一点的原因差不多，测试不懂开发做不好自动化，测试不懂设计也不能做好复杂系统的系统的自动化。这是一个工程能力问题，自动化不光光测试工具的选择，是要有设计的，自动化测试框架尤为重要。自动化不是一堆工具的堆积。这个系统设计的思想是一样的，把自动化当成一种系统来设计，同样要在设计之处就要考虑稳定性、可维护性、可扩展性，易用性。什么东西该隐藏，什么东西不该隐藏，也是需要进行权衡的。敏捷时代，对自动化环境的稳定性、可靠性要求更高。

回到测试分析与设计，测试分析有很多工程方法，用例设计也有很多种方法。有些用户场景光靠人是测试不了，比如接口异常、用户并发等情况下，必须借助机器来做。因此我的观点，把自动化当着一种测试分析和设计的方法，开展自动化不仅仅是用来提高效率的，也是用来扩展测试范围的。在测试项目最初阶段，就把自动化考虑进去，不要等到后期再开展。这样主要有哪些好处呢？

（1）自动化在初期开展，容易能清楚哪些能开展自动化，哪些不能用自动化。比较容易控制测试范围。

（2）自动化在初期开展，容易针对系统提出自动化测试需求，系统内部信息，测试人员能够方便获取；提前规范系统输出等。减少后续的浪费。

（3）自动化在初期开展，避免了项目结束后再去自动化测试开发，测试工作一次性就做对了。

（4）自动化在初期开展，容易赶上敏捷节奏，才能能够支撑好每日构建，每日测试。

（5）项目初期，测试人员投入不需要太多，这个时候自动化人员有比较多的时间去考虑自动化系统的设计，有时间考虑更多的自动化方案，避免后期进度压力，匆忙设计。

要想达到上述的自动化效果，对自动化人员的技能要求是比较高的，有时一个自动化人员不足以支撑。我的建议

（1）在你的团队，建设良好的自动化氛围，把自动化技能当着必备技能，而且是测试的一种技能。

（2）重点培养自动化工程师，团队比较大，甚至需要建立自动化工程师团队。

（3）统一你的自动化语言，统一你的自动化工具。不是什么工具好就去用什么工具，这就跟什么语言比什么语言好一样，要找到适合自己产品的自动化工具，不需要经常变化。采用什么工具，要符合本团队的主流自动化方案。可以3~5年一大变，短时间避免大的变化。

（4）同等对待自动化工程师和测试设计工程师，因为他们同等重要。如果幸运的话，你的测试设计工程师又具备自动化设计能力，测试技术你完全放心交给ta了。如果你再有一个能力强的项目经理，你的测试项目，很难不成功了。

最后，回到我的观点，自动化是一种测试分析与设计方法，不仅仅是自动化工具的选用。如果工具不适合，你就得开发测试工具，要让工具为自己所用，而不是被工具绑架。自动化最核心的就是设计。改变你的测试观点，测试需要多种思维的人才，开发者和设计者的思想，在测试团队中，同样能发挥巨大作用。就看你如何对待测试工作了。