故意学习,故意生活,故意活的像个人!

发布新日志

  • LoadRunner监视的性能计数器

    2006-12-13 10:55:09

    大家好,今后,我们将以专题的方式展开对LR监视的性能计数器及LR的场景设计设计的讨论,欢迎大家涌跃发言。
    今天,我先把我整理的一些计数器及其阈值要求等贴出来,这些计数器是针对我对windows操作系统,C/S结构的sql server数据库及WEB平台.net产品测试时的一些计数器;大家可以继续补充,作过unix平台上oracle数据库测试及J2EE架构及WEBLOGIC方面测试的朋友,也希望把自己使用的计数器贴出来,让大家分享。
    好了,先说这些了,希望通过这个专题,最终能让大家对自己的测试结果进行分析。

    Memory: 内存使用情况可能是系统性能中最重要的因素。如果系统“页交换”频繁,说明内存不足。“页交换”是使用称为“页面”的单位,将固定大小的代码和数据块从 RAM 移动到磁盘的过程,其目的是为了释放内存空间。尽管某些页交换使 Windows 2000 能够使用比实际更多的内存,也是可以接受的,但频繁的页交换将降低系统性能。减少页交换将显著提高系统响应速度。要监视内存不足的状况,请从以下的对象计数器开始:
    Available Mbytes:可用物理内存数. 如果Available Mbytes的值很小(4 MB 或更小),则说明计算机上总的内存可能不足,或某程序没有释放内存。


    page/sec: 表明由于硬件页面错误而从磁盘取出的页面数,或由于页面错误而写入磁盘以释放工作集空间的页面数。一般如果pages/sec持续高于几百,那么您应该进一步研究页交换活动。有可能需要增加内存,以减少换页的需求(你可以把这个数字乘以4k就得到由此引起的硬盘数据流量)。Pages/sec 的值很大不一定表明内存有问题,而可能是运行使用内存映射文件的程序所致。


    page read/sec:页的硬故障,page/sec的子集,为了解析对内存的引用,必须读取页文件的次数。阈值为>5. 越低越好。大数值表示磁盘读而不是缓存读。
    由于过多的页交换要使用大量的硬盘空间,因此有可能将导致将页交换内存不足与导致页交换的磁盘瓶径混淆。因此,在研究内存不足不太明显的页交换的原因时,您必须跟踪如下的磁盘使用情况计数器和内存计数器:
    Physical Disk\ % Disk Time
    Physical Disk\ Avg.Disk Queue Length
    例如,包括 Page Reads/sec 和 % Disk Time 及 Avg.Disk Queue Length。如果页面读取操作速率很低,同时 % Disk Time 和 Avg.Disk Queue Length的值很高,则可能有磁盘瓶径。但是,如果队列长度增加的同时页面读取速率并未降低,则内存不足。
    要确定过多的页交换对磁盘活动的影响,请将 Physical Disk\ Avg.Disk sec/Transfer 和 Memory\ Pages/sec 计数器的值增大数倍。如果这些计数器的计数结果超过了 0.1,那么页交换将花费百分之十以上的磁盘访问时间。如果长时间发生这种情况,那么您可能需要更多的内存。


    Page Faults/sec:每秒软性页面失效的数目(包括有些可以直接在内存中满足而有些需要从硬盘读取)较page/sec只表明数据不能在内存的指定工作集中立即使用。
    Cache Bytes:文件系统缓存(File System Cache),默认情况下为50%的可用物理内存。如IIS5.0 运行内存不够时,它会自动整理缓存。需要关注该计数器的趋势变化
    如果您怀疑有内存泄露,请监视 Memory\ Available Bytes 和 Memory\ Committed Bytes,以观察内存行为,并监视您认为可能在泄露内存的进程的 Process\Private Bytes、Process\Working Set 和Process\Handle Count。如果您怀疑是内核模式进程导致了泄露,则还应该监视 Memory\Pool Nonpaged Bytes、Memory\ Pool Nonpaged Allocs 和 Process(process_name)\ Pool Nonpaged Bytes。


    Pages per second :每秒钟检索的页数。该数字应少于每秒一页。

    Process:
    %Processor Time: 被处理器消耗的处理器时间数量。如果服务器专用于sql server,可接受的最大上限是80-85%
    Page Faults/sec:将进程产生的页故障与系统产生的相比较,以判断这个进程对系统页故障产生的影响。
    Work set: 处理线程最近使用的内存页,反映了每一个进程使用的内存页的数量。如果服务器有足够的空闲内存,页就会被留在工作集中,当自由内存少于一个特定的阈值时,页就会被清除出工作集。
    Inetinfo:Private Bytes:此进程所分配的无法与其它进程共享的当前字节数量。如果系统性能随着时间而降低,则此计数器可以是内存泄漏的最佳指示器。

    Processor:监视“处理器”和“系统”对象计数器可以提供关于处理器使用的有价值的信息,帮助您决定是否存在瓶颈。
    %Processor Time:如果该值持续超过95%,表明瓶颈是CPU。可以考虑增加一个处理器或换一个更快的处理器。
    %User Time:表示耗费CPU的数据库操作,如排序,执行aggregate functions等。如果该值很高,可考虑增加索引,尽量使用简单的表联接,水平分割大表格等方法来降低该值。
    %Privileged Time:(CPU内核时间)是在特权模式下处理线程执行代码所花时间的百分比。如果该参数值和"Physical Disk"参数值一直很高,表明I/O有问题。可考虑更换更快的硬盘系统。另外设置Tempdb in RAM,减低"max async IO","max lazy writer IO"等措施都会降低该值。
    此外,跟踪计算机的服务器工作队列当前长度的 Server Work Queues\ Queue Length 计数器会显示出处理器瓶颈。队列长度持续大于 4 则表示可能出现处理器拥塞。此计数器是特定时间的值,而不是一段时间的平均值。
    % DPC Time:越低越好。在多处理器系统中,如果这个值大于50%并且Processor:% Processor Time非常高,加入一个网卡可能会提高性能,提供的网络已经不饱和。

    Thread
    ContextSwitches/sec: (实例化inetinfo 和dllhost 进程) 如果你决定要增加线程字节池的大小,你应该监视这三个计数器(包括上面的一个)。增加线程数可能会增加上下文切换次数,这样性能不会上升反而会下降。如果十个实例的上下文切换值非常高,就应该减小线程字节池的大小。

    Physical Disk:
    %Disk Time %:指所选磁盘驱动器忙于为读或写入请求提供服务所用的时间的百分比。如果三个计数器都比较大,那么硬盘不是瓶颈。如果只有%Disk Time比较大,另外两个都比较适中,硬盘可能会是瓶颈。在记录该计数器之前,请在Windows 2000 的命令行窗口中运行diskperf -yD。若数值持续超过80%,则可能是内存泄漏。
    Avg.Disk Queue Length:指读取和写入请求(为所选磁盘在实例间隔中列队的)的平均数。该值应不超过磁盘数的1.5~2 倍。要提高性能,可增加磁盘。注意:一个Raid Disk实际有多个磁盘。
    Average Disk Read/Write Queue Length:指读取(写入)请求(列队)的平均数。
    Disk Reads(Writes)/s: 物理磁盘上每秒钟磁盘读、写的次数。两者相加,应小于磁盘设备最大容量。
    Average Disksec/Read: 指以秒计算的在此盘上读取数据的所需平均时间。
    Average Disk sec/Transfer:指以秒计算的在此盘上写入数据的所需平均时间。
    Network Interface:
    Bytes Total/sec :为发送和接收字节的速率,包括帧字符在内。判断网络连接速度是否是瓶颈,可以用该计数器的值和目前网络的带宽比较

    SQLServer性能计数器:
    Access Methods(访问方法) 用于监视访问数据库中的逻辑页的方法。
    . Full Scans/sec(全表扫描/秒) 每秒不受限的完全扫描数。可以是基本表扫描或全索引扫描。如果这个计数器显示的值比1或2高,应该分析你的查询以确定是否确实需要全表扫描,以及S Q L查询是否可以被优化。
    . Page splits/sec(页分割/秒)由于数据更新操作引起的每秒页分割的数量。
    Buffer Manager(缓冲器管理器):监视 Microsoft® SQL Server? 如何使用: 内存存储数据页、内部数据结构和过程高速缓存;计数器在 SQL Server 从磁盘读取数据库页和将数据库页写入磁盘时监视物理 I/O。 监视 SQL Server 所使用的内存和计数器有助于确定: 是否由于缺少可用物理内存存储高速缓存中经常访问的数据而导致瓶颈存在。如果是这样,SQL Server 必须从磁盘检索数据。 是否可通过添加更多内存或使更多内存可用于数据高速缓存或 SQL Server 内部结构来提高查询性能。
    SQL Server 需要从磁盘读取数据的频率。与其它操作相比,例如内存访问,物理 I/O 会耗费大量时间。尽可能减少物理 I/O 可以提高查询性能。
    .Page Reads/sec:每秒发出的物理数据库页读取数。这一统计信息显示的是在所有数据库间的物理页读取总数。由于物理 I/O 的开销大,可以通过使用更大的数据高速缓存、智能索引、更高效的查询或者改变数据库设计等方法,使开销减到最小。
    .Page Writes/sec (.写的页/秒) 每秒执行的物理数据库写的页数。
    .Buffer Cache Hit Ratio. 在“缓冲池”(Buffer Cache/Buffer Pool)中没有被读过的页占整个缓冲池中所有页的比率。可在高速缓存中找到而不需要从磁盘中读取的页的百分比。这一比率是高速缓存命中总数除以自 SQL Server 实例启动后对高速缓存的查找总数。经过很长时间后,这一比率的变化很小。由于从高速缓存中读数据比从磁盘中读数据的开销要小得多,一般希望这一数值高一些。通常,可以通过增加 SQL Server 可用的内存数量来提高高速缓存命中率。计数器值依应用程序而定,但比率最好为90% 或更高。增加内存直到这一数值持续高于90%,表示90% 以上的数据请求可以从数据缓冲区中获得所需数据。
    . Lazy Writes/sec(惰性写/秒)惰性写进程每秒写的缓冲区的数量。值最好为0。
    Cache Manager(高速缓存管理器) 对象提供计数器,用于监视 Microsoft® SQL Server? 如何使用内存存储对象,如存储过程、特殊和准备好的 Transact-SQL 语句以及触发器。
    . Cache Hit Ratio(高速缓存命中率,所有Cache”的命中率。在SQL Server中,Cache可以包括Log Cache,Buffer Cache以及Procedure Cache,是一个总体的比率。) 高速缓存命中次数和查找次数的比率。对于查看SQL Server高速缓存对于你的系统如何有效,这是一个非常好的计数器。如果这个值很低,持续低于80%,就需要增加更多的内存。
    Latches(闩) 用于监视称为闩锁的内部 SQL Server 资源锁。监视闩锁以明确用户活动和资源使用情况,有助于查明性能瓶颈。
    . Average Latch Wait Ti m e ( m s ) (平均闩等待时间(毫秒)) 一个SQL Server线程必须等待一个闩的平均时间,以毫秒为单位。如果这个值很高,你可能正经历严重的竞争问题。
    . Latch Waits/sec (闩等待/秒) 在闩上每秒的等待数量。如果这个值很高,表明你正经历对资源的大量竞争。
    Locks(锁) 提供有关个别资源类型上的 SQL Server 锁的信息。锁加在 SQL Server 资源上(如在一个事务中进行的行读取或修改),以防止多个事务并发使用资源。例如,如果一个排它 (X) 锁被一个事务加在某一表的某一行上,在这个锁被释放前,其它事务都不可以修改这一行。尽可能少使用锁可提高并发性,从而改善性能。可以同时监视 Locks 对象的多个实例,每个实例代表一个资源类型上的一个锁。
    . Number of Deadlocks/sec(死锁的数量/秒) 导致死锁的锁请求的数量
    . Average Wait Time(ms) (平均等待时间(毫秒)) 线程等待某种类型的锁的平均等待时间
    . Lock Requests/sec(锁请求/秒) 每秒钟某种类型的锁请求的数量。
    Memory manager:用于监视总体的服务器内存使用情况,以估计用户活动和资源使用,有助于查明性能瓶颈。监视 SQL Server 实例所使用的内存有助于确定:
    是否由于缺少可用物理内存存储高速缓存中经常访问的数据而导致瓶颈存在。如果是这样,SQL Server 必须从磁盘检索数据。
    是否可以通过添加更多内存或使更多内存可用于数据高速缓存或 SQL Server 内部结构来提高查询性能。
    Lock blocks:服务器上锁定块的数量,锁是在页、行或者表这样的资源上。不希望看到一个增长的值。
    Total server memory:sql server服务器当前正在使用的动态内存总量.

    监视IIS需要的一些计数器
    Internet Information Services Global:
    File Cache Hits %、File CacheFlushes、File Cache Hits
    File Cache Hits %是全部缓存请求中缓存命中次数所占的比例,反映了IIS 的文件缓存设置的工作情况。对于一个大部分是静态网页组成的网站,该值应该保持在80%左右。而File Cache Hits是文件缓存命中的具体值,File CacheFlushes 是自服务器启动之后文件缓存刷新次数,如果刷新太慢,会浪费内存;如果刷新太快,缓存中的对象会太频繁的丢弃生成,起不到缓存的作用。通过比较File Cache Hits 和File Cache Flushes 可得出缓存命中率对缓存清空率的比率。通过观察它两个的值,可以得到一个适当的刷新值(参考IIS 的设置ObjectTTL 、MemCacheSize 、MaxCacheFileSize)
    Web Service:
    Bytes Total/sec:显示Web服务器发送和接受的总字节数。低数值表明该IIS正在以较低的速度进行数据传输。
    Connection Refused:数值越低越好。高数值表明网络适配器或处理器存在瓶颈。
    Not Found Errors:显示由于被请求文件无法找到而无法由服务器满足的请求数(HTTP状态代码404)

  • LoadRunner的一个解决方案

    2006-12-13 10:53:37

    某web项目需求信息:要求在用户的登录时间小于5秒(包含登录中下载所有资源的时间)情况下的最大用户并发数。
    场景描述:以小规模的用户数每格一定的时间递增用户,递增的用户随正在运行的用户一起并发登录。每个用户的响应时间超过5秒就认为是错误。
    LoadRunner实现方式:
    1、录制脚本并把登录过程定义为一个事务,在事务前加一集合点;
    2、使用手动方案,设置用户数为较大的用户数;
    3、设置集合策略,选择“释放:当达到100%运行用户时”;
    4、设置加载方式为“每x秒加载y个用户”,数字根据具体情况设置;
    5、设置持续时间为“无限期运行”;
    6、在Controller的运行时设置中设置“浏览器仿真”,选中“下载非HTML资源”和“每次迭代模拟一个新用户”;
    7、在“Internet协议首选项”的高级设置中,选中“在本地保存快照资源”和“出现错误时激活快照”;
    8、接上步,单击“设置高级选项”右侧的“选项”按钮,在弹出的窗口中设置“HTTP请求连接超时”“HTTP请求接收超时”“步骤下载超时”均为5秒,并选择“由资源引起的步骤超时是一条警告信息”为否。
    9、开始运行脚本。
    辅助信息:
    1、可以参考“从Controller中监视VU执行脚本的情况”了解Virtual User的执行情况。
    2、可在脚本中适当增加检查点。
    3、以上第8步可能不太合理,你看出来了吗,一定还有更好的方式吧^_^
    从Controller窗口中查看当前脚本中的参数和vu的迭代次数的脚本实例:
    #include "as_web.h"
    static int iteration;
    Action()
    {
    char *pp;
    //请自定义参数文件NewParam
    pp="value={NewParam}";
    //在vugen调试窗口中显示当前参数值,在Controller窗口中不会显示出来
    lr_output_message("Para is:%s",lr_eval_string("{NewParam}"));
    //在Controller监视窗口中显示当前参数值和当前vu迭代次数,在vugen调试窗口中不会显示出来
    lr_vuser_status_message("Para is:%s,%dTimes Iteration",lr_eval_string("{NewParam}"),++iteration);
    return 0;
    }
    运行场景时在Controller运行窗口中单击Vusers按钮(开始方案按钮的下面),弹出窗口中可看到信息。

    web_url(); 步骤包含了思考时间,即使是在没有指定的情况下。
    解决方式:
            即使没有指定思考时间,系统也会自动为web_url("default.asp")步骤指定思考时间。
            在重播思考时间启用时该步骤会有10秒钟的暂停。忽略思考时间可以使它立即直接访问。
            在Analysis中如果选中筛选器中的包含思考时间选项就可以在结果中看到思考时间。
    以下是有关服务请求的细节知识:
            “在某些情况下运行脚本时,LoadRunner会加入它自己的思考时间。其中一种情况是当收到一个401错误时。当请求的cookie设置不正确时,有时应用服务器会返回401错误。LoadRuner一旦收到这个错误信息它就会等待10秒钟并且重新请求资源。这次LoadRunner将会向服务器发送正确的cookie,从而进行访问。”
            “401错误的存在要求站点运行正常。它的工作方式是这样的,第一次请求某个URL或着以一个新的会话返回了URL,服务器需要为此URL认证或指定一个session id,这样就会在错误的请求钟设置一个cookie信息。然后就会重新请求该URL,这次是使用的是一个有效的cookie,然后服务器发送你所请求的信息。”
            “如果没有返回401错误的话就不能生成一个新的cookie。没有新的cookie的话就不能访问服务器。”
            “在这里我们想要做的是让LoadRunner立即重新发送请求而不等待10秒。为了达到这个目的,请在脚本文件夹下default.cfg文件中的[Web]下面加入下面语句:”
             Retry401ThinkTime=0
            “这样设置以后,从Vugen中再次运行脚本或把它加到新的场景中或在已有的场景中删除并重新加入后运行,就不会在重新请求资源时等待10秒钟了。”
    使用自定义的VuGen脚本模板
    步骤:
    1、创建一个新的脚本;
    2、对此脚本进行所需的设置(自定义);
    3、保存脚本;
    4、现在,拷贝该脚本目录下的default.cfg文件到Program Files\Mercury Interactive\LoadRunner\template\{dir}目录下。{dir}表示你将要创建脚本的出处。例如,Web/HTML虚拟用户的目录是\qtweb\目录。你也可以自定义init.c、end.c和action.c,这样以后新建的脚本都会使用这些模板了。 

     

  • Loadrunner中参数的设置

    2006-12-13 10:47:47

    做负载或者压力测试时,很多人选择使用了Loadrunner测试工具。该工具的基本流程是先将用户的实际操作录制成脚本,然后产生数千个虚拟用户运行脚本(虚拟用户可以分布在局域网中不同的PC机上),最后生成相关的报告以及分析图。但是在录制脚本的过程中会遇到很多实际的问题,比如不同的用户有不同的使用数据,这就牵涉到参数的设置问题。本文就Loadrunner中参数的设置进行说明,希望对大家有所帮助。
    在录制程序运行的过程中,VuGen(脚本生成器) 自动生成了包含录制过程中实际用到的数值的脚本。如果你企图在录制的脚本中使用不同的数值执行脚本的活动(如查询、提交等等),那么你必须用参数值取代录制的数值。这个过程称为参数化脚本。
    本文主要包括如下内容:理解参数的局限性、建立参数、定义参数的属性、理解参数的类型、为局部数据类型设置参数的属性、为数据文件设置参数的属性、从已经存在的数据库中引入数据。
    除了GUI,以下的内容适合于各种类型的用户脚本。

    一、关于参数的定义
    在你录制程序运行的过程中,脚本生成器自动生成由函数组成的用户脚本。函数中参数的值就是在录制过程中输入的实际值。
    例如,你录制了一个Web应用程序的脚本。脚本生成器生成了一个声明,该声明搜索名称为“UNIX”的图书的数据库。当你用多个虚拟用户和迭代回放脚本时,也许你不想重复使用相同的值“UNIX”。那么,你就可以用参数来取代这个常量。结果就是你可以用指定的数据源的数值来取代参数值。数据源可以是一个文件,也可以是内部产生的变量。
    用参数表示用户的脚本有两个优点:① 可以使脚本的长度变短。② 可以使用不同的数值来测试你的脚本。例如,如果你企图搜索不同名称的图书,你仅仅需要写提交函数一次。在回放的过程中,你可以使用不同的参数值,而不只搜索一个特定名称的值。
    参数化包含以下两项任务:① 在脚本中用参数取代常量值。② 设置参数的属性以及数据源。
    参数化仅可以用于一个函数中的参量。你不能用参数表示非函数参数的字符串。另外,不是所有的函数都可以参数化的。

    二、参数的创建
    可以指定名称和类型来创建参数。不存在对脚本中参数个数的限制。在Web程序的用户脚本中,你可以使用如下过程在基于文本的脚本视图中创建参数。或者,也可以在基于图标的树形视图中创建参数。
    在基于文本的脚本视图中创建一个参数:
    1、 将光标定位在要参数化的字符上,点击右键。打开弹出菜单。
    2、 在弹出菜单中,选择“Replace with a Parameter”。选择或者创建参数的对话框弹出。
    3、 在“Parameter name”中输入参数的名称,或者选择一个在参数列表中已经存在的参数。
    4、 在“Parameter type”下拉列表中选择参数类型。
    5、 点击“OK”,关闭该对话框。脚本生成器便会用参数中的值来取代脚本中被参数化的字符,参数用一对“{}”括住。
    注意:在参数化CORBA或者General-Java 用户脚本的时候,必须参数化整个字符串,而不是其中的部分。另外注意:除了Web或者WAP,缺省的参数括号对于任何脚本都是 “{}”。你可以在“General Options”对话框中的“Parameterization”标签(Tools>General Options)中定义参数括号种类。
    6、 用同样的参数替换字符的其余情况,选中参数,点击右键,弹出菜单。从弹出的菜单中,选择“Replace More Occurrences”。搜索和替换对话框弹出。“Find What”中显示了你企图替换的值。“Replace With”中显示了括号中参数的名称。选择适当的检验框来匹配整个字符或者大小写。如果要搜索规则的表达式(.,!,?等等),选中“Regular Expression”检验框,然后点击“Replace”或者“Replace All”。
    注意:小心使用“Replace All”,尤其替换数字字符串的时候。脚本生成器将会替换字符出现的所有情况。
    7、 如果想用以前定义过的参数来替换常量字符串的话,选中该字符串,点击右键,然后选择“Use Existing Parameter”,子菜单“Use Existing Parameters”弹出。从子菜单“Use Existing Parameters”选择参数,或者用“Select from Parameter List”来打开参数列表对话框。
    注意:如果用以前定义过的参数来替换常量字符串的话,那么,使用“Parameter List”非常方便。同时,还可以查看和修改该参数的属性。
    8、 对于已经用参数替换过的地方,如果想取回原来的值,那么,就在参数上点击右键,然后选择“Restore Original value”。
    在Web用户脚本的树形视图中创建参数:
    1、将光标定位在企图参数化的地方,点击右键,从弹出的菜单中选择“Properties”。则相关的属性对话框打开。
    2、点击在要参数化的参量的旁边的“ABC”形状的图标。“Select or Create Parameter”对话框打开。
    3、在“Parameter name”中输入参数的名称,或者从列表中选择一个已经存在的参数。
    4、在“Parameter type”中输入参数的类型。
    5、点击“OK”关闭该对话框。用户脚本生成器会用参数来替换最初的字符串常量,并用一个表格形状的图标替换“ABC”形状的图标。
    6、要恢复参数化以前的值,点击图标,然后从弹出的菜单中选择“Undo Parameter”,则以前的值便会重现。

    三、定义参数的属性
    创建参数完成后,就可以定义其属性了。参数的属性定义就是定义在脚本执行过程中,参数使用的数据源。在Web用户脚本中,你既可以在基于文本的脚本视图中定义参数属性,也可以在基于图标的树形视图中定义参数属性。下面的过程将教你如何在基于本文的脚本视图中定义参数属性。
    在基于文本的脚本视图中定义参数属性步骤:
    1、 在参数上点击右键,有菜单弹出。
    2、 在弹出的菜单中,选择“Parameter Properties”。参数属性对话框打开,显示和当前参数类型相关的属性。
    3、 输入参数的属性值。
    4、 点击“Close”关闭参数属性对话框。
    在Web用户脚本的树形视图中定义参数的属性:
    1、 将关标定位在参数上,然后点击右键,选择“Properties”。属性对话框打开。
    2、 点击要定义属性的参数旁边的表格形状按钮,点击右键,选择“Parameter Properties”。参数属性对话框打开,和参数类型相关的属性显示出来。
    3、 输入参数的属性。
    4、 点击“Close”关闭参数属性对话框。
    使用参数列表:  使用参数列表可以在任意时刻查看所有的参数,创建新的参数、删除参数,或者修改已经存在参数的属性。
    1、 点击参数列表按钮或者用“Vuser>Parameter List”。参数列表对话框打开。
    2、 要创建新的参数,点击“New”按钮。新的参数则被添加在参数树中,该参数有一个临时的名字,你可以给它重新命名,然后回车。设置参数的类型和属性,点击“OK”,关闭参数列表对话框。
    注意:不要将一个参数命名为“unique”,因为这个名称是用户脚本生成器本身的。用户脚本生成器创建新的参数,但是不会自动用该参数在脚本中替换任意选中的字符串。
    3、 要删除已有的参数,那么,要先从参数树中选择该参数,点击“Delete”,然后确认你的行为即可。
    4、 要修改已有参数,那么,要先从参数树中选择该参数,然后编辑参数的类型和属性。

     

    四、理解参数的类型  在你定义参数属性的时候,要指定参数值的数据源。你可以指定下列数据源类型的任何一种:
    Internal Data―― 虚拟用户内部产生的数据。
    Data Files ――存在于文件中的数据。可能是已存在的文件或者是用脚本生成器新创建的。
    User-Defined Functions―― 调用外部DLL函数生成的数据  Internal Data包括以下几种:
    1、 Date/Time  Date/Time用当前的日期/时间替换参数。要指定一个Date/Time格式,你可以从菜单列表中选择格式,或者指定你自己的格式。这个格式应该和你脚本中录制的Date/Time格式保持一致。
    2、 Group Name  Group Name 用虚拟用户组名称替换参数。在创建scenario的时候,你可以指定虚拟用户组的名称。当从用户脚本生成器运行脚本的时候,虚拟用户组名称总是None。
    3、 Load Generator Name  Load Generator Name用脚本负载生成器的名称替换参数。负载生成器是虚拟用户在运行的计算机。
    4. Iteration Number  Iteration Number用当前的迭代数目替换参数。
    5、 Random Number  Random Number用一个随机数替换参数。通过指定最大值和最小值来设置随机数的范围。
    6、 Unique Number  Unique Number用一个唯一的数字来替换参数。你可以指定一个起始数字和一个块的大小。
    7、 Vuser ID  Vuser ID用分配给虚拟用户的ID替换参数,ID是由Loadrunner的控制器在scenario运行时生成的。如果你从脚本生成器运行脚本的话,虚拟用户的ID总是-1。

    五、数据文件  数据文件包含着脚本执行过程中虚拟用户访问的数据。局部和全局文件中都可以存储数据。可以指定现有的ASCII文件、用脚本生成器创建一个新的文件或者引入一个数据库。在参数有很多已知值的时候数据文件非常有用。数据文件中的数据是以表的形式存储的。一个文件中可以包含很多参数值。每一列包含一个参数的数据。列之间用分隔符隔开,比如说,用逗号。  对数据文件设置参数属性  如果使用文件作为参数的数据源,必须指定以下内容:文件的名称和位置、包含数据的列、文件格式,包括列的分隔符、更新方法。  如果参数的类型是“File”,打开参数属性(Parameter Properties)对话框,设置文件属性如下:
    1、 在“File path”中输入文件的位置,或者点击“Browse”指定一个已有文件的位置。缺省情况下,所有新的数据文件名都是“parameter_name.dat”,注意,已有的数据文件的后缀必须是.dat。


    2、 点击“Edit”。记事本打开,里面第一行是参数的名称,第二行是参数的初始值。使用诸如逗号之类的分隔符将列隔开。对于每一新的表行开始一行新的数据。  注意:在没有启动记事本的情况下如果想添加列,就在参数属性对话框中点击“Add Col”,那么“Add new column”对话框就会弹出。输入新列的名称,点击“OK”。脚本生成器就会添加该列到表中,并显示该列的初始值。


    3、 在“Select Column”部分,指明包含当前参数数据的列。你可以指定列名或者列号。列号是包含你所需要数据的列的索引。列名显示在每列的第一行(row 0)。


    4、 在“Column delimiter”中输入列分隔符,你可以指定逗号、空格符等等。


    5、 在“First data line”中,在脚本执行的时候选择第一行数据使用。列标题是第0行。若从列标题后面的第一行开始的话,那就在“First data line”中输入1。如果没有列标题,就输入0。


    6、 在“Select next row”中输入更新方法,以说明虚拟用户在脚本执行的过程中如何选择表中的数据。方法可以是:连续的、随机的、唯一的、或者与其它参数表的相同行。
    6.1、 顺序(Sequential):该方法顺序地给虚拟用户分配参数值。如果正在运行的虚拟用户访问数据表的时候,它会取到下一行中可用的数据。
    6.2、 随机(Random):该方法在每次迭代的时候会从数据表中取随机数
    6.3、 使用种子取随机顺序(Use Random Sequence with Seed):如果从Loadrunner的控制器来运行scenario,你可以指定一个种子数值用于随机顺序。每一个种子数值在测试执行的时候代表了一个随机数的顺序。无论你何时使用这个种子数值,在scenario中同样的数据顺序就被分配给虚拟用户。如果在测试执行的时候发现了一个问题并且企图使用同样的随机数序列来重复测试,那么,你就可以启动这个功能(可选项)。
    6.4、 唯一(Unique):Unique方法分配一个唯一的有顺序的值给每个虚拟用户的参数。
    6.5 、与以前定义的参数取同一行(Same Line As ):该方法从和以前定义过的参数中的同样的一行分配数据。你必须指定包含有该数据的列。在下拉列表中会出现定义过的所有参数列表。注意:至少其中的一个参数必须是Sequential、Random或者Unique。
    如果数据表中有三列,三个参数定义在列表中:id1,name1和title1,如下:。
    ID Name Title
    132 Kim Manager
    187 Cassie Engineer
    189 Jane VP
    对于参数id1,你可以指示虚拟用户使用Random方法,而为参数name1和title1就可以指定方法“Same Line as id1”。所以,一旦ID“132”被使用,那么,姓名(Name)“Kim”和职位(Title)“Manager”同时被使用。


    7、Updta value on数据的更新方法
    7.1、Each iteration――每次反复都要取新值。
    7.2、Each occurrence――只要发现该参数就要重新取值。
    7.3、Once――在所有的反复中都使用同一个值


    8、When out of values超出范围:(选择数据为unique时才可用到)
    8.1、Abort Vuser――中止
    8.2、Continue in a cyclic manner――继续循环取值
    8.3、Continue with last value――取最后一个值


    9、Allocate Vuser values in the Controller在控制器中分配值:(选择数据为unique时才可用到)

  • [Study LoadRunner] LoadRunner Java环境设置

    2006-12-13 10:16:04

    如果要使用LoadRunner对Java的应用环境(例如面对处理RMI, Corba, or Template VUsers等环境)进行Virtual Users操作,这个时候你必须对LoadRunner执行机器进行一定的设置,特别要注意Windows系统环境变量中的两个影响因素“PATH”、“CLASSPATH”

    PATH?

    这个变量告诉计算机到什么地方寻找文件,例如你要使用C:\Foo\Ammm.txt,假设程序内部只是设置了一个相对路径,当计算机需要调用这个文件的时候它有可能在当前路径下找不到该文件,造成整个程序执行失败。如果你在Windows的系统变量PATH中设置了C:\Foo\Ammm.txt或者C:\Foo,这种类型的问题就不会发生了。

    如果用LoadRunner做Java项目的性能测试,则LoadRunner需要使用Java Development Kit,所以Java Development Kit的路径设置就要当心了。不过现在的Java Development Kit在安装的时候会自动设置路径,等它安装后你需要检查一下,呵呵。

    J2SE Development Kit DownLoad

    J2EE Development Kit DownLoad

    操作PATH,在“我的电脑”点击鼠标右键打开菜单,选择“属性”,选择“高级”,在“高级”页面点击“环境变量”按钮,在“系统变量”中可以看到“Path”项目,可自行操作。

    CLASSPATH?

    CLASSPATH专属于Java,当你操作一个Java程序的时候这个系统变量告诉计算机从什么地方寻找 Java Development Kit或者寻找其他Java开发包,如果用LoadRunner做Java项目性能测试,你需要把所有该项目使用的Jar或者Zip文件的路径设置到CLASSPATH中,否则会在执行的时候由Java抛出“Not Found xxxClass”的异常。

    操作PATH,在“我的电脑”点击鼠标右键打开菜单,选择“属性”,选择“高级”,在“高级”页面点击“环境变量”按钮,在“系统变量”中可以看到“CLASSPATH”项目,可自行操作。如果没有用户可以自行添加,注意关键字“CLASSPATH”必须一致。




    安装开始:

    1.安装LoadRunner,最好以独立路径安装LoadRunner,例如:

    C:\LR702 or C:\loadrunner

    最好不要这样:C:\Program Files\loadrunner.

    2.安装Java Development Kit

    首页已经提供了SUN的最新开发包下载地址,不要安装SUN的JRE因为它不足以支持LoadRunner的需要。

    3.安装Java项目的RMI/Corba Application (可选)

    如果你需要RMI/Corba应用服务器(比如需要假设一个Web-based应用)就安装,一般现在都是服务器客户端模式本机可能不需要安装,不过Corba 需要在客户端安装Corba客户端支持软件,否则不能正常访问。
  • 软件测试:不可忽略的阶段

    2006-12-12 15:16:12

    在开发模型中,测试常常作为亡羊补牢的事后行为,但也有以测试为中心的开发模型。在本文中,让我们对V模型进行考察,看看它有没有问题?

    软件开发的几十年历程业已证明,在开发生命周期中划分阶段的做法是很有好处的。在经典的瀑布模型基础上,还有螺旋模型和过程迭代方法,快速软件开发(RAD)以及较新的Rational统一过程(RUP),但在这些过程方法中,并没有充分强调测试的价值,也没有给测试以足够的重视。

    就象开发有开发模型一样,测试也有测试模型,尽管这些方法鲜为人知。部分原因是因为很多测试人员已经在他们的工作中积累了大量的经验,利用这些经验就可以做好他们的工作。总的来说,测试往往要占据整个开发周期的时间,但即使在很多正规的大学中,也没有为那些即将开始软件生涯的学生们设置软件测试课程。

    软件专家们不断在提供新的开发模型,这也是实际开发需要使然,与此同时,在开发过程中也不断感受到这些已存在的方法的不足,例如,还没有比RUP更充分的方法,但RUP也存在一些明显的不足,例如,RUP没有对测试计划进行定位。

    V-模型


    V模型只得到软件业内比较模糊的认可。V-模型宣称测试并不是一个事后弥补行为,而是一个同开发过程同样重要的过程。V模型如下图所示:



    图1:V模型示意图


    V模型最早由已故的Paul Rook在80年代后期提出,V模型被包含在英国国家计算中心文献中发布,旨在改进软件开发的效率和效果。V模型在欧洲尤其是英国被接受,并被认为是瀑布模型的替代品,而在美国则被误解为是又一种瀑布模型。

    在传统开发过程中,仅仅把测试过程作为在需求分析、概要设计、详细设计及编码之后的一个阶段,事实上,V模型的推出也是对此所进行的改进。在瀑布模型中,确实给人们造成了这样的不良影响,即在很多重要开发活动完成后,测试只是收尾工作,而不是主要的过程,尽管有时测试会占据项目周期一半的时间,很多项目主管却仍然还是坚持这么认为。

    测试是一项意义显著的工作


    V模型描述了一些不同的测试级别,并说明了这些级别所对应的生命周期中不同的阶段。如模型图中所示,左边下降的是开发过程各阶段,与此相对应的是右边上升的部分,即各测试过程的各个阶段。请注意在不同的组织中,对测试阶段的命名可能有所不同。

    在模型图中的开发阶段一侧,先从定义业务需求开始,然后要把这些需求不断地转换到概要设计和详细设计中去,最后开发为程序代码。在测试执行阶段一侧,执行先从单元测试开始,然后是集成测试、系统测试和验收测试。

    V模型的价值在于它非常明确地标明了测试过程中存在的不同级别,并且清楚地描述了这些测试阶段和开发过程期间各阶段的对应关系:

    · 单元测试的主要目的是针对编码过程中可能存在的各种错误,例如用户输入验证过程中的边界值的错误。

    · 集成测试主要目的是针对详细设计中可能存在的问题,尤其是检查各单元与其它程序部分之间的接口上可能存在的错误。

    · 系统测试主要针对概要设计,检查了系统作为一个整体是否有效地得到运行,例如在产品设置中是否达到了预期的高性能。

    · 验收测试通常由业务专家或用户进行,以确认产品能真正符合用户业务上的需要。

    在不同的开发阶段,会出现不同类型的缺陷和错误,所以需要不同的测试技术和方法来发现这些缺陷。

    发现缺陷的艺术


    大多数测试人员比较容易接受V模型的观点,即测试和开发在开发过程中是平等的。即使是开发人员也同样很欣赏V模型所提出的测试级别和开发过程相对应的方式,但很少有人去充分利用V模型的全部威力。很多人认为测试只是在编码或者系统某个部分完成后会发生什么,并且错误地将测试看作为“执行测试”。这样,他们知道要开始执行测试的时候才真正想到了测试。

    测试不仅仅是测试。测试过程还包括确定要测试什么(测试范围和条件)以及产品如何被测试(制作测试用例),建立测试环境,执行测试,最后再评估测试结果,检查是否达到已完成测试的标准,并报告进展情况。而且,仅有这些还不够,根据很多测试者的经验,当你认为什么地方有问题时,你就很可能会在那里发现问题。如测试专家Boris Beizer在他经典的测试著作《Software Testing Techniques (Thomson Computer Press, 1990)》中所说,测试设计可以发现缺陷和错误。

    而且,如果你把测试设计放在最后阶段,就错过了发现构架设计和业务逻辑设计中存在的严重问题的时机,到那时,要修复这些缺陷将很不方便,因为缺陷已经扩散到系统中去了,所以这样的错误将很难寻找和修复,并且代价更高。

    比较灵活的解释,尽量提早的测试


    V模型在欧洲,至少在英国很容易被解释,但在美国却比较难以被接受。例如,虽然V模型没有明确说明早期的测试设计,而Graham则认为它体现在了处理过程中,并认为这是V模型的强大力量所在。V模型所没有明确说明的这些其它的测试行为有时被演化为一种W模型,因为实际上开发是"V",测试也是与此相重叠的"V"。不管V模型是否明确说明了早期的测试设计行为,测试设计确实是值得强调的。

    根据V模型的要求,一旦有文档提供,就要及时确定测试条件,以及编写测试用例,这些工作对测试的各级别都有意义。当需求被提交后,就需要确定高级别的测试用例来测试这些需求。当概要设计编写完成后,就需要确定测试条件来查找该阶段的设计缺陷。

    如果测试文档能尽早提交,那么就有了更多的检查和检阅的时间,这些文档还可用于评估开发文档。另外还有一个很大的益处是,测试者可以在项目中尽可能早地面对规格说明书的挑战(测试是一种接受挑战的行为)。

    这意味着测试不仅仅是评定软件的质量,测试还可以尽可能早地找出缺陷所在,从而帮助改进项目内部的质量。参与前期工作的测试者可以预先估计问题和难度,这将可以显著地减少总体测试时间,加快项目进度。

    What-How-Do


    对于传统的瀑布生命周期模型来说,V模型常被错误地认为是要求开发和测试保持一种线性的前后关系,需要有严格的指令表示上一阶段完全结束,才可正式开始下一个阶段。这样就无法支持迭代,自发性以及变更调整。例如,Brian Marickarick(《The Craft of Software Testing (Prentice Hall, 1995)》一书的作者)在“测试过程新模型”一文中提到,“V模型的问题在于一定要将系统开发过程分为具有严格边界的阶段,这使人们无法在这些边界之间交接和交换测试信息。”

    情况其实并不是这样的,严格规定不是有效的开发人员和测试人员在应用各种模型过程中所采用的方式。实际上,各种模型只是简单地提醒我们,有必要定义一些必须要做什么(需求)--What,然后描述如何做(设计)--How,然后花很多力气来实现(编码)--Do。V模型所做的是强调每一个开发级别都有一个与之相关联的测试级别,并且建议测试应该在各级别之前进行设计。

    各模型并没有规定工作量大小。有效的开发人员总是能将项目分解为可操作的小阶段,例如在迭代式开发中整个项目被分解为很多小片断,并忽略了各片段的实际大小。此时,模型的what-how-do顺序对于按时交付就具有重要意义,而且对于保证每一个阶段目标的实现也非常重要。

    V模型所不能做的


    V模型适用于所有类型的开发过程,但并不一定适用于开发和测试过程的所有方面。不管是GUI还是批处理、 大型机还是Web、Java还是Cobol,都需要单元测试、集成测试、系统测试和验收测试。但是,V模型本身并不会告诉你如何定义单元测试或集成测试的内容、以如何顺利工作、如何进行具体的测试设计,以及该输入怎样的数据,输出怎样的输出结果才是正确的。

    有些测试者认为:“是否使用V模型要看该所应用的项目。有些项目需要应用V模型,而有些项目不需要。可以只在需要V模型的项目中采用。”这样的做法实际上对任何模型都是有害的。我们应该尽可能地去应用模型中对项目有实用价值的方面,但不强行地为使用模型而使用模型,否则也没有实际意义。

    例如,V模型的反对者经常声称V模型只有对需求非常明确,已经文档化了的项目才有用,因为所有的开发人员和测试人员都需要严格定义好的需求和设计来开展工作。对于当前很多文档需要事后补充,或者根本没有文档的做法下(这已成为一种开发的文化),开发人员和测试人员都面临同样的困惑。在这种情况下,V模型的概念仍然是有用的,但在需求不明确的情况下更难应用,因为不管要开展什么工作,要测试什么,首先需要明确知道开发了什么。

    V模型的反对者可能会声称V模型不适用于极限编程(XP),在XP中提倡快速开发,结对编程,在编码之前就已完成测试用例。首先,我们提倡同时应用这两种方法,另外,也需要指出的是XP方法也强调在编程之前尽可能发现需求。

    V模型没有明确说明需求和设计文档应如何定义,要定义多少文档,同时V模型也没有说明在各测试阶段如何进行测试设计。在采用XP策略的开发过程中,V模型的支持者认为,可以将单元测试应用于所划分的各个代码片段上,但V模型没有定义各单元测试之间应如何匹配。只在必要的时候,才需要进行集成测试,而最终意义上的集成测试也就是系统测试。尽管一些XP工作者将这些测试看作为“验收测试”,其实际目的只是希望降低让用户进行测试的必要性,同时又希望能确保系统在功能上满足用户业务的需要。

    V模型的替代品--X模型?


    也许是由于V模型存在已有了一段时间,它曾带来过一定程度上的滥用,尤其是在那些Internet时代比较紧急的项目中。

    Marick认为:"我们对V模型的需要就象是鱼对自行车的需要一样。"在他的文章中提出了测试过程的新模型。他认为,有些测试要比商业行为更早些,而另外一些测试则要在更晚的时候得以进行。而且,V模型使人很难对不同阶段的系统描述进行综合。

  • 软件测试:不可忽略的阶段-V模型

    2006-12-12 15:14:57

    在开发模型中,测试常常作为亡羊补牢的事后行为,但也有以测试为中心的开发模型。在本文中,让我们对V模型进行考察,看看它有没有问题?

    软件开发的几十年历程业已证明,在开发生命周期中划分阶段的做法是很有好处的。在经典的瀑布模型基础上,还有螺旋模型和过程迭代方法,快速软件开发(RAD)以及较新的Rational统一过程(RUP),但在这些过程方法中,并没有充分强调测试的价值,也没有给测试以足够的重视。

    就象开发有开发模型一样,测试也有测试模型,尽管这些方法鲜为人知。部分原因是因为很多测试人员已经在他们的工作中积累了大量的经验,利用这些经验就可以做好他们的工作。总的来说,测试往往要占据整个开发周期的时间,但即使在很多正规的大学中,也没有为那些即将开始软件生涯的学生们设置软件测试课程。

    软件专家们不断在提供新的开发模型,这也是实际开发需要使然,与此同时,在开发过程中也不断感受到这些已存在的方法的不足,例如,还没有比RUP更充分的方法,但RUP也存在一些明显的不足,例如,RUP没有对测试计划进行定位。

    V-模型


    V模型只得到软件业内比较模糊的认可。V-模型宣称测试并不是一个事后弥补行为,而是一个同开发过程同样重要的过程。V模型如下图所示:



    图1:V模型示意图


    V模型最早由已故的Paul Rook在80年代后期提出,V模型被包含在英国国家计算中心文献中发布,旨在改进软件开发的效率和效果。V模型在欧洲尤其是英国被接受,并被认为是瀑布模型的替代品,而在美国则被误解为是又一种瀑布模型。

    在传统开发过程中,仅仅把测试过程作为在需求分析、概要设计、详细设计及编码之后的一个阶段,事实上,V模型的推出也是对此所进行的改进。在瀑布模型中,确实给人们造成了这样的不良影响,即在很多重要开发活动完成后,测试只是收尾工作,而不是主要的过程,尽管有时测试会占据项目周期一半的时间,很多项目主管却仍然还是坚持这么认为。

    测试是一项意义显著的工作


    V模型描述了一些不同的测试级别,并说明了这些级别所对应的生命周期中不同的阶段。如模型图中所示,左边下降的是开发过程各阶段,与此相对应的是右边上升的部分,即各测试过程的各个阶段。请注意在不同的组织中,对测试阶段的命名可能有所不同。

    在模型图中的开发阶段一侧,先从定义业务需求开始,然后要把这些需求不断地转换到概要设计和详细设计中去,最后开发为程序代码。在测试执行阶段一侧,执行先从单元测试开始,然后是集成测试、系统测试和验收测试。

    V模型的价值在于它非常明确地标明了测试过程中存在的不同级别,并且清楚地描述了这些测试阶段和开发过程期间各阶段的对应关系:

    · 单元测试的主要目的是针对编码过程中可能存在的各种错误,例如用户输入验证过程中的边界值的错误。

    · 集成测试主要目的是针对详细设计中可能存在的问题,尤其是检查各单元与其它程序部分之间的接口上可能存在的错误。

    · 系统测试主要针对概要设计,检查了系统作为一个整体是否有效地得到运行,例如在产品设置中是否达到了预期的高性能。

    · 验收测试通常由业务专家或用户进行,以确认产品能真正符合用户业务上的需要。

    在不同的开发阶段,会出现不同类型的缺陷和错误,所以需要不同的测试技术和方法来发现这些缺陷。

    发现缺陷的艺术


    大多数测试人员比较容易接受V模型的观点,即测试和开发在开发过程中是平等的。即使是开发人员也同样很欣赏V模型所提出的测试级别和开发过程相对应的方式,但很少有人去充分利用V模型的全部威力。很多人认为测试只是在编码或者系统某个部分完成后会发生什么,并且错误地将测试看作为“执行测试”。这样,他们知道要开始执行测试的时候才真正想到了测试。

    测试不仅仅是测试。测试过程还包括确定要测试什么(测试范围和条件)以及产品如何被测试(制作测试用例),建立测试环境,执行测试,最后再评估测试结果,检查是否达到已完成测试的标准,并报告进展情况。而且,仅有这些还不够,根据很多测试者的经验,当你认为什么地方有问题时,你就很可能会在那里发现问题。如测试专家Boris Beizer在他经典的测试著作《Software Testing Techniques (Thomson Computer Press, 1990)》中所说,测试设计可以发现缺陷和错误。

    而且,如果你把测试设计放在最后阶段,就错过了发现构架设计和业务逻辑设计中存在的严重问题的时机,到那时,要修复这些缺陷将很不方便,因为缺陷已经扩散到系统中去了,所以这样的错误将很难寻找和修复,并且代价更高。

    比较灵活的解释,尽量提早的测试


    V模型在欧洲,至少在英国很容易被解释,但在美国却比较难以被接受。例如,虽然V模型没有明确说明早期的测试设计,而Graham则认为它体现在了处理过程中,并认为这是V模型的强大力量所在。V模型所没有明确说明的这些其它的测试行为有时被演化为一种W模型,因为实际上开发是"V",测试也是与此相重叠的"V"。不管V模型是否明确说明了早期的测试设计行为,测试设计确实是值得强调的。

    根据V模型的要求,一旦有文档提供,就要及时确定测试条件,以及编写测试用例,这些工作对测试的各级别都有意义。当需求被提交后,就需要确定高级别的测试用例来测试这些需求。当概要设计编写完成后,就需要确定测试条件来查找该阶段的设计缺陷。

    如果测试文档能尽早提交,那么就有了更多的检查和检阅的时间,这些文档还可用于评估开发文档。另外还有一个很大的益处是,测试者可以在项目中尽可能早地面对规格说明书的挑战(测试是一种接受挑战的行为)。

    这意味着测试不仅仅是评定软件的质量,测试还可以尽可能早地找出缺陷所在,从而帮助改进项目内部的质量。参与前期工作的测试者可以预先估计问题和难度,这将可以显著地减少总体测试时间,加快项目进度。

    What-How-Do


    对于传统的瀑布生命周期模型来说,V模型常被错误地认为是要求开发和测试保持一种线性的前后关系,需要有严格的指令表示上一阶段完全结束,才可正式开始下一个阶段。这样就无法支持迭代,自发性以及变更调整。例如,Brian Marickarick(《The Craft of Software Testing (Prentice Hall, 1995)》一书的作者)在“测试过程新模型”一文中提到,“V模型的问题在于一定要将系统开发过程分为具有严格边界的阶段,这使人们无法在这些边界之间交接和交换测试信息。”

    情况其实并不是这样的,严格规定不是有效的开发人员和测试人员在应用各种模型过程中所采用的方式。实际上,各种模型只是简单地提醒我们,有必要定义一些必须要做什么(需求)--What,然后描述如何做(设计)--How,然后花很多力气来实现(编码)--Do。V模型所做的是强调每一个开发级别都有一个与之相关联的测试级别,并且建议测试应该在各级别之前进行设计。

    各模型并没有规定工作量大小。有效的开发人员总是能将项目分解为可操作的小阶段,例如在迭代式开发中整个项目被分解为很多小片断,并忽略了各片段的实际大小。此时,模型的what-how-do顺序对于按时交付就具有重要意义,而且对于保证每一个阶段目标的实现也非常重要。

    V模型所不能做的


    V模型适用于所有类型的开发过程,但并不一定适用于开发和测试过程的所有方面。不管是GUI还是批处理、 大型机还是Web、Java还是Cobol,都需要单元测试、集成测试、系统测试和验收测试。但是,V模型本身并不会告诉你如何定义单元测试或集成测试的内容、以如何顺利工作、如何进行具体的测试设计,以及该输入怎样的数据,输出怎样的输出结果才是正确的。

    有些测试者认为:“是否使用V模型要看该所应用的项目。有些项目需要应用V模型,而有些项目不需要。可以只在需要V模型的项目中采用。”这样的做法实际上对任何模型都是有害的。我们应该尽可能地去应用模型中对项目有实用价值的方面,但不强行地为使用模型而使用模型,否则也没有实际意义。

    例如,V模型的反对者经常声称V模型只有对需求非常明确,已经文档化了的项目才有用,因为所有的开发人员和测试人员都需要严格定义好的需求和设计来开展工作。对于当前很多文档需要事后补充,或者根本没有文档的做法下(这已成为一种开发的文化),开发人员和测试人员都面临同样的困惑。在这种情况下,V模型的概念仍然是有用的,但在需求不明确的情况下更难应用,因为不管要开展什么工作,要测试什么,首先需要明确知道开发了什么。

    V模型的反对者可能会声称V模型不适用于极限编程(XP),在XP中提倡快速开发,结对编程,在编码之前就已完成测试用例。首先,我们提倡同时应用这两种方法,另外,也需要指出的是XP方法也强调在编程之前尽可能发现需求。

    V模型没有明确说明需求和设计文档应如何定义,要定义多少文档,同时V模型也没有说明在各测试阶段如何进行测试设计。在采用XP策略的开发过程中,V模型的支持者认为,可以将单元测试应用于所划分的各个代码片段上,但V模型没有定义各单元测试之间应如何匹配。只在必要的时候,才需要进行集成测试,而最终意义上的集成测试也就是系统测试。尽管一些XP工作者将这些测试看作为“验收测试”,其实际目的只是希望降低让用户进行测试的必要性,同时又希望能确保系统在功能上满足用户业务的需要。

    V模型的替代品--X模型?


    也许是由于V模型存在已有了一段时间,它曾带来过一定程度上的滥用,尤其是在那些Internet时代比较紧急的项目中。

    Marick认为:"我们对V模型的需要就象是鱼对自行车的需要一样。"在他的文章中提出了测试过程的新模型。他认为,有些测试要比商业行为更早些,而另外一些测试则要在更晚的时候得以进行。而且,V模型使人很难对不同阶段的系统描述进行综合。

  • 软件测试术语

    2006-12-11 16:17:59



    术语:软件测试
    定义:软件测试是根据软件开发各阶段的规格说明和程序的内部结构而精心设计一批测试用例,并利用这些测试用例运行软件,以发现软件错误的过程。
    术语:测试用例
    定义:测试用例指对一项特定的软件产品进行测试任务的描述,体现测试方案、方法、技术和策略的文档;内容包括测试目标、测试环境、输入数据、测试步骤、预期结果、测试脚本等。
    术语:测试计划
    定义:测试计划是指对软件测试的对象、目标、要求、活动、资源及日程进行整体规划,以保证软件系统的测试能够顺利进行的计划性文档。
    术语:测试对象
    定义:测试对象是指特定环境下运行的软件系统和相关的文档。作为测试对象的软件系统可以是整个业务系统,也可以是业务系统的一个子系统或一个完整的部件。
    术语:测试流程
    定义:测试流程是指为了保证测试质量而精心设计的一组科学、合理、可行的有序活动。比较典型的测试流程一般包括“制定测试计划”、“编写测试用例”、“执行测试”、“跟踪测试缺陷”、“编写《测试报告》”等活动。
    术语:测试评估
    定义:测试评估是指对测试过程中的各种测试现象和结果进行记录、分析和评价的活动。
    术语:《测试报告》
    定义:《测试报告》是一份有关本次测试的总结性文档,主要记录了有关本次测试的目的、测试结果、评估结果及测试结论等信息。
    术语:测试环境
    定义:测试环境指对软件系统进行各类测试所基于的软、硬件设备和配置。一般包括硬件环境、网络环境、操作系统环境、应用服务器平台环境、数据库环境以及各种支撑环境等。
    术语:白盒测试
    定义:白盒测试是指基于一个应用代码的内部逻辑知识,即基于覆盖全部代码、分支、路径、条件的测试,白盒测试又叫“结构测试”
    术语:黑盒测试
    定义:黑盒测试是指不基于内部设计和代码的任何知识,而基于需求和功能性的测试,黑盒测试又叫“功能测试”。
    术语:单元测试
    定义:单元测试是指针对程序模块(软件设计的最小单位)来进行正确性检验的测试工作,单元测试又称模块测试。
    术语:集成测试
    定义:集成测试是指对程序模块采用一次性或增值方法组装起来,对模块间接口进行正确性检验的测试工作,集成测试又称组装测试。
    术语:系统测试
    定义:系统测试是指将通过集成测试的软件系统或子系统,作为基于计算机系统的一个元素,与计算机硬件、外设、某些支持软件、数据和人员等其他系统元素组合在一起所进行的测试工作;目的在于通过与系统的需求定义作比较,发现软件与系统定义不符合或与之矛盾的地方。
    术语:确认测试
    定义:确认测试是指在模拟(或正式)的生产环境下,运用黑盒测试的方法,验证所测软件是否满足用户需求说明书中所列出的需求,确认测试又称有效性测试。
    术语:功能测试
    定义:功能测试是指为了保证软件系统功能实现的正确性、完整性及其他特性而进行的测试。
    术语:性能测试
    定义:性能测试是指为了评估软件系统的性能状况和预测软件系统性能趋势而进行的测试和分析。
  • 软件测试中常用术语定义

    2006-12-11 16:15:53



    术语:软件测试
    定义:软件测试是根据软件开发各阶段的规格说明和程序的内部结构而精心设计一批测试用例,并利用这些测试用例运行软件,以发现软件错误的过程。
    术语:测试用例
    定义:测试用例指对一项特定的软件产品进行测试任务的描述,体现测试方案、方法、技术和策略的文档;内容包括测试目标、测试环境、输入数据、测试步骤、预期结果、测试脚本等。
    术语:测试计划
    定义:测试计划是指对软件测试的对象、目标、要求、活动、资源及日程进行整体规划,以保证软件系统的测试能够顺利进行的计划性文档。
    术语:测试对象
    定义:测试对象是指特定环境下运行的软件系统和相关的文档。作为测试对象的软件系统可以是整个业务系统,也可以是业务系统的一个子系统或一个完整的部件。
    术语:测试流程
    定义:测试流程是指为了保证测试质量而精心设计的一组科学、合理、可行的有序活动。比较典型的测试流程一般包括“制定测试计划”、“编写测试用例”、“执行测试”、“跟踪测试缺陷”、“编写《测试报告》”等活动。
    术语:测试评估
    定义:测试评估是指对测试过程中的各种测试现象和结果进行记录、分析和评价的活动。
    术语:《测试报告》
    定义:《测试报告》是一份有关本次测试的总结性文档,主要记录了有关本次测试的目的、测试结果、评估结果及测试结论等信息。
    术语:测试环境
    定义:测试环境指对软件系统进行各类测试所基于的软、硬件设备和配置。一般包括硬件环境、网络环境、操作系统环境、应用服务器平台环境、数据库环境以及各种支撑环境等。
    术语:白盒测试
    定义:白盒测试是指基于一个应用代码的内部逻辑知识,即基于覆盖全部代码、分支、路径、条件的测试,白盒测试又叫“结构测试”
    术语:黑盒测试
    定义:黑盒测试是指不基于内部设计和代码的任何知识,而基于需求和功能性的测试,黑盒测试又叫“功能测试”。
    术语:单元测试
    定义:单元测试是指针对程序模块(软件设计的最小单位)来进行正确性检验的测试工作,单元测试又称模块测试。
    术语:集成测试
    定义:集成测试是指对程序模块采用一次性或增值方法组装起来,对模块间接口进行正确性检验的测试工作,集成测试又称组装测试。
    术语:系统测试
    定义:系统测试是指将通过集成测试的软件系统或子系统,作为基于计算机系统的一个元素,与计算机硬件、外设、某些支持软件、数据和人员等其他系统元素组合在一起所进行的测试工作;目的在于通过与系统的需求定义作比较,发现软件与系统定义不符合或与之矛盾的地方。
    术语:确认测试
    定义:确认测试是指在模拟(或正式)的生产环境下,运用黑盒测试的方法,验证所测软件是否满足用户需求说明书中所列出的需求,确认测试又称有效性测试。
    术语:功能测试
    定义:功能测试是指为了保证软件系统功能实现的正确性、完整性及其他特性而进行的测试。
    术语:性能测试
    定义:性能测试是指为了评估软件系统的性能状况和预测软件系统性能趋势而进行的测试和分析。
885/5<12345
Open Toolbar