业务流程以及这些流程内的任务在更为多样的平台上执行，这就要求能够在界面间无缝移动，尤其是从移动到 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. 业务逻辑层次结构