自动化测试框架思路

第一次写类似的文章，语言组织能力不够，就从最简单的开始一路白话文把自己搭框架时的想法一路写下来，可能比较啰嗦，各位看官见谅。
在了解什么是自动化测试框架之前，先了解一下什么叫框架？框架是整个或部分系统的可重用设计，表现为一组抽象构件及构件实例间交互的方法；另一种定义认为，框架是可被应用开发者定制的应用骨架。所以自动化测试框架的定义为：由一个或多个自动化测试基础模块、自动化测试管理模块、自动化测试统计模块等组成的工具集合。当然了，上述这些大道理是百度百科上的解释，下面是我在silktest的基础上参考前辈的资料建立的一个自动化测试框架，主要是围绕如何将脚本复用，如何提升自动化效率，如何将整个自动化流程规范化，如何管理测试用例和测试计划、以及如何自动生成详细的测试报告来设计的。思路如下：
1、一般自动化测试工具最基础的功能就是录制+回放，将测试步骤按部就班的复制下来，写个流水账似的测试程序。这样的测试脚本只能用来回放，需求改变或者数据改变后就不能用了。所以，要提升脚本的复用率，最基本的就是要将脚本和数据分离开来，再将数据参数化，此时脚本将分为用例和函数两部分，用例的主要作用是标识测试用例的基本信息，预定义输入输出的参数，提供进入函数的入口等，函数则是自动化执行的主体，即录制下来的流程+其他辅助功能。此时自动化测试框架包含了用例库和函数库，这就是最原始的一种框架——数据驱动测试框架，仅仅是将测试数据从测试脚本中分离出来，开始了非混沌状态的第一步，这是所有测试架构中最简单的一种。

2、上述是我们的第一个脚本，随着自动化用例脚本越来越多，不可能再一个个的单独执行，此时就需要一个测试计划（plan），用于批量执行多个自动化测试脚本，silktest完美提供了该功能，只需要建立对应的测试计划就行，此时我们的自动化测试框架多了个计划库。

3、上一步说到批量执行多个测试脚本，此时我们就面临一个问题：多个脚本逐个执行的时候，上一个脚本执行完后，应用程序/web场景是不可预料的，而自动化脚本往往需要特定的初始场景。那么我们就需要设计好相应的初始化模板，该函数模板的作用是使得应用程序/web初始化，使上一个测试用例不影响下一个用例的执行。每个用例执行前引入执行该函数检查场景是否初始化，但由于每次都要执行该函数，所以设计初始化函数时要注意精简，否则容易影响整个测试执行的效率。

4、有了脚本，初始化场景和计划，自动化测试就能执行起来了吗？答案是肯定的可以，但同时也是肯定的错误百出。这时我们就需要自定义异常处理机制了，此处可以有白名单和黑名单两种处理思想，具体可根据被测系统来设计。

5、脚本数据分离后，接下来为了提高脚本的可读性和可维护性，需要将脚本进一步模块化，基于silktest强大的库，我们可以将被测系统的控件识别和控件支持的操作封装在测试库中，完成控件识别操作和业务逻辑的分离，这样就算被测系统层次结构发生变化也方便测试脚本的维护。

6、不管测试脚本多么华丽，脚本只是手段，公司/领导需要的是结果，测试报告是反应测试结果最直观的方式之一。要自动生成测试报告，就相当于说要对测试实施全程监控，此处说说大概思路，思路最重要，详细设计就不赘述了。我们可以将一个完整的测试流程分为如下几点：
（1）、测试任务始于测试计划，那么需要一个标志测试开始的模块——测试计划开始函数/用例（用于在工程开始时往日志数据库插入信息，记录该工程的ID，开始时间，模块数等）；
（2）、执行完测试计划开始模块后，进入整个测试的主体部分，为了标识每个测试模块，在每个测试模块执行前需要一个测试模块开始函数（用于记录该测试模块开始时间，将日志数据库中对应计划ID的脚本模块数+1等）；
（3）、每个测试模块包含若干测试用例，所以在每个测试用例执行时也需要一个用例开始函数来记录用例信息（用于记录用例对应的模块名称，用例开始时间，用例信息等）；
（4）、在我看来这一步是最重要的了，测试中我们要验证功能是否符合需求，每个功能的验证步骤都可以分为几个关键点，此时我们需要一个测试步骤记录函数（用于记录测试用例详细的步骤，预期结果、测试结果等）
（5）、测试用例执行完后需要一个用例结束函数来标识用例的结束（用于记录用例结束时间，用例执行状态等）；
（6）、当一个测试模块下的所有测试用例都执行完后需要一个测试模块结束函数（用于记录该模块的结束时间，测试结果等）；
（7）、所有测试模块执行完后还需要一个测试计划结束函数/用例来标识整个测试工程的结束（记录计划结束时间，计划执行的用例数，通过率等）。
上述7个模块均写在公共函数库中以供引用，引用的时候是用例嵌套在模块中，模块嵌套在计划中的，由于脚本与数据分离的思想，3、4、5三个函数在每个用例的函数体中引用，1、7在测试计划中引用，6在用例中引用。其中最重要的4，一个用例每个步骤执行的情况，我们需要公共函数4来记录步骤信息，将4插入在文本检查点或关键业务后面记录每个关键点的测试情况，实现日志记录的功能，生成步骤的具体信息，并将测试结果保存到外部数据库。

7、有了上面这些，整个框架已大体实现，但自动化测试过程中我们会遇到很多类似的操作，它们或许与被测系统有关，也可能与被测系统无关。我们可以归纳这些操作，将冗余的代码段整合成一个公共函数最终形成自己的公共函数库，在脚本函数中直接引用该公共函数，既可以提升脚本开发效率，还能增加脚本可读性，也利用后期维护。此处可以根据公共函数的适用范围分为与被测系统无关的公共库和个性化的公共函数库，可根据函数类型分为操作函数库和sql函数库等。
8、同样，类似公共函数的思想，在一个系统中，随着新功能的迭代和开发，测试脚本亦将与日俱增，其中相同数据出现的概率也会越来越高，于长远的自动化脚本维护考虑，我们可以预定义一些常用的变量，它们可以是参数化的数据或者公用的控件等。至此，一个自动化测试框架已初具模型，骨架已全，之后的工作则是在实际的测试中完善细节。