前言

随着对软件质量的要求越来越高，测试也越来越被重视。而采用自动化测试的方法显得非常重要。

初采用自动化测试的目的是为了进行回归测试：因为自动化测试能够在测试用例执行方面大幅度的降低成本，减少测试执行工程师；但是对于编写自动化测试脚本成本和效率的考虑，也使得自动化测试应用范围不是很大。

但是，自动化测试能够给用户带来的不仅仅是非常好的执行效率和较低的执行成本，同时也能够使测试工程师编写更多的测试用例来提升测试覆盖率，提升测试效果。

使用自动化来进行测试的软件开发组织越来越多，但是大多数的自动化测试都是不成功的：往往付出很多成本，回报很小??只能够覆盖部分测试用例、测试环境管理复杂、测试数据复杂、支持业务流程的自动测试复杂。

本文的目标是对这些问题作一个基本的讨论，来说明如果构建一个自动化测试框架来解决这些问题。主要是提出一个规范和指标，并不涉及如何实现。

 

自动测试框架的目标

自动测试框架的宏观目标，是：1）降低单个测试脚本的复杂程度，使得测试脚本更简洁、更规范，只关注于测试操作过程；2）测试用例支持BPT（business process testing），支持在测试用例中的业务流；3）测试用例复用；4）把测试环境从“定性”的抽象管理，转变成“定量”管理，具体化测试环境；5）管理精确的测试数据；6）截取正确或者错误的用例执行信息；7）支持测试迭代。

 

自动测试框架的要求

n        自动测试3+模型

在传统的测试模型中，特别是手工测试用例中，测试设计人员不太需要去考虑测试用例之下的层次??对于使用自然语言的描述信息，而不是形式化的方式描述??只关心测试用例可以了。

但是，如果需要自动执行，需要编写自动化的测试脚本。过于体现流程的自动化测试脚本，会带来：1）数据管理的复杂性。每个脚本都是被参数化的，并且具备多组数据，而测试用例如果需要使用多个脚本，数据复杂性会大大提高，不离于进行管理；2）测试脚本的复用支持。测试脚本需要付出很多代价得到的（需要编写、测试），管理者从节约成本的角度上，需要测试脚本进行重用，即可以通过测试脚本组合出很多不同的测试用例；3）测试迭代。如果需要把上一次测试过程中产生的测试用例、测试集，作为下一轮次测试的输入，需要测试集支持多层次的包涵，即允许一个测试集合包含另外一个测试集合。

     基于以上的要求，自动测试的模型，应该是支持“3+层”的模型：

     第一层，体现测试脚本，即测试执行的操作流程层；

     第二层，体现测试的业务流程，即测试用例层；

     第三层，测试集合层，即多个测试用例的集合，用来执行。

     第n层，测试计划层，支持在一个测试计划中拥有多个测试集合。

 

     3+层模型，能够把整个自动化测试的模型变得更简单，更多的参数化和可配置，如同TestCenter类似。TestCenter本身的测试框架，是基于3+层模型的。

n        对测试用例的要求

对于自动测试用例而言，要求：1）测试数据依赖于测试用例；2）测试用例支持内部的流程配置；3）测试用例内部的参数传递；4）测试用例的输入参数；5）测试用例验证规则支持。

测试数据依赖于测试用例，而不是测试脚本，是自动测试框架中基本的要求。

测试用例支持测试流程，是BPT的具体体现，这里不再解释。

测试用例的内部参数传递，是测试过程对测试用例的要求，在测试框架中，需要实现的是允许测试设计工程师配置这个参数传递过程，而不是通过修改测试脚本来实现。也是说，需要在测试用例中定义传递规则，在执行时刻由测试框架来实现参数传递，而不是脚本自己来实现。

测试用例的输入参数，这个部分解释起来会涉及到测试环境管理，这里不再详细描述。

测试用例的验证规则，是测试用例是否执行通过的基本要求，也是必须的。在自动测试框架中，需要定义规则，而不是在测试脚本中来实现。因为如果测试脚本中实现了规则，会导致测试脚本的重用成为难以逾越的问题。

n        对测试脚本的要求

测试脚本需要体现操作流程，而不体现测试逻辑。

测试框架对测试脚本的要求，是??“尽可能简单”。

n        测试数据管理

测试数据分成两个部分（自动测试中）：1）测试用例数据；2）测试数据场景数据。

首先，我们给出一个概念：测试数据场景。测试数据场景定义：相对于测试计划，测试计划中的所有测试用例对测试环境的数据依赖，是测试数据场景。

测试数据，包括在测试用例中。

 

测试框架要求测试用例把依赖于测试数据场景的数据部分，定义为输入参数。这样，当我们获得一个测试用例的集合（体现为测试集），我们可以得到所有测试用例输入参数的集合。

测试数据的集合，可以和测试数据场景来对应，也是说，这个集合是自动测试能够执行所依赖的测试数据场景。

自动测试框架的构建

自动测试框架可以通过几种方式来构建：

1.        基于编写程序来构建

可以通过自己来编写一个程序，实现所有的自动测试框架。实际上，这是一个编写一个类似于TestCenter这样的关系系统。

也有部分的测试组织来管理，相对比较少。

2.       基于QC来构建

QC是一个两层次的架构，用户可以通过在QC中增加一些插件，来实现三层的测试框架、数据管理框架、测试场景框架。

大多数使用自动化测试的用户也是这样来做的。

还有一种方法，是对测试脚本进行二次封装，在测试脚本层面实现一个三层的测试框架。当然这种方法可以实现：1）参数传递；2）测试配置等工作。如果需要更好的实现自动测试框架，这种方法还是存在很多缺憾。

3.        基于TestCenter来构建

TestCenter是实现3+层框架的测试工具，已经包括了完整的自动化测试框架。用户可以基于此工具来建立自己的自动化测试体系，对于当前用户对自动化测试的需求，已经支持的比较好了。

特别是对于迭代测试，TestCenter提供了非常好的支持：把第一次测试产生的测试集合，作为下一次测试的输入，组装成测试集合的测试集合，很方便的进行后一个轮次的测试过程。