理解自动化测试框架设计

理解自动化测试框架设计

为什么需要设计测试框架？

首先我们需要明确一点，自动化测试工具或程序的开发与一个软件产品的开发在本质上是没有区别的，特别是从技术层面上来说，更是如出一辙。我们开发一套软件产品，也是为了能够帮助客户解决某些层面的问题，提升效率或降低成本，正因为有客户需要才有开发这套产品的价值。同样的道理，我们开发一套自动化测试工具，当然是为了更好地给测试团队使用进而提高测试团队的执行效率，提升软件产品的质量，所以这套工具的客户即为测试团队成员，因为他们有需要，因为他们不想把时间花费在一些重复的劳动上，所以这也是自动化测试工具的价值所在。
既然都是在开发软件产品，软件工具，那么毫无疑问，我们必须要考虑开发效率及维护成本。这个时候，一套高效的框架便很有必要。所谓框架，就是介于原生代码和最终产品之间的一个半成品。

如何评价一个框架的好坏？

我们主要可以从以下几个方面来评估一个框架的质量：
(1) 独立于测试工具：无论使用什么样的测试工具或测试技术，并不影响框架本身。
(2) 测试步骤可重用：一个项目中难免会有很多操作过程是类似的，应该设计为可重用。
(3) 测试资产可重用：测试资产包括测试脚本，测试数据，测试环境等。
(4) 测试数据易定制：比如通过外部数据源定制不一样的测试数据，完善测试用例。
(5) 异常处理机制：测试执行过程中难免会遇到各种未知异常，应该捕获并截图保存。
(6) 测试脚本易开发：测试框架一旦定义完成，应该使测试脚本的开发变得更加容易。
(7) 测试脚本易维护：对可能的操作均进行封装，并且对相关操作进行分层处理。
(8) 无人干预执行：持续集成的关键所在，从版本构建到测试到报告甚至到发布，均自动完成。
(9) 代码可移植性高：测试脚本当中没有Hard-Code，同时针对不同的项目，也能顺便移植。
(10) 适宜于团队开发：自动化测试框架也需要考虑团队开发的问题，要定义好自己的接口规范。

目前流行的框架设计思路

每一个人在构思一个框架时，都会受限于自己的思维方式，实践经验，成功案例，甚至于所测试的产品领域和业务流程等。所以我们很难说什么框架一定是最好的，什么框架一定不好。甚至也不能简单的评判一些通用性强的框架就一定是好的，通用性差的框架就一定不好，这都会出现以偏概全的误解。笔者在此为大家整理了目前比较流行的一些框架设计思想，供读者朋友参考：
(1) 数据驱动测试：即英文单词Data-Driven Testing，简称DDT。
(2) 关键字驱动测试：即英文单词Keyword-Driven Testing，简称KDT。
(3) 业务流程测试：即英文单词Business Process Tesing，简称BPT。
(4) 页面对象模式：即英文单词Page Object Model，简称POM。
(5) 基于组件的测试：即英文单词Component-Based Testing，简称CBT。

关于框架设计中的分层思想

事实上，无论是自动化测试框架的设计还是软件产品的研发框架的设计，在很多思想上都是完全一致的，其中很重要的一点就是“分层思想”。
那么，什么是分层思想呢，其核心就是不同的操作，应该放在不同的类和不同的方法中，层与层之前互相依赖，互相调用，每一层都有自己独特的分工。就像我们之前学习TCP/IP模型一样，应用层，传输层，网络层和物理层，每一层都需要共同结合才能真正完成一个任务，但是每一层都有自己独特的分工，不能乱来，一旦乱了，分层思想也就失去了其价值。
分层思想的设计指导原则如下：
(1) 上层总是依赖下层，不要跨层访问
(2) 一切从系统需要提供的功能进行分析
(3) 每个层的接口有明确的职责范围
(4) 只要接口规范无变化，接口的实现互不影响

关于CBT框架的设计思想

强哥原创的CBT框架有两种解释：Component-Based Testing和Component & Business Testing，两种解释中的核心在于“Component”组件和“Business”业务，所以其核心是基于产品业务和基于测试组件。而这里的每一个接口，每一个业务操作，都可以认为是一个“组件”，而整个自动化测试程序，则是由诸多不同类别的组件构成，这些组件大致可以划分为以下几类：
(1) 公共组件：用于测试框架中一些可重用的功能，提高开发效率和维护效率。
(2) 操作组件：用于对接口或GUI进行关键操作，但是不需要进行断言测试。
(3) 测试组件：通过调用操作组件，并对其操作的进行进行断言，属于自动化测试的核心部分。
(4) 业务组件：针对不同的业务，我们可以封装不同的组件，可以结合操作组件，测试组件等。
(5) 模块组件：一个模块组件应该由多个测试组件的调用构成，我们可以为此开放一个接口，专门用于将其模块相关的测试封装起来，可以更严谨地定义测试用例的调用顺序，针对该模块的测试设计模块私有的公共组件等，同时也更方便测试执行时的调用。

目前的测试框架存在的问题

目前市面上的测试框架，很难评价其好坏，更多的应该从被测试产品的产品架构，业务形态进行考量，适合自己的才是最好的。但是，通常的框架都存在一些这样或那样的问题，简单总结如下：
(1) 测试框架只针对某些特定领域。比如专门针对Selenium的框架，专门针对性能测试的框架，专门针对接口测试的框架等。无法很好地覆盖全流程测试。
(2) 测试框架试图减少测试人员的编码时间，而因此导致自动化测试脚本被各种操作限制得非常死，只能完成一些简单的自动化测试，无法进行深度开发和定制。
(3) 测试框架的通用性更强，试图适用于各类测试。比如Robot Framework，其通用性很强，可以针对PC端和移动端，可以对GUI进行测试，也可以测试接口，甚至于命令行。但是其通过关键字进行操作，虽然作为入门级使用非常方便，可以关注更少量的代码，但是其灵活性也大打折扣，我们无法定制更强的功能，反而对于一个有经验的测试开发工程师来说，是非常不习惯于被其关键字操作所限制，在功能组件的扩展上也显得比较麻烦。

所以，我们更希望通过自己完全从零开始编码来将业务的这些框架思想进行代码实现，从而对各个环节及代码细节有更清晰的认识。只有这样，我们才能够更好地应用一些成熟的框架，或者定制适合自己企业的专有框架，而不会受限于别人的框架，以致于导致自动化测试开发无法真正应用起来，产生应有的价值。