//Click Next
image_next3().click();
//etc...
}
}
通过使用 callScript 命令，您可以调用您的模块化脚本，这些脚本是您从测试中创建的。这使得代码可读性更强，并且更加维护。这是一个非常好的方法，您可以使用象这样的模块脚本构建模块，以创建不同的测试用例场景。对于上面您所有的每个模块脚本，您可能会有三个(或更多)不同的成本分类：便宜的、一般的、昂贵的。然后您可以进行混合，并将它们匹配到不同场景的测试上，如带有高成本功效的便宜租金，或使用信用卡支付的低成本运输费用。
优势和劣势
此系列的三种框架类型将涵盖模块化、数据驱动和关键字驱动，模块化框架理解和实现起来是最简单的。它也是最易于和其它框架联合使用的--例如，将模块化框架和数据驱动框架组合在一起。通常，在 Rational Functional Tester 中实现模块化要求有底层的技术知识。您真正需要学习的是如何管理帮助类--如果您在使用 Rational Functional Tester 的任何功能(包括记录和回放)，您确实应当理解它们。
模块化的主要优势是重用和减少重用伴随而来的维护成本。对比记录和回放，模块化应当产生更多可读的脚本，易于阅读和调试。创建测试模块脚本然后记录和回放脚本通常会有较高的成本，但是维护成本更加便宜。这意味着您需要知道您要使用您的测试脚本多长时间，以完全了解实现模块化的成本。成本-收益分析可能会帮助您决定模块化是否适合于您目前的项目。可能性就是，即使如果您的整个框架不是模块化的，您将会不在识别核心的功能，而转移到帮助类或帮助脚本上。
使用模块化，应用程序的状态和数据共享会变成一个问题。如果一个模块失败了，对所有依赖它的模块意味着什么呢?如果一个订单从来没有被提交过，您如何检查订单状态?如果您从来没有执行过一个搜索，您如何将一个物品项添加到购物车中?共享数据和状态的复杂性会使脚本调试变得更困难，并且常常会花较长时间来识别，一个脚本失败是测试脚本还是被测应用程序的问题造成的。这些问题将造成可靠性的问题。
下一步
在您正在测试的应用程序中，花一些时间将最常用的功能抽象到脚本或者类中。您也可以考虑为应用程序的大多数动态部分进行这项工作。在您已有的脚本和任何您生成的新脚本中使用模块化。您不需要立刻转化所有的脚本。这是有关模块化的精彩内容的其中一个;您可以按照您的需求，使用或者不使用它们。您并没有被要求一定要使用他们。
另外值得提到的是这样一个事实，即模块化可以扩展以用于高级的框架中，如基于模型的测试框架和用于海量自动化测试的框架。如果您对如何扩展已有的模块化框架感兴趣，可以看下面列表中的许多资源。在本系列的下一篇文章中，将会带您去了解如何在 Rational Functional Tester 中实现一个数据驱动的框架。最后，查看一些资源，以充分理解与一个模块化框架相关联的成本和收益，以及对于更加强大的测试自动化，您可以使用模块化的方式。
文章来源于领测软件测试网 https://www.ltesting.net/
