经常把这些名词的意思混淆，现在把段念写的《软件性能测试过程详解与案例剖析》中的描述贴出来。希望自己多看几遍。

        在实际的性能测试中，经常接触到的与并发用户数相关的概念还包括“并发用户数”、“系统用户数”和“同时在线用户数”，下面用一个实际的例子来说明它们之间的差别。

        假设有一个OA系统，该系统有2000个使用用户——这就是说，可能使用该OA系统的用户总数是2000名，这个概念就是“系统用户数”，该系统有一个“在线统计”功能（系统用一个全局变量记数所有已登录的用户），从在线统计功能中可以得到，最高峰时有500人在线（这个500就是一般所说的“同时在线人数”），那么，系统的并发用户数是多少呢？

        根据我们对业务并发用户数的定义，这500就是整个系统使用时最大的业务并发用户数。当然，500这个数值只是表明在最高峰时刻有500个用户登录了系统，并不表示实际服务器承受的压力。因为服务器承受的压力还与具体的用户访问模式相关。例如，在这500个“同时使用系统”的用户中，考察某一个时间点，在这个时间上，假设其中40%的用户在较有兴致地看系统公告（注意：“看”这个动作是不会对服务端产生任何负担的），20%的用户在填写复杂的表格（对用户填写的表格来说，只有在“提交”的时刻才会向服务端发送请求，填写过程是不对服务端构成压力的），20%部分用户在发呆（也就是什么也没有做），剩下的20%用户在不停地从一个页面跳转到另一个页面——在这种场景下，可以说，只有20%的用户真正对服务器构成了压力。因此，从上面的例子中可以看出，服务器实际承受的压力不只取决于业务并发用户数，还取决于用户的业务场景。

       在实际的性能测试工作中，测试人员一般比较关心的是业务并发用户数，也就是从业务角度关注究竟应该设置多少个并发数比较合理，因此，在后面的讨论中，也是主要针对业务并发用户数进行讨论，而且，为了方便，直接将业务并发用户数称为并发用户数。

        （1）  计算平均的并发用户数： C = nL/T      

        （2）  并发用户数峰值： C’ ≈ C+3根号C

         公式（1）中，C是平均的并发用户数；n是login session的数量；L是login session的平均长度；T指考察的时间段长度。

        公式（2）则给出了并发用户数峰值的计算方式中，其中，C’指并发用户数的峰值，C就是公式（1）中得到的平均的并发用户数。该公式的得出是假设用户的login session产生符合泊松分布而估算得到的。

实例：

        假设有一个OA系统，该系统有3000个用户，平均每天大约有400个用户要访问该系统，对一个典型用户来说，一天之内用户从登录到退出该系统的平均时间为4小时，在一天的时间内，用户只在8小时内使用该系统。

则根据公式（1）和公式（2），可以得到：

               C = 400*4/8 = 200

               C’≈200+3*根号200 = 242

     看到51上三个高手Zee, 大漠飞鹰，xingcyx的一场非常精彩的关于并发用户数和集合点的讨论，很有意义。如果对这两个概念不清楚的朋友，一定要仔细领悟了。
故事开始于xingcyx的一番话：
声明：以下的问答是我根据实际工作经验和通过各种途径得到的信息而整理的，其回答内容主要代表我个人观点，并非标准答案，读者如有不同意见，欢迎批评指教。
Q：并发用户数和集合点有必然联系吗？在性能测试中必须使用集合点来测试吗？
A：并发用户数，顾名思义，就是同时操作的用户，这里的“操作”可以指对系统真正的操作，也可以只是连接（此时通常叫作“并发连接数”），而集合点是一种特殊情况下的并发，多用于测试系统在瞬间加压的表现。因此，并发用户数和集合点有联系，但并非必然的联系，在测试并发用户的性能测试场景中，可以不必设置集合点，这将视测试目标和测试策略而定。

Q：不设置集合点的测试，能代表是“并发”操作吗？
A：有这样一种说法，设置集合点是为了确保 “严格意义上”的并发，其实从本质上看，这主要是一个看问题的粒度大小的问题。集合点的作用是通过工具的控制，确保一个请求严格的“同时”从前台提交到后台。可是如果微观地看，是不存在严格意义上的并发的，即使在客户端通过设置集合点的方式将100个请求同时提交到后台，经过网络上的传输消耗，可能它们并不是同时到达的，而即便100个请求同时到达服务器端，受到中间件和应用系统、数据库的各种连接池、缓冲区， CPU处理队列等的限制，也可能在服务器端产生等待的。因此，严格意义上的“并发”可以说是不存在的，我们需要做的是在可以接受的粒度范围内取得一个最佳的平衡点，站在这个平衡点的层面上去看待“并发”这个问题。
性能测试无非有两个目的，一是评测，二是调优。
在以评测为目的的性能测试中，用户更关心的是业务上的并发，也就是真实业务场景的并发情况，这种情况下只要按照业务操作的模式去设置场景就可以了，并不需要设置集合点。
集合点是一种特殊情况下的并发，通常是在以调优为目的的性能测试中才会用得到，目的是有针对性地对某个可能存在性能问题的模块施压，以便找到性能瓶颈。
集合点在我实际的测试过程中用得并不多。

Zee：
关于集合点，我一直觉得没有什么可争议的，这两天看到几个帖子在说这个东西。有一点我想大家都是认同的：集合是相对的集合。
集合是在产生负载的机器上的集合。如果考虑网络，中间件等等的因素。到服务器肯定不会是同一时间点，那于是就有人希望能更接近在服务器端实现并发的操作。认为这才是真正的并发。
我觉得首先要做的是分析应用系统，到底你想做的是什么。
比如说，你想让某个URL能达到1000个同时请求的目的。这样的目标就比较明确了。
而在讨论集合点的时候，大家很少拿具体的东西来举个例子。这样有点说不清楚。要想达到并发。我觉得应该更具体的分析应用。再来定下目标来做。而不是一直在讨论LR如何能实现。

Xingcyx：
因为在实践中，我经常会碰到这样的情况：
测试需求说，该系统应支持200个并发用户。
那么我们就开始测，录制好脚本，下一步就是在场景中执行了，在控制台中设置某脚本并发用户数为200，测试结果为通过或未通过。此时争议就来了：这200个用户的脚本如果执行通过，测试结果可以接受，是否可以说这个系统支持了200个并发呢？

大漠飞鹰：
测试前肯定要了解需求，或者说是测试目的。
就说明“该系统应支持200个并发用户。”， 这种需求严格意义上来说是不合格的需求，因为描述不够清晰，过于模糊等。
当然，在实际中，这类需求到了我们测试人的手里也是常有的，一般就当普遍的情况来出来。
比如，web系统，就按2/5/8，或者2/5/10来处理，如果能通过就pass，否则就让开发人员调优。

