览器端测试的具体应用
对于这种模拟浏览器端操作的测试，微软已经有了非常成熟的测试框架，其中应用比较广泛的是ECHO和KAF。ECHO是一个可以驱动Web UI的、面向对象的测试架构，它允许终端用户使用XML或受.Net托管的编程语言，如C#来编写自动化测试用例。而KAF可谓ECHO的后继者，目前基于ECHO的测试项目都在逐渐向KAF迁移。这是因为KAF不但包括ECHO的大部分功能，而且支持多种浏览器（目前支持IE和Firefox），对页面上的动态元素也有很好的支持，灵活性更强。当然这些测试架构都是微软内部使用的工具，是不允许对外发布的。但大部分的Web UI测试架构都是建立在如下的设计思路，按照这样的设计思路，我们完全可以构建封装适合自己项目的Web UI测试架构进行浏览器端的测试（见图1）。
图1
（1）UI Element
Web页面是由一系列的对象元素组成的，比如按钮、文本框等。UI Element就代表了这些通用的网页接口元素。UI Element类一般都是super class（超类），这个类通常会有以下的类成员：
- string Name: UI Element元素的名称。作为这个元素的唯一标识。
- Driver UIDriver: 是对UI Element所使用的UI驱动实施的一个引用。针对不同的浏览器会选择不同的驱动方法。
- List<List<UIElementAttr>>AttributeLists: UI Element属性的集合，UI Driver将遍历所有的属性列表去定位匹配的Element。当某个元素在不同的状态可能会有不同的属性时，例如我们熟知的button的三态，我们就需要有多个属性列表。UIElementAttr通常是一个集合，一般包含有属性名称、属性值、是否准确匹配等。
- string ContainerName: UI Element所在的容器名称。对于Web页面，就是指元素所在的框架的名称。
以上只是一些基本的类成员，可以根据实际情况对这个类进行补充。通常我们会创建一些UIElement子类内置到我们的测试架构中，这此子类主要是如下的一些常见的Web控件：
- TextBox
- Button
- RadioButton
- Link
- Label
- Image
- Checkbox
- SelectItem
- ComboBox
- DropDownMenu
我们通常会将静态的UI Element存储到XML文档，这样做的好处是当UI Element元素发生变化时，只需要修改这个XML文档，而不必修改我们的测试代码。
有时候可能在Test Cases运行期间，用来确定UI Element唯一性的属性会变化，这时候我们也需要用编码动态地去更新属性列表，来创建这个UI Element。
（2）Browser Agent
我们设计Web测试框架最主要的目的就是能够让测试代码在不同的浏览器，比如IE、Firefox中都能自动地、正常地运行。提供Browser Agent可以更灵活设置浏览器的类型，以及完成一些常规的浏览器功能，比如清除浏览器的缓存及载入页面等。
（3）UI Driver Interface
为了实现测试代码在不同浏览器都能够自动执行这个目的，可以抽象出一个UI的驱动层。在这一层里可以设计出能在各种浏览器里执行的、所有可能的UI动作，而且我们设计的Test Cases也只与这一层进行交互。这样可以将驱动的实现与Test Cases进行分离，将来Test Cases的修改不会影响到Driver Implement层代码的实现部分，而且UI Driver Implement层的改变也会不影响到测试代码。常见的一些方法如下：
- Click(…):
- Select(…):
- DragAndDrop(…)
- GetTitle(…):
- PressKey(…):
（4）UI Driver Implement
这是建立一个Web测试架构的基础，对于不同的浏览器可能会采用不同的驱动实现方法。
