解决多通道测试的挑战

　　简介： 随着移动以及有 Web 功能的应用程序的飞速传播，多通道测试出现了新的挑战，或是单个测试场景跨几个界面交叉。业务流程以及这些流程内的任务在更为多样的平台上执行，这就要求能够在界面间无缝移动，尤其是从移动到 Web 以及反向移动。过去曾经有效的那些举措导致了应对未来的讨论。

　　多通道 描述的是具有多个界面的应用程序。随着我们从桌面发展到基于 Web 的计算甚至是移动计算，多通道越来越常见。由于设备(平板、手机、笔记本电脑、台式计算机)以及与设备交互方式(特定于设备的 “应用程序”、浏览器和传统的客户端应用程序)的组合，同一个应用程序的界面越来越多。比如，使用相同业务逻辑的面向 Web 应用程序、移动应用程序甚至是一个 CLI(命令行界面)的银行应用程序。由于面向服务的架构 (SOA) 和 Web 服务日益流行，在很多情况下，集成者要做的工作就是把服务与新的前端重新组合。但业务逻辑(亦称服务)则保持相同。

　　以开发团队重用代码来减少维护成本并提高生产效率相同的方式，要跟上开发团队，测试团队就需要一些方法来重用测试场景并实现自动化。

　　应对多通道测试的挑战

　　几年前，我是一名自动化测试架构师，负责为具有多个界面的两个(而不是一个)应用程序构建所有的自动化。二者都有遗留的 “本地” 用户界面，使用的是 Microsoft Windows 32 位 MFC (Microsoft Foundation Class) 控件、一个使用了 JavaScript 的 Web 界面、ASP 和 JSP(Active Server Pages 和 JavaServer Pages)、一个新的(更新的)Eclipse SWT (Standard Widget Toolkit) 界面以及一个命令行界面。当然，不可能找到对所有这些界面均有效的自动化工具，但我们可以暂时将其放到一边。

　　编程时，您往往会专注于通过促进重用减少需要维护的代码量。有了面向对象的编程和重构，很少有理由需要在多个地方具有相同的代码了。但是需要设计一个架构，这样我就可以考虑如何从一个单一的测试自动化代码库解决多个界面的测试。首先，尽管它们是同一个应用程序的所有界面，但并不是所有的界面都会浮现相同的功能，更不用说使用同样的方式了。但也有许多以客户为中心的场景(用例)，这对跨所有界面进行测试很有意义。

　　然而，负责设计测试用例和测试计划的测试团队没有以这种方式考虑他们的测试。事实上，他们是分离的，并根据他们所要处理的界面以竖井方式分离。构建并测试了该 CLI 的团队认为他们只需要少量的客户场景测试。他们主要集中于单元测试，并没有真正考虑通过 CLI 的一个客户流。负责 Eclipse UI 的测试团队想要大量的 UI 特性和自动化的功能。他们有一长串需要执行的测试用例，要实现这个目标，需要完全专注于客户流。但是，我们为什么就不能使用由主题专家 (SME) 为应用程序煞费苦心完成的用来测试所有界面的这些信息呢?

　　一种层次结构方式

　　使用面向对象的编程 (OOP) 的典型测试自动化框架一般会抽象化控制集的实现细节，而不是通过控件表达的概念性操作。这实际上是许多商业 GUI 自动化工具使用的方式。例如，所有文本字段会接受文本，用 setText(string) 方法定义一个文本字段类，并在此应用程序的所有版本上使用它。但这并不适用于跨界面构建自动化测试的所有情况。当一个 GUI 使用单选按钮而另一个使用复选框时会发生什么呢?您实际上不能对于相同操作依靠于同一界面。以下显示了这种传统的 OOP 方式。

　　图 1. GUI 控制层次结构

　　在我们的示例中，界面的差异很大，但所代表的操作和业务流程则实质上相同。为了最大化重用，我们选定了一个业务逻辑层次结构(参见图 2)以跨多个界面重用测试场景。这不仅能最大化我们的代码重用，还意味着将会依赖测试工具来管理 GUI 界面，而这正是他们的设计初衷。图 2 显示了此方式，您可能已经识别出了这个抽象工厂模式。

　　图 2. 业务逻辑层次结构

　　通过采用业务逻辑的方式，通过应用程序的每个流都可以表示成操作集，而操作又被定义为抽象类上的方法。虽然每个界面都可能在操作内具有一些不同的步骤，但它们都允许、理解和需要这些相同的操作。这就相当于为了测试而构建一个特定于应用程序的测试框架来代表测试业务任务下的这个应用程序。这种方法意味着要定义一组对象，在应用程序中执行操作所需的数据和信息就可以封装在对象之中。然后，我们需要在这些对象内定义一组方法来描述操作，并收集操作专门需要的任何额外的数据，如图 3 中的代码片段所定义的。

　　图 3. 抽象类的代码示例

　　以文本表单格式查看图 3 的代码

　　Query 是一个抽象类，收集创建和执行查询所需的有趣数据，以及有趣操作，如运行、创建、编辑和重命名。重命名方法需要新名称的额外参数，但当它成功后，会自动更新此查询对象的名称值。在这个级别对用户界面没有假设。用户界面的细节只在特定于界面的具体类内表达。要在一个给定的界面上执行，需要在运行时为每个界面实例化一个具体类并调用此操作，具体类似于如下所示：

Query myQuery = (parent_location, findRecords);
myQuery.rename(renamedQuery); 

原文转自：http://www.ibm.com/developerworks/cn/rational/multichannel-testing-challenge/index.html