连载丨自动化测试该往哪些方向发展？ ——Part.2 从线性脚本到关键字驱动

2016-03-01 09:45:07
陈能技

自动化测试线性脚本关键字驱动

正当人们感觉自动化测试是解决软件测试诸多问题的好办法时，却一不小心掉入了测试工具厂商的圈套。

对于GUI层的对象识别、录制回放型自动化测试工具，销售往往过于强调其录制回放功能，夸大了其易用性，往往忽略了其维护性工作量。

从线性脚本到模板化脚本

一个系统登录的功能，通过工具录制得到的脚本类似如下代码：

对于熟悉工具和编程语言的自动化测试工程师而言，这样的代码是比较容易看懂的，它由界面控件的关键字（例如Window、Edit），代表动作的关键字（例如Input、Click），以及测试数据（例如“Admin”、“123456”）按一定的格式组成。

但是想像一下，如果类似的脚本多起来，例如，通过等价类的测试用例设计，需要验证更多的测试数据。另外，还有其它功能的脚本，也需要首先“登录”，那就需要录制更多冗余的脚本出来，这些脚本都放到一个文件中，其更改维护的工作量就逐渐上来了！

解决这样的问题需要用到编程思想中的结构化、模块化、函数化。

例如，上述登录过程的代码，可以封装成一个函数：

这样，当其它脚本需要用到“登录”过程时，只需要调用这个函数，传入测试数据UserName、PassWord就可以了。

由此可见，单纯的“录制回放”造就的线性脚本可维护性差，由简单录制的简易性、便利性带来的好处（测试脚本开发工作量的节省和效率的提高），会很快被脚本的维护工作量抵消掉！

自动化测试非常类似于开发过程，很多在开发领域的思想都可以应用到自动化测试领域，例如：一样存在设计、编程的思想，强调重用、可维护性。

从模块化脚本到数据驱动脚本

模块化的脚本还没有把重用、可维护性的问题根本解决。

例如，脚本中的数据没有分离出来，这样会导致同样的测试过程，不同的测试数据，需要多个测试脚本实现，如下：

如果把数据分离出来，放到一个单独的表格（例如Excel表）存储：

脚本参数化后放到一个循环结构中，每次执行Login时，从表格读取一条数据，这样就能遍历所有设计的测试数据，但是核心的脚本保持在精简的量级。

这就是数据驱动脚本模式，数据分离、测试流程重用！

从数据驱动脚本到关键字驱动脚本

发展到后边，我们发现，既然数据能从脚本中单独分离出来，放到表格集中维护，那么脚本中的其它东西时候也可以分离？例如对象以及它的操作。

如果脚本从原先的这种写法：

变成这种写法：

我相信很多非自动化测试工程师也能看懂并维护，即使在不懂工具和编程的情况下。因为这种写法更接近手工测试用例的写法，更接近业务流程的描述语言。

通过封装一个核心的解析引擎，把“输入”、“点击”这些关键字解析成工具能够执行的脚本，把“用户名”、“密码”这些控件对象放到对象库中维护，这样就能用编写普通的手工测试用例类似的方法编写自动化测试脚本。

由原来需要专职自动化测试工程师干的活，变成由大量手工测试人员、甚至是业务人员也能做的工作。

降低了对专业自动化测试技术的要求，降低了脚本维护的工作量，同时提高了测试脚本单位时间的产量。

如果把上述底层的关键字脚本再提炼，还可以封装成高层业务关键字脚本，例如：

更进一步提高代码可重用性和可维护性。

作者介绍陈能技

新炬网络首席APM架构师。
14年开发测试与质量架构经验，擅长DevOps及APM、Docker、持续集成、持续交付在企业中的落地实施。
著有《软件性能测试诊断分析与优化》、《软件自动化测试成功之道》、《深入浅出性能测试与LoadRunner实战》等书。

Tips：

关注“中国数据架构师联盟”，并回复“陈能技”，即可查看上期文章《连载丨自动化测试该往哪些方向发展？——Part.1自动化的起源》哦~

关于DAMS中国数据资产管理峰会：

中国数据资产管理峰会主题是行业顶级“数据”峰会，覆盖大数据与数据资产管理、架构、数据安全、云、运维及跨界数据应用等，预计2016年7月15-16日2天在上海，1主场9分场1500人规模，指导单位上海经信委，联合主办：上海云计算产业中心、DBA+社群，目前已经邀请到来自腾讯、阿里、蚂蚁金服、京东、小米、创大、浙江移动、壳牌等重量级演讲嘉宾，目标听众：CIO、CTO、架构师、大数据工程师、数据分析师、DBA等。

春节门票大放送，限时优惠，快快点击首页购票吧！