实现基于自动化测试框架Framework的构建

　　实现基于自动化测试框架Framework的构建  软件测试

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

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

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

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

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

　　自动测试框架的目标

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

　　自动测试框架的要求

　　1、自动测试3+模型

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

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

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

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

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

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

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

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

　　2、对测试用例的要求

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

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

原文转自：http://www.ltesting.net