自动化测试框架的设计思路
1.自动化测试框架的概念
它是由一个或多个自动化测试基础模块、自动化测试管理模块、自动化测试统计模块等组成的工具集合。
以常见的前端UI测试为例，一个测试框架大概包括测试对象，测试组件，基础类和函数，工具类，测试数据，异常处理，测试日志，断言和测试报告等这些模块。
2.框架的驱动模式
2.1 数据驱动模式
如果被测系统业务逻辑固定不变或变动较小，我们可以使用数据驱动，通过不同数据来保证测试覆盖率，通常数据都是保存在外面文件或数据库中，运行时自动获取。特点是数据与测试脚本分离，基于模块化的测试库，一个驱动脚本可以执行多个相似测试，这样非常容易建立新测试。
2.2 关键字驱动模式
关键字驱动测试也被称为“表格驱动测试”或“操作名测试”，他是一种软件自动化测试的方法论，将数据与关键字结合来描述如何使用数据执行测试。这种方法具备数据驱动的优势，同时非编程人员也能建立新类型测试。例如Robot Framework就是典型的关键字驱动模式。
2.3 模块驱动测试
模块驱动测试使用独立的小脚本来对应待测试的模块、零件和子功能。这些不同层级的小脚本按照一定规则组合成更大级别的测试，如此就实现了一个特定功能的自动化测试案例。在所有自动化测试架构中，这应该是最容易领会和控制的一种，其应用非常广泛，即屏蔽组件的内部实现，仅提供组件的对外抽象接口。如此下层的测试组件发生变动时，对上层自动化测试案例来说是透明的。模块驱动测试引入了抽象和封装的原则，目的是提升自动化测试的可维护性和可扩展性。
2.4 混合自动化测试
混合自动化测试是由其他自动化测试框架综合发展起来的。成功的自动化测试框架通常融合了“关键字驱动测试”和“数据驱动测试”。他们即拥有测试逻辑与测试数据相互分离的优点，又集成了关键字驱动的先进架构。这一架构会使得数据驱动脚本更加简洁，并减少运行时意外失败的可能性。另一方面，该架构可以实现一些纯粹的“关键字驱动测试”难以实现的自动化测试任务。该架构由核心数据驱动引擎、功能函数组件，以及支持库所构成。
2.5 基于模型测试
基于模型测试适合于采用“基于模型设计”的软件系统。在这种架构下，会有一个成熟的测试模型来描述测试数据的所有方面，以及测试案例和案例执行环境。通常这一测试模型是全部或者部分从待测试系统功能模型中提取出来的。测试模型描述了待测试系统的抽象行为，因此从测试模型中可以派生出功能测试案例。这些测试案例构成了抽象测试案例集，不过抽象测试案例集不能直接在待测试系统上执行。真正可以执行的测试案例集（可以与待测试系统进行交互），是从抽象测试案例集派生出来的。有些基于模型测试的测试工具，支持从模型（包含足够信息）产生可执行测试案例集，从模型派生出案例，可以有很多种方式，因此测试很多时候是依靠经验去尝试，并没有固定的最佳方法。你需要事先收集“测试需求、测试目标，用户用例"因为他们包含待测试系统模型的信息。测试案例集是从模型而非代码派生出来的，因此基于模型测试可以被视为某种黑盒测试。事实上，基于模型测试目前只适合于功能不太负责的软件系统，复杂商业软件系统的基于模型测试，还处于探索阶段。
3.设计框架的原则
3.1 高内聚低耦合
高内聚就是每个模块尽可能独立完成自己的功能，不依赖于模块外部的代码；低耦合就是模块与模块之间接口的复杂程度，比如在类内部尽可能减少方法之间的调用，否则一个方法的变动会影响调用它的另一个方法。
3.2 脚本分离
对象、测试数据、业务逻辑相互剥离、灵活调用,在前端UI测试上可以得到明显的效果，我们可以使用PageObject设计模式来实现对象和业务逻辑的剥离，使用DataProvider来实现数据业务逻辑分离。
3.3 模块化设计用例，脚本的可重用
如果时间充裕且项目提供支持，可以遵循以下顺序进行测试： 页面对象 - 功能点 - 业务逻辑 - 业务流程。
从实现来说就是：先测试底层的页面操作对象，通过调用操作对象、及业务逻辑实现对功能点的验证，再通过调用业务逻辑组合功能点实现对业务流程的验证。不同的业务流程，对于底层的操作组件、中间层的功能点函数是完全可以复用的，只是调用的业务逻辑的差异，或者是测试数据的差异性。这样的好处是脚本相互独立性，代码复用，易维护，如有新的业务流程可以调用已有代码来组合。
3.4 封装基础方法
对于一些较通用的方法，可以封装，比如log，assert，异常处理，文件读写操作，数据库读写操作，保存页面截图等等。在需要的时候直接在测试用例里调用即可。
