论程序员的自我修养——自动化功能测试

为什么自动化功能测试与开发有关系？

        把程序员和自动化测试联系起来，估计很多人都没有想过这个问题，或者也有人能联系上，但也仅仅止步在自动化单元测试了。是的，自动化测试是一个很广泛的概念，单元测试、功能测试、容量测试等等都可以自动化，但这篇文章仅仅只会设计功能测试，毕竟每种测试涉及的东西都很多，在一篇文章里都说清楚是不现实的。

        说到功能测试，很多人第一反应就是：嗯，这是测试人员的事情。这么说也没错，前提是如果测试还停留在测试人员机械地点鼠标的话。如果功能测试也实现自动化，开发人员介入功能测试就是一个必不可少的事情。使用过自动化功能测试工具的应该知道，自动化工具不可避免地会跟被测程序的某些模块有较高的耦合，要么是UI层，要么是UI层与业务逻辑层之间的中间层。纯粹由测试人员编写测试脚本，测试人员便很难界定与被测程序的交互哪些是可以抽象重用，哪些是容易改变的部分不应该被抽象的，从而很难编写出易于维护的测试脚本。以上表述都是基于测试有不错的开发能力为前提的，但事实上现在大部分公司实施功能测试的测试都是完全对软件开发没有概念的，别说写出高质量的测试脚本，连能不能写测试脚本都是一个问题（这里仅仅表述我看到的现状，并不是否定测试人员的专业性）。

为什么开发不能独自开发测试脚本？

        开发看到这个问题一定会觉得很纳闷，既然测试脚本需要开发介入编写，为什么就不能干脆全包了？因为功能测试和单元测试最大的不同在于：单元测试是面向技术的，它验证程序是否与程序员预想的方式运行；功能测试是面向业务的，它验证的是程序是否与用户预想的方式运行。程序员很容易犯的一个错误，便是以技术的眼光看待非技术的业务，而且很多时候是不知不觉就犯了。因此最起码功能测试的测试用例不能纯粹让开发去设计。

        所以功能测试的测试用例是应该由测试人员与用户（或产品经理）一起设计的，开发人员只需要把测试用例用特定的测试脚本表达出来，或者协助测试人员完成测试脚本即可。测试人员依然是整个自动化功能测试环节最重要的一环，他们将要直接影响着功能测试的测试质量。

测试人员的工作就只剩下这些了么？

        如果测试某位测试人员偶然看到这篇文章，看到这里应该应该觉得很沮丧了。难道测试人员就只能沦为用户或产品经理与开发之间的桥梁了么？非也。自动化测试并不是万能了。有些情况是自动化测试无法做到的，比如易用性测试、UI的美工效果和向用户演示系统功能等。另一种是不建议使用自动化测试的，比如那些经常改变的功能。因为维护功能测试的脚本成本还是比较高的，如果脚本需要经常变动，维护的成本就有可能比手工测试的成本还高，倒不如直接使用手工测试就好。

        因此，自动化测试的目的不是要替换掉测试，而是让测试人员从机械地点击鼠标中解放出来，去从事更有创造性，更有价值的工作，但这也要求测试人员要有更高的素质。

如何选择自动化功能测试工具？

        选择自动化测试功能，和选择系统架构一样，都是一件应该慎重对待的事情，因为它直接影响着测试方案的实施，而且后悔的代价是很大的。对于不同类型的系统，对测试工具的选择可能千差万别，但我相信以下几点原则对大部分软件系统选择测试工具还是通用的：

        可命令化执行测试用例。这个可以说是选择工具的底线了，因为只有可通过命令执行测试用例，才有可能很容易地把自动化测试整合到持续集成中。把测试自动化还远远没有达到高效、高质量开发软件的要求，能把持续集成，甚至是部署流水线也做到，才是最终目的。因此，从最开始的测试工具选择，就应该考虑到持续集成的整合。

        高可编程性的测试脚本。高可编程性的脚本便意味着更好的抽象能力，更简洁的代码。好的编程语言与不好的编程语言在重用性和管理性方面差距是很大的。比较一下VBA和Java之间的差距就知道了。因此，为了能更好高效的开发和更好地管理测试脚本，测试工具支持的测试脚本必须具有较高的可编程性。

        支持并行运行。这是衡量一个自动化测试工具好坏的一个很好标准。功能测试的一个测试用例具有很高的可能性需要运行很长时间，支持并行地运行测试用例，可以大大减少执行一次功能测试的时间。在项目早期这种需要可能还不明显，但随着项目的发展，费时的功能逐渐添加进来，用例数量也持续增加，并行的好处便会体现出来。从一开始就考虑到并行的情况，以后扩容便会变得更简单。

        还有一个可能不是最重要，但是个人还是很看重的点：工具不能太依赖屏幕录制功能。屏幕录制功能是一把双刃剑，它能够很好地帮助我们生成“枯燥”代码，但是程序生成的代码通常都很多，而且严重违法DRY原则，后续的脚本维护将会变得相当困难。有这种想法是因为看过WinRunner和Visual Studio的UI测试功能生成的测试脚本，被恶心到了。

