把程序员和自动化测试联系起来，估计很多人都没有想过这个问题，或者也有人能联系上，但也仅仅止步在自动化单元测试了。是的，自动化测试是一个很广泛的概念，单元测试、功能测试、容量测试等等都可以自动化，但这篇文章仅仅只会设计功能测试，毕竟每种测试涉及的东西都很多，在一篇文章里都说清楚是不现实的。
说到功能测试，很多人第一反应就是：嗯，这是测试人员的事情。这么说也没错，前提是如果测试还停留在测试人员机械地点鼠标的话。如果功能测试也实现自动化，开发人员介入功能测试就是一个必不可少的事情。使用过自动化功能测试工具的应该知道，自动化工具不可避免地会跟被测程序的某些模块有较高的耦合，要么是UI层，要么是UI层与业务逻辑层之间的中间层。纯粹由测试人员编写测试脚本，测试人员便很难界定与被测程序的交互哪些是可以抽象重用，哪些是容易改变的部分不应该被抽象的，从而很难编写出易于维护的测试脚本。以上表述都是基于测试有不错的开发能力为前提的，但事实上现在大部分公司实施功能测试的测试都是完全对软件开发没有概念的，别说写出高质量的测试脚本，连能不能写测试脚本都是一个问题（这里仅仅表述我看到的现状，并不是否定测试人员的专业性）。
为什么开发不能独自开发测试脚本？
开发看到这个问题一定会觉得很纳闷，既然测试脚本需要开发介入编写，为什么就不能干脆全包了？因为功能测试和单元测试最大的不同在于：单元测试是面向技术的，它验证程序是否与程序员预想的方式运行；功能测试是面向业务的，它验证的是程序是否与用户预想的方式运行。程序员很容易犯的一个错误，便是以技术的眼光看待非技术的业务，而且很多时候是不知不觉就犯了。因此最起码功能测试的测试用例不能纯粹让开发去设计。
所以功能测试的测试用例是应该由测试人员与用户（或产品经理）一起设计的，开发人员只需要把测试用例用特定的测试脚本表达出来，或者协助测试人员完成测试脚本即可。测试人员依然是整个自动化功能测试环节最重要的一环，他们将要直接影响着功能测试的测试质量。
测试人员的工作就只剩下这些了么？
如果测试某位测试人员偶然看到这篇文章，看到这里应该应该觉得很沮丧了。难道测试人员就只能沦为用户或产品经理与开发之间的桥梁了么？非也。自动化测试并不是万能了。有些情况是自动化测试无法做到的，比如易用性测试、UI的美工效果和向用户演示系统功能等。另一种是不建议使用自动化测试的，比如那些经常改变的功能。因为维护功能测试的脚本成本还是比较高的，如果脚本需要经常变动，维护的成本就有可能比手工测试的成本还高，倒不如直接使用手工测试就好。
因此，自动化测试的目的不是要替换掉测试，而是让测试人员从机械地点击鼠标中解放出来，去从事更有创造性，更有价值的工作，但这也要求测试人员要有更高的素质。
如何选择自动化功能测试工具？
选择自动化测试功能，和选择系统架构一样，都是一件应该慎重对待的事情，因为它直接影响着测试方案的实施，而且后悔的代价是很大的。对于不同类型的系统，对测试工具的选择可能千差万别，但我相信以下几点原则对大部分软件系统选择测试工具还是通用的：
可命令化执行测试用例。这个可以说是选择工具的底线了，因为只有可通过命令执行测试用例，才有可能很容易地把自动化测试整合到持续集成中。把测试自动化还远远没有达到高效、高质量开发软件的要求，能把持续集成，甚至是部署流水线也做到，才是最终目的。因此，从最开始的测试工具选择，就应该考虑到持续集成的整合。
高可编程性的测试脚本。高可编程性的脚本便意味着更好的抽象能力，更简洁的代码。好的编程语言与不好的编程语言在重用性和管理性方面差距是很大的。比较一下VBA和Java之间的差距就知道了。因此，为了能更好高效的开发和更好地管理测试脚本，测试工具支持的测试脚本必须具有较高的可编程性。
支持并行运行。这是衡量一个自动化测试工具好坏的一个很好标准。功能测试的一个测试用例具有很高的可能性需要运行很长时间，支持并行地运行测试用例，可以大大减少执行一次功能测试的时间。在项目早期这种需要可能还不明显，但随着项目的发展，费时的功能逐渐添加进来，用例数量也持续增加，并行的好处便会体现出来。从一开始就考虑到并行的情况，以后扩容便会变得更简单。
还有一个可能不是最重要，但是个人还是很看重的点：工具不能太依赖屏幕录制功能。屏幕录制功能是一把双刃剑，它能够很好地帮助我们生成“枯燥”代码，但是程序生成的代码通常都很多，而且严重违法DRY原则，后续的脚本维护将会变得相当困难。有这种想法是因为看过WinRunner和Visual Studio的UI测试功能生成的测试脚本，被恶心到了。
