loadrunner controller将使用驱动程序mmdrv运行Vuser。用户可以在controller的run-time setting中选择Vuser的运行方式, 是多进程方式or多线程方式。

如果选择以线程方式来运行虚拟用户：

在场景设置时，“是单行脚本，还是多行脚本”会决定系统启动的进程数的多少：

    假设并发用户设置为30，如果是单行30个用户，系统只需启动一个进程；

    假设并发用户设置为30，如果是多行，30行，每行一个用户，系统就需要启动30个进程；

如果选择以进程方式来运行虚拟用户：

   那么无论脚本在场景组中怎么设置，是单行多用户还是多行少用户方式，系统需要启动的进程数是一定的，就是并发用户的总数；

进程方式和线程方式的优缺点：               

       如果选择按照进程方式运行， 每个用户都将启动一个mmdrv进程，多个mmdrv进程会占用大量内存及其他系统资源，这就限制了可以在任一负载生成器上运行的并发用户数的数量，因为负载机的资源（内存及其他系统资源）是有限的。

       如果选择按照线程方式运行，在默认情况下，controller为每50个用户仅启动一个mmdrv进程，而每个用户都按线程方式来运行，这些线程用户将共享父进程的内存段，这就节省了大量内存空间，从而可以在一个负载生成器上运行更多的用户。（如果选择线程方式来运行用户，每个进程中会多出几个线程，例如是53个，多出来的进程可能是用于维护进程之间的运行的）

      选择线程方式虽然可以减少启动的mmdrv进程数，减少了内存的占用，但是也容易出现一个问题，例如，同一个测试场景，用线程并发就会出现超时失败或报错，而用进程并发就没错。为什么呢？因为线程的资源是从进程资源中分配出来的，因此同一个进程中的多个线程会有共享的内存空间，假设a线程要用资源就必须等待b线程释放，而b线程也在等待其他资源释放才能继续，这样就会出现这个问题。

系统需要启动的mmdrv进程数与哪些因素有关：

       与在controller 的运行时设置中选择的是进程方式or线程方式来运行虚拟用户有关

             进程方式：无论是单行or多行脚本，需要启动的进程数就是并发用户数；

             线程方式：假设是单行脚本，每50个用户才启动一个进程；多行脚本，有几行（每行<50人）就启动几个进程，而不是每个用户启动一个进程。

       如果选择了线程方式，需启动的进程数，进一步还与脚本是单行还是多行有关

             单行脚本，多用户，假设少于50，只需启动一个进程，100个用户，只需启动2个进程，依此类推；

             多行脚本，即使每行一个用户，也需要启动一个进程，多一行就需要多启动一个进程；不是每个用户启动一个进程，有几行（每行<50人）就需要启动几个进程。

       在启动了IP欺骗功能后，所需启动的进程数，还与选择的是按进程还是按线程来分配IP地址有关

             按进程分IP：每个ip（负载生成器）就需要多启动一个进程；

             按线程分IP：每个ip（负载生成器）不需要多启动一个进程。

                   

