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

图 3. 抽象类的代码示例

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

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

　　基于应用程序的框架

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

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

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

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

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

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

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

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