测试自动化框架
“在开发我们的测试策略时，我们必须最小化因为应用程序的改变或测试工具的改变而对测试工作产生的影响。”
1.1 思考那些过时的“项目”
1.1.1 测试自动化的问题
案例学习：昂贵的自动化失败
1.1.2 一些测试策略指导
1.1.3 测试自动化是一个全职工作，而不是兼职
1.1.4 测试设计和测试框架是完全独立的
1.1.5 测试框架需要独立于应用程序
1.1.6 测试框架必须容易扩展、维护，并长期有效
1.1.7 测试策略/设计词汇应当独立于框架
1.1.8 测试策略/设计需要从复杂的测试框架中去除大多数测试者
1.2 数据驱动测试框架
1.2.1 数据驱动脚本
1.2.2 关键字或表驱动测试自动化
1.2.3 混合测试自动化（或，“所有上述”）
1.2.4 商业关键字驱动框架
1.3 关键字驱动自动化框架模型
下面这个自动化框架模型是经过 18 个月的计划、设计、编码和不断的调试完成的。不过那并不是说它需要花费 18 个月才能完成——实际上它的一个工作原型花费了大约 3 人月，也就是说，一个人在这上面花费了三个月。
这个模型的焦点在于实现“关键字驱动自动化框架”，而并没有包含象跟踪需求、跟踪自动化测试结果返回值之类的功能，也没有提供测试过程中需要的其他任何功能，它仅仅是提供了一个通过关键字驱动自动化执行测试的引擎。
市场上可买到框架一般有更多的特性和更广阔的应用范围——当然，对于这一点，也可以从它们的价格上体现出来。
1.3.1 项目指导
这个非正式的项目遵循以下指南和惯例：
1.3.2 代码和文档标准
1.3.3 我们的自动化框架
1.3.4 Application MAP
1.3.5 Component Functions
1.3.6 Test Tables
1.3.7 核心数据驱动引擎
1.3.8 支持库
1.4 自动化框架工作流程
我们已经看到我们的自动化框架的主要特征并且我们现在应该把它加到我们的测试中。这一节提供了一个对于这个框架可以非常有效工作的测试工作流程模型。具体说，就是我们先定义了一个高层次的套表（CycleTables），并提供越来越多的细节给我们的Application MAP和低层次的Step Tables。
例如，我们可以虚构一个关于某个WEB站点的安全行鉴定的假想测试设计。我们介绍这些信息并创建表的顺序是我们的自动化框架的一些理想的工作流程。它也将举例说明为什么我们甚至不需要为了展示这些测试而准备一些可以实际运行的应用程序。
1.4.1 高层测试－套表（Cycle Tables）
我们将开始定义我们的高层次 套表（Cycle Tables），参见 表16 。这里列出了那些检查“用户验证”功能所需的测试。那儿仍然没有应用程序，但是我们指导我们将通过在一个登录界面上输入一些用户ID和密码来验证一些用户。有了这些信息，我们可以开始设计一些测试。
在这个层次，我们的表里仅仅是关键字或我们计划做的动作。这些关键字表示当我们已经准备好了或者了解了更多关于应用程序的信息准备实现时那些组（Suites）的名称。
我们将试用高层次表 VerifyAuthenticationFunction 测试，参见 表16 。它将不会显示我们检查关于WEB站点“用户验证”特性所需要执行的所有测试，而仅仅是举例说明我们的测试设计过程。
| KEYWORDS (Suite Tables) | TABLE PURPOSE |
| VerifyInvalidLogin | Tests with Invalid UserID and/or Password |
| VerifyBlankLogin | Tests with Missing UserID and/or Password |
| VerifyValidLogin | Tests with Valid UserID and Password |
表16
上述表中举例说明了我们计划在检查我们的应用程序中的“用户验证”功能时运行的三个测试。我们将来可以在这个列表中添加或删除一个测试，但是，这是为什么我们当前相信这个功能可以被充分的测试。（but this is how we currently believe this functionality can be adequately verified.）
1.4.2 中间层测试－组表（Suite Tables）
当我们准备为我们的“用户验证”测试工作提供更多的细节时，我们可以开始充实我们的“中间层表”（Suite Tables）。我们现在必须在我们的高层 VerifyAuthenticationFunction 套表定义的三个“组”（suite）上进行扩展。
首先，我们计划检查用无效的用户ID或无效的密码或无效用户ID加上无效的密码来尝试无效的登录。这时第一个Suite Tables 被调用，VerifyInvalidLogin 参见 表17 。
其次，我们应该使用空的用户ID和密码进行一个简单的测试。这时第二个 Suites Tables 被调用，参见VerifyBlankLogin 表18 。
我们必须实现的最后一个 Suite Tables 是确保当我们提供了有效的用户ID和密码时可以成功的登录到系统。这个被命名为 VerifyValidLogin ，参见 表19 。
| KEYWORDS (Step Tables) | USERID | PASSWORD |
| LaunchSite | | |
| Login | BadUser | GoodPassword |
| VerifyLoginError | | |
| Login | GoodUser | BadPassword |
| VerifyLoginError | | |
| Login | BadUser | BadPassword |
| VerifyLoginError | | |
| ExitLogin | | |
|
Suite Table: VerifyBlankLogin |
||
|
KEYWORDS (Step Tables) |
USERID |
PASSWORD |
|
LaunchSite |
|
|
|
Login |
"" |
"" |
|
VerifyLoginError |
|
|
|
ExitLogin |
|
|
|
Suite Table: VerifyValidLogin |
||
|
KEYWORDS (Step Tables) |
USERID |
PASSWORD |
|
LaunchSite |
|
|
|
Login |
GoodUser |
GoodPassword |
|
VerifyLoginSuccess |
|
|
|
ShutdownSite |
|
|
表 19
注意，我们开始发现有大量的测试表在这里可以重用。在还没有完成定义之前，我们就会发现，我们会非常频繁的使用LaunchSite, Login, VerifyLoginError, 和 ExitLogin 。同样你可以想像，VerifyLoginSuccess 和 ShutdownSite 也将在关于这个WEB站点的所有测试中被广泛的使用，但是在这里我们只关注“用户验证”。
你应该也注意到了，我们的 Login 关键字是描述了一个 Step Tables，它将接收两个参数——我们希望提供的用户ID和密码。我们还不能明确如何设计自动化框架将要实现的那些细节，但是测试可以接收不同的数据便提供了重用的可能。这些表可以在用不同的用户ID和密码进行组合登录系统时使用。
1.4.3 Application MAPs
到现在为止，我们都还没有用到 Application MAP 。几乎所有的高层和中层测试都是在参考特定的窗口组件之前抽象完成。但是当我们接近我们的最底层测试设计时，我们就真正地需要参考特定的应用程序元素。因此，对于测试自动化，我们需要建立我们的 Application Map 。
组件命名：
这件事情要测试团队自己来做，除非应用程序有完备的设计文档明确的为窗体和组件提供有意义的名字。
整个团队必须讨论并一致通过每个窗体和组件的命名。有时候我们可以使用开发者在代码中已经分配给组件的名字。但是团队会经常为了有意义的和可以明确标示的名字进行讨论。但是不管怎么说，一定定义好了，选定的名字就不能改变。否则，如果这种需要出现，一个项目就总会有多于一个的名字。
Test Design Application Map:
对于底层的测试设计和手工测试，应该建立一个适合人们使用的 Application Map ，这个Application MAP通常是从屏幕上的各种应用程序窗口捕获到的。当给每个组件命名时，这些屏幕捕获可以作为明确的参考，同时也可能指明了每个组件的类型（TYPE）。
虽然大多数控件可以比较准确的定义，但是也不是全是这样。也有很多控件是没有窗体的或者不能通过应用程序界面识别的，比如 COM 对象。所以，对于不同对象的识别还要考虑对象的类型（TYPE）信息。
Automation Framework Application Map:
对于自动化测试，需要建立一个适合自动化框架使用的 Application MAP ，我们将使用 Test Design Application Map 中用于标示对象的那些命名。The identification syntax suitable for the automation tool will then be mapped to each name as discussed in Section 1.3.4.
我们的测试设计迄今为止已经包括了三个界面：（1）登录界面；（2）登录失败是显示的错误提示信息对话框；（3）登录成功时显示的 WEB 站点的主页。在测试过程中我们还要考虑浏览器界面。
|
我们现在必须建立一个 Application MAP ——它包含了上面三项中的所有对象已经它们在自动化框架中对应的识别方法。为了简单起见，我们的登录界面之包括用户ID和密码两个 EDIT 组件，以及 SUBMIT 和 CANCEL 两个按钮（BUTTON），参见 图7 |
|
|
图 7
错误提示对话框实际上是一个系统警告提示对话框，参见 图8 ，对话框上有一个包含错误信息的 Label 和一个 OK 按钮。
图 8
应用程序的主界面可能包含了很多不同的元素，不过，对于我们这次测试的目的和这个例子，我们仅仅需要识别出这个界面就可以了。因为我们并不准备把主页上所有的组件都包含进来，所以我们只需要建立一个简单的 Application MAP就可以了。
表20中显示了我们用于识别浏览器窗口和三个页面的适合自动化框架使用的内容。
|
OBJECTNAME |
IDENTIFICATION METHOD |
|
Browser: |
|
|
Browser |
WindowID=WebBrowser |
|
|
|
|
LoginPage: |
|
|
LoginPage |
FrameID=content;\;DocumentTitle=Login |
|
UserID |
FrameID=content;\;DocumentTitle=Login;\;TextBoxIndex=1 |
|
Password |
FrameID=content;\;DocumentTitle=Login;\;TextBoxIndex=2 |
|
SubmitButton |
FrameID=content;\;DocumentTitle=Login;\;ButtonText=Submit |
|
CancelButton |
FrameID=content;\;DocumentTitle=Login;\;ButtonText=Cancel |
|
|
|
|
ErrorWin: |
|
|
ErrorWin |
WindowCaption=Error |
|
ErrorMessage |
LabelIndex=1 |
|
OKButton |
ButtonText=OK |
|
|
|
|
HomePage: |
|
|
HomePage |
FrameID=content;\;DocumentTitle=Home |
表 20
Application MAP 的物理格式决定了自动化框架如何访问它，我们可以使用文本文件、数据库表、电子表格等方式来存放 Application Map 。
注意，在 表20 所示的 Application Map 中，我们为每个需要识别的界面分配了一节。我们的应用中包含了很多组件，我们需要避免它们之间的命名冲突。例如，可能在很多窗体中包含了 Submit 按钮，每个窗体中都可以有一个命名为 SubmitBuuton 的按钮，因为它们中的每一个在 Application Map 中的某一个节中都是唯一的。
我们现在已经为我们的所有组件建立了明确的标示，其中 OBJECTNAME 是在底层的 Step-Tables 中调用某个组件的标志，而 IDENTIFICATION METHOD 则是具体定义了在计算机识别不同组件时所需要的信息。
The syntax for these component identifications is different depending upon the automation tool deployed. The example syntax we used is not for any particular automation tool, but is representative of what is needed for automation tools in general. The Application Map designer will need a thorough understanding of the automation tool’s component identification syntax in order to create effective Application Maps.
新的组件类型：
当我们检查一个应用和开发一个 Automation Framework Application Map 时，我们可能会发现一个在我们手头上的 Component Functions 中不存在的的组件类型。对于这种情况，we need to either implement a new Component Function module for each new component type, or determine how best they can be handled by existing Component Functions. 对于这个过程，应该由专职的自动化技术人员来进行。
1.4.4 底层测试－步骤表（Step Tables）
当我们已经知道了应用的设计情况，并且我们的 Application Map 已经开发完成，我们可以开始认真考虑我们测试中具体的细节。我们也可以在没有 Application Map 的情况下开发 Step Tables ，但是如果没有 Application Map ，我们就不能自动化执行那些测试。
回顾在高层的 VerifyAuthenticationFunction Cycle Table 中描述的所有 Suite ，我们发现有 6 个调用是被重复使用的，参见 表21 中列出的部分。我们将在 Step Tables 中实现它们。
|
STEP TABLE |
TABLE PURPOSE |
|
LaunchSite |
Launch the web app for testing |
|
Login |
Login with a User ID and Password |
|
VerifyLoginError |
Verify an Error Dialog on Invalid Login |
|
ExitLogin |
Exit the Login Page via Cancel |
|
VerifyLoginSuccess |
Verify Home Page up after Successful Login |
|
ShutdownSite |
Logoff and close the browser |
表 21
1.5 摘要
