该方法的另一个好处是：尽管仍然被表示为代码，但它在一个足够高的抽象级别可读取为伪代码，这对非编程人员 SME 很有意义。这让非编程人员能够创建新的自动化脚本，以及运行和理解自动化团队所交付的测试脚本。
清单 1 是与 Eclipse 视图交互的一个示例代码。
清单 1. 与 Eclipse 视图交互的代码
| Perspective resource = new Perspective("Resource"); Perspective general = new Perspective("General"); app.start(); EclipseView bookmarks = new EclipseView("Bookmarks", resource); EclipseView explorer = new EclipseView("Project Explorer",general); resource.open(); resource.reset(); bookmarks.open(); explorer.open(); bookmarks.switchTo(); explorer.switchTo(); bookmarks.maximize(); bookmarks.restore(); bookmarks.minimize(); bookmarks.restore(); bookmarks.close(); resource.reset(); app.exit(); |
采用这种方法可以降低维护成本，并能确保对于 GUI 的任何部分，在自动化测试代码内都只需在一个地方进行调整。但这种方法的好处只有在 CLI 上实现了进行业务逻辑的具体步骤之后才会变得真正清晰。
负责测试该特性的团队已宣布 “完成”，且没有明显的缺陷。自动化的实现是为了为未来版本确保一个回归测试套件。但是当我们运行用来针对此 CLI 实现测试 GUI 的测试脚本时，就会发现 50 多个缺陷！这些都是重要的缺陷，肯定会被我们的客户发现。
作为测试人员，我们总是很兴奋能首先发现缺陷，因为早期发现问题能明显节约成本。另外，构建不只能验证产品稳定性的测试自动化也很令人兴奋。同样重要的就是信誉、既有的顾客满意度，以及此测试自动化所带来的整体质量改进方面的商业利益。
如今的多通道测试
在上述的项目过程中，我们可以在运行时只选择一个界面。一个测试脚本必须是完全自动化的，且必须要有为每个需要测试的界面实现的一个完整的业务逻辑操作集。这种方式在当时是合理的也是可以接受的，这是因为最终用户一般不会在一组操作期间从一个桌面客户端切换到一个 Web 客户端。
但时过境迁。现在考虑一个可能开始于 Web 客户端、穿过一个移动应用程序、然后再回到 Web 的测试场景，甚或是一个针对数据库后端的独立验证已不再符合实际了。
考虑这样一个场景：有人在 eBay 竞价。使用一个台式计算机和浏览器（Web 客户端）对商品进行搜索和研究更容易。一旦决定了想要的商品，就可以进行竞价。您可以离开计算机，并在您的智能手机收到一个通知，告知您竞价胜出，于是您从手机上更新出价。当赢得竞价时，您再回到计算机前，在浏览器中输入付款信息。
这是一个测试场景，与其从屏幕上此界面的一个部分（使用屏幕抓取或对象属性）中验证交易的成功，还不如直接使用数据库并检查记录。这种独立于界面的验证更健壮，也更稳定。我们可以把这种方式称为 “混合” 测试场景。并且，从理论上来说，当自动化一些产品区域太难（或过于昂贵）时，混合场景应该允许混合进手动测试执行来提高测试覆盖率。
所以，我已经开始幻想如何能实现这样一个流，于是我将不同的界面和操作实现拼装成一个能在界面之间无缝移动的复杂流。可以肯定的是，的确存在挑战，并且挑战可能会不可逾越。而了解了当运行时环境受制约时哪些数据在操作间移动则会相对简单得多。而当跨越界面时，哪些数据可能需要在操作间传输则不能立即清晰。使用上面的示例，将需要先登录到一个 Web 客户端和移动电话。身份验证明显是个问题，但实现这些混合测试场景注定会有很多并发问题。
