http://blog.csdn.net/samsunge808/archive/2009/08/01/4397625.aspx
测试 自动化的架构定义了如何存储、引用、分组、共享以及重用测试脚本和测试数据。
脚本的执行通常都由工具所支持，通常被称作测试自动化框架。框架是一个基础的结构，我们相互独立的测试自动化工具中的脚本和数据整合到这个框架中。
由脚本的开发者来决定如何组织测试数据，以及脚本如何读取这些测试数据。另一方面，测试数据的操作和维护的易用性也是框架可行性的关键方面。
全局和局部测试数据
相关联的测试脚本通常放到一组，称为测试集（ test sets），用于覆盖被测试应用程序的特定功能区。
测试集定义了一系列的脚本，这些脚本由测试自动化框架按一定的顺序以批处理的方式执行。
常见的测试集包括冒烟测试集（smoke test set）和回归测试集（regression test set）等。
一个脚本可以从属于多个测试集，并且用不同的测试数据来运行。
自动化框架从脚本库中选取脚本（以及相关的数据文件）在各分布式的主机上以测试集所定义的顺序运。
测试数据可以按范围来进行分类。
全局（Global）测试集数据对于测试集中的所有脚本都是可见的、可共享的，而局部（local）数据只对其所创建的脚本是可见的。
全局测试数据通常是那些可配置的参数，例如服务器名、启动页面的URL地址等，它们是所有脚本的基础数据。图1展示了这些测试集的数据组织情况。
图1
设计规则
在行业最佳实践的基础上，我定出了6个普遍适用的设计规则，实践证明对于在框架中组织测试数据是非常有效的。这些规则应该被视为开发内部测试自动化框架的功能需求，或者用于评估商业框架之用。
下面列出这些规则以及给测试自动化框架用户带来的好处：
规则1：测试数据必须与测试脚本分离
这是代码设计的最基本原则，对于测试脚本设计一样适用。但是我曾经无数次看到这个规则被违反。由此带来的后果是代码需要被重写，导致进度延误。一旦程序通过调试并发布后，就应该避免代码的修改，除非万不得已。任何代码的修改都容易引入错误。
如果数据写死在代码中，则可能导致你修改了一个地方，但是忘记修改其他 地方。
另外一个原因是代码的国际化问题；所有代码中的可读的字符串都应该用变量表示，并且存储在单独的资源文件中。这样一旦需要改变区域设置，你只需要修改配置引用新的区域设置对应的目录的文件，不需要做任何的代码修改。
这个规则对于测试自动化的主要好处是：对于测试一个产品的不同功能，相同的代码可以被重用而不需要修改，仅需要修改对应的测试数据即可。把脚本和数据分离还可以显著地减少需要维护的脚本的代码行。
规则2：测试数据应该以表格的形式出现
以表格形式展现数据有利于数据驱动测试的设计。数据驱动测试（data-driven test）是一种自动化测试 技术 ，它允许一个自动化脚本可以通过循环读取数据表格的每一行的数据来驱动测试，从而实现多个测试用例。
规则3：数据表格应该以外部文件的形式提供，并且应该容易访问和修改。
我把测试脚本的用户分成两大类：测试自动化工程师（test automation engineer）和领域专家（subject matter expert）。
后者通常不具备编程技巧，但是他们在被测试程序所涉及到业务领域具有很深的理解。他们知道用哪些数据来验证应用程序的功能细节。如果一个脚本被恰当地设计，则领域专家应该可以很容易地执行，而不需要看懂脚本代码。他们只需要修改测试数据。如果在数十个子文件夹中寻找数据文件很困难的话，则证明测试自动化框架是效率低下的、不可用的。
规则4：对于测试集的所有脚本普遍适应的全局数据应该与局部数据分离开来。
如果在一个大的测试集的脚本数据文件既包含全局数据又包含局部数据，则需要更多的时间来修改所有数据文件中的相同数据。
这个过程是低效率的，并且容易出错。如果我们有一个统一的库来存储全局数据，则只需要每个测试集做一次修改，然后就能自动同步到所有脚本中。
每个人只要通过修改全局的设置，然后就可以在他的环境中执行测试集，而对于那些仍然有效的局部数据，则可以直接重用而不需要修改。
规则5：局部测试数据应该与测试脚本以及包含测试脚本的测试集唯一地关联起来。
与测试集的关联，对于在多个测试集运行相同的脚本，但是以不同的数据运行来说是必要的。
就像图1一样，我把测试数据分为两套，一套是为测试脚本运行的，另外一套是为测试集运行的。
规则6：为每个测试集准备的局部数据应该分离开来，但是共存于同一数据文件中。
在运行脚本时，测试自动化框架从脚本库中读取脚本开发者提供的数据文件。
为了后续测试集的数据修改，你需要重写原来的数据文件。这将导致数据冲突。一个可行的解决办法是：一个脚本和多个数据文件对应到每个测试集。这样的方法对数据文件的维护和动态映射正确的数据文件到脚本来说会产生一定的工作 量。但是如果对于每个测试集，我们仅有一个数据文件，局部数据共存于文件中，则会简化数据列表以及搜索的难度。而且数据共存也能避免数据冲突和重写。
下面是一个例子，是一个测试数据组织的灵活、有效的架构，其遵循了上述的设计规则。这个解决方案是针对Window平台的，但是对于其他平台同样适用，那些数据设计规则是平台无关的。
数据组织
在这个应用的例子中，每个脚本只与一个数据文件关联。遵循规则2，它使用一个Excel表单来存储测试 数据。根据规则3，这些数据文件应该很容易被领域专家访问到。这提出了另外一个很基本的问题：如何有效地将脚本和数据文件分组存储。
当一个工程师开始一个测试自动化项目，面对的第一个工作 任务就是如何组织测试脚本和数据。
为了完成这个任务，我提出一个实践：创建应用程序的功能分解模型，把所有功能都分解到有层次关系的功能区域和子区域。然后把这个结构映射到一个目录树，在目录树中存储测试用例和脚本，这些用例和脚本对应到功能区域的目录。领域专家不需要查看那些脚本，但是他们需要知道那些脚本是做什么的，它们对应的数据存储在什么地方。
通过在Excel中使用“分组和大纲”（Group and Outline）功能创建脚本和数据目录，如图2所示。针对每一个脚本记录，都能链接到相对应的数据文件，可以直接在表单中打开、修改和保存。
图2
每个数据文件都有多个工作表单，其中一个是默认的工作表单（如图3所示）。这个工作表单包含由脚本开发者提供的原始测试数据。
图3
所有工作表单都有相同的结构：第一行包含标题头（参数名），而所有其他 行包含测试数据的值。拥有多行数据则表示这是个数据驱动的测试。如果要修改原始的局部测试数据，你应该创建一个以该测试集命名的工作表单，并在该表单中输入测试数据（如图4）。这样，不同测试集的局部数据可以与测试集的名字关联起来（规则5），并且可以共存于一个数据文件中（规则6）。
图4
我们使用以下简单的算法来访问局部测试数据。
每个脚本根据测试集名称从工作表单中读取关联的属于脚本的数据。
如果没有这样的工作表单，则自动读取“Default”表单中的默认数据。
如果领域专家希望修改原始的测试数据，他们只需要根据测试集名称在Excel数据文件中创建一个工作表单。
全局数据的实现
让我们来看一种典型的情况。你组合了一个包含100个脚本的测试集合，这些脚本都是由其他人开发的。
你继承了这些脚本的测试数据文件。每个测试集中的脚本都使用Server_Name来作为输入参数。
但是问题是你的测试环境中的服务器名与原始的数据文件中定义的不一致。
那么你如何避免因为修改100个数据文件中的服务器名而引入的错误呢？解决办法是使用全局数据（规则4）。
对于在什么地方存储全局数据，有3种选择：Windows 注册表、环境变量、文件。其中一种方便的方式是通过环境变量，因为可以在Windos控制面板中通过系统工具方便地查看和编辑这些环境变量。每个测试集通过一个设置脚本（Setup scrīpt）来为所有全局数据创建环境变量。全局变量值是在名为Setup的Excel数据文件中的。
测试集的名称是其中一种全局变量，它的值可以被每个脚本用于判断哪个工作表单包含脚本的局部数据（见图4所示的例子）。在某些测试自动化框架，例如HP的 Quality Center，脚本可以使用框架API来获取其所属的测试集的名称。这是个适用于所有框架的简单的解决方案。这个算法可以很容易地扩展成更为复杂的情况。
不像其他脚本数据，Setup数据文件只有一个工作表单，列名以全局变量命名。其中两列是必须的，包括“Order”和“Test_Set”。
Order列用于描述测试集由测试自动化框架组织执行的顺序。
Test_Set列包含测试集的名称。工作表单中的每一行都代表一个测试集的全局变量值（见图5）。
图5
为了运行一系列的测试集，我们还需要定义一个环境变量TS_CURRENT，并且手工为其赋一个初始的值为1。
在图5所示的测试集Smoke中，Setup脚本读取TS_CURRENT，并且创建环境变量，它们的值从Order数等于TS_CURRENT的数据行中读取。
现在，测试集中的所有脚本在Setup访问了全局数据后都得以执行。由于Test_Set变量定义后，每个脚本也就知道了从哪个工作表单读取它们的局部数据。
我们以一个Reset脚本来终止每个测试集，Reset脚本删除当前测试集的所有环境变量并且把TS_CURRENT的值累加1，以便执行下一个测试集。当回归测试集开始执行时，TS_CURRENT就变成了2。
因此，在我们的实现过程中，每个测试集都包含表格1所示的脚本。
表格1
通过使用这个测试数据架构（你可在自己的测试环境中略作修改），你就可更加高效地管理你的测试数据，让其更标准、可重用性更强。以我的经验来看，以这种方式管理数据-使用测试自动化框架-让我的测试生活 变得轻松和有趣。