1、SQL数据库：
1． User 0 Connections (用户连接数，也就是数据库的连接数量)；
2． Number of deadlocks/Sec/－Total （数据库死锁）
3． Memory\ Availalle Mbyte 内存监控 (可用内存)
4． Physicsdisk \disk time \－Total（磁盘读写总时间）（出现瓶颈时检查读磁盘的时间长还是写磁盘的时间长）
5． Butter Caile hit(数据库缓存的选取命中率)
6． 数据库的命中率不能低于92％
2、Web Server：
1． Processor \ Processon time \ Tatol cpu时间
2． Memory \ Availalle MbyteAvai 应用服务器的内存
3． Requst Quened 进入HTTP队列的时间；队列/每秒
4． Total request 总请求数时间
5． Avg Rps 平均每秒钟响应次数＝ 总请求时间 / 秒数
6． Avg time to last byte per terstion （mstes）平均每秒迭代次数 ； 上一个页面到下一个页面的时间是你录入角本的一个过程的执行
7． Http Error 无效请求次数
8． Send 发送请求次数字节数
Webload的压力参数：
l Load Size(压力规模大小)
l Round Time(请求时间)
l Rounds (请求数)
l Successful Rounds（成功的请求）
l Failed Rounds （失败的请求）
l Rounds Per Second （每秒请求次数）(是指你录入角本的任务在一秒中执行的次数，类似Avg time to last byte per terstion （mstes）)
l Successful Rounds Per Second(每秒成功的请求次数)
l Failed Rounds Per Second（每秒失败的请求次数）
l Page Time 页面响应时间
l Pages （页面数）
l Pages Per Second （每秒页面响应数）
l H it Time（点击时间）
l Hits（点击次数,也可以是请求次数，不过有一些不一样）
l Successful Hits （成功的点击次数）
l Failed Hits （失败的点击次数）
l Hits Per Second (每秒点击数)
l Successful Hits Per Second （每秒成功的点击次数）
l Failed Hits Per Second （每秒失败的点击次数）
l Attempted Connections （尝试链接数）
l Successful Connections（成功的连接数）
l Failed Connections（失败的连接数）
l Connect Time（连接时间）
l Process Time（系统执行时间,一般用来显示CPU的运算量，服务器端与客户端都要记录）
l Receive Time（接受时间）
l Send Time（请求时间）
l Time To First Byte （）
l Throughput （Bytes Per Second）（）
l Response Time（回应时间）
l Response Data Size（）
l Responses（）
 
 
 
Transactions per second（每秒处理事务数） http连接Get or Post方法的事务数
Rounds per second（每秒完成数） 每秒完全执行Agenda〔代理〕的数量
Throughput（吞吐量）(bytes per second〔每秒字节数〕) 测试服务器每秒传送的字节数
Round Time 完成一次事务所用的必要时间，单位是秒
Transaction Time是完成一次事务的必须时间。事务：包括连接时间，发送、响应和处理时间。
Connect Time 客户端到测试服务器的一个连接完成的时间，单位秒（包括建立和收到的TCP/IP时间）
Send Time 是将事务写入测试服务器的缓冲必要时间 ，单位秒
Response Time 是客户端请求接受测试服务器响应的必要时间，单位秒
Process Time 处理数据的必要时间
Load Size 负载测试时开启的虚拟客户数量〕
Rounds 在测试会话期间执行议程脚本的时间数
Attempted Connections 尝试连接测试服务器的数量
HTTP Response Status 每一个http响应被结束的时间数量
Response Data Size 由测试服务器发送的响应大小，单位字节。

最近在网上下了一套试题，一家企业招聘的测试笔试题，前面关于基本理论的部分基本上都会做，但是到了后面的测试工具和具体的测试实践部分就稀里糊涂了，别说蒙对了，好多概念和说法闻所未闻，怎一个汗字可以形容。看来学习的东西还有很多，希望自己能够一路坚持下来。

    下面把自己在各处看到的关于软件测试过程模型的介绍敲过来，感觉还是很不错的，和大家一起来学习一下，要是有高手有更好的文字说明，希望不吝赐教，小妹在此先言谢了，费话少说，进入正题吧.

背景知识：

    目前主流的软件生命周期模型或软件开发过程模型有：瀑布模型、原型模型、螺旋模型、增量模型、渐进模型、快速软件开发(RAD)以及Rational统一过程(RUP)等，这些模型对于软件开发过程具有很好的指导作用，但是在这些过程方法中，软件测试的地位和价值并没有体现出来，也没有给软件测试以足够的重视，利用这些模型无法更好地指导测试实践。软件测试是与软件开发紧密相关的一系列有计划、系统性的活动，显然软件测试也需要测试模型去指导实践。下面对主要的模型做一些简单的介绍。