一个工具的例子

        一般来说，我不太喜欢介绍工具，因为具体的工具总有过时的一天，所以我希望我的文章是在传“道”而不是在传“术”。但通过一个工具，能让人更好地了解我上面说的内容，因此我还是介绍一个自动化功能测试的工具吧。

        由于我是从事Web开发的，因此会特别留意有关Web的测试工具。这次要介绍的是selenium（http://seleniumhq.org/）。该工具支持市面上各种主流浏览器（IE、Chrome、Firefox等等），另外也支持Android的测试。因此这个工具可以顺便测了浏览器的兼容性问题了。

        下图是selenium的结构图：

        通过这个结构图，其实也很容易看出selenium的原理了。各种不同语言的API访问不同浏览器的驱动程序，由驱动程序来控制各个浏览器。由于selenium是开源的，因此只要实现浏览器驱动和符合selenium规范的API，就算是国内一些奇葩的浏览器（比如QQ

浏览器、360浏览器等等）都可以进行自动化测试了。

        selenium的使用方法就不细说了，有兴趣的朋友可以上官网看各种文档学习。重点还是说说为什么selenium能被我看上眼吧。

        selenium是一套API，而不是一个独立的软件。selenium不想WinRunner，它没有独立的运行环境，仅仅是一套自动化测试的API，因此它可以结合具体语言的自动化测试框架使用（比如大名鼎鼎的xUnit系列），从而能够很容易地通过命令行方式运行，并读取测试结果。

        selenium没有自创语言。selenium没有使用独创的语言作为测试脚本，而是使用了已经存在的编程语言作为其测试脚本，大大降低了学习成本之余，其脚本的可编程性也相当高（因为这些语言都是通用的编程语言）。而且selenium是开源的，实在对现有API的编程语言不爽，也可以自己写一套，比如用Go。

        selenium支持C/S模式的远程调用。这个特性使得一个测试套件可以分布到不同的机器上运行，并行地运行测试用例可以有效地提高测试的效率。

        selenium的屏幕录制功能不强大。selenium的屏幕录制工具（selenium IDE）是一个FireFox插件，可以帮助测试人员生成xUnit风格的测试脚本。虽然是五脏俱全，但是比起WinRunner那华丽的录制功能，还是略显简陋。简陋是好事，这就促使开发和测试人员手工编写测试脚本了。

自动化测试还需要注意什么？

        纵观整篇文章，大部分篇幅都在说工具，却没有提到测试最基本的东西——用例设计。不说不代表不重要，用例设计依然是自动化功能测试的灵魂，如果用例设计不好，以上所说的都是废话。但黑盒测试的资料太多，什么分类法，边界值法之类的方法google一下不会弄不明白的，关键还是要多练习。

        尽管在系统开发初期就开发自动化测试脚本有点难度，但是用例的设计和测试脚本的设计要尽早进行，而且开发也要主动参与其中。及早地考虑自动化测试，有助于系统架构能适应自动化测试的要求，这点与单元测试是一样。

总  结

        自动化功能测试是一个开发与测试紧密合作完成的工程。从用例设计，测试工具的选择，测试脚本的编写与维护，到最终自动化测试的执行，就需要整个团队的紧密合作。它能大大提高测试的效率，减少手工测试的不确定性，也能促进开发对系统的重构。但自动化测试的目的不是替代测试人员，用例设计、易用性测试等依然需要测试人员的参与，自动化测试就是希望用计算机替代机械的手工操作，让测试人员从事更有创造性的工作。