回归测试是指修改了旧代码后，重新进行测试以确认修改没有引入新的错误或导致其他代码产生错误。自动回归测试将大幅降低系统测试、维护升级等阶段的成本。回归测试作为软件生命周期的一个组成部分，在整个软件测试过程中占有很大的工作量比重，软件开发的各个阶段都会进行多次回归测试。在渐进和快速迭代开发中，新版本的连续发布使回归测试进行的更加频繁，而在极端编程方法中，更是要求每天都进行若干次回归测试。因此，通过选择正确的回归测试策略来改进回归测试的效率和有效性是很有意义的。

——度娘

面对如此回归，懒人如是说：

技术解放手工，用自动化做回归，势在必行

希望保留手工的习惯，用excel写写用例，不敲代码

希望重复的测试数据只写一次，就可以循环使用

希望兼容不同电脑系统与不同浏览器，最好还能并行执行

希望安装启动使用方便，入门门槛要低

希望可以适用于不同的应用系统上

希望功能扩展简单，随时满足DIY

……

1、自动化历程及优缺

对于我们这代站在巨人肩膀上的人来说，看看前人的进展还是很有必要的。以下是自动化测试的历程及优缺：

对于两大流行框架，关键字驱动的自动化测试系统与数据驱动的系统相比，主要的不同有两点：

数据文件的设计方法不同

数据驱动系统中数据文件存储的是测试输入数据，脚本中仍然存在业务逻辑，这样业务的变化会引起脚本的更改，而关键字驱动系统数据文件的设计将业务和测试输入数据都集成在数据表格中，虽然设计复杂，但当业务发生变化时，无需更改测试所用的脚本，从而提高了测试的效率。

脚本封装范围不同

与数据驱动系统相比，由于关键字驱动系统中数据文件的设计包含了业务信息，因此，将测试所进行的操作封装为关键字支持脚本。由动作封装的关键字支持脚本不包含任何的数据和业务信息，其重用性得到了极大的增强。

2、简单框架之搭建

结合懒人需求，设计初级框架如下：

（关键字驱动的测试框架）

基于excel表格和页面参数配置，调用关键字脚本，实现用例组合和数据调用，最终达到测试用例执行、结果验证、报告输出的目的。

action：与页面交互进行动态变更参数配置文件，加载配置文件和jar包，脚本调度

service：解析excel组装测试用例及数据，测试报告备份成功及数据统计。

object：util包括ExcelUtil、PropertiesUtil文件创建读写修改等操作；

ClassLoadUtil：自定义的类加载器；

keyword：关键字对应功能函数方法库，封装浏览器鼠标各个操作及定位方式；

constent：全局参数；

log：辅助脚本日志；

DbLibrary：与数据库相关操作的封装类，支持oracle，mysql。

通过这种方式使测试逻辑、测试脚本和测试数据相互脱离，在回归测试中仅通过对控制文件的修改就可以对相同功能，不同数据的用例进行测试。同时测试脚本不关心测试用例，测试数据和业务逻辑都集成在测试数据表格之中，测试的设计就简化为测试数据表格的设计。

3、框架设计之关键

脚本设计的关键在于能够将业务逻辑抽象为关键字组成的表，所以针对web应用测试的脚本应该将浏览器执行的每一步操作步骤分解为关键字组成的语句。

首先，对操作抽象分析，可以如下表示：操作＝命令＋页面元素＋输入值。

浏览器的操作命令通常包括点击，输入事件。页面元素包括按钮，输入框等等吗，输入值通常是操作时需要的测试数据。

其次，一个没有验证点的脚本是不完整的自动化脚本，验证点是判断是否执行成功的关键。验证点也由三部分组成：验证点＝类型＋验证元素＋期望值。

其中类型表示使用哪种验证方式，验证方式主要有比较元素属性值、元素文本值、页面标题及数据库值。验证元素即需要验证的页面元素，而期望值则是测试用例中希望得到的值。

结合浏览器操作和验证点的需求，可以统一抽象，表示如下：操作＝动作＋元素定位＋测试数据。

由此，设计出关键字脚本。

脚本实际是由一个大量关键字组成的表格。为了实现数据分离的操作，因此对测试数据进行专门的管理。以用例脚本的元素定位列数，索引值确认行数，最终得到相应的数据。

如果测试数据表仅有一条数据，则会无限次调用同一条；如果是多条，则会循环调用。同时为了方便不同模块的组合执行，专门设计一个表格进行管理用例，测试人员可以自定义模块是否使用及执行的顺序。

以知乎登录为例，如下：

定位方式：By.xpath、By.id、By.name、By.linkText、By.partialLinkText、By.className、By.cssSelector。

执行操作：input（输入事件）、click（点击事件）、navigate（跳转）、openBrowser（打开浏览器）、checkText（检查页面元素值）等等，可以自定义不同的操作，封装相应的方法调用即可。

例如：

常见操作的方法网上很多，感兴趣的可自行前往，此处不再一一赘述。

4、使用框架之操作

将war包放在tomcat上，开启服务，访问该项目，即可进入如下页面：

配置所使用电脑的系统，使用浏览器地址，TestSuite、TestCase、TestData地址，以及你想要输出报告和图片的具体的地址。配置信息在第一次使用的时候需要全部配置，之后哪些信息变更就配置哪些信息即可。

点击按钮开始测试。测试完成后会返回提示页，如下：

其中，测试报告会对上次的执行结果进行备份，每个执行将由单独的report表格存储结果，展示如下：

统计结果展示如下：

5、优化框架之设想

目前框架基本已经满足了懒人只写测试用例不管代码的需求。然而，还有很多东西需要继续扩展，如测试并行执行、持续集成、融入APP自动化等等。需求不断，开发不止，然而终级目的是为了更快速更高效的完成测试工作。

以上是笔者自己的期望和设想，源码地址：

https://code.dianrong.com/users/houhp/repos/keywordtest/browse。有同僚或者感兴趣的朋友，欢迎加入一起讨论，共同开发出一款适合自己的自动化工具。

本文作者：侯海萍（点融黑帮），目前就职于点融网Fintech团队。爱好羽毛球、乒乓球。