Zee：
从集合点到并发数的确定。我觉得这其中的转换最主要的地方在于分析业务。
比如用户说了：要求200个用户并发。
那要问清楚的就是，200个用户是个什么样的比例，有多少人在干这个，有多人在干那个，按百分比，用不同的脚本来跑。
那再来想一下客户。他关心的是200个用户在服务器上同时点同一个URL或者某一个相同的资源？这个客户我想大多不会关心。而他想要的就是我有200个用户在线的时候。响应时间不至于让人不可接受。至于多少才不可接受。按平常人的心理承受能力来衡量就可以了。再或者有其他的说法，就是200人同时点同一 URL或者请求同一资源，我想可以通过计算来增加vuser的数量或者集合呀，或者其他的方法来努力的向这个目标靠近。
如果说非要在服务器上这个时间并发这么多的用户。我觉得只能尽量把它缩小到一个时间段内。而这样做我觉得并不是从分析业务出发的，

Xingcyx：
楼上说的是最常见的一种情况，在这种测试需求下，我会设置一个混合场景来测试，也就是按照做不同事情的用户的百分比去设置。
但会有另外一些时候，并不是一个实际的应用系统，可能是一个开发平台，或者工作引擎等，它涉及的性能的概念会更偏向底层一些，这个时候可能就不是像一般的应用系统那样，设置一个混合场景来测试那么简单了。

大漠飞鹰：
一般说的并发数指的是业务并发，而不是服务器端的并发数。
理解：业务并发分相对的和绝对的，分同时在线和同时触发，是从功能角度上去分析，如对某个功能操作进行并发测试；服务器并发是从服务器端看，接收到并发请求，一般是绝对并发，客户端绝对的无间隔并发在服务器端不一定无间隔并发，因为有网络等原因，到了服务器端往往就不是绝对并发了，是从技术角度去分析。

B/S.C/S架构之间的比较分析        C/S就是客户机和服务器结构,在客户端需要安装一个软件.将业务需求合理的分配到客户机与服务器两端来进行. C/S结构的软件需要针对不同的操作系统开发不同版本的软件. 如果产品的更新换代很快的话，就很难适应上百台电脑用户同时更新。更新的代价很高.          B/S 结构 即浏览器和服务器结构. 它是随着互联网技术的兴起，对C/S结构的一种变化或者改进的结构。在这种结构下，用户工作界面是通过浏览器来实现，极少部分事务逻辑在前端（Browser）实现，主要事务逻辑是在服务器端（Server）实现，形成所谓三层3结构。这样就大大简化了客户端电脑载荷，减轻了系统维护与升级的成本和工作量，降低了用户的总体成本。以目前的技术看，建立B/S结构的网络应用，在互联网模式下数据传输，相对易于把握、成本也是较低的。近似于一次性到位的开发，能实现不同的人员，从不同的地点，访问和操作共同的数据库. 下面谈一下C/S架构软件的优点与缺点 C/S的主要优势是服务器运行负荷比较轻。 最简单的C/S体系结构的数据库应用由两部分组成，即客户应用程序和数据库服务器程序。二者可分别称为前台程序与后台程序。服务器程序启动后,就会随时等待响应客户程序发来的请求；客户程序运行在用户自己的电脑上,当需要对数据库中的数据进行任何操作时，客户程序就自动地寻找服务器程序，并向其发出请求，服务器程序根据预定的规则做出响应，送回结果，这样服务器运行数据负荷较轻。 我们现在使用的软件,就是这样的流程,每次对服务器数据库的变更只是更改一些状态与需要更改的内容.更多的业务流程都是在本地实现,比如生成文档,统计图表,这样就减少了对服务器的要求. C/S架构的缺点是高昂的维护成本高投资大 首先，采用C/S架构，要选择适当的数据库平台来实现数据库数据的真正“统一”，使分布于两地的数据能够同步的去管理，但这需要两地的操作者要直接访问同一个数据库才能有效实现，如果需要建立“实时”的数据同步，就必须在两地间建立实时的通讯连接，保持两地的数据库服务器在线运行，网络管理工作人员既要对服务器维护管理，又要对客户端维护和管理，这需要高昂的投资和复杂的技术支持，维护成本很高，维护任务量大。 我们的软件现在对下面各市的数据库就不能做到实时的监控. 对于下面处理的流程就无法及时的掌握.问题也就在于C/S这个技术本身的瓶颈.   其次，传统的C/S结构的软件需要针对不同的操作系统系统开发不同版本的软件，对于我们现在的软件而言,在开发软件的时候就要注意开发工具,OFFICE套件之间的版本是否兼容,要注意加密狗与印章是否兼容,如果这些在版本上不能匹配的话,  很容易出现各种错误.   C/S最大的局限性,就在于应用范围,如果应用范围相对较小,那么用C/S, 否则必须用B/S. B/S架构软件的主要优势是维护和升级方式简单。 目前，软件系统的改进和升级越来越频繁. 对于我们单位来说，让系统管理员在几百甚至上千部电脑之间来回奔跑，效率和工作量是可想而知的，但B/S架构的软件只需要管理服务器就行了，所有的客户端只是浏览器，根本不需要做任何的维护。无论用户的规模有多大，有多少分支机构都不会增加任何维护升级的工作量，所有的操作只需要针对服务器进行；如果是异地，只需要把服务器用网络链接起来，实现远程维护、升级和共享。今后，软件升级和维护会越来越容易，而使用起来会越来越简单，这对用户人力、物力、时间、费用的节省是显而易见的。 B/S另一个优势是成本降低，选择更多。 大家都知道现在桌面电脑大部分操作系统都是windows，IE浏览器成为了标准配置，但在服务器操作系统上windows并不是处于绝对的统治地位。现在很多使用B/S架构的应用管理软件，只需安装在Linux服务器上即可，而且安全性高。所以服务器操作系统的选择是很多的，不管选用那种操作系统都可以让大部分人使用windows作为桌面操作系统电脑不受影响，这就使的免费的Linux操作系统快速发展起来， 这次中软来改版, 就是准备应用java语言开发, 那么所选用的服务器就比较多样,不会局限于windows,这样有助于提高安全性.   C/S 程序可以不可避免的整体性考虑， 构件的重用性不如在B/S要求下的构件的重用性好。 B/S 对的多重结构，要求构件相对独立的功能。替换一个模块的时候,不会影响到整个系统, B/S的缺点也主要在于服务器方面,由于B/S架构管理软件只安装在服务器端（Server）上，网络管理人员只需要管理服务器就行了，主要的业务流程全部通过服务器来做, 浏览器只是负责一个显示的功能。这样，应用服务器运行数据负荷较重，某些操作不易控制.比如像打印一个流转单,那么在浏览器下,控制单据格式是比较困难的.再比如生成Word文档,需要有固定的模板.这个操作如果在C/S下做,可以很迅速的完成.而且格式内容可以自由控制修改.而在B/S下,操作相对繁琐,有的操作只能下载到本地来处理. 服务器生成Word是比较消耗资源的.尤其是一台服务器下同时生成多个Word，很容易造成意想不到的错误.   针对图表生成与统计分析这些工作,在B/S平台上做,可以保证数字的及时性.但是如果统计过多的话,就会很慢,在浏览器上出报表图片,对服务器的性能也是一个考验. 用C/S方式来做.就可以有效的利用起客户机的相关资源.不会对服务器造成很大的负担. 今后进入2期细化的时候, 省级版可以考虑一下用C/S来解决统计分析相关需求.   再比如词语联想功能,类似Google搜索上面的提示词.这个如果在C/S上做,那就比较简单,对服务器影响不大,不过如果在B/S上,对服务器速度影响就会很大.   在安全方面, C/S做到保密性是相对来说比较容易的.当初选择使用点击平台,也是因为它通过了保密局的认定,而B/S在公网上面对公众,相对来说是开放的,这就对服务器的安全性提出了更高的要求. 一旦发生服务器“崩溃”等问题，整个系统就会瘫痪。因此，加强服务器备份也是十分重要的. 平时上传文件,比如上传比较大的报告,采用B/S上传比较容易造成断线,因为B/S比较难以实现断点续传功能.所以在传输上,为了保证完整性,可以适当考虑C/S传输. 在即时通讯方面, 用C/S就是最好的选择,所以我们最好采用点击作为即时通讯软件,然后将改版后的B/S系统嵌入点击平台.这样通过B/S与C/s的结合,各方面需求都能有所保障

不好意思，是转别人的成果。不过真的很不错，不偷学过来不甘心。哈哈

LoadRunner是一个强有力的压力测试工具。它的脚本可以录制生成，自动关联；测试场景可以面向指标，多方监控；测试结果可以用图表显示，并且可以拆分组合。

作为专业的性能测试工具，通过模拟成千上万的用户对被测系统进行操作和请求，能够在实验室环境中重现生产环境中可能出现的业务压力，再通过测试过程中获取的信息和数据来确认和查找软件的性能问题，分析性能瓶颈。

2.1  LoadRunner创建测试脚本

开发LoadRunner脚本需要经过图2-1所示的几个步骤。

在录制脚本时要遵循以下录制原则：

1．提高脚本执行效率

所录制的脚本内容要精练，而且是用户的真实操作，不可增加多余或重复性的操作，这样的脚本执行起来更能准确地模拟用户的真实行为，减少了执行时间，执行结果更准确。

2．录制具有代表性的功能

在一个软件中有很多不同的功能，但要录制所有的功能几乎是不可能的，所以要选择常用的、使用频率较高的业务功能来进行测试。

3．选择具有影响的事务

测试人员要对被测功能具有一定的认识和了解，选择一些对于整个测试过程中有影响的事务来测试，否则测试结果是无意义的。

当启动Visual User Generator后会出现选择脚本类型的对话框，在此对话框中，请选择我们常用的脚本类型，也就是Web（HTTP/HTML）协议，这是最为常见的。以下脚本介绍以此类型为例。

2.1.1  录制普通脚本

启动Visual User Generator，在弹出的对话框中选择需要新建的协议脚本，通过VuGen可以采用单协议或多协议模式，进行脚本的录制。选择单协议还是多协议，根据测试程序的实际需要而定。

1．选择协议

采用单协议模式时，VuGen将只录制指定的协议；采用多协议模式时，VuGen将录制多个协议中的操作。下列协议支持多协议脚本：COM、FTP、IMAP、Oracle NCA、POP3、RealPlayer、Window Sockets（原始）、SMTP和Web。“双协议Web/Web Services”的引擎使用一种不同的机制，应视为单协议，不能与其他多协议类型结合使用。

各种Vuser类型之间的另一个区别是多操作支持功能。大多数协议都可支持多个操作部分，如Oracle NCA、Web、RTE、General（C Vusers）、WAP、i-Mode 和VoiceXML等协议。

对于大多数Vuser类型，在每次录制时都会新建一个Vuser脚本，而不能在现有脚本中进行录制。但是，在录制Java、CORBA-Java、RMI-Java、Web、WAP、i-mode、Voice XML、Oracle NCA或RTE Vuser脚本时，可以在现有脚本中进行录制。

创建脚本时，单击“New”（新建）打开“New Virtual User”（新建Vuser）对话框，该对话框可提供选择录制脚本协议的快捷方式。

（1）单协议脚本：创建单协议Vuser脚本，这是“Startup”（启动）对话框打开时的默认选项。从Vuser生成器的“类别”中进行选择，并选择录制脚本的协议，如图2-2所示。

图2-2  选择单协议脚本

（2）多协议脚本：创建多协议Vuser脚本，VuGen将显示所有可用的协议。选择一个协议后，单击右箭头，将其移入“Selected Protocols”（选定的协议）部分中，如图2-3所示。

图2-3  选择多协议脚本

（3）使用最近使用过的协议新建脚本：从最近创建脚本的协议中选择已经使用过的协议，并且这些协议已经体现了录制脚本类型，如图2-4所示。

图2-4  选择最近使用的协议

2．开始录制

假设需要测试的是Web应用，选择“Web（HTTP/HTML）”协议，单击“OK”按钮确定后，进入主窗体，如图2-5所示。

图2-5  录制结果的主窗体

单击工具栏中“Start Record”按钮，根据录制的对话框，输入要测试程序的地址，开始进行录制。通过“Vuser”菜单来启动录制脚本的命令，如图2-6所示。

图2-6  选择录制按钮

也可以在工具栏中直接单击“Start Recording”按钮，但录制之前还要进行相应的设置，如图2-7所示。

图2-7  录制配置界面

（1）环境设置

首先，勾选“Record the application startup”，单击“OK”后，就会自动启动要测试的程序，还可以选择要把录制的脚本放到哪一个部分，默认情况下是“Action1”。

然后，单击左下角的“Options”按钮，进入录制环境设置界面，如图2-8所示。

