声明：本空间大部分博客信息为寻找问题时在网上拷贝或转载，在此博客中做个记录，方便自己也方便有类似问题的朋友，因原出处已不好查询，如有侵权，请发邮件表明文章和原出处地址，本人一定会在文章中注明。谢谢。
【转】软件测试自动化框架
软件测试是在软件开发周期中必不可少的、耗时的一部分。为了保持与产品的开发和发布同步，我们需要实现一种有效的、可重用的软件测试自动化框架。本文详细阐述了当今存在的几种自动化测试框架，并进行了比较；然后介绍了一个关键字驱动的自动化测试模型．以说明框架的具体实现方法。
自动化测试在过去的20年中已经有了很大的发展。最初的测试工具只提供了简单的捕捉／回放功能：记录并播放键盘按键，然后捕捉和比较屏幕。这些测试方法虽然最容易应用，但是几乎不可能维护。录制回放工具最终被功能和灵活性更强的测试脚本工具代替。
但是，脚本工具也有自己的问题。他们实现起来需要很强的开发技术和经验，同时，不确定它们是一定可以维护的。更糟糕的是高度个性化的脚本工具技术．加上没有什么文档记录，最后的结果经常是重写包含成千上万行代码的脚本库，成本开销巨大。
后来，一种新的自动化测试产品——自动化测试框架出现了，它可以减少实现和维护的成本，使测试人员可以把精力集中在应用程序的测试用例设计上，而不是开发测试。
常用的自动化测试框架
所谓自动化测试框架，是由一些假设，概念和为自动化测试提供支持的实践组成的集合。接下来将描述一下几种比较常用的自动化测试框架：
1．录制／回放的神话
每一家自动化测试工具厂商都会宣传，他们的工具非常容易使用，没有技术背景的测试人员只要简单录制测试的操作过程，然后播放录制好的测试脚本，就可以轻松自动化所有的测试。这样的说法是非常不负责的。
现在我们来分析一下自动化测试不能单单只依靠录制／回放来完成的原因。
通过录制建立的脚本，基本上都是用脚本语言以硬编码的方式编写的，当应用程序变动时，这些硬编码也随之需要更改。因此，维护这些录制好的脚本，成本是非常高的，高到几乎不能接受。
所有的测试脚本都必须是在应用程序可以正确执行时才能录制，如果在录制过程中发现缺陷，测试人员必须向缺陷管理机制报告，等到该缺陷修正了，整个录制脚本的动作才能继续下去。在这样的情况下，如果仅仅依靠录制脚本来进行测试，效率是十分低下的。
同时，这些录制好的脚本不是非常可靠，甚至在应用程序完全没有变动的情况下直接播放，也可能因为一些意外状况而无法执行。如果录制脚本时测试人员使用了错误的脚本语言，则脚本就必须重新录制。
综上所述，通过录制的方式来建立自动化测试脚本的方式看似容易，但实际上会遇到下列问题：①测试人员大多不具备技术背景，难以完全掌握测试工具；②应用 程序必须达到一定的稳定性，才能开始录制测试脚本；③录制的测试脚本与测试数据耦合得太紧密；④维护自动化测试脚本的成本非常高。
因此，仅仅依靠录制／回放来完成自动化测试是远远不够的，我们应找到一种能解决上述问题并能很好地执行自动化测试的方法。
2.数据驱动的自动化测试框架
数据驱动的自动化测试是针对上述开发与测试之间紧密耦合问题提出的测试方法。通过建立测试与开发定义的软件元数据的关联——元数据映射表．在测试与开发 之间建立松耦合关系。不论测试人员修改测试脚本，还是开发人员修改软件，只需要修改元数据映射表，既可以满足测试与开发同步进行。这样，可以减少测试脚本 调试的工作量，更好的实现自动化测试。
什么是数据驱动的自动化测试框架
数据驱动的自动化测试框架是这样的一个框架，从某个数据文件(例如ODBC源文件、Excel文件、Csv文件、ADO对象文件等)中读取输入，输出的 测试数据，然后通过变量传入事先录制好的或手工编写的测试脚本中。其中，这些变量被用作传递(输入／输出)用来验证应用程序的测试数据。在这个过程中，数 据文件的读取、测试状态和所有测试信息都被编写进测试脚本里；测试数据只包含在数据文件中，而不是脚本里，测试脚本只是一个“驱动”，或者说是一个传送数 据的机制。
数据驱动脚本
数据驱动脚本就是那些和应用程序相关联的脚本。这些脚本通过录制或手工编写写进自动化工具私有的语言．然后对其中的变量赋予合适的数值，作为测试数据的输入。这些变量作为一些关键应用程序输入的媒介．使脚本能通过外部的数据来驱动应用程序。
1)可变数据，硬编码组件标志
这些数据驱动的脚本经常包含硬编码的数据．有时是一些窗口组件中非常脆弱的识别字符串。出现这种情况时，脚本很容易由于程序的更改而失去作用。
2)高度技术化的、重复的测试设计
数据驱动脚本的另一个共同特点就是，所有在测试设计上所作的努力最终都体现在自动化工具的脚本语言中，或者复制到手工和自动化测试脚本中。这意味着每个和自动化测试开发或执行有关的人必须对测试环境和自动化工具的编程语言非常精通。
优点与缺点
1)优点：①在应用程序开发的同时就可以同步建立测试脚本，而且当应用功能变动时，只需要修改业务功能部分的脚本；②利用模型化的设计，避免重复的脚 本，减少建立或维护脚本的成本；③测试输入数据，验证数据和预期的测试结果与脚本分开．存放在另外的数据文件里．利于测试人员修改和维护；④透过判断功能 回传值是“True”或“Fslse”，可作错误处理，增加了测试脚本的健壮性；⑤自动化测试开发人员创建数据驱动的测试过程．测试员创建测试数据；⑥在 测试的过程中收集测试结果，并在输入数据的语境中表示测试结果，这样可以简化手工结果分析。
2)缺点：①对自动化测试工具里的脚本语言必须非 常精通；②每个脚本都会对应多个数据文件，这些数据文件需要根据脚本的功能类别存放在各自的目录中，增加了使用的复杂性；③测试人员除了需要根据具体测试 数据维护相应的测试计划，还要将这些数据写入各个需求不同的数据文件中；④在编辑数据文件时，必须注意测试脚本所要求的传输格式，否则会在处理脚本时产生 错误。如由专门的技术人员对其进行维护，依赖于数据驱动脚本的自动化测试框架实现起来更简单、快捷。但是，维护工作困难，而且还需要保持这种数据驱动的模 式，这样，即便长时间的维持也会导致失败。
3．关键字驱动的自动化测试
关键字驱动的自动化测试(也称为表驱动测试自 动化)，是数据驱动自动化测试的变种，可支持由不同序列或多个不同路径组成的测试。它是一种独立于应用程序的自动化框架，在处理自动化测试的同时也要适合 手工测试。关键字驱动的自动化测试框架建立在数据驱动手段之上，表中包含指令(关键词)，而不只是数据。这些测试被开发成使用关键宇的数据表，它们独立于 执行测试的自动化工具。关键字驱动的自动化测试是对数据驱动的自动化测试的有效改进和补充。
关键字驱动的自动化测试的整个过程所包含的功能都是由关键字驱动的，关键字控制了整个测试过程。下面以“Post
a Payment”为例．说明这种自动化测试方法是如何运作的(表1)。
上表的COLUMN1里的每一个关键字都与一个应用脚本有关，而其他栏标识的是该脚本所要传入的参数。事实上，按照这个表格里所描述的测试用例．测试人员也可以手工实行这个测试用例。
图1以表1所描述的测试用例为例，说明了整个关键字驱动的自动化测试的运作机制：
1)测试人员会以ExceI表格建立如表1所示的测试数据文件，如KeyWord_Web．xls；
2)会有一个驱动测试脚本启动整个测试的进行，包含一些初始化的工作，如Driver脚本；
3)Controller脚本包含负责解析整个测试数据文件的关键字，以便决定运行哪一个应用脚本；
4)应用脚本实际执行每个测试动作，并使用表1中其他栏里的参数，执行完后将结果回传给Controller脚本，当Con-troller脚本执行到最后一行，整个测试用例结束执行。
需要注意的是，虽然这种自动化测试方法同时适合手工和自动执行，但并不意味着只要应用程序准备好可以执行，这些测试就能自动地执行。表1中的记录很容易被测试人员理解和执行，但是，除非我们提供给它，自动化框架不知道记录中对象的任何信息。
优劣分析
关键字驱动的自动化测试框架是一种截然不同的思想，它把传统测试脚本中变化的与不变的东西进行了分离，这种分离使得分工更明确，并且避免了它们相互之间 的影响。 这种模型的开发和实现与传统的测试流程相比可能是困难的，最耗时的，因为，我们正在努力地将我们的测试和自动化工具以及应用程序本身的变化完全隔离开来。 为了实现这个目标，最重要的是要增强自动化工具所提供的组件功能，例如，错误纠正、避免和数据同步。但是这样的投资是一次性的，一旦开发结束并投入使用， 它给我们带来的效益是巨大的，是自动化测试框架中最容易维护和使用的，而且可以反复运用于各种应用中，长期发挥作用。
另外，现在已经有一些符合需求的商业化产品可供使用，减少了实现这种框架的困难。利用关键字驱动的自动化测试框架，测试人员不需要录制测试脚本，而是设计测试脚本。
4．混合的自动化测试框架
结合以上几种自动化测试框架的比较，目前最为成功的自动化测试框架应是综合使用数据驱动和关键字驱动的自动化测试框架：以数据驱动的脚本作为输入，通过 关键字驱动框架的处理得到测试结果，完成自动化测试过程。这样可以使数据驱动的脚本利用关键字驱动框架通常所提供的库和工具。这些框架工具可以使数据驱动 的脚本更为紧凑，而且也不容易失败。
关键字驱动的自动化测试框架模型
下面将介绍一种以关键字驱动自动化测试框架思想为指导的自动化测试实现方案——关键字驱动的自动化测试模型，它是由SAS Institute的Carl Nagle开发的。图2描述了该测试模型的结构。
这个模型主要由核心数据驱动引擎、组件函数、支持库和应用映射表组成。自动化测试首先由初始脚本开始执行，这个脚本把高层测试表传递给高层驱动器，高层 驱动器在处理这些表的过程中．遇到中层测试表后就调用中层驱动器，中层驱动器处理中层表时也作类似的处理。当低层驱动器处理低层表时，它尝试着使应用与测 试保持同步。当低层驱动器遇到对某一个组件的低层关键字组件时，它判断这个组件的类型并调用相应的组件函数模块来处理这个指令操作。所有这些元素都要依靠 映射表中的信息，它是自动化测试模型和被测应用程序的桥梁。
应用映射表
应用映射表是自动化测试模型中最关键的组件之 一。在进行测试设计之前，测试人员首先对应用中的每一个对象定义一套命名规范，并利用映射表把这些名字和自动化工具识别的对象名联系起来，使工具能准确地 定位和操纵对象。我们的测试脚本只需进行单点维护。在上面的例子中，如果按钮的名字或显示文字发生了变化，那么脚本中所有涉及这些名字的地方都要进行修 改。如果我们建立这样一个映射．用逻辑对象SavePushButton表示真实的确认保存的按钮对象，那么这个例子就可以写成“Click SavePushButton”。当按钮的名字或显示文字改变时，只需要快速修改一下映射表中对应的识别方法就可以了，而不用修改脚本(表2)
组件函数
组件函数是实现用户对界面对象操作指令的函数，一个组件对象的类型对应一个组件函数库。例如对于一个文本框对象．测试人员可能会对它执行多种操作：输入 文本、验证文本框的值、验证文本框的某些属性等，实现这些操作行为的函数就被放在文本框的组件函数库中。一般的测试工具都提供了这样的函数，而我们可以在 其中加入额外的代码来检测错误、纠正错误和帮助同步，这类代码是实现无人职守的自动化测试所必需的。
组件函数相当于在应用和自动化工具之间提 供了一个隔离层．如果没有这个隔离层．自动化工具本身的改变或提高就会影响已有的脚本．但是有了组件函数，我们可以增加一对修补代码来适应这些变化，转移 对测试的破坏。组件函数关键字和它们的参数构成自动化模型最低层的词库．了解了低层词库和映射表，就可以建立在它们基础之上的测试表。
测试表和核心数据驱动引擎
测试表分低层、中层和高层。低层测试表指定了测试的每一步指令的细节，这些指令都是直接作用在界面对象上的，是无法再细分的指令。中层测试表把低层测试 表组装起来执行更多有用的任务。同一个低层表可以用于多个中层表，所以我们应该开发尽可能少的低层表，然后把它们按照不同的目的组装起来．实现最大的重用 性。同样的，高层测试表把中层表组装起来，形成一个测试循环，每个循环都是完整的，可以定制不同类型和数量的测试。
例如打开网页、登录。关闭 网页这3个动作可以用3个低层表来表示，每个表定义了实现相应动作的具体步骤，所以低层表又叫做步骤表。低层表中使用了映射表中定义的对象名．和由组件函 数定义的低层关键字词库。表3是一个实现登录动作的低层表。而这个表示“登录”的低层表关键字很可能会出现在“验证错误登录”。“验证正确登录”、“验证 空白登录”等中层表中，这些中层表合起来构成了“验证权限”高层表。
对应于以上这3个测试表．核心数据驱动引擎相应地分成了高层驱动器．中层驱动器和低层驱动器。高层驱动器读取高层表的每个记录，如果遇到中间表关键字。 就把这个表传递给中层驱动器，依此类推，直至到达低层表，低层驱动器调用关键字词库中的低层指令所对应的组件函数来完成最后的执行。最后要说明的是这样一 种层次结构并不是固定不变的．可以根据实际应用情况进行调整。
支持库
支持库是一些程序和工具，例如文件处理、字符串处理、缓；中处理、数据库访问、日志记录工具等，它们为自动化模型提供最基础的支持。
结语
自动化测试框架无疑是企业实施自动化测试的一个必然的发展方向．它对于产生成功的测试自动化的适当基础是重要的。为了选择一个合适的自动化测试框架．企 业需要综合考虑维护成本、测试数据、可测试性、测试人员的技能等诸多因素。回顾自动化测试发展的过程，以往的经验告诉我们，无法依靠简单的录制／回放的测 试方法或传统的测试脚本工具来完成测试，因为录制产生的脚本维护困难，而且生存期很短。因此，为了减少实现和维护的成本，使测试人员可以把精力集中在应用 程序的测试用例设计上，关键字驱动自动化框架加上数据驱动的脚本是现阶段自动化测试实践中最好的解决方法。
自动化测试在过去的20年中已经有了很大的发展。最初的测试工具只提供了简单的捕捉／回放功能：记录并播放键盘按键，然后捕捉和比较屏幕。这些测试方法虽然最容易应用，但是几乎不可能维护。录制回放工具最终被功能和灵活性更强的测试脚本工具代替。
但是，脚本工具也有自己的问题。他们实现起来需要很强的开发技术和经验，同时，不确定它们是一定可以维护的。更糟糕的是高度个性化的脚本工具技术．加上没有什么文档记录，最后的结果经常是重写包含成千上万行代码的脚本库，成本开销巨大。
后来，一种新的自动化测试产品——自动化测试框架出现了，它可以减少实现和维护的成本，使测试人员可以把精力集中在应用程序的测试用例设计上，而不是开发测试。
常用的自动化测试框架
所谓自动化测试框架，是由一些假设，概念和为自动化测试提供支持的实践组成的集合。接下来将描述一下几种比较常用的自动化测试框架：
1．录制／回放的神话
每一家自动化测试工具厂商都会宣传，他们的工具非常容易使用，没有技术背景的测试人员只要简单录制测试的操作过程，然后播放录制好的测试脚本，就可以轻松自动化所有的测试。这样的说法是非常不负责的。
现在我们来分析一下自动化测试不能单单只依靠录制／回放来完成的原因。
通过录制建立的脚本，基本上都是用脚本语言以硬编码的方式编写的，当应用程序变动时，这些硬编码也随之需要更改。因此，维护这些录制好的脚本，成本是非常高的，高到几乎不能接受。
所有的测试脚本都必须是在应用程序可以正确执行时才能录制，如果在录制过程中发现缺陷，测试人员必须向缺陷管理机制报告，等到该缺陷修正了，整个录制脚本的动作才能继续下去。在这样的情况下，如果仅仅依靠录制脚本来进行测试，效率是十分低下的。
同时，这些录制好的脚本不是非常可靠，甚至在应用程序完全没有变动的情况下直接播放，也可能因为一些意外状况而无法执行。如果录制脚本时测试人员使用了错误的脚本语言，则脚本就必须重新录制。
综上所述，通过录制的方式来建立自动化测试脚本的方式看似容易，但实际上会遇到下列问题：①测试人员大多不具备技术背景，难以完全掌握测试工具；②应用 程序必须达到一定的稳定性，才能开始录制测试脚本；③录制的测试脚本与测试数据耦合得太紧密；④维护自动化测试脚本的成本非常高。
因此，仅仅依靠录制／回放来完成自动化测试是远远不够的，我们应找到一种能解决上述问题并能很好地执行自动化测试的方法。
2.数据驱动的自动化测试框架
数据驱动的自动化测试是针对上述开发与测试之间紧密耦合问题提出的测试方法。通过建立测试与开发定义的软件元数据的关联——元数据映射表．在测试与开发 之间建立松耦合关系。不论测试人员修改测试脚本，还是开发人员修改软件，只需要修改元数据映射表，既可以满足测试与开发同步进行。这样，可以减少测试脚本 调试的工作量，更好的实现自动化测试。
什么是数据驱动的自动化测试框架
数据驱动的自动化测试框架是这样的一个框架，从某个数据文件(例如ODBC源文件、Excel文件、Csv文件、ADO对象文件等)中读取输入，输出的 测试数据，然后通过变量传入事先录制好的或手工编写的测试脚本中。其中，这些变量被用作传递(输入／输出)用来验证应用程序的测试数据。在这个过程中，数 据文件的读取、测试状态和所有测试信息都被编写进测试脚本里；测试数据只包含在数据文件中，而不是脚本里，测试脚本只是一个“驱动”，或者说是一个传送数 据的机制。
数据驱动脚本
数据驱动脚本就是那些和应用程序相关联的脚本。这些脚本通过录制或手工编写写进自动化工具私有的语言．然后对其中的变量赋予合适的数值，作为测试数据的输入。这些变量作为一些关键应用程序输入的媒介．使脚本能通过外部的数据来驱动应用程序。
1)可变数据，硬编码组件标志
这些数据驱动的脚本经常包含硬编码的数据．有时是一些窗口组件中非常脆弱的识别字符串。出现这种情况时，脚本很容易由于程序的更改而失去作用。
2)高度技术化的、重复的测试设计
数据驱动脚本的另一个共同特点就是，所有在测试设计上所作的努力最终都体现在自动化工具的脚本语言中，或者复制到手工和自动化测试脚本中。这意味着每个和自动化测试开发或执行有关的人必须对测试环境和自动化工具的编程语言非常精通。
优点与缺点
1)优点：①在应用程序开发的同时就可以同步建立测试脚本，而且当应用功能变动时，只需要修改业务功能部分的脚本；②利用模型化的设计，避免重复的脚 本，减少建立或维护脚本的成本；③测试输入数据，验证数据和预期的测试结果与脚本分开．存放在另外的数据文件里．利于测试人员修改和维护；④透过判断功能 回传值是“True”或“Fslse”，可作错误处理，增加了测试脚本的健壮性；⑤自动化测试开发人员创建数据驱动的测试过程．测试员创建测试数据；⑥在 测试的过程中收集测试结果，并在输入数据的语境中表示测试结果，这样可以简化手工结果分析。
2)缺点：①对自动化测试工具里的脚本语言必须非 常精通；②每个脚本都会对应多个数据文件，这些数据文件需要根据脚本的功能类别存放在各自的目录中，增加了使用的复杂性；③测试人员除了需要根据具体测试 数据维护相应的测试计划，还要将这些数据写入各个需求不同的数据文件中；④在编辑数据文件时，必须注意测试脚本所要求的传输格式，否则会在处理脚本时产生 错误。如由专门的技术人员对其进行维护，依赖于数据驱动脚本的自动化测试框架实现起来更简单、快捷。但是，维护工作困难，而且还需要保持这种数据驱动的模 式，这样，即便长时间的维持也会导致失败。
3．关键字驱动的自动化测试
关键字驱动的自动化测试(也称为表驱动测试自 动化)，是数据驱动自动化测试的变种，可支持由不同序列或多个不同路径组成的测试。它是一种独立于应用程序的自动化框架，在处理自动化测试的同时也要适合 手工测试。关键字驱动的自动化测试框架建立在数据驱动手段之上，表中包含指令(关键词)，而不只是数据。这些测试被开发成使用关键宇的数据表，它们独立于 执行测试的自动化工具。关键字驱动的自动化测试是对数据驱动的自动化测试的有效改进和补充。
关键字驱动的自动化测试的整个过程所包含的功能都是由关键字驱动的，关键字控制了整个测试过程。下面以“Post
a Payment”为例．说明这种自动化测试方法是如何运作的(表1)。
上表的COLUMN1里的每一个关键字都与一个应用脚本有关，而其他栏标识的是该脚本所要传入的参数。事实上，按照这个表格里所描述的测试用例．测试人员也可以手工实行这个测试用例。
图1以表1所描述的测试用例为例，说明了整个关键字驱动的自动化测试的运作机制：
1)测试人员会以ExceI表格建立如表1所示的测试数据文件，如KeyWord_Web．xls；
2)会有一个驱动测试脚本启动整个测试的进行，包含一些初始化的工作，如Driver脚本；
3)Controller脚本包含负责解析整个测试数据文件的关键字，以便决定运行哪一个应用脚本；
4)应用脚本实际执行每个测试动作，并使用表1中其他栏里的参数，执行完后将结果回传给Controller脚本，当Con-troller脚本执行到最后一行，整个测试用例结束执行。
需要注意的是，虽然这种自动化测试方法同时适合手工和自动执行，但并不意味着只要应用程序准备好可以执行，这些测试就能自动地执行。表1中的记录很容易被测试人员理解和执行，但是，除非我们提供给它，自动化框架不知道记录中对象的任何信息。
优劣分析
关键字驱动的自动化测试框架是一种截然不同的思想，它把传统测试脚本中变化的与不变的东西进行了分离，这种分离使得分工更明确，并且避免了它们相互之间 的影响。 这种模型的开发和实现与传统的测试流程相比可能是困难的，最耗时的，因为，我们正在努力地将我们的测试和自动化工具以及应用程序本身的变化完全隔离开来。 为了实现这个目标，最重要的是要增强自动化工具所提供的组件功能，例如，错误纠正、避免和数据同步。但是这样的投资是一次性的，一旦开发结束并投入使用， 它给我们带来的效益是巨大的，是自动化测试框架中最容易维护和使用的，而且可以反复运用于各种应用中，长期发挥作用。
另外，现在已经有一些符合需求的商业化产品可供使用，减少了实现这种框架的困难。利用关键字驱动的自动化测试框架，测试人员不需要录制测试脚本，而是设计测试脚本。
4．混合的自动化测试框架
结合以上几种自动化测试框架的比较，目前最为成功的自动化测试框架应是综合使用数据驱动和关键字驱动的自动化测试框架：以数据驱动的脚本作为输入，通过 关键字驱动框架的处理得到测试结果，完成自动化测试过程。这样可以使数据驱动的脚本利用关键字驱动框架通常所提供的库和工具。这些框架工具可以使数据驱动 的脚本更为紧凑，而且也不容易失败。
关键字驱动的自动化测试框架模型
下面将介绍一种以关键字驱动自动化测试框架思想为指导的自动化测试实现方案——关键字驱动的自动化测试模型，它是由SAS Institute的Carl Nagle开发的。图2描述了该测试模型的结构。
这个模型主要由核心数据驱动引擎、组件函数、支持库和应用映射表组成。自动化测试首先由初始脚本开始执行，这个脚本把高层测试表传递给高层驱动器，高层 驱动器在处理这些表的过程中．遇到中层测试表后就调用中层驱动器，中层驱动器处理中层表时也作类似的处理。当低层驱动器处理低层表时，它尝试着使应用与测 试保持同步。当低层驱动器遇到对某一个组件的低层关键字组件时，它判断这个组件的类型并调用相应的组件函数模块来处理这个指令操作。所有这些元素都要依靠 映射表中的信息，它是自动化测试模型和被测应用程序的桥梁。
应用映射表
应用映射表是自动化测试模型中最关键的组件之 一。在进行测试设计之前，测试人员首先对应用中的每一个对象定义一套命名规范，并利用映射表把这些名字和自动化工具识别的对象名联系起来，使工具能准确地 定位和操纵对象。我们的测试脚本只需进行单点维护。在上面的例子中，如果按钮的名字或显示文字发生了变化，那么脚本中所有涉及这些名字的地方都要进行修 改。如果我们建立这样一个映射．用逻辑对象SavePushButton表示真实的确认保存的按钮对象，那么这个例子就可以写成“Click SavePushButton”。当按钮的名字或显示文字改变时，只需要快速修改一下映射表中对应的识别方法就可以了，而不用修改脚本(表2)
组件函数
组件函数是实现用户对界面对象操作指令的函数，一个组件对象的类型对应一个组件函数库。例如对于一个文本框对象．测试人员可能会对它执行多种操作：输入 文本、验证文本框的值、验证文本框的某些属性等，实现这些操作行为的函数就被放在文本框的组件函数库中。一般的测试工具都提供了这样的函数，而我们可以在 其中加入额外的代码来检测错误、纠正错误和帮助同步，这类代码是实现无人职守的自动化测试所必需的。
组件函数相当于在应用和自动化工具之间提 供了一个隔离层．如果没有这个隔离层．自动化工具本身的改变或提高就会影响已有的脚本．但是有了组件函数，我们可以增加一对修补代码来适应这些变化，转移 对测试的破坏。组件函数关键字和它们的参数构成自动化模型最低层的词库．了解了低层词库和映射表，就可以建立在它们基础之上的测试表。
测试表和核心数据驱动引擎
测试表分低层、中层和高层。低层测试表指定了测试的每一步指令的细节，这些指令都是直接作用在界面对象上的，是无法再细分的指令。中层测试表把低层测试 表组装起来执行更多有用的任务。同一个低层表可以用于多个中层表，所以我们应该开发尽可能少的低层表，然后把它们按照不同的目的组装起来．实现最大的重用 性。同样的，高层测试表把中层表组装起来，形成一个测试循环，每个循环都是完整的，可以定制不同类型和数量的测试。
例如打开网页、登录。关闭 网页这3个动作可以用3个低层表来表示，每个表定义了实现相应动作的具体步骤，所以低层表又叫做步骤表。低层表中使用了映射表中定义的对象名．和由组件函 数定义的低层关键字词库。表3是一个实现登录动作的低层表。而这个表示“登录”的低层表关键字很可能会出现在“验证错误登录”。“验证正确登录”、“验证 空白登录”等中层表中，这些中层表合起来构成了“验证权限”高层表。
对应于以上这3个测试表．核心数据驱动引擎相应地分成了高层驱动器．中层驱动器和低层驱动器。高层驱动器读取高层表的每个记录，如果遇到中间表关键字。 就把这个表传递给中层驱动器，依此类推，直至到达低层表，低层驱动器调用关键字词库中的低层指令所对应的组件函数来完成最后的执行。最后要说明的是这样一 种层次结构并不是固定不变的．可以根据实际应用情况进行调整。
支持库
支持库是一些程序和工具，例如文件处理、字符串处理、缓；中处理、数据库访问、日志记录工具等，它们为自动化模型提供最基础的支持。
结语
自动化测试框架无疑是企业实施自动化测试的一个必然的发展方向．它对于产生成功的测试自动化的适当基础是重要的。为了选择一个合适的自动化测试框架．企 业需要综合考虑维护成本、测试数据、可测试性、测试人员的技能等诸多因素。回顾自动化测试发展的过程，以往的经验告诉我们，无法依靠简单的录制／回放的测 试方法或传统的测试脚本工具来完成测试，因为录制产生的脚本维护困难，而且生存期很短。因此，为了减少实现和维护的成本，使测试人员可以把精力集中在应用 程序的测试用例设计上，关键字驱动自动化框架加上数据驱动的脚本是现阶段自动化测试实践中最好的解决方法。
TAG:
