什么是软件自动化测试框架.doc

软件自动化测试框架什么是软件自动化测试框架目前测试工作大多数以手动为主，并不是各个软件公司不想做自动化测试，无奈再没有成熟单位应用的情况下，但靠每个公司自己的摸索，显然比手动测试代价更大，且项目变化频度过快，也对测试框架提出了挑战，到底公司能够下多大的人力，物力来做测试框架的搭建，想必也是困扰了大家许久。框架这个概念并不是只有在测试里面有，开发同样也有框架的概念。框架(Framework)是整个或部分系统的可重用设计，表现为一组抽象构件及构件实例间交互的方法;另一种定义认为，框架是可被应用开发者定制的应用骨架。前者是从应用方面而后者是从目的方面给出的定义。可以说，一个框架是一个可复用的设计构件，它规定了应用的体系结构，阐明了整个设计、协作构件之间的依赖关系、责任分配和控制流程，表现为一组抽象类以及其实例之间协作的方法，它为构件复用提供了上下文(Context)关系。因此构件库的大规模重用也需要框架。构件领域框架方法在很大程度上借鉴了硬件技术发展的成就，它是构件技术、软件体系结构研究和应用软件开发三者发展结合的产物。在很多情况下，框架通常以构件库的形式出现，但构件库只是框架的一个重要部分。框架的关键还在于框架内对象间的交互模式和控制流模式。框架比构件可定制性强。在某种程度上，将构件和框架看成两个不同但彼此协作的技术或许更好。框架为构件提供重用的环境，为构件处理错误、交换数据及激活操作提供了标准的方法。应用框架的概念也很简单。它并不是包含构件应用程序的小片程序，而是实现了某应用领域通用完备功能(除去特殊应用的部分)的底层服务。使用这种框架的编程人员可以在一个通用功能已经实现的基础上开始具体的系统开发。框架提供了所有应用期望的默认行为的类集合。具体的应用通过重写子类(该子类属于框架的默认行为)或组装对象来支持应用专用的行为。应用框架强调的是软件的设计重用性和系统的可扩充性，以缩短大型应用软件系统的开发周期，提高开发质量。与传统的基于类库的面向对象重用技术比较，应用框架更注重于面向专业领域的软件重用。应用框架具有领域相关性，构件根据框架进行复合而生成可运行的系统。框架的粒度越大，其中包含的领域知识就更加完整。框架，即framework.其实就是某种应用的半成品，就是一组组件，供你选用完成你自己的系统。简单说就是使用别人搭好的舞台，你来做表演。而且，框架一般是成熟的，不断升级的软件。同样，测试框架也是如此，每个公司力求的最终结果，就是花少量的资源来尽可能多的完成测试任务，所以测试框架的建立以及框架的重用性方面是最值得探讨的地方，沙龙里面“自动化测试的框架要讲究粒度”和“建立测试框架需要一定的开发能力”这2句话说的非常有道理，你不能苛求测试人员完成所有测试应用框架的建立，这是不现实的，时间、资源都不允许。所以被测系统的主营业务，核心应用理当成为框架的首选。软件自动化测试框架STAF 工作当中接触到这个开源的软件自动化测试框架，特此上线扯个蛋，不感冒的自觉走开，呵呵一、什么是STAF STAF(Software Testing Automation Framework)是一个由IBM开发的开源、跨平台、支持多语言且基于可重用的组件来构建的自动化测试框架，而这一系列的组件都是一些可以处理调用、资源管理、监视等一些列的服务组成，后面将会介绍这些概念。STAF框架为自动化测试建立了基础，在高层解决方案提供一种可插拨的机制，支持多种平台与多种语言。二、我们真的需要这个框架么 当然，我不是一个推销员，也更不肯能是。但是，我想说的是，单从软件产品测试的角度来看，产品的平台兼容性是一个不可忽视的问题。对于Windows平 台上，软件产品需要能够完美的兼容早期的Win98、WinNT系统，还得兼容表现优秀的WinXP、Windows Server系统，更要支持用户群扩大的Win7。 如果产品做的好，甚至还需要兼容Linux、Mac OS。注意了，其实对于每种系统还可以继续分为32位系统与64位系统，而每次产品在Release之前都需要在在上述各个平台上测试N遍。如果纯手工的 测试，那么在投入的人力、设备、以及时间成本上是很惊人的，那么一种自动化测试需求便应运而生了，而STAF便是满足这种需求的一种框架。三、怎么运用STAF来解决我们的需求 那么，你可能会疑问，STAF框架怎么解决上述这个问题的呢？一种合理的解决方案是，一般公司都会有一些性能配置优越的服务器(暂且称为Lab机器)， 而我们工作人员一般的机器性能都仅仅满足我们的日常工作(暂且称为Office机器)，做一些日常的开发和文档处理绰绰有余，但是同时开多台虚拟机跑测试 的话，估计机器也就卡的半死不活了，到时候我们只能大眼瞪小眼了，而逐个平台的测试的话，时间却又是我们所不能接受的。所以我们可以将跑测试的工作交由处 理能力很强的Lab机器，而我们测试人员的Office机器需要做的则是告诉Lab机器需要做什么，然后Lab机器在执行完测试任务后会将测试结果返回到 Office机器上。 在上述的描述中，Office机器与Lab机器都必须装有STAF，需要指出的是，各个装有STAF环境的机器之间的关系是对等的(Peer to Peer)，也就是没有服务器与客户端区别。Office机器端上的STAF可以通过与Lab机器上的STAF进行通信,从而调用Lab机器上STAF提 供的各种服务(例如可以要求Lab机器启动NotePad这个进程或者调用某个测试脚本程序)。为了方便大家理解，可以参考下图进行理解： 四、理解STAF中的一些概念 1、STAFProc进程 STAFProc 进程这个概念很重要，在上图中就是STAF Daemo进程(守护进程)。熟悉Linux或者Java的朋友可能对于守护进程这个概念不陌生，守护进程一般是一些运行在后台，进程级别很低的进程，且生命周期一般很长，主要监视系统的一些状态并在适当的时机做出一些操作。如JVM(Java虚拟机)中的垃圾回收器进程，则是运行在虚拟机里面的守护进程，其随着JVM启动而存在，不断的检测是否存在可回收的内存资源，并在适当的时候进行垃圾内存的回收。而在STAF中，也存在这种类型的进程，它就是 STAFProc进程，这种进程一般随着系统启动就开始运行，不断的监听来自其他对等断点STAF的请求，并在收到请求后调用相应的服务加载器 （ServiceLoader）来加载相应的服务，如调用STAF中的Process服务来启动一个本地进程。 2、STAF服务(Service) STAF是基于服务来构建自动化框架的，每个服务就是STAF的可重用组件，其通过STAFProc分派来的任务来实现其人生价值。在STAF中主 要分为两种类型的服务，一种是内部服务(Internal Service)，一种为外部服务(External Service)。 那么，上述两种服务有什么区别呢？内部服务的话则一般被集成到STAFProc,一般都是一些比较基本而常用的服务;而外部服务则是需要动态载入，其可 执行码不在STAFProc中，一般都在外部Jar中或者外部DLL库中。其实，这个对于Java熟悉的朋友比较好理解，我们Java程序JdK装完后可 以使用的那些包(Package)就相当于内部服务，而当我们需要进行一些特殊开发的时候，往往需要引入一些第三方库(如开发蓝牙服务的 BlueCover.jar),这些就好比外部服务。 3、内部服务 有如下常见内部服务: 服务名称作用DELAY可以使得服务得到延迟一段时间。应用场景：在执行一个耗费时间的任务时候，在进行下一步操作前，需要延迟等待一段时间PROCESS可以启动、停止或者查询进程，如执行一个指定的测试脚本程序等PING通过该服务检测远程或者本地机器是够通讯的上SERVICE该服务可以列出机器上可以使用的服务SHUTDOWN该服务用来关闭STAFProc进程，好处在于通过该命令关闭STAFProc,可以释放进程的所占用的资源FILE SYSTEM该服务提供网络之间的文件拷贝服务，例如从本机拷贝一些文件到目标测试机上 4、外部服务 外部服务一般需要到STAF官网去下载服务组件包(网址为/),一般服务组件包下完后还需要一些配置，这个在下篇文章会以STAX为例介绍，先列出一些常用的外部服务 服务名称作用STAX一个基于XML的执行引擎，在XML中定义测试工作流，可以实现并行执行、嵌套测试用例、控制运行时间等，STAX支持Java和Python模块ResPool用于日志的记录和查看Monitor提供查看、创建、删除等针对资源池的管理或操作Zip提供压缩与解压 5、服务请求格式 STAF的服务组件之间通过发送STAF请求(Request)完成各类工作，一个STAF请求格式一般为：STAF Command+EndPoint+Service Name+Request Content四个组成部分(注意将加号换成空格)。其 中，STAF Command就是STAF ; EndPoint部分可以是远程机器IP或者Localhost ; Service Name则是Endpoint端机器上STAF环境中的服务名称（这个可以通过STAF命令来查看，如查看本机STAF环境中的服务列表，可以通过 STAF Local Service List命令查看）;Request Content则是请求的内容，举几个例子方便大家理解：1）请求IP地址为60机器中的STAF的Process服务执行关机的命令： STAF 60 process start command shutdown -s -t 60 （不同部分用颜色区分开了） 备注：对于关机这类具有一定Destructive的操作，我们有时执行上述命令会失败。这是因为在STAF中有安全等级制度，总共分为5个安全等级，在 后面会具体讲到。这时候，我们可能需要在60这台机器的STAF环境中修改下其配置文件，将本地机器或者所在网段的受信任等级提升，并重启服务， 在后面的STAF安全机制会提到。 2）测试IP地址为45的机器中的STAF服务是否存活(Alive) STAF 45 PING PING 备注：该命令主要是向远程机器的PING服务提交内容为PING的Request，如果对方机器中的STAF环境是存活的话，则本机STAF端回接受到回应，在本机表现为命令行回显： Resonse - PONG 看到上述命令，就知道对方机器的STAF环境已经是准备就绪的了。在此，提醒初学者要区分直接在命令行中运用Ping命令和上述命令，不要傻乎乎的打开Cmd然后输入Ping 45，要知道，此Ping非彼Ping也。 6、STAF实例 在同一个操作系统中，其实我们可以同时运行多个STAF实例，而STAF实例名则成为了每个STAF实例的标示。默认的实例名为STAF,当然我们也可 以修改实例名，通过设置环境变量STAF/Config/InstanceName可以改变实例名称（STAF中的环境变量在下面会讲述）。 7、STAF中句柄 STAF中的句柄是个唯一的标识，在提交STAF的Request的时候，一般以句柄为颗粒单位提交。一般句柄标识是结合了STAF的实例名和对应进程的部分唯一标识构成。 8、 STAF中的变量 在STAF启动之后，其实在内存中就存在一些STAF变量，这些变量主要用来存储一些配置信息、运行时信息以及系统环境信息。由于这些都是加载在内存中 的，所以对这些STAF变量的更改会立即生效而无需重启服务。我们可以通过命令STAF Local Var List命令查看本地STAF启动后有哪些变量。 从官方开放的文档中，还可以看出STAF有变量池的概念，主要分为下列三种变量池： 1）会维持一个系统(System)变量池(Pool),在这个变量池中的所有变量对于所有的句柄都是可以访问且共用的（可以使用命令STAF Local Var List System命令查看） 2）同时STAF中存在变量共享池(Shared Pool),除了具有系统变量的特征之外，共享池中的变量可以跨网络共享，即本机可以使用远程机器STAF环境中的共享变量池中的变量(可以使用命令STAF Local Var List Shared查看) 3）除了上述两种变量，STAF中的每个句柄也拥有自己的变量池，这其中的变量都是私有的： 查看某个句柄变量池中的变量命令：STAF Local Var List Handle 1 备注：注意这儿的1是句柄的标识ID，可以通过命令STAF Local Handle List查看各个句柄对应的标识ID 9、STAF中的安全机制软件自动化测试框架的发展基于界面的软件自动化测试框架和工具的发展大致经历了三个阶段（有人也据此将测试工具分为三代）： 1）简单的录制回放：由工具录制并记录操作的过程和数据形成脚本，通过回放来重复人工操作的过程。在这种模式下数据和脚本混在一起，几乎一个测试用例对应一个脚本，维护成本很高。而且即使界面的简单变化也需要重新录制，脚本可重复使用的效率低。 2）数据驱动（data driven）的自动化测试：从数据文件读取输入数据，通过变量的参数化，将测试数据传入测试脚本，不同的数据文件对应不同的测试用例。在这种模式下数据和脚本分离，脚本的利用率、可维护性大大提高，但受界面变化的影响仍然很大。 3）关键字驱动（keyword driven）的自动化测试：关键字驱动测试是数据驱动测试的一种改进类型，它将测试逻辑按照关键字进行分解，形成数据文件，关键字对应封装的业务逻辑。 主要关键字包括三类：被操作对象（Item）、操作（Operation）和值（value），用面向对象形式可将其表现为 Item.Operation(Value)。关键字驱动的主要思想是：脚本与数据分离、界面元素名与测试内部对象名分离、测试描述与具体实现细节分离。 相应地，软件测试自动化脚本的类型，从低到高的发展层次是： 1）线性脚本：通过录制直接产生的线性执行的脚本。 2）结构化的脚本：具有顺序、循环、分支等结构的脚本。 3）共享的脚本：可以被多个测试用例使用，被其它脚本调用的脚本。 4）数据驱动的脚本：数据和流程控制分离的脚本，通过读入数据文件来驱动流程进行的脚本。 5）关键字驱动的脚本：脚本、数据、业务分离，数据和关键字在不同的数据表中，通过关键字来驱动测试业务逻辑。关键字驱动脚本的特点是它看起来更像描述一个测试事例做什么, 而不是如何做。 目前，大多数测试工具处于数据驱动到关键字驱动之间的阶段，有些工具厂商已经提出了声称支持关键字驱动的版本。 从上面可以看到，自动化测试框架和脚本的发展是和软件工程思想的发展一脉相承的。软件开发的模式从面向机器、到面向过程、再到面向对象、面向服务，是一个 从底层到高层、从具体到抽象、复用的粒度从细到粗的发展过程。而软件开发中的模块化、层次化、松耦合等思想对自动化测试框架的设计都具有借鉴意义。小议软件自动化测试框架的改进以下是自动化测试框 架的建议，需要在以后的实践中改进。自动化测试框架一般可以分为上下两个层次，上层是管理整个自动化测试的开发，执行以及维护，在比较庞大的项目中，它体 现重要的作用，它可以管理整个自动测试，包括自动化测试用例执行的次序、测试脚本的维护、以及集中管理测试用例、测试报告和测试任务等。下层主要是测试脚 本的开发，充分的使用相关的测试工具，构建测试驱动，并完成测试业务逻辑。一、自动化测试管理自动化测试用例的执行机制一般包括管理端和执行端，由管理端发出信号通知执行端开始执行相应的测试任务，从而执行相应的脚本进行测试，并将测试结果报告管理端。1管理端管理端主要完成以下任务：运行控制的决策系统，负责建立并维护运行队列，控制运行策略和信号灯；在管理端还必须维护一个测试任务的队列，每个测试任务的开始执行的时间可能不同，状态也不一样，管理端根据这些标志对其进行控制。2执行端执行端根据管理端的决策系统，来执行运行队列中的测试脚本，其中运行控制的执行系统，负责分配测试脚本，并按照指定策略启动脚本等也是执行端的功能。二、自动化测试脚本开发1测试驱动测试驱动是一个自动化测试框架的核心，其决定整个自动化脚本设计。当前比较流行的测试驱动有数据驱动和关键字驱动，使用不同的测试驱动，关系到脚本重用率，以及后期的可维护性。（1）数据驱动基于数据驱动的自动化测试框架是指测试驱动引擎从数据源获取测试数据，然后将将数据以参数的形式传递给测试脚本，最后通过执行测试脚本，验证测试结果，并将测试结果输出。一般数据源与测试结果存储在数据库、 Excel文件、Csv文件等。数据驱动主要优点是：测试脚本与测试数据的分离，当应用功能变更时，只需要修改该功能部分的脚本；执行测试用例的人员不需 要了解测试脚本的实现，只关注测试数据表与测试报告表。而且测试脚本的执行是离散的，即非线性的，测试人员可以有选择的执行测试用例。（2）关键字驱动关键字驱动的自动化测试框架是在数据驱动的基础上进行改进，数据源里包含的不只是数据，还有关键字，一个测试用例由一个或若干个关键字组成。每个关键字对应个不同的业务逻辑，例如，登录、注销等。数据表通过关键字，查找映射表，执行相关的脚本。（3）驱动引擎驱动引擎是对数据表的数据进行分析，根据不同的测试数据或关键字调用相应测试脚本。驱动引擎还需完成一些测试环境初始化、全局参数设置、测试用例是否执行的判断，以及测试报告的处理等。2测试脚本开发测试脚本开发必须通过详细、合理的设计，要对脚本代码进行划分，脚本文件或数据文件分层管理。这样有利于自动化脚本的开发与维护，从而节省自动化测试的投入成本，也使得不同测试人员或开发人员可以协调开发脚本。（1）脚本规范测试脚本的开发也要遵循编程的规则与标准，应该统一规划，所有开发脚本的人员按照统一的规定进行编码。除了编程本身规范，还考虑测试用例与库函 数名的命名，测试用例需要加上项目名称，但公共的库函数却不需要，因为公共的库函数是独立于项目的。例如，项目M4.1客户端登录测试用例可命名 为：TC_M4.1_client_login；读取excel表的函数可命名为：read_excel。（2）脚本划分测试脚本的划分，如何定义公共的脚本库，不同模块特有的脚本库，以及直接构建测试用例的脚本。为了方便以后脚本的维护问题，必须对脚本进行有效的分层，同时，提高了脚本的复用率。 公共类库公共类库包括所有模块都可能用户的操作方法，其抽象了不同模块同性，比如操作excel表的方法、读写测试报告、驱动引擎等。 模块特定类库在模块内部将可以为该模块共享使用的方法抽象出来，作为一个公共类。它可以是一个单的逻辑操作，也比较独立。比如客户端登录操作、控制台登录操作、控制台更新操作等。 测试用例脚本测试用例脚在最上层，它根据测试点进行设计，面向具体的应用。它可直接调用公共类库或模块特定类库的方法，即调单个逻辑操作。它是单个或多个逻辑操作的集合，即一个测试用户脚本。比如，在客户端访问资源的测试用例，它调用了客户端登录方法和访问资源方法。（3）测试用例 测试用例粒度测试用例的粒度决定了用例模型级的复杂度，也决定了每一个用例内部的复杂度。应该根据每个系统的具体情况来把握各个层次的复杂度，在尽可能保证 整个用例模型的易理解性前提下决定用例的大小和数目。用例不能太大，这样一旦出执行测试用例出错，不利于定位问题；但也不能太细化，太小则不方便执行。 测试用例与测试套件一个大型的项目有许功能模块，必然会产生大量的测试用例，怎样才能有效的管理这些测试用例呢？这就需要创建测试套件，通过测试套件将测试某一个 模块或功能点的测试用例集合起来，方便运行与管理。例如，只验证“用户管理”模块功能，则只需要执行“用户管理”模块套件即可。（4）脚本与html标记分离脚本与html标记分离使得在一定程度上脚本独立于WEB页面，脚本没有直接的处理html标记，脚本代码通过html映射表获取赋有WEB页 面标记值的变量。WEB页面标记包括html标记和页面内容（文本或图片等，这些都可能是判断用例是否成功能的检查点），当WEB页面标记变更后，不需要 在范围的修改脚本。（5）选择适合自动化测试的用例在编写自动化测试脚本前，首先要确定哪些用例适合做自动化测试，因为自化测试不像手工测试，它不能那么智能，也没有发发散思维。通常适合自动化测试的用例有：产品型项目。产品型的项目，新版本是在旧版本的基础上进行改进，功能变不大的项目，但项目的新老功能都必须重复的测试。回归测试。回归测试是自动化测试的强项，它能够很好的验证你是否引入了新的缺陷，老的缺陷是否修改过来了。在某种程度上可以把自动化测试工具叫做回归测试工具。机械并频繁的测试。每次需要输入相同、大量的一些数据，并且在一个项目中运行的周期比较长。有一些交互性比较强，需要人工干预的操作，就不要指望通过自动化测试来完成了。例如，用户使用DKEY登录。软件自动化测试框架设计参考准则测试框架是在所有不同的测试自动化阶段定义的一整套指导准则：需求分析阶段、脚本设计阶段、执行阶段、报告和维护阶段。框架即对于内部复杂架构的一种包装，这样的包装可以使得最终用户方便的使用。框架还具有对于流程标准的强制执行性。目前为止，还没有一种关于如何开发测试框架以及在开发过程中需要考虑哪些因素的准则。有很多记载 着各式各样的测试框架以及它们各自是如何工作的白皮书，但是这些白皮书中还没有任何一篇文档是记录着测试框架设计共同需要考虑的因素。本文基于测试框架需 求，涵盖了测试框架各个方面以及一些必备的基本要素。1. 自动化测试框架的类型 目前普遍存在的框架有以下几种： 数据驱动框架 当测试对象流程固定不变（仅仅数据发生变化），可以使用这种测试框架。测试数据是由外部提供的，比如说Excel表、XML等等 关键字驱动框架 这种自动化测试框架提供了一些通用的关键字，这些关键字适用于各种类型的系统。它还为自动化测试工具和被测系统提供了抽象性。举个例子，它可以使用相同的测试用例来测试类似的Web和Windows系统。 混合型的框架 混合型自动化测试框架同时具有数据驱动型和关键字驱动型框架的优点。这种测试框架不但具有通用的关键字，还有基于被测系统业务逻辑的关键字。例如“登录”、“退出”是可以被使用的仅局限于某系统的关键字。2. 不要过分的改造 自动化测试框架应该尽可能的使自动化测试工具发挥它自己强大的功能，而不是通过实现新的关键字来重新定义整套语言。开发一套关键字驱动的自动化测试框架的 代价是很大的而且非常耗时。开发一套混合型的自动化测试框架的代价就相对较小而且开发周期短。3. 可重用性 测试框架应该尽最大可能提高可重用性。把单独的Action组合成业务逻辑可以提供可重用性。举个例子，可以把类似于“输入用户名”、“输入密码”和“点击登录”这些Action组合成一个可被重用的模块：“登录”4. 支持系统的不同版本 自动化测试框架应该允许重复使用基线化脚本，这样可以保证这份脚本能被用来对被测系统的多个版本进行测试。对不同系统的支持有两种方式： 复制和修改 这种方法包含了新建基线脚本的一个拷贝、修改这份拷贝用以测试特定版本的项目。51Testing软件测试网 b1o.N8W0Y 重用和升级 这种方法包含了重用基线脚本、提供一个此脚本的升级和优化用以测试特定版本的项目。这样做可以最大化的保障可重用性，这也是推荐的方法。5. 支持脚本版本化 测试脚本应该被储存在类似于CVS、微软的VSS等版本控制工具中。这样做可以保障在灾难发生的时候可以被恢复。6. 将开发和发布环境分开 自动化应当和其它开发项目同等看待。测试脚本应当在一个测试环境下创建和调试。一旦测试脚本测试通过后唯一该做的就是将它部署到发布环境。在紧急发布版本的情况也同样适用这种方法。7. 外部可配置性 脚本的可配置项应当被保存在一个外部文档中。系统的URL、版本、路径等都可以被视作可配置项放在外部文件中。这样做可以使得在不同的环境中都可以执行测 试脚本。需要注意的是外部配置文件的路径不要写死，如果把它写死了虽然在任何环境中都还是可以运行脚本，但是每次只能在一个环境运行。配置文件的路径使用 相对路径即可解决这个问题。8. 自身可配置性 理想的测试框架应该是自身可配置的。一旦部署到系统中之后应当不需要再做任何手工配置，脚本应当自动配置完成一些必要的设置。9. 任何对象改动引起的变动应该是最小的 自动化过程中最为常见的问题是对象识别的变更。测试框架应该支持可以很容易的来完成这些修改。这可以通过将所有的对象识别设置储存在一个共享文件来实现。 这个文件可以是XML文件、Excel文件、数据库或者自动化所特有的格式。这里有两种可能的方式来实现对象识别设置的方式：51Testing软件测试 静态方法 这种方法中，所有对象定义都在测试最初被加载到内存中。任何对象定义变更只能通过停止和重新运行测试来实现。 动态方法 对象定义是通过需求拉动的。这种方式和静态方式比较而言显得较为缓慢。但是对于非常大的脚本而言，并且对象识别需要在运行时做修正的情况下，动态方法是适用的。10. 测试执行 自动化测试框架也许需要满足以下需求（基于实际需求） 执行单独的测试用例； 批量执行测试用例（一组测试用例）； 只执行失败的测试用例； 可以在前一个（一组）测试用例执行结果的基础上，执行下一个（一组）测试用例；根据实际需求还会有许多其他情况。一个框架可能无法实现所有这些需求，但它应具有足够的灵活性以适应今后此类需求。51Testing软件测试网?#q!U l!Y%K1n11. 状态监测 - 一个框架应允许实时监控执行状态，一旦失败能够发出警报。这样可以在出现failure之后迅速反馈。12. 报表 不同的系统对报表有不同的需求，有时候需要一组测试的整体报表，有时候只需要单个测试用例级别的测试执行报表。一个好的测试框架应该有足够的弹性来按需支持不同的报表。13. 发生更改的时候对测试工具尽量小的依赖性 一些测试脚本的更改可能只能在打开测试工具后，在测试工具中进行修改，然后保存。测试脚本应该在没有测试工具的情况下也可以对脚本进行更改。这样的实现可 以减少license的购买从而为公司节省开支。这样的实现还可以让所有想去修改脚本的人无需安装测试工具也可以很方便的对脚本进行修改。14. 方便的调试 调试在自动化过程中占据了大量的时间，因此在调试这个过程中需要加以特别的关注。关键字驱动的测试框架因为使用了外部的数据源（比如Excel数据表）去读取脚本中的关键字和测试过程，所以较难调试。15. 日志 - 生成日志是执行的重要组成部分。在一个测试案例的不同点生成调试信息这是非常重要的。这些信息有助于快速地找到问题的范围，同时缩短了修改时间。16. 易用性 - 该框架应易于学习和使用。对框架的人员培训费时且昂贵。有一个好文档的框架更容易理解和使用。17. 灵活性 - 框架应该足够的灵活，以适应任何改进，而不会影响已有的测试案例。18. 性能的影响 框架还应考虑对执行性能的影响。一个复杂的框架会增加脚本的加载或执行时间，这一定不是我们所期望的。像缓存技术，当执行时编译所有代码到单个库中等.只要可能都应该用于性能的改善。19. 框架支持工具 开发一些外部工具来完成任务，这对框架设计会有帮助。这是一些例子：51Testing软件测试网: 从本地文件夹上传脚本到QC51Testing软件测试网 结合库文件到当前打开的脚本51Testing软件测试网 同步本地和QC上的脚本文件20. 编码标准 - 编码标准应确保脚本的一致性，可读性和易于维护。编码标准应包含下列内容： 命名规范（变量、子程序、函数、文件名、脚本名称等），例如i_VarName为整数变量， fn_i_FuncName为返回值是整数的函数； 库、子程序、函数的头部注释。这应包含,如版本历史，创建者，最后修订者，最后修订日期，说明，参数，示例； 对象命名规范。例如txt_FieldName为一个文本框；我们应该把自动化测试看作是一个开发项目，而不仅仅是记录和回放事件。先有一个良好的框架，再开始自动化测试，这样可以确保较低的维护成本。当你在开发一个框架，进行框架的需求分析时，可以参考本文谈到的这些准则。*软件测试中有关界面测试经验总结 1.应验证界面显示内容的完整性： a) 报表显示时应考虑数据显示宽度的自适应或自动换行。 b) 所有有数据展现的界面(如统计、查询、编辑录入、打印预览、打印等)，必须使测试数据的记录数超过一屏/一页，以验证满屏/页时其窗体是否有横向、纵向滚动条或换页打印，界面显示是否正常; 2.应验证界面显示内容的一致性： a) 如有多个系统展现同一数据源时，应保证其一致性; 3.应验证界面显示内容的准确性： a) 对于报表中的所有字段值都应该有明确的定义，对于无意义的字段值，不应该显示空，应显示“-”或“/”，表示该字段值无意义。 4.应验证界面显示内容的友好性： a) 对统计的数据应按用户习惯进行分类、排序。 b) 某些重要信息在输入、修改、删除时应有“确认”提示信息; c) 界面内容更新后系统应提供刷新功能。 d) 用户在退出系统后重新登陆时应考虑是否需要自动返回到上次退出系统时的界面; 5.应验证界面提示信息的指导性： a) 在多个业务功能组成的一个业务流程中，如果各个功能之间的执行顺序有一定的制约条件，应通过界面提示用户。 b) 用户提示信息应具有一定的指导性，在应用程序正在进行关键业务的处理时，应考虑在前台界面提示用户应用程序正在进行的处理，以及相应的处理过程，在处理结束后再提示用户处理完毕。 c) 在某些数据输入界面，如果要求输入的数据符合某项规则，应在输入界面提供相应的规则描述;当输入数据不符合规则时应提示用户是否继续。 d) 在对任何配置信息修改后，都应该在用户退出该界面时提示用户保存(如果用户没有主动保存的情况下);6.应验证界面显示内容的合理性： a) 在对某些查询功能进行测试时，应考虑查询条件的设置的合理性以及查询结果的互补性。如某些后台处理时间不应该作为查询条件。 b) 界面测试时，应考虑某一界面上按钮先后使用的顺序问题，以免用户对此产生迷惑。例如只能在查询成功后显示执行按钮。 c) 界面测试时，应验证窗口与窗口之间、字段与字段之间的浏览顺序是否正确; 7.界面测试时，应考虑用户使用的方便性： a) 在某些对数据进行处理的操作界面，应考虑用户可能对数据进行处理的频繁程度和工作量，考虑是否可以进行批量操作。 8.界面测试时，应考虑界面显示及处理的正确性： a) 界面测试时应验证所有窗体中的对象状态是否正常，是否符合相关的业务规则需要。 b) 应验证各种对象访问方法(Tab 健、鼠标移动和快捷键)是否可正常使用，并且在一个激活界面中快捷键无重复; c) 界面测试不光要考虑合理的键盘输入，还应考虑是否可以通过鼠标拷贝粘贴输入。 d) 对于统计查询功能的查询结果应验证其是否只能通过界面上的查询或刷新按键人工触发，应避免其他形式的触发。 e) 对界面上的任何对象进行拖拉，然后进行查询、打印，应保证查询打印结果不变; 9.界面测试时，应考虑数据显示的规范性： a) 确保数据精度显示的统一：如单价0元，应显示为0.00元; b) 确保时间及日期显示格式的统一; c) 确保相同含义属性/字段名的统一; d) 对所有可能产生的提示信息界面内容和位置进行验证，确保所有的提示信息界面应居中。*软件黑盒测试用例设计方法总结一、等价类划分等价类划分方法是把所有可能的输入数据，即程序的输入域划分成若干部分（子集），然后从每一个子集中选取少数具有代表性的数据作为测试用例。该方法是一种重要的、常用的黑盒测试用例设计方法。1. 等价类的概念等价类：等价类是指某个输入域的子集合。在该子集合中，各个输入数据对于揭露程序中的错误都是等 效的。并合理地假定，测试某等价类的代表值就等于对这一类其它值的测试。因此，可以把全部输入数据合理划分为若干等价类，在每一个等价类中取一个数据作为 测试的输入条件，就可以用少量代表性的测试数据。取得较好的测试结果。等价类划分可有两种不同的情况:有效等价类和无效等价类。有效等价类：是指对于程序的规格说明来说是合理的，有意义的输入数据构成的集合。利用有效等价类可检验程序是否实现了规格说明中所规定的功能和性能。无效等价类：与有效等价类的定义恰巧相反。设计测试用例时，要同时考虑这两种等价类。因为，软件不仅要能接收合理的数据，也要能经受意外的考验。这样的测试才能确保软件具有更高的可靠性。2. 划分等价类的方法下面给出六条确定等价类的原则：1) 在输入条件规定了取值范围或值的个数的情况下，则可以确立一个有效等价类和两个无效等价类。2) 在输入条件规定了输入值的集合或者规定了“必须如何”的条件的情况下，可确立一个有效等价类和一个无效等价类。3) 在输入条件是一个布尔量的情况下，可确定一个有效等价类和一个无效等价类。4) 在规定了输入数据的一组值（假定n个），并且程序要对每一个输入值分别处理的情况下，可确立n个有效等价类和一个无效等价类。5) 在规定了输入数据必须遵守的规则的情况下，可确立一个有效等价类（符合规则）和若干个无效等价类（从不同角度违反规则）。6) 在确知已划分的等价类中各元素在程序处理中的方式不同的情况下，则应再将该等价类进一步的划分为更小的等价类。3. 设计测试用例在确立了等价类后，可建立等价类表，列出所有划分出的等价类：输入条件 有效等价类 无效等价类。然后从划分出的等价类中按以下三个原则设计测试用例：1) 为每一个等价类规定一个唯一的编号。2) 设计一个新的测试用例，使其尽可能多地覆盖尚未被覆盖地有效等价类，重复这一步。直到所有的有效等价类都被覆盖为止。3) 设计一个新的测试用例，使其仅覆盖一个尚未被覆盖的无效等价类，重复这一步。直到所有的无效等价类都被覆盖为止。二、边界值分析法边界值分析方法是对等价类划分方法的补充。边界值分析方法的考虑：长期的测试工作经验告诉我们，大量的错误是发生在输入或输出范围的边界上，而不是发生在输入输出范围的内部。因此针对各种边界情况设计测试用例，可以查出更多的错误。使用边界值分析方法设计测试用例，首先应确定边界情况。通常输入和输出等价类的边界，就是应着重测试的边界情况。应当选取正好等于，刚刚大于或刚刚小于边界的值作为测试数据，而不是选取等价类中的典型值或任意值作为测试数据。基于边界值分析方法选择测试用例的原则：1) 如果输入条件规定了值的范围，则应取刚达到这个范围的边界的值，以及刚刚超越这个范围边界的值作为测试输入数据。2) 如果输入条件规定了值的个数，则用最大个数，最小个数，比最小个数少一，比最大个数多一的数作为测试数据。3) 根据规格说明的每个输出条件，使用前面的原则1)。4) 根据规格说明的每个输出条件，应用前面的原则2)。5) 如果程序的规格说明给出的输入域或输出域是有序集合，则应选取集合的第一个元素和最后一个元素作为测试用例。6) 如果程序中使用了一个内部数据结构，则应当选择这个内部数据结构的边界上的值作为测试用例。7) 分析规格说明，找出其它可能的边界条件。三、错误推测法错误推测法：基于经验和直觉推测程序中所有可能存在的各种错误，从而有针对性的设计测试用例的方法。错误推测方法的基本思想：列举出程序中所有可能有的错误和容易发生错误的特殊情况，根据他们选择 测试用例。例如，在单元测试时曾列出的许多在模块中常见的错误。以前产品测试中曾经发现的错误等，这些就是经验的总结。还有，输入数据和输出数据为0的情 况。输入表格为空格或输入表格只有一行。这些都是容易发生错误的情况。可选择这些情况下的例子作为测试用例。四、因果图方法前面介绍的等价类划分方法和边界值分析方法，都是着重考虑输入条件，但未考虑输入条件之间的联 系，相互组合等。考虑输入条件之间的相互组合，可能会产生一些新的情况。但要检查输入条件的组合不是一件容易的事情，即使把所有输入条件划分成等价类，他 们之间的组合情况也相当多。因此必须考虑采用一种适合于描述对于多种条件的组合，相应产生多个动作的形式来考虑设计测试用例。这就需要利用因果图（逻辑模 型）。因果图方法最终生成的就是判定表。它适合于检查程序输入条件的各种组合情况。利用因果图生成测试用例的基本步骤：1) 分析软件规格说明描述中，那些是原因(即输入条件或输入条件的等价类)，那些是结果(即输出条件)，并给每个原因和结果赋予一个标识符。2) 分析软件规格说明描述中的语义。找出原因与结果之间，原因与原因之间对应的关系。根据这些关系，画出因果图。3) 由于语法或环境限制，有些原因与原因之间，原因与结果之间的组合情况不不可能出现。为表明这些特殊情况，在因果图上用一些记号表明约束或限制条件。4) 把因果图转换为判定表。5) 把判定表的每一列拿出来作为依据，设计测试用例。从因果图生成的测试用例（局部，组合关系下的）包括了所有输入数据的取TRUE与取FALSE的情况，构成的测试用例数目达到最少，且测试用例数目随输入数据数目的增加而线性地增加。五、判定表驱动分析方法前面因果图方法中已经用到了判定表。判定表（Decision Table）是分析和表达多逻辑条件下执行不同操作的情况下的工具。在程序设计发展的初期，判定表就已被当作编写程序的辅助工具了。由于它可以把复杂的逻辑关系和多种条件组合的情况表达得既具体又明确。判定表通常由四个部分组成。条件桩（Condition Stub）：列出了问题得所有条件。通常认为列出得条件的次序无关紧要。动作桩（Action Stub）：列出了问题规定可能采取的操作。这些操作的排列顺序没有约束。条件项（Condition Entry）：列出针对它左列条件的取值。在所有可能情况下的真假值。动作项（Action Entry）：列出在条件项的各种取值情况下应该采取的动作。规则：任何一个条件组合的特定取值及其相应要执行的操作。在判定表中贯穿条件项和动作项的一列就是一条规则。显然，判定表中列出多少组条件取值，也就有多少条规则，既条件项和动作项有多少列。判定表的建立步骤（根据软件规格说明）：1) 确定规则的个数。假如有n个条件，每个条件有两个取值（0，1），故有n2种规则。2) 列出所有的条件桩和动作桩。3) 填入条件项。4) 填入动作项。等到初始判定表。5) 简化。合并相似规则（相同动作）。适合使用判定表设计测试用例的条件：1) 规格说明以判定表形式给出，或很容易转换成判定表。2) 条件的排列顺序不会也不影响执行哪些操作。3) 规则的排列顺序不会也不影响执行哪些操作。4) 每当某一规则的条件已经满足，并确定要执行的操作后，不必检验别的规则。5) 如果某一规则得到满足要执行多个操作，这些操作的执行顺序无关紧要。六、黑盒测试的测试用例设计方法总结1. 等价类划分方法2. 边界值分析方法3. 错误推测方法4. 因果图方法5. 判定表驱动分析方法6. 正交实验设计方法7. 功能图分析方法*软件测试管理的几个基本要素本文将就软件测试管理中的基本要素做逐一介绍.1. 符合软件开发计划时间框架的软件测试计划软件测试计划是一个老生常谈的问题了，不同的人对计划的理解往往是大相径庭的。这里让我们回顾一 下何为计划，一般来说计划的目的是用来识别任