自动化测试的探讨

发布: 2009-11-11 13:50 | 作者: webmaster | 来源: 本站原创 | 查看: 191次 | 进入软件测试论坛讨论

自动化测试的探讨 软件测试

目前测试工作大多数以手动为主，并不是各个软件公司不想做自动化测试，无奈再没有成熟单位应用的情况下，但靠每个公司自己的摸索，显然比手动测试代价更大，且项目变化频度过快，也对测试框架提出了挑战，到底公司能够下多大的人力，物力来做测试框架的搭建，想必也是困扰了大家许久。框架这个概念并不是只有在测试里面有，开发同样也有框架的概念。

框架（Framework）是整个或部分系统的可重用设计，表现为一组抽象构件及构件实例间交互的方法;另一种定义认为，框架是可被应用开发者定制的应用骨架。前者是从应用方面而后者是从目的方面给出的定义。

可以说，一个框架是一个可复用的设计构件，它规定了应用的体系结构，阐明了整个设计、协作构件之间的依赖关系、责任分配和控制流程，表现为一组抽象类以及其实例之间协作的方法，它为构件复用提供了上下文(Context)关系。因此构件库的大规模重用也需要框架。

构件领域框架方法在很大程度上借鉴了硬件技术发展的成就，它是构件技术、软件体系结构研究和应用软件开发三者发展结合的产物。在很多情况下，框架通常以构件库的形式出现，但构件库只是框架的一个重要部分。框架的关键还在于框架内对象间的交互模式和控制流模式。

框架比构件可定制性强。在某种程度上，将构件和框架看成两个不同但彼此协作的技术或许更好。框架为构件提供重用的环境，为构件处理错误、交换数据及激活操作提供了标准的方法。

应用框架的概念也很简单。它并不是包含构件应用程序的小片程序，而是实现了某应用领域通用完备功能（除去特殊应用的部分）的底层服务。使用这种框架的编程人员可以在一个通用功能已经实现的基础上开始具体的系统开发。框架提供了所有应用期望的默认行为的类集合。具体的应用通过重写子类(该子类属于框架的默认行为)或组装对象来支持应用专用的行为。

应用框架强调的是软件的设计重用性和系统的可扩充性,以缩短大型应用软件系统的开发周期，提高开发质量。与传统的基于类库的面向对象重用技术比较，应用框架更注重于面向专业领域的软件重用。应用框架具有领域相关性，构件根据框架进行复合而生成可运行的系统。框架的粒度越大，其中包含的领域知识就更加完整。

框架，即framework。其实就是某种应用的半成品，就是一组组件，供你选用完成你自己的系统。简单说就是使用别人搭好的舞台，你来做表演。而且，框架一般是成熟的，不断升级的软件。

同样，测试框架也是如此，每个公司力求的最终结果，就是花少量的资源来尽可能多的完成测试任务，所以测试框架的建立以及框架的重用性方面是最值得探讨的地方，沙龙里面“自动化测试的框架要讲究粒度”和“建立测试框架需要一定的开发能力”这2句话说的非常有道理，你不能苛求测试人员完成所有测试应用框架的建立，这是不现实的，时间、资源都不允许。所以被测系统的主营业务，核心应用理当成为框架的首选。

自动化测试框架比较多，基本上都是以junit为基础，以TestCase和TestSuit为主要运用，对所要测试的类和主要方法，加test方法，然后作assert判断，如果与结果不符合，就抛出异常。可以一次执行多个testcase.这样就简化了人工的干预，可以称之为自动化测试。

由此也衍生了不少更强大的测试框架，比如可以得出执行时间指标，内存指标，以及web测试和多线程测试，使之扩展测试的深度和广度。这其中，人工干预的环节基本上在前期，也就是写testcase的环节上，比如要构造最初输入参数，编写测试逻辑流程，如果方法之间本身耦合度较高，就需要比较复杂的测试逻辑流程，这也就是说，增加了前期的工作量，但也极大降低了后期的时间和工作量，总体而言还是极大提高了测试的效率。

　　但如果测试的前期能够降下来的话，这不是更好吗？这也是我当时的一个最初想法。

　　举个具体的例子阐述一下想法：

　　比如

　　@ValidateIntValue(min=25,max=35)

　　private String age;

　　从上面这个age变量，我们可以得出age的最小值25，最大值35，这是它的规则，就是说，如果在程序测试中，如果出现age不符合这个范围，就必须抛出异常，提示出错，这个也是一个朋友上面说的校验。但另一方面，这也给我们提供了一个testcase输入参数的思路，这就是如果我们遇到以age为输入参数的话，我们可以自动生成3个参数来执行三个case，2个边缘case，25，35，还有一个在这个随机值范围里面。当然我们可以修改为：

　　@ValidateIntValue(min=25,max=35，default=28)

　　private String age;

　　这取决于我们的偏好。

　　由于这些meta信息不只可以作用于方法里面，也可以作用在类里面，我们也可以针对类作一些描述，这样我们就可以对类本身也可以作一些特定的描述。

　　一般来说，对复杂的类变量，populate方法必须提供能够实现递归，即填充父类的信息以及自身内部的变量信息，一直深入到最小的不可分解的原型变量，因为我们一般面对的都是一些比较复杂的类。

　　这样我们就简化了前期的一部分工作量。但是测试的业务流程并没有简化，尤其是一些复杂的业务流程。

　　我的思路是另外一种思路，就是做一个图形界面工具，通过对类方法的拖拉，基于流程图的形式，自动生成相对应的代码。我感觉是可行的，因为一般来说，测试的逻辑并不是怎么复杂。不过因为我没有实践过，所以不知道可行性，也不知道网上是否已经有这类框架。

　　这半年来基本上没有写过一行代码了，不过有时间的话，还是愿意尝试一下，和大家共享代码，虽然我已经决定不再吃技术这碗饭了，但是它确实已经成为我生命的一部分了。