Ÿ   “Recording”标签页：默认情况下选择“HTML-based Script”，说明脚本中采用HTML页面的形式，这种方式的Script脚本容易维护和理解，推荐用这种方式录制。“URL-based Script”说明脚本中的表示采用基于URL的方式，WAS和ACT中的录制方式就是这种，这种方式看上去比较乱。

其他标签页功能说明如下，如有需要可作相应的设置。

Ÿ   “Browser”标签页：浏览器的选择。

Ÿ   “Recording Proxy”标签页：浏览器上的代理设置。

图2-8  环境设置界面

Ÿ   “Advanced”标签页：可以设置录制时的思考时间（Think Time）、支持的字符集标准等。

Ÿ   “Correlation”标签页：手工设置关联，通过关联可在测试执行过程中保存动态值。使用这些设置可以配置VuGen在录制过程中执行的自动关联的程度。

（2）脚本内容

在录制过程中，可以单击“Pause”（暂停录制）按钮，在脚本中插入事务、注释和集合，防止在录制完成后再插入这些事务找不到具体位置。当业务流程完成后，单击“Stop”（停止录制）按钮，会自动生成脚本，退出录制过程，如图2-6所示。

单击“Save”（保存）按钮，起个与实际业务有关系的名字，保存到相应的位置。

使用VuGen录制之后生成的每个Vuser脚本都至少包含vuser_init、一个或多个Actions及vuser_end等三部分。

在通常情况下，将登录到服务器的活动记录在vuser_init部分中，将客户端活动录制到Actions部分中，并将注销过程录制到vuser_end部分中。因为运行多次迭代的Vuser脚本时，只有脚本的Actions部分重复，而vuser_init和vuser_end部分将不重复。

脚本图例如图2-9所示。

图2-9  脚本图例

在录制脚本期间，发出的消息可以通过日志来查看，选择“View”>“Output Window”，然后选择“Recording Log”选项卡。可以在“Run time Setting”的“Log”选项卡中设置该日志的详细级别，如图2-10所示。

图2-10  录制日志

录制时，VuGen会创建一系列配置、数据和源代码文件。这些文件包含Vuser运行时和设置信息。VuGen会将这些文件连同脚本一起进行保存。

至此，一个完整的Vuser脚本录制完成。

多协议脚本的录制与单协议脚本的录制过程基本相同，只是比单协议脚本的录制多一个选项界面，如图2-11所示。

在此界面中单击协议，可以进行添加和删除协议的操作。在协议前的复选框中打对号，即为选中，否则删除。

图2-11  添加协议

2.1.2  录制Web Services脚本

在进行性能测试时，大部分对Web性能测试，选择“Web（HTTP/HTML）”协议即可，但录制完脚本后，回放脚本过程中有时会发生中断或停止的情况，查看错误时，如果无法找到SOAP文件字样时，就需要考虑更换脚本录制协议了。通常首先考虑更换Web Services协议，再次录制脚本，问题就相应解决了。

在录制Web Services脚本前，首先对Web Services做一个简要的介绍，这样有助于读者或者测试人员能够更好地利用Web Services协议录制脚本。

1．什么是Web Services

Web Services是一种构建应用程序的普通模型，并能在所有支持Internet通信的操作系统上实施运行。Web Services令基于组件的开发和Web的结合达到最佳，基于组件的对象模型，如：分布式组件对象模型（Distributed Component Object Model, DCOM）、远程方法调用（Remote Method Invocation, RMI）、互联网内部对象请求代理协议（Internet Inter-Orb Protocol, IIOP）都已经发布很长时间，但是它们都依赖于特殊对象模型协议。而Web Services利用SOAP和XML对这些模型在通信方面作了进一步的扩展，以消除特殊对象模型的障碍。

进一步地，Web Services还基于HTTP和SOAP协议，使得Web用户通过Web调用的方法使用SOAP和HTTP来调用远程对象，确保业务数据得以在Web上传输。

2．Web Services结构

客户根据WSDL描述文档，会生成一个SOAP请求消息。Web Services都是放在Web服务器（如IIS）后面的，客户生成的SOAP请求会被嵌入在一个HTTP POST请求中，发送到Web服务器，Web服务器再把这些请求转发给Web Services请求处理器。请求处理器的作用在于，解析收到的SOAP请求，调用Web Services，然后再生成相应的SOAP应答。Web服务器得到SOAP应答后，会再通过HTTP应答的方式把信息送回到客户端。

3．Web Services体系

Web Services体系主要包括以下几个方面：

（1）Web Services包括3种组件。

服务提供者：提供服务，进行注册以使服务可用；

服务代理者：服务交换所，服务提供者和服务请求者之间的媒体；

服务请求者：向服务代理请求服务，调用这些服务创建应用程序。

（2）Web Services提供3种操作。

发布/不发布（Publish/Unpublish）：服务提供者向服务代理者发布（注册）服务或不发布（移去）这些服务的注册；

发现（Find）：由服务请求者向服务代理者执行发现操作，服务请求者描述要找的服务，服务代理者分发匹配的结果；

绑定（Bind）：在服务请求者和服务提供者之间绑定，这两部分协商以使请求者可以访问和调用提供者的服务。

（3）UDDI规范

统一描述、发现和集成（Universal Description Discovery and Integration, UDDI）是一个Web Services的信息注册规范，基于UDDI的Web Services注册可以被发现。UDDI的核心部分是UDDI业务登记逻辑，即在Web上有一种分布的注册服务，这种服务以一种通用的XML格式进行描述。通过XML中的结构化描述，可以很方便地在互联网上发现需要的数据，进而方便进行分析和操作。从概念上看，一个UDDI业务登记逻辑所提供的信息包括三个部分：“白页”包括地址、协议和已有标识；“黄页”包括基于分类标准的工业类型；“绿页”是关于企业所包含的服务技术信息，包括网络服务说明参考和根据发现机制对各种文件和网址提供的标识支持。

（4）网络服务描述语言（WSDL）

网络服务描述语言（Web Services Description Language, WSDL）遵循XML语法，为服务提供者提供了描述构建在不同协议或编码方式之上的Web Services请求基本格式的方法。WSDL用来描述一个Web Services能做什么，它的位置在哪里，如何调用它等。在假定以SOAP/HTTP/MIME作为远程对象调用机制的情况下，WSDL会发挥最大作用。UDDI注册描述了Web Services绝大多数方面，包括服务的绑定细节。WSDL可以看作是UDDI服务描述的子集。