1、V模型

    V模型是最具有代表性的测试模型。V模型最早是由Paul Rook在20世纪80年代后期提出的，V模型在英国国家计算中心文献中发布，旨在改进软件开发的效率和效果。

    在传统的开发模型中，比如瀑布模型，通常把测试过程作为在需求分析、概要设计、详细设计和编码全部完成之后的一个阶段，尽管有时测试工作会占用整个项目周期一半的时间，但是有人仍认为测试只是一个收尾工作，而不是主要的工程。V模型是软件开发瀑布模型的变种，它反映了测试活动与分析和设计的关系，从左到右，描述了基本的开发过程和测试行为，明确地标明了测试工程中存在的不同级别，清楚地描述了这些测试阶段和开发过程期间各阶段的对应关系。如图5-1所示。

                   图1  V模型图

    图1 V模型图中箭头代表了时间方向，左边下降的是开发过程各阶段，与此相对应的是右边上升的部分，即测试过程的各个阶段。

    V模型的软件测试策略既包括低层测试又包括了高层测试，低层测试是为了确保源代码的正确性，高层测试是为了使整个系统满足用户的需求。

    V模型指出，单元和集成测试是验证程序设计，开发人员和测试组应检测程序的执行是否满足软件设计的要求；系统测试应当验证系统设计，检测系统功能、性能的质量特性是否达到系统设计的指标；由测试人员和用户进行软件的确认测试和验收测试，追溯软件需求说明书进行测试，以确定软件的实现是否满足用户需求或合同的要求。

   V模型存在一定的局限性，它仅仅把测试过程作为在需求分析、概要设计、详细设计及编码之后的一个阶段。容易使人理解为测试是软件开发的最后一个阶段，主要是针对程序进行测试寻找错误，而需求分析阶段隐藏的问题一直到后期的验收测试才被发现。

类比记忆：此模型与软件开发模式中的线性模型（典型的瀑布模型）有相似的不足，在瀑布模型中，测试阶段处于软件实现后，这意味着必须在代码完成后有足够的时间预留给测试活动，否则将导致测试不充分，开发前期未发现的错误会传递并扩散到后面的阶段，而在后面发现这些错误时，可能已经很难回头再修正，从而导致项目的失败。

2、W模型

   V模型的局限性在于没有明确地说明早期的测试，不能体现“尽早地和不断地进行软件测试”的原则。在V模型中增加软件各开发阶段应同步进行的测试，被演化为一种W模型，因为实际上开发是V，测试也是与此相并行的V。基于“尽早地和不断地进行软件测试”的原则，在软件的需求和设计阶段的测试活动应遵循IEEE std1012-1998《软件验证和确认(V&V)》的原则。

一个基于V&V原理的W模型示意图如图2所示。

                      图2  W模型图

    相对于V模型，W模型更科学。W模型可以说是V模型自然而然的发展。W模型强调测试伴随着整个软件开发周期，而且测试的对象不仅仅是程序，需求、功能和设计同样要测试。这样，只要相应地开发活动完成，我们就可以开始执行测试，可以说，测试与开发是同步进行的，从而有利于尽早地发现问题。以需求为例，需求分析一完成，就可以对需求进行测试，而不是等到最后才进行针对需求的验收测试。

    如果测试文档能尽早提交，那么就有了更多的检查和检阅的时间，这些文档还可用于评估开发文档。另外还有一个很大的益处是，测试者可以在项目中尽可能早地面对规格说明书中的挑战。这意味着测试不仅仅是评定软件的质量，还可以尽可能早地找出缺陷所在，从而帮助改进项目内部的质量。参与前期工作的测试者可以预先估计问题和难度，这将可以显著地减少总体测试时间，加快项目进度。

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

    W模型也是有局限性的。W模型和V模型都把软件的开发视为需求、设计、编码等一系列串行的活动。同样，软件开发和测试保持一种线性的前后关系，需要有严格的指令表示上一阶段完全结束，才可以正式开始下一个阶段。这样就无法支持迭代、自发性以及变更调整。对于当前很多文档需要事后补充，或者根本没有文档的做法(这已成为一种开发的文化)，开发人员和测试人员都面临同样的困惑。

