一个工具的例子
一般来说，我不太喜欢介绍工具，因为具体的工具总有过时的一天，所以我希望我的文章是在传“道”而不是在传“术”。但通过一个工具，能让人更好地了解我上面说的内容，因此我还是介绍一个自动化功能测试的工具吧。
由于我是从事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一下不会弄不明白的，关键还是要多练习。
尽管在系统开发初期就开发自动化测试脚本有点难度，但是用例的设计和测试脚本的设计要尽早进行，而且开发也要主动参与其中。及早地考虑自动化测试，有助于系统架构能适应自动化测试的要求，这点与单元测试是一样。
总 结
自动化功能测试是一个开发与测试紧密合作完成的工程。从用例设计，测试工具的选择，测试脚本的编写与维护，到最终自动化测试的执行，就需要整个团队的紧密合作。它能大大提高测试的效率，减少手工测试的不确定性，也能促进开发对系统的重构。但自动化测试的目的不是替代测试人员，用例设计、易用性测试等依然需要测试人员的参与，自动化测试就是希望用计算机替代机械的手工操作，让测试人员从事更有创造性的工作。
相关文章：