WSDL将服务定义为一个网络端点的集合，或者说端口的集合。在 WSDL 里面，端点及消息的抽象定义与它们具体的网络实现和数据格式绑定是分离的。这样就可以重用这些抽象定义：消息（需要交换的数据的抽象描述）和端口类型（操作的抽象集合）。针对一个特定端口类型的具体协议和数据格式规范构成一个可重用的绑定。一个端口定义成网络地址和可重用的绑定的连接，端口的集合定义为服务。因此，一个WSDL文档在定义Web Services时使用如下的元素：

类型——使用某种类型系统定义数据类型的容器；

消息——通信数据抽象的有类型的定义；

操作——服务支持动作的抽象描述；

端口类型——操作的抽象集合，该操作由一个或多个端点支持；

绑定——针对一个特定端口类型的具体协议规范和数据格式规范；

端口——单一的端点，定义成一个绑定和一个网络地址的链接；

服务——相关端点的集合。

不难看出，WSDL给客户提供了一个模板，方便客户描述和绑定服务。

上面简单介绍了Web Services基本的知识，下面采用Web Services单协议进行简要的脚本录制，读者可结合录制脚本的过程进一步了解它，具体步骤如下：

选择“开始”>“程序”>“LoadRunner”>“Virtual User Generator”（Vuser生成器），启动VuGen。在VuGen的“File”下拉菜单中选择“New”，新建一个脚本；从“Category”（类别）列表中选择“Web Services”协议，单击“OK”按钮开始录制Vuser脚本。

首先配置Web Services录制向导，配置程序录制的方式。“Record Client Application”方式是通过客户端进行录制的，“Scan WSDL file”方式需要录入WSDL文件才可录制，在这里选择“Record Client Application”进行录制，如图2-12所示。

“Specify WSDL files for recording”向导用于配置WDSL文件，由于选择“Record Client Application”的录制方式，所以在此选择“Do not use WSDL file during recording”，表示不利用WSDL文件进行录制，如图2-13所示。

   

图2-12  Web Services录制界面1              图2-13  Web Services录制界面2

“Specify application to record”向导用于配置程序的访问地址、浏览器和录制脚本中的一些初始化设置。在URL中添加测试程序的访问地址；如果程序需要其他的浏览器，选择“Record any application”进行其他浏览器的设置，这里不需要特殊的浏览器，所以不选择此项；“Record into action”选项用于指定把录制的脚本放到哪一个部分，一般初始化放在vuser_init中，循环部分在Action中，结束退出部分放在vuser_end中，如图2-14所示。如有需要请单击后面的“Advanced Details”按钮，可以详细地配置“Options Recording”用来录制脚本，这里不介绍Options Recording，在以后的章节中有详细的介绍。单击“完成”按钮即可完成Web Services的向导配置。

然后VuGen将根据程序的访问地址自动启动应用程序，并显示“Recording…”（录制）工具栏，开始脚本的录制，如图2-15所示。

图2-14  Web Services录制界面3

图2-15 “Recording…”工具栏

在整个操作过程完成后，单击“停止”按钮，脚本录制结束，LoadRunner自动把录制的内容保存在脚本中。在录制完毕的脚本中会出现一些函数，在后面章节中会详细介绍这些函数的使用方法。

一个生成的Web Services的脚本节选如图2-16所示。

图2-16  Web Services脚本图例

这样就完成了Web Services单协议脚本的录制过程。

2.1.3  回放脚本及调试

录制完脚本后，需要单机运行一下脚本，因为在录制脚本的过程中可能会出现错误。例如：有些连接、图片或界面无法找到，需要调试；有些地方需要参数化，只有唯一值才能执行通过；还有可能回放脚本时出现-404、-500等错误页面，发生超时等现象。这时就需要把这些问题解决掉。

单击工具栏中的“Compile”按钮，查看脚本中是否有语法或者乱码错误，如果出现错误需要手工及时调试，如果没有错误，在执行日志中显示“No error detected”消息提示。

然后，单击工具栏中的“Run”按钮，开始执行脚本，在执行脚本期间，同样可以通过日志来查看发出的一些消息。选择“View”>“Output Window”，再选择“Execution Log”选项卡。

如果有错误，VuGen将会提示错误。双击错误提示，VuGen能够定位到出现错误的那一行，如图2-17所示。

图2-17  提示运行脚本错误

单机运行测试脚本后，如果编译通过，就会开始运行，运行结果如图2-18所示。

在每次单击回放脚本后，都会出现如图2-18所示的运行结果页。在结果页中可以清楚地看到脚本运行的情况，显示整个运行过程中出现成功、失败和警告情况各自的运行时间，并且记录下整个运行开始、结束的日期和时间。

图2-18  单机运行脚本结果

如果整个运行过程成功，在页面的左侧是整个脚本的树型结构，显示出的每个脚本的控件名称前都有绿色对号的标志，例如图片、链接、提交表单等，如图2-19所示。

图2-19  运行成功时的结果页

单击某个控件，在其右边便显示出其控件的页面或相应的运行步骤，如图2-20所示。

图2-20  显示运行成功步骤

在此结果页中还可以检测脚本中控件或者其他错误，如果脚本回放出现错误的话，会在相应控件前出现红色叉号的错误提示，如图2-21所示。

图2-21  运行失败的结果页

单击其控件后，在右边出现脚本未通过的具体原因，以便查找出错位置进行改正，如图2-22所示。

图2-22  定位运行失败

脚本录制、调试完成后，还可以通过插入事务、集合点等操作来完善、增强脚本。

2.1.4  完善脚本

为什么要完善增强脚本呢？

首先，为了衡量服务器的性能，需要定义事务（Transaction）。例如在脚本中有一个数据查询操作，为了衡量服务器执行查询操作的性能，可以把这个操作定义为一个事务。这样在运行测试脚本时，LoadRunner运行到该事务的开始点时，就会开始计时，直到运行到该事务的结束点，计时结束。这个事务的运行时间在测试结果中会有反映。LoadRunner允许在脚本中插入不限数量的事务。

在方案执行期间，控制台将测量执行每个事务所用的时间。方案运行后，可使用LoadRunner的图和报告来分析各个事务的服务器性能。

其次，使用集合点是为了衡量在加重负载的情况下服务器的性能情况。在测试计划中，可能会要求系统能够承受多人同时提交数据，LoadRunner通过在提交数据操作前面加入集合点的方法，检查同时有多少用户运行到集合点，人数不足时，LoadRunner会命令已经到集合点的用户等待，当在集合点等待的用户达到要求容纳的人数（如1000人）时，LoadRunner向系统提交数据。

在脚本中加入集合点后，控制台运行脚本时，可以对集合点进行策略设置，这样就可以根据实际情况在系统上模拟用户负载了。