类比记忆：W模型相当两个V模型的叠加，一个是开发的V，一个是测试的V，由于在项目中开发和测试的是同步进行，相当于两个V是并列同步的进行的，测试在一定程度是随着开发的进展而不断向前进行。

3、H模型

     V模型和W模型均存在一些不妥之处。首先，如前所述，它们都把软件的开发视为需求、设计、编码等一系列串行的活动，而事实上，虽然这些活动之间存在相互牵制的关系，但在大部分时间内，它们是可以交叉进行的。虽然软件开发期望有清晰的需求、设计和编码阶段，但实践告诉我们，严格的阶段划分只是一种理想状况。试问，有几个软件项目是在有了明确的需求之后才开始设计的呢？所以，相应的测试之间也不存在严格的次序关系。同时，各层次之间的测试也存在反复触发、迭代和增量关系。其次，V模型和W模型都没有很好地体现测试流程的完整性。

为了解决以上问题，提出了H模型。它将测试活动完全独立出来，形成一个完全独立的流程，将测试准备活动和测试执行活动清晰地体现出来。H模型如图3所示。

           图3  H模型图

    H模型图仅仅演示了在整个生存周期中某个层次上的一次测试“微循环”。图中的其他流程可以是任意开发流程。例如，设计流程和编码流程。也可以是其他非开发流程，例如，SQA流程，甚至是测试流程自身。也就是说，只要测试条件成熟了，测试准备活动完成了，测试执行活动就可以(或者说需要)进行了。

概括地说，H模型揭示了：

1）软件测试不仅仅指测试的执行，还包括很多其他的活动。

2）软件测试是一个独立的流程，贯穿产品整个生命周期，与其他流程并发地进行。

3）软件测试要尽早准备，尽早执行。

4）软件测试是根据被测物的不同而分层次进行的。不同层次的测试活动可以是按照某个次序先后进行的，但也可能是反复的。

    在H模型中，软件测试模型是一个独立的流程，贯穿于整个产品周期，与其他流程并发地进行。当某个测试时间点就绪时，软件测试即从测试准备阶段进入测试执行阶段。

 

4、其他测试模型

    除了上述三种常见模型外，还有其他几种模型，如X模型、前置测试模型等。X模型提出针对单独的程序片段进行相互分离的编码和测试，然后经过频繁的交接，通过集成最终合成为可执行的程序。前置测试模型体现了开发与测试的结合，要求对每个交付的内容进行测试。这些模型都针对其他模型的缺点进行了一些修正，但本身仍然存在一些不足的地方。所以在软件测试过程中正确选取模型是一个很关键的问题。

测试模型的使用

    前面我们介绍了几种典型的测试模型，应该说这些模型对指导测试工作的进行具有重要的意义，但任何模型都不是完美的。我们应该尽可能地去应用模型中对项目有实用价值的方面，但不强行地为使用模型而使用模型，否则也没有实际意义。

    在这些模型中，V模型强调了在整个软件项目开发中需要经历的若干个测试级别，而且每一个级别都与一个开发级别相对应，但它忽略了测试的对象不应该仅仅包括程序，或者说它没有明确地指出应该对软件的需求、设计进行测试，而这一点在W模型中得到了补充。W模型强调了测试计划等工作的先行和对系统需求和系统设计的测试，但W模型和V模型一样也没有专门对软件测试流程予以说明，因为事实上，随着软件质量要求越来越为大家所重视，软件测试也逐步发展成为一个独立于软件开发的一系列活动，就每一个软件测试的细节而言，它都有一个独立的操作流程。比如，现在的第三方测试，就包含了从测试计划和测试用例编写，到测试实施以及测试报告编写的全过程，这个过程在H模型中得到了相应的体现，表现为测试是独立的。也就是说，只要测试前提具备了，就可以开始进行测试了。

    因此，在实际的工作中，我们要灵活地运用各种模型的优点，在W模型的框架下，运用H模型的思想进行独立的测试，并同时将测试与开发紧密结合，寻找恰当的就绪点开始测试并反复迭代测试，最终保证按期完成预定目标。

    试并反复迭代测试，最终保证按期完成预定目标。