自动化测试代码架构浅谈

2014/12/29

      最近和不少同学谈论到自动化测试代码编辑的时候，需不需要类似于MVC框架的代码结构的问题，结合我先前遇到的问题，我们今天来谈论一下自动化测试编辑中的代码架构。

     还是先从一个故事开始吧！我从一毕业就开始做自动化测试，工作了两年多感觉应该换一下工作环境了，于是就换了个工作。在进入新公司的时候，他们公司已经做了一部分自动化了，领导让我接手，以后我要负责这一块。我看了一下代码，测试数据和函数混合在一起，功能模块重复，hard code相当多，而且各个测试用例之前的耦合度也相当紧凑，函数和测试用例没有任何注释等等 ，让我看了真上火。于是我决定自己写一版，原来的先不动，另一个同事来维护，结果在进行多线程运行的时候，死活进行不下去了，为什么呢？多线程的时候测试用例招待顺序不固定，用例之间的紧耦合性，让程序无法执行，而且被测试的网页变动的时候，维护成本相当高。这就是提前没有规划好代码结构造成的混乱，如果此时修改代码，成本也会非常高的。

  现在介绍一下常用的自动化测试用例编写的方法：

简单录制回放式

     由于现在各种录制工具比较多，给自动化测试用例的编写带来了很大的方便。比如说selenium IDE工具，Appium工具，可以录制你的测试操作，同时还可以转化成你想要的脚本文件。此时你只需要对脚本做简单的调整，添加一些儿必要有检测点，就能运行测试。而你的测试任务，可以通过大量这样的脚本文件来组织，足以完成回归测试的工作。

优点：只要熟练使用录制工具，编写测试用例相当方便，快捷；而且能根据操作的顺序进行完美回放。

缺点：代码利用率低，相同功能要录制重复的操作，维护成本高，如果改动大，则需要重新录制。

适用场景：简单的测试 ，只需要运行几次，用来反复测试某个或是某几个功能，不需要做长期维护，功能上线即可丢弃测试代码的场合。

类MVC框架式

   此框架类似于MVC，只是没有统一的名字，就先这样称呼它了。这种模式是将测试用例划分成以下几部分：通用函数部分，测试用例部分，测试数据部分，TestSuite部分。现将各个部分介绍如下：

通用函数部分：此部分存储所有测试用例或是大部分测试用例都能用到的函数，以类的方式对他们进行分类，可以是各类操作的类文件集合。

测试用例部分：此部分是具体测试用例，以一个完整的测试用例为一个文件，文件中包含具体的测试步骤，用例执行完后的检测点儿等，但不包含具体的测试数据，测试数据从数据文件中读取。

测试数据部分：此部分是对应该测试用例文件的测试数据，一个测试数据文件（xml）提供一个测试用例所能用到的所有数据。建议文件名和测试用例文件名相同。

TestSuite部分：此部分根据需要来组织测试用例，比如说，测试环境下回归需要回归所有的功能；而线上回归就不能回归对其他正常用户产生影响或是产生测试数据的测试用例。此时就可以编写不同的TesetSuite文件来应对不同场景的测试需求。

优点：代码利用率高，测试用例耦合度低，代码结构清晰，维护成本比较低。被测试网站或程序用变化，只需要维护测试数据部分即可。

缺点：对测试用例编写人员要求较高，要有清晰的代码架构概念，对通用函数的抽象要达到一定的水平。

 

适合场景：适合于用来做长期回归测试的自动化测试代码的编写，被测试对像变成较小，而且是主要功能的场景。对于使用次数较少的自动化测试用例，这种方式成本较高。

     好的组织结构利于团队开发，以及后期的维护。编写自动化测试用例，不是代码写出来了，运行没有出错就可以了。要有长远的目光，我写的代码清晰吗？如果交给他人来用，能看懂不？代码通用性如何？效率如何？等等都要考虑的哟！类MVC架构经过我的使用，感觉比较好，录制方式也比较简单快捷，根据业务需要来选择合适的代码架构，毕竟代码和工具只是为测试任务服务的嘛！