再次，在录制过程中最好加入注释，因为在录制完脚本后看到的都是脚本代码，操作复杂的业务无法找到相应的位置进行关联或者参数化的动作，这时，注释就显得尤为重要。

最后，LoadRunner提供了很多函数，有些函数是在录制时根据不同的协议自带的函数。其中有些函数是供手工添加的，这就要根据实际情况进行添加了。例如脚本关联，有些变量无法实现系统自动关联，只能添加函数进行手动关联。

在录制完成的脚本中，还可以根据实际情况，添加事务、集合点、注释、函数等内容来增强脚本，进一步完善。下面逐一进行介绍。

1．插入事务

脚本中插入事务既可以在录制过程中直接插入，也可以在脚本录制结束后经编辑插入。建议采用在脚本的录制过程中插入事务的方法，这样不至于遗漏程序中应插入事务的操作。

在需要插入事务的操作前，通过工具栏上的“Start Transaction”（开始事务）按钮插入事务，事务的名称最好有意义，这样在最后分析系统时，有助于发现系统的瓶颈点是否在具体的事务中。

具体的操作方法如下：在录制Vuser脚本时，在需要定义事务的操作前面，单击“录制”工具栏上的“Start Transaction”菜单项，将打开“Start Transaction”对话框，如图2-23所示。

接着出现如图2-24所示的对话框。

  

图2-23  插入事务开始点                    图2-24  输入事务开始名称

在给事务起名字时，事务名必须以字母或数字开始，可以包含字母、数字或者下列字符：!、$、%、&、'、-、[、^、_、`、<、>、{、}、|或~。填写好事务名称后，就可以对系统进行操作，单击“OK”接受该事务名称。

VuGen将自动在Vuser脚本中插入事务的起始标志（“lr_start_transaction”）和终点标志（“lr_end_transaction”）。起点和终点之间的内容就是录制或者编写的测试事务脚本。

在录制脚本过程中，随时可以单击“录制”工具栏上的“End Transaction”菜单项，结束录制，如图2-25所示。

图2-25  插入事务结束点

此时会出现如图2-26所示的结束事务的对话框。

单击“Transaction Name”下拉框的箭头获得已打开事务的列表，选择要关闭的事务。事务的状态在默认情况下是LR_AUTO。一般情况下，也不需要修改，除非在手工编写代码时，有可能需要手动设置事务的状态。单击“OK”按钮接受该事务名称。

脚本中事务的代码如图2-27所示。

               

图2-26  选择要结束事务的名称                        图2-27  插入事务图例

当结束事务时，通过工具栏上的“End Transaction”按钮，结束事务。在结束列表中会显示最近定义的事务的名称，只要选择自己新建的事务的名称即可结束该事务。

这样就完成了事务的插入操作。

2．插入集合点

集合点只能在Action中插入，不能在vuser_init或vuser_end中插入。

在需要插入集合点的操作前，通过工具栏上的集合点按钮插入集合点，并在集合点的输入框中输入集合点的名称。集合点的名称最好是有意义的名称，这样有助于在系统分析时，分析系统的瓶颈所在。

插入集合点具体的操作方法如下：在录制Vuser脚本时，在需要插入集合点的位置，单击“录制”工具栏上的“集合点”按钮或单击“Insert”菜单下的“Rendezvous”子菜单。将打开“Rendezvous”（集合点）对话框，如图2-28所示。

图2-28  插入集合点

接着，出现如图2-29所示的对话框。输入该集合点的名称，注意，名称最好能够清楚地说明该集合点所完成的动作。脚本中集合点的代码如图2-30所示。

        

图2-29  输入集合点名称                图2-30  插入集合点图例

3．插入注释

注释可以在录制脚本时插入，也可以在脚本录制后插入，其顺序对程序分析没有影响。在需要插入注释的操作前，通过工具栏上的“注释”按钮或者“Insert”菜单下的“Comment”子菜单插入注释。在“Insert Comment”对话框中输入对操作的注释，以便于对脚本的重复使用。

在需要插入注释的位置，通过菜单或者工具栏操作，如图2-31所示。

图2-31  插入注释

接着，出现如图2-32所示的对话框。脚本中注释的代码如图2-33所示。

                 

图2-32  输入注释内容                           图2-33  插入注释图例

4．插入函数

在录制脚本的过程中，根据不同的协议，会用到不同的函数，在此介绍几个脚本中比较常见的函数，希望初学者能对插入函数的基本操作方法有大概的了解。详细的函数调用方法，会在第6章的“LoadRunner函数介绍”中说明，这里不再赘述。

（1）web_custom_request：允许使用HTTP支持的任何方法来创建自定义HTTP请求。

（2）web_image：在定义的图像上模拟鼠标单击。

例子：

web_image("46.gif",

"Src=frame/sapphire/image/tree/15/46.gif",

"Ordinal=2",

"Snapshot=t4.inf",

EXTRARES,

"Url=frame/sapphire/style/controls.css","Referer=http:// 192.168.1.10:7001/mail/login.do", ENDITEM,

"Url=frame/sapphire/style/custom.css",

"Referer=http://192.168.1.10/mail/login.do ", ENDITEM, LAST);

（3）web_link：在定义的文本链接上模拟鼠标单击。

例子：

    web_link("MAIL",

    "Text= MAIL ",

    "Snapshot=t3.inf",

    EXTRARES,

    "Url=frame/sapphire/style/menu.css",

"Referer=http://192.168.1.10:7001/mail/login.do ", ENDITEM,

    "Url=frame/sapphire/style/panel.css",

"Referer=http:// 192.168.1.10:7001/mail/login.do ", ENDITEM, LAST);

（4）web_submit_data：执行“无条件”或“无上下文”的表单。

例子：

web_submit_data("j_security_check",

"Action=http://192.168.1.121:10001/Application/j_security_check",

    "Method=POST",   

    "RecContentType=text/html",

    "Referer=http://192.168.1.121:10001/Application/login.jsp; jsessionid=013613D116183D08E6C0C05A1310B70F.node1",

    "Snapshot=t2.inf",

    "Mode=HTTP",

    ITEMDATA,

    "Name=j_username", "Value=mayi", ENDITEM,

    "Name=j_password", "Value=1", ENDITEM,

    "Name=prelogon", "Value=登录", ENDITEM,

    LAST);

（5）web_submit_form：模拟表单的提交。

例子：

web_submit_form("zxlogin.do",

"Snapshot=t2.inf",

ITEMDATA,

"Name=username", "Value=001_yangzhifang", ENDITEM,

"Name=password", "Value=1", ENDITEM,

"Name=btnlogin", "Value=登录", ENDITEM,

EXTRARES,

"Url=frame/images/quick_1_01.gif",

"Referer=http://192.168.1.103:8080/Application/mail/fox/zxMain.jsp",ENDITEM,

"Url=frame/images/quick_2_03.gif",

"Referer=http://192.168.1.103:8080/Application/mail/fox/zxMain.jsp",ENDITEM,LAST);

（6）web_url：加载由“URL”属性指定的URL。

例子：

web_url("Application",

"URL=http://192.168.1.121:10001/Application",

"Resource=0",

"RecContentType=text/html",

"Referer=",

"Snapshot=t1.inf",

"Mode=HTTP",

LAST);

（7）web_add_cookie：添加新的Cookie或修改现有的Cookie。

例子：

web_add_cookie("cnt_uid_www=9f9e130439330156c92c51430b3e0120; DOMAIN=top2007.csdn.net");

web_add_cookie("IMMsgID_d41d8cd98f00b204e9800998ecf8427e=70; DOMAIN=top2007.csdn.net");

（8）web_set_timeout：指定Vuser等待执行指定任务的最长时间。

2.1.5  脚本回放问题解决

在运行脚本回放过程中，有时会出现错误，这在实际测试中是不可避免的，毕竟自动录制生成的脚本难免会有问题，需要运行脚本进行验证，把问题都解决后才加入到场景中进行负载测试。下面结合常用的协议（如Web、Web Services协议）录制的脚本进行回放时出现的问题介绍一下解决的方法。

需要注意的是，回放脚本时出现的错误有时是程序自身的原因导致的，因此在解决脚本回放问题前必须保证程序录制出的脚本是正确的。

1．LoadRunner超时错误：在录制Web协议脚本回放时超时情况经常出现，产生错误的原因也有很多，解决的方法也不同。

错误现象1：Action.c(16): Error -27728: Step download timeout (120 seconds) has expired when downloading non-resource(s)。

错误分析：对于HTTP协议，默认的超时时间是120秒（可以在LoadRunner中修改），客户端发送一个请求到服务器端，如果超过120秒服务器端还没有返回结果，则出现超时错误。

解决办法：首先在运行环境中对超时进行设置，默认的超时时间可以设置长一些，再设置多次迭代运行，如果还有超时现象，需要在“Runtime Setting”>“Internet Protocol：Preferences”>“Advanced”区域中设置一个“winlnet replay instead of sockets”选项，再回放是否成功。

错误现象2：Action.c(81):Continuing after Error -27498: Timed out while processing URL=http://172.18.20.70:7001/workflow/bjtel/leasedline/ querystat/ subOrderQuery.do

错误分析：这种错误常常是因为并发压力过大，服务器端太繁忙，无法及时响应客户端的请求而造成的，所以这个错误是正常现象，是压力过大造成的。

如果压力很小就出现这个问题，可能是脚本某个地方有错误，要仔细查看脚本，提示的错误信息会定位某个具体问题发生的位置。

解决办法：例如上面的错误现象问题定位在某个URL上，需要再次运行一下场景，同时在其他机器上访问此URL。如果不能访问或时间过长，可能是服务器或者此应用不能支撑如此之大的负载。分析一下服务器，最好对其性能进行优化。

如果再次运行场景后还有超时现象，就要在各种图形中分析一下原因，例如可以查看是否服务器、DNS、网络等方面存在问题。

最后，增加一下运行时的超时设置，在“Run-Time Settings”>“Internet Protocol:Preferences”中，单击“options”，增加“HTTP-request connect timeout” 或者“HTTP-request receive”的值。

2．LoadRunner脚本中出现乱码：在录制Web协议脚本时出现中文乱码，在回放脚本时会使回放停止在乱码位置，脚本无法运行。

错误现象：某个链接或者图片名称为中文乱码，脚本运行无法通过。

错误分析：脚本录制可能采用的是URL-based script方式，如果程序定义的字符集合采用的是国际标准，脚本就会出现乱码现象。

解决办法：重新录制脚本，在录制脚本前，打开录制选项配置对话框进行设置，在“Recording Options”的“Advanced”选项里先将“Surport Charset”选中，然后选中支持“UTF-8”的选项。

3．LoadRunner HTTP服务器状态代码：在录制Web协议脚本回放脚本的过程中，会出现HTTP服务器状态代码，例如常见的页面-404错误提示、-500错误提示。

错误现象1：-404 Not Found服务器没有找到与请求URI相符的资源，但还可以继续运行直到结束。

错误分析：此处与请求URI相符的资源在录制脚本时已经被提交过一次，回放时不可再重复提交同样的资源，而需要更改提交资源的内容，每次回放一次脚本都要改变提交的数据，保证模拟实际环境，造成一定的负载压力。

解决办法：在出现错误的位置进行脚本关联，在必要时插入相应的函数。

错误现象2：-500 Internal Server Error服务器内部错误，脚本运行停止。

错误分析：服务器碰到了意外情况，使其无法继续回应请求。

解决办法：出现此错误是致命的，说明问题很严重，需要从问题的出现位置进行检查，此时需要此程序的开发人员配合来解决，而且产生的原因根据实际情况来定，测试人员无法单独解决问题，而且应该尽快解决，以便于后面的测试。

4．LoadRunner请求无法找到：在录制Web协议脚本回放脚本的过程中，会出现请求无法找到的现象，而导致脚本运行停止。

错误现象：Action.c(41): Error -27979: Requested form. not found [MsgId: MERR-27979]

Action.c(41): web_submit_form. highest severity level was "ERROR",0 body bytes, 0 header bytes  [MsgId: MMSG-27178]"

这时在tree view中看不到此组件的相关URL。

错误分析：所选择的录制脚本模式不正确，通常情况下，基于浏览器的Web应用会使用“HTML-based script”模式来录制脚本；而没有基于浏览器的Web应用、Web应用中包含了与服务器进行交互的Java Applet、基于浏览器的应用中包含了向服务器进行通信的JavaScript/VBScript代码、基于浏览器的应用中使用HTTPS安全协议，这时则使用“URL-based script”模式进行录制。

解决办法：打开录制选项配置对话框进行设置，在“Recording Options”的“Internet Protocol”选项里的“Recording”中选择“Recording Level”为“HTML-based script”，单击“HTML Advanced”，选择“Script. Type”为“A script. containing explicit”。然后再选择使用“URL-based script”模式来录制脚本。

5．LoadRunner不执行检查方法：在录制Web协议脚本中添加了检查方法Web_find，但是在脚本回放的过程中并没有执行。

错误现象：在脚本中插入函数Web_find，在脚本中设置文本以及图像的检查点，但是在回放过程中并没有对设置的检查点进行检查，即Web_find失效。

错误分析：由于检查功能会消耗一定的资源，因此LoadRunner默认关闭了对文本以及图像的检查，所以在设置检查点后，需要开启检查功能。

解决办法：打开运行环境设置对话框进行设置，在“Run-time Settings”的“Internet Protocol”选项里的“Perference”中勾选“Check”下的“Enable Image and text check”选项。

6．LoadRunner回放Web Services协议脚本错误：LoadRunner 8.0版本在录制Web Services协议的脚本时正常，但在回放时会出现错误，提示停止脚本运行。

错误现象：利用LoadRunner 8.0版本来录制Web Services协议的脚本没有任何错误提示，回放脚本时会出现如下错误提示“Error：server returned an incorrectly formatted SOAP response”。

错误分析：出现此错误的原因是LoadRunner8.0在录制Web Services协议的脚本时存在一个缺陷：如果服务器的操作系统是中文的，VuGen会自动将WSDL文件的头改为<?xml version="1.0"encoding="zh_cn" ?>，所以才会有此错误提示。

解决办法：下载两个补丁，分别为“LR80WebServicesFPI_setup.exe”和“lrunner_web_ services_patch_1.exe”安装上即可。

 

工作快两年了，两年中大部分是跟着项目在跑，眼袋深了，人老了，人也变老了。有点迷茫，有点郁闷。下面是我老大给我们的一点忠告，记下来，自己好慢慢品尝。

无论做哪一行，工作一段时间后，都会感觉迷茫。主要的原因在于，在工作一定时间后，对工作方法和技术已经比较熟悉，工作已经不像当年刚入行时，具有新意和创新性，更多的可能是重复繁琐的工作，如果看到同学朋友，有了更好的发展，往往就会感到迷茫和郁闷，往往就怀疑自己当初的选择，甚至自我的感觉就像是被困在一个木桶里，动弹不得的，但是桶里面却又有很多飞虫不断地骚扰，心中虽有鸿心壮志，却总是一无所展。所以，此时此刻，人就会感觉郁闷，迷茫，麻木，感觉一身抱负没得舒展，更加郁闷的是，自己有什么抱负，也搞不清楚。人就是这样一种动物，当看到不光明或者看到不路的尽头的时候，往往就失去了动力。
      这种情况，大体上也不是现在才有的，大体上几千年前就有了，不信，你读读那些唐诗宋词，大多也会体味得到这种感觉。这也就是为什么，你读那些诗词的时候，为什么会有同感的原因了。这种情况，也不是只有你遇到，大体上所有人都遇到。这种情况，也不是你现在没有，以后就不会有，这个跟你当时的需求有关，如果你需要的东西，你一直拿不到，你肯定会感觉痛苦和迷茫，而人的欲望是无穷的，不是你想要什么就能得到什么的，所以郁闷的人自然就不少。
      为什么会有这种现象？其实，无论做什么或者学习什么，到了一程度后，就会遇到发展的瓶颈。就如练武功一样，练的境界越高，遇到的困难就越大，这就是为什么，高手总是极少的，越高的手越少。说回来，我们职业发展，如果你工作一段时间，感觉迷茫和郁闷，一方面说明你有上进心，一方面说明，你不知道如何处理遇到的情况，如何调整自己。我觉得，首先，最重要的是不能遇到瓶颈就轻易选择放弃，或者怀疑自己的选择。换一行后，工作两三年后，会遇到同样的问题的，同样会遇到发展的瓶颈，如果跨不过去，永远会觉得自己前面有道坎。不断的换行，不断地从头开始，只要跨不过那道坎，终究是一无是处的。其次，不要跟别人比，一般情况下，都是你看我好我看你好！因为你不知道别人的难处，只看到人家好的。这样越比较，自己就越痛苦。还要是做好自己，踏实地一步一步前进，机会总是留给有准备的人，所谓十年河东，十年河西，平淡中要做出不平淡的事情来，做好积累。我们需要做好坚持和忍耐。
      再说回我们，我感觉，目前我们大体会有以下几个方面，让我们感觉迷茫和痛苦的。
第一、测试人员的缺口很大，按道理应该是有发展潜力的。可能为什么我感觉不到？
第二、做测试两年多了，为什么还在从事简单重复的测试工作？难道我没的进步？
第三、我的优势在哪里？怎么样才能得到晋升或者加薪，怎么样才能得到别人尊重？
第四、有没有更轻松又能赚到更多钱或者有更好地位的工作，我做测试是不是亏了？
第五、同学中或者朋友中，有人已经取得成功，可是我为什么不能像他们那样？
      目前，随着国内企业对软件质量的重视，测试人员的缺口很大。就目前的人员结构来看，是两头小中间大，高层次的测试人才奇缺。目前高层次的测试人员，月薪一万以上，已经不稀奇。所以说，行业的需求是有的，关键是看自己如何提高自己技能。
      前几年，听了一个《成功学》讲座，感觉挺受启发的。一个人想富有，不能光想着钱，只想钱，钱是不会到你口袋的，应该想想，如何能让你成为某方面不可缺少的人，也就是说，要让组织你对有依赖，只有你成为组织中不可替代的人，你的收入自然就会不断地增长，自然你就会得到别人的尊重，因为他 需要你，你能给他们带来利益。当年，我的想法也很简单，在保证完成本职工作的基础上，我想成为性能测试最牛的人。于是我在业余时间，放了大量的精力在上面。通过很多项目的试验和改进，我自认为，这方面，我的水平还是可以的。其实，不断地做项目，对改进和验证我的工作方法和思路起了很大的作用。在每完成一个项目，我便会进行自我的总结，想想怎么样能更好地做好项目。我的做法很简单，每做完一个项目，我便会把OSSP中的过程和一些理论书再看一遍，看完后，你会发现工作中很多的不足，应该是如何做更好。
      还有一点要说的是，尽量自己独立地去负责一个项目。这样便能把自己的想法付之实现，通过不断的实践和改进，就能积累很多做项目的经验和具体的实施办法、还有技术。当然，你需要把你的想法，在实施前跟领导探讨一下。虽然独立负责一个项目，有时候会比较辛苦，但是，往往就是你建立别人对你的信任的时候。如果你做到了，组织对你的依赖度就会越来越高，你就会变得越来越重要，你就能上一个台阶。
     记住：独立地做事，通过实践来验证和改进你的工作，多花时间研究。这些很重要。

     希望各位朋友也能留下你的意见和建议，谢谢！