解决多通道测试的挑战(2)

　　基于应用程序的框架

　　定义用来描述测试所需操作的抽象业务逻辑类的一个后果是可以将所定义的方法重组成新的流。此外，还可以指定在运行时运行哪个界面。这是一个强大的组合，可以完成几件事情：

　　针对此应用程序的操作只定义一次

　　GUI 元素只被发现和处理一次

　　为一个界面设计的测试场景可以在另一个界面上运行

　　因重用的增加，维护显著减少

　　当然，这其中的诀窍是在每个要测试的界面内如何对任何给定的操作进行编码。这需要面对大量的工作，但在一个界面完成后，有许多测试脚本可用于任何其他的界面。而这就是必须为每个后续界面要实现的全部步骤：

　　添加在该界面上执行操作所需的实际步骤

　　补充此框架来涵盖其他界面内所没有的任何功能

　　该方法的另一个好处是：尽管仍然被表示为代码，但它在一个足够高的抽象级别可读取为伪代码，这对非编程人员 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 客户端和移动电话。身份验证明显是个问题，但实现这些混合测试场景注定会有很多并发问题。

　　但没有关系，那不过是一个珠穆朗玛峰。让我们出发吧!通过加入 LinkedIn 上的 IBM Rational Functional Tester Network 讨论组 参与讨论，或对本文提出建议来告诉我们您的想法，或添加您的意见。