问题1：当用户在网上商店购物时，一次完整的购买流程需要用户进行好几个步骤的操作（包括选择商品、填写订单信息、选择支付方式、确认订单等），涉及四到五个页面以及数十个类的协作。如何在开发过程中始终确保该流程能够正确无误、畅通无碍？
问题2：客户提出需求：在显示货物列表时，应该首先按货物名称排序，名称相同的货物再按照价格排序。我们已经实现了这一功能，并且有单元测试作为保障，但如何让客户看到我们的成果？
问题3：美工在制作页面时，一不小心把一个<form>的id属性删掉了。几天之后，另一个页面上的JavaScript莫名其妙地失效，我们花了很多时间才发现这个问题。应该如何避免类似的情况再次发生？
这三个问题对于做惯了web应用的读者来说一定不陌生——实际上，我们的每个项目都或多或少地遇到类似的问题。说穿了，这三个问题都是关于同一件事情：如何验证一个东西是正确的，以及如何便利而自动地重复这一验证过程。在代码层面上，xUnit单元测试工具（对于J2EE项目，就是Junit）给了我们帮助。但是，当问题涉及到web界面和用户交互时，JUnit就显得有些力不从心了，这也是很多采用测试驱动开发（TDD）方法的团队只能把TDD贯彻到web controller层面的原因。
| 单元测试 vs. 功能测试 正如它的名字所揭示的，JUnit是一个单元测试工具。而我们在前面提出的三个问题，实际上已经属于功能测试（functional test）或者验收测试（acceptance test）的范畴。尽管单元测试能够保证各个单元的正确，却无法确保将这些单元组合起来之后的效果。需要依靠功能测试工具，我们才能继续TDD的脚步。 另一方面，功能测试在很多时候应该由客户——或者是具有一定技术背景的客户代表（可能是项目的需求分析师）——来编写的（这也是“验收测试”这个名称的由来：通过这些测试就代表工作通过验收），因此编写这些测试不应该要求太高的编程能力。在这一点上，JUnit也是令人望而生畏的。 |
由ThoughtWorks员工开发并维护的Selenium（http://selenium.thoughtworks.com）正是帮助我们解决上述问题的得力工具。简单地说，Selenium是一个自动化的web应用功能测试工具——我知道，这个短语不足以让读者了解它所描述的对象。所以，在进一步介绍之前，我想先请读者来看一个活生生的例子。请打开你的浏览器，访问下列URL地址：
http://www.openqa.org/selenium/demo1/TestRunner.html
你将会看到Selenium的主操作界面（如图1）。可以看到，整个页面被分成四个
