最近有个性能测试项目，测试对象是用domino 开发的B/S架构的网站系统，网站首页的扩展名是nsf。 第一次录制的时候，采用基于HTML方式录制，录制结束后回放脚本，LR报错，如附图所示。

 

无法生成扩展名为.ci和.cci的文件。

 

遂改成用基于URL的方式录制。再次回放，成功。

 

这是一个非常典型的录制方式选择例子。

当模拟较大数量的并发用户时，单台负载生成器往往是难以满足需要的，容易导致负载机因资源占用过大而成为“假瓶颈” ，这种情况下最好使用多台负载生成器来模拟大量并发用户。如何保证controller与负载生成器连接成功呢？

这并非难事，但仍然有朋友出现这或那的连接障碍。具体问题可以具体分析。这里我提的是必备的前提。

首先，保证controller机与负载生成机之间能ping通，即网络连接畅通。两者之间安装的防火墙不会阻隔54345端口的通信。

其次，在负载生成器上必须运行agent process。运行的方法是：点击loadrunner->advanced settings->agent configuration ， 成功运行后会在右下角生成一个agent process图标

完成以上步骤，就可以尝试在controller里连接指定IP的负载生成器了。

 

成都四方公司测试同行写的博客，里面有一篇非常有深度的文章，关于测试管理方面http://blog.csdn.net/nilxin/archive/2009/11/06/4777446.aspx

读后颇多感想，也想谈谈。

这两个概念，是用loadrunner做性能测试时需要考虑的时间指标，含义分别是：

thinktime：用户思考时间，模拟真实用户在操作过程中的等待时间。

pacing：两次迭代之间的间隔时间。

近日在某测试论坛看到有人探讨这两个时间指标的设置，自己也颇有感想，摘录如下：

thinktime 和pacing值的含义并不难理解，设置这两个值的目的，是为了让测试场景更逼真地模拟用户真实操作，难的是 如何确定它们的值。个人觉得，需要请教有丰富的用户行为研究经验的人才可以。但在实际情况中，需求人员的精力大多在调研功能需求方面，对这样的问题，他们很多时候是不会去了解和考虑的。不过曾经听说象微软，google这样的大公司，是专门设有用户体验研究部门，专门研究用户行为，这样的机构会有大量有说服力的数据。

有的项目实例分析，用的是假设的字眼，比如假设用户浏览网页用1秒，从而设置thinktime=1。但我认为，不应该把thinktime和pacing的值定为一个固定值，这样没有代表性，有的用户看得慢些，有的用户看得快些，有的用户急性子，有的用户慢性子，成千上万的用户都有着千差万别的操作习惯。我的实际做法是，把thinktime和pacing值均设置为一个范围，在脚本执行一次的过程中，用户停顿的时间在一个范围内，比如1-10秒（最小值针对动作快反应快的人，最大值针对动作最反应慢的人）。

而pacing值，如何设置，就不是一两句可以说清楚了。这个值直接影响对服务器施加压力的大小，pacing值越长，相对来说压力就越小，它相当于一个虚拟用户执行完某项业务操作后休息停顿的时间，期间该虚拟用户对服务器不构成压力。在一些网站项目实例中，可能要求被测系统能够支撑每分钟几千个用户请求，那就先计算每分钟虚拟用户能完成多少次迭代，发送多少次请求，从而衡量出所需的虚拟用户数。

Runtime—setting中设置的迭代次数，只在 Run until complete 运行模式下起作用。如果是real-life schedule模式，是由Loadrunner根据你设置的duration时间，结合每次迭代部分的耗时，来决定迭代次数。

正版loadrunner高昂的价格，相信是很多企业望而却步的，大多数的测试人员依然是靠破解版loadrunner来练手。

以本人使用的破解版loadrunner9.0为例，就发生过一件有点意思的事情：
破解步骤此处不详细说了，就说做到最后一步时，要输入licence。破解说明书里提供了两个licence，一个是globe-100的，一个是web-10000的，我输入licence的时候，一古脑儿输入了这两个，loadrunner都提示成功，然后我就心花怒放的等着用。结果却发现，LR的controller不支持多协议录制脚本的回放。百思不得其解啊，明明都有licence了，怎么会不支持呢？

直到后来某一天，我在另外一台机再次安装LR并进行破解的时候才发现，先后输入的两个licence，实际上lr只能保存其中的一个！比如先输入globe-100后输入web-10000，那lr就只保存web-10000的licence，若先输入web-10000后输入globe-100，那就只保存globe-100的licence，两个licence是无法并存的。此前出现不支持多协议脚本回放的原因，昭然若揭——正因为后输入的web-10000 licence覆盖了先输入的globe-100 licence，所以lr不能回放包括web协议以外协议的脚本

本人在测试项目实践中经过总结，制定了一份供测试人员提交BUG时给BUG的严重程度定级的参考标准。

这里首先强调缺陷的严重程度与优先级的区别。严重程度是测试人员提交BUG时给BUG定性，以便给开发组一个参考。而优先级则是项目经理根据项目进度和缺陷的严重程度来决定缺陷处理的先与后。

我曾经在测试论坛看到过一份传播较广的缺陷严重程度定级标准，感觉不太规范，因为其中的描述太过于具体，不够抽象。比如文中这样描述：出现XXXX情形时，将严重程度定为“致命”。XXXX描述的是一些很具体的情形，不具有概括性和抽象性。所以我在定制这份《软件缺陷严重程度定级标准》时，尽量使描述具有抽象性。

有的软件公司，将软件缺陷的严重程度定了4个级别：致命、严重、一般、较小。我觉得没有必要。因为致命和严重之间的差距不会太大，且无论是致命还是严重的缺陷，肯定都得让开发组修复，这些缺陷往往影响用户使用系统。在这两者间再做细分，感觉没必要。所以，我只将缺陷的严重程度划分为三级：严重 、中等、轻微。

1、  严重(urgent)：

 

①    用户需求未实现（影响到用户完成业务）；

 

②    用户需求实现错误（影响到用户完成业务）；

 

③    导致被测软件响应明显很慢（假死）、死机、非法退出、崩溃；

 

④    用户使用频繁的功能，响应时间超出忍耐限度（不影响其他功能模块）；

 

⑤    导致后台数据受损或丢失

 

2、  中等(medium) ：

 

①    用户需求未实现（不影响用户完成业务、用户使用不频繁) ；

注：用户执行删除操作时系统应弹出确认提示将固定视为用户需求，无删除确认提示的缺陷归属本类

 

②    用户需求实现错误 （不影响用户完成业务、用户使用不频繁) ；

 

③    用户操作过程中系统出现异常报错，但不影响系统功能的使用。

 

④    用户使用不频繁的功能，响应时间超出忍耐限度；

注：忍耐限度根据实际软件系统的特点而定

 

⑤    UI上存在错误引导用户的信息。

 

⑥    UI上信息缺失、无法显示完整或出现乱码从而给用户造成疑惑的。

 

⑦    用户频繁使用的功能易用性差（操作起来麻烦、复杂、效率低）

 

 

3、  轻微(low)：

 

①    UI控件不符合界面规范。 

 

②    影响UI友好性。

 

③    用户不频繁使用的功能易用性差

这套标准启用后，我所在的测试团队成员反映不错 ，基本上能覆盖测试项目中可能遇到的各种性质缺陷。但本人发现还有一种情况：开发人员实现了需求说明书里未规定实现的功能，即多余的功能，这也属于软件BUG 。但如何对其严重程度进行定性，无法一概而论。倘若这个多余的功能，给系统带来不好的影响，比如使得系统死机、响应很慢，崩溃等导致用户无法继续操作的现象，那严重程度就归属为严重；倘若对系统毫无影响，但无法正常使用、提示出错，那严重程度可以归属为中等；倘若对系统无影响，也能正常使用，仅相当于一个摆设，那严重程度可以归属为轻微。

    在一台IP地址自动分配的机子上安装oracle 10g home版。安装完后启动“企业管理控制台”添加数据库。配置信息如下：

（请点击图片看大图）

随后连接该数据库，oracle提示ERROR - ORA-12541: TNS: 无监听程序。

查看\oracle\product\10.2.0\db_1\network\admin\tnsnames.ora 文件，显示oracle值：

ORACLE =

  (DESCRIPTION =

    (ADDRESS = (PROTOCOL = TCP)(HOST =自动分配的IP地址)(PORT = 1521))

    (CONNECT_DATA =

      (SERVER = DEDICATED)

      (SERVICE_NAME = oracle)

    )

  )

 

主机名输入localhost或127.0.0.1都会提示无监听程序。由于自动分配的IP地址会有变动，所以将oralce值中的host改成本机的计算机名，保存修改后的tnsnames.ora。再次新建数据库，出错问题解决。

 

# tnsnames.ora Network Configuration

File: G:\oracle\product\10.2.0\db_1\network\admin\tnsnames.ora

# Generated by Oracle configuration tools.

 

ORACLE =

  (DESCRIPTION =

    (ADDRESS = (PROTOCOL = TCP)(HOST =计算机名称)(PORT = 1521))

    (CONNECT_DATA =

      (SERVER = DEDICATED)

      (SERVICE_NAME = oracle)

    )

  )

 

……

 

 

    一直习惯于在软件公司做内部测试，这个“内部测试”的定义是：测试团队属于软件开发组织的一个分支，一个子团队，服务于软件质量，整个开发组织的目标是为客户提供满意的软件。在这样的组织中，测试组角色与开发组角色是个矛盾体：测试人员对开发人员的工作产品进行检验，随即把检验结果反馈给开发人员，开发人员再次修复程序，又提交给测试人员……，如此反复，双方就象个足球队的甲队和乙队。测试团队既独立但又受制于开发团队。 独立，是因为它有自己的一套流程和方法，可以根据测试成熟度来选择介入的阶段，实施质量保证活动；受制，是因为测试活动会受到开发活动的极大影响 ，比如软件系统需求分析活动，如果做得不好，那就会直接影响测试需求的确定和测试用例的设计；开发人员修复软件缺陷的质量，也会影响测试的进度；测试活动的规范度也受项目整体进度影响，项目进度吃紧的时候，测试可能无法做到规范和充分。

         记得4年前，我刚入这个行业的时候，就听说过技术层面更高，更具权威性的测试机构——独立的软件评测中心，曾几何时，自己将这种地方当成自己追求的职业理想。但随着岁月的推移，这个梦逐渐模糊起来，进步的脚步慢了，不满足于现状但却安于现状，是个矛盾。自己也无数次暗地想过，就在软件部做测试到老吗？会有更大的发展空间吗？老的时候还跳得动槽吗？还能有机会拿更高的薪水吗？谁对未来都没有未卜先知的能力。

         讶异于命运的逆转，区区一个月的时间，我的境遇就发生了很大的变化，之前的烦忧全然不存在，新的挑战降临我，这已经是我职业生涯中第N次变动了，有时候真不明白自己为什么总是被选中的那个人，最终只能用天将降大任于斯人也，必先苦其心志来，劳其筋骨……来安慰自己。但是纠结在所难免。如今，冷静思忖，竟然发现，上天给了个机会让我去实现曾经的梦想，但通向理想地的路途上，必然是挑战与艰辛重重，就看自己是否有勇气和底气去承载面临的一切。又想起一句至理名言：不要抱怨自己没有好的机遇，其实机会是留给准备好的人。当你准备好的时候，机会总会不期而遇！

        其实，梦想也是一座围城，当你没有机会冲进去的时候，你会发了狂的寻找一个洞，甚至一条缝也不放过；但当机会来临，一扇门向你敞开了，你会突然感到害怕，担心自己没有准备好去迎接梦想。   

       上天总是特别体察到我的内心想法，这次也不例外，连我曾经的梦想都被它记住了，god is young man ！        

近期有一个测试项目是用C#3.5开发的一个报表查询网站，实现方式：Report Viewer控件+ RDLC报表（动态生成图表），数据源是报表服务器上的web service

注：客户端的rdlc报表无法实现打印功能

使用LR录制了一段业务操作：用户使用合法帐号登录网站，登录后会默认显示某报表。由于需要考察这个报表显示时间，所以在此定义了一个login事务。录制到的脚本中有这样一个函数：

web_url("Reserved.ReportViewerWebControl.axd", 
        "URL=http://10.194.159.236/PowerDemandAnalysisSite/Reserved.ReportViewerWebControl.axd?ReportSession=cmif3r55wq1irpnjw4glcsjr&ControlID=a6759610018c4899a8a88bd725aa683f&Culture=2052&UICulture=2052&ReportStack=1&OpType=SessionKeepAlive&TimerMethod=KeepAliveMethodctl00_baseBody_ReportViewerReportsTouchSession0&CacheSeed=Thu%20Jul%2002%2011%3A32%3A43%202009", 
         "Resource=0", 
         "RecContentType=text/html", 
         "Referer=http://10.194.159.236/PowerDemandAnalysisSite/reports/NormalReport.aspx?url=/DMISRS/MainReport", 
         "Snapshot=t5.inf", 
         "Mode=HTML", LAST);

注：ReportViewerWebControl.axd 并非一个页面，它是一个 HTTP Handler（HTTP处理程序）

回放脚本的时候，LR在这个函数处报错，错误码http404。跟开发人员沟通后，初步怀疑原因是这个被reportviewer控件调用的url参数值不能通过ie直接访问，只能通过控件来访问（这个url参数值应该就是结果报表的路径，包含有reportsession、ControlID（控件标识符）、Culture、UICulture、ReportStack等参数），所以致使LR报http404错误代码。但真正的原因是否如此？这样的问题又该如何解决？

有高手前辈指点说让我录制两次脚本，观察控件的参数值是否一致。我连续录制两次后发现果然有两个参数的值不一样：ReportSession 和 ControlID，也就是有必要在此处做手动关联。

解决方案：先去掉recording options里的enable correlation during recording选项，录制脚本后选择vuser-scan action for correlation，LR能自动筛选出需做关联的两个位置，即ReportSession 和ControlID，点击correlation

再次运行脚本，问题解决！：）

 

相关背景知识

http://www.cnblogs.com/1-2-3/archive/2007/09/01/877290.html 《HTTP 处理程序介绍》

http://hi.baidu.com/annleecn/blog/item/ea59b21395fd7dc6c3fd7830.html 《RDLC报表》

http://www.bitscn.com/pdb/dotnet/200904/160906.html 《VS.Net中的水晶报表的应用》

http://tieba.baidu.com/f?kz=336538956  《使用ASP.NET 2.0中的ReportViewer控件》

在软件需求分析阶段，测试人员评审需求文档目的主要有三方面：

1、及时检测出软件需求文档中具有不可测试性的需求点。
不可测试：某功能模块输入可见，输出不可见，无法验证模块功能是否正确；或是该功能模块的输出无参考标准

来衡定。

2、及时发现软件需求文档的不完整性，从而提醒需求分析人员弥补描述。

3、熟悉业务需求，保证与需求人员保持理解一致，及时发现中文档中有歧义、二义性、模糊的描述，从而提醒

需求分析人员以精确的文字来描述需求点。

在这三个评审目的的指导下，测试人员的评审行为包括：

1、找出不可测试的需求点
2、找出用户提出的、但未被完整描述的需求点
3、找出描述有歧义、二义性、模糊的需求点

评审需求文档后填写评审记录，反馈给需求分析人员，双方可在需求评审会上做讨论，随后需求分析人员在评审记录表中填写处理结果。

    今天，看到一个测试同行发表了一篇文字，题目叫《淘宝质量组三轮测试的感想》。作者在文中提倡“当天发现的bug，开发人员尽量在当天解决，而测试人员尽可能的验证完毕”的做法。我也想谈谈自己的看法。

    这种工作模式不一定适合所有的软件开发项目。关键在于：开发组提交修复版本的紧迫程度。有的开发项目的进度非常紧迫，项目经理要求开发人员在测试人员开始测试的当天就提交修复版本，测试人员也在当天验证完所有修复的BUG。但这种情况实属特殊，实际上对项目进度掌控力好的项目经理是不会让这样的状况发生。毕竟这样高效的工作模式可能会让开发人员和测试人员过于焦虑及劳累，开发人员的修复速度远远赶不上测试人员提BUG的速度，在要求尽快修复的压力下，开发人员会很紧张，重现BUG现象到准确定位原因然后修复，这都需要一定的时间，特别是一些棘手的深层次BUG，显然这样的工作强度很高。如果修复花费很长时间，那测试人员也要陪同等待，然后验证修复。长此以往恐怕双方都会吃不消。我就经历过全体组员封闭开发的软件项目，老板为了拉单给客户许下早早交付的承诺，实际上也很难为项目经理，但这样的现象在国内的软件企业比比皆是。我们当时的做法是：开发组按计划在某日下晚班前提交修复版本，测试人员做冒烟测试验证修复版本的可测试性，然后加班做回归测试或在第2日上班时先过滤出状态=fixed的BUG优先做处理，处理完后再进行新的测试。

    但我后来换了一个项目组，情况就完全相反，进度不那么紧迫，大家都是不紧不慢的。一般是测试人员提交BUG后几天才修复，测试人员的回归测试也留足时间。当天测试当天提交修复当天验证的情况仅是偶尔几次。

    说了那么多，就想总结一句：当天测试当天提交修复当天验证的高强度工作模式只适合特定情况的项目，即特别紧迫那种，但不适合推广到所有的开发项目中去。

测试管理工具TestDirector（简称TD）可以在同类型或不同类型的数据库之间完成项目数据移植。移植操作完全可在客户端界面进行,无须对后台数据库进行任何操作。但目前仍有很多同行对TD数据移植多少存在些误解，认为唯一的方案是在后台数据库进行表间复制等繁琐的操作，其实不然。现在我想给大家推荐一种简单易行，而且很安全的方法。这个方法在我1年前尝试搭建测试管理平台时屡试不爽……

因附图，详情请看附件文档。

09年伊始，公司领导要求规范本公司现行的软件测试过程，并要求制定考核项。我作为任务完成者，整理出一套软件测试过程实施细则。本公司的软件产品开发现状：采用迭代式开发模式，针对每一次迭代开发的功能模块/子系统，软件测试模型参考V模型，成熟度接近TMM 4级。整理软件测试过程实施细则的意义在于指导今后的软件测试活动。

注：过程包括流程及相关的过程文档

《软件功能测试篇》

     1.    测试计划阶段

测试项目立项后指定一个测试负责人制订功能测试计划, 测试计划的文档命名和内容严格按照《项目功能测试计划模板》规范来制订。测试负责人在预计的工作日内完成计划编写并提交给项目测试计划评审成员评审（成员包括测试负责人、项目经理、项目开发人员），并收集所有评审成员的意见。在预计的工作日内完成项目测试计划的修订，定稿后分别发予项目经理和项目开发人员。

 2.    功能需求评审阶段

需求组提交软件需求说明书后，项目测试负责人参加《软件需求说明书》评审会，评审前在预计的工作日内填写完《功能需求评审记录》并发给需求分析人员（需求分析组应在评审会召开前3天提前通知质量组）。监督需求分析人员提交定稿后的需求说明书。

 3.    测试设计阶段

项目测试人员根据定稿后的软件需求说明书设计功能测试用例。指定的同行测试人员在预计的工作日内完成功能测试用例评审，项目测试人员在预计的工作日内根据内审意见完成修订，并提交需求组评审。项目测试人员收集需求组评审意见在预计的工作日内完成修订，形成功能测试用例正式稿。

 4.    测试准备阶段

开发组在预计的工作日提交可测试的软件系统和测试记录表，项目测试人员在进行功能测试之前对软件做冒烟测试，检查软件的主要功能是否正常。如果软件不通过冒烟测试，则没有进一步测试的必要，须要求开发组重新提交可测试的软件系统。同时检查开发人员是否正确填写测试记录表-《报告页》标签中的“开发填写内容”。

项目测试负责人在缺陷管理系统为新的测试项目做好相关配置工作，并对项目组相关人员进行缺陷管理工具使用培训。

5.    首次执行测试阶段

项目测试人员在预计的工作日内完成首次测试用例执行，提交功能缺陷报告至缺陷管理系统，同时填写测试记录表-《报告页》标签中的“测试填写内容”和《任务明细》标签中的“执行结果” ，并提交给项目测试负责人做测试总结。测试总结完提交给项目经理审阅功能测试执行结果，项目经理在预计的工作日内参照《缺陷管理工具使用指南》对缺陷报告进行预处理。（见《开发组处理缺陷流程》章节）

6.    回归测试阶段   

开发人员在预计的工作日内提交软件修复版本和测试记录表，项目测试人员在预计的工作日内根据测试记录表中提交的功能缺陷修复记录来验证软件缺陷的修复情况（原则上需遍历所有测试功能点），并填写测试记录表-《报告页》标签中的“测试填写内容”和《任务明细》标签中的“执行结果”，同时检查指定的缺陷解决人是否正确处理缺陷状态（参照《缺陷管理工具使用指南》-“开发组处理缺陷流程”章节）。项目测试负责人检查测试人员在预计的工作日是否及时做回归测试，是否正确处理缺陷状态（参照《缺陷管理工具使用指南》-“质量组处理缺陷流程”章节）。

7.    发布测试阶段

项目经理决定要修复的所有功能缺陷被修复后方可提交给测试人员做发布测试。要求开发组搭建发布测试环境与用户现行的使用环境必须一致，并提交发布测试记录表。测试人员在预计的工作日内完成发布测试并提交测试记录表。项目经理根据发布测试结果决定是否将软件发布到用户方。若不能发布，则在本次发布测试版本的回归测试通过后再次组织发布测试。

8.    测试总结阶段

软件通过发布测试后，由项目测试负责人撰写功能测试报告，测试报告文档名称及内容符合《测试报告模板》规范。项目测试负责人在预计的工作日内完成撰写后发予项目经理。

9.    软件维护阶段

软件发布给用户使用后，项目组收集用户反馈的修改意见，安排专人将那些开发组接受的修改意见录入缺陷管理系统以便统一管理。同时通知项目测试负责人安排测试人员做回归测试和发布测试。测试人员在预计的工作日内完成软件的回归测试和发布测试，相关的工作规范参照第6、7点。

《软件性能测试篇》

     1.    测试计划阶段

测试项目立项后指定一个测试负责人制订性能测试计划, 测试计划的文档命名和内容严格按照《项目性能测试计划模板》规范来制订。测试负责人在预计的工作日内完成计划编写并提交给项目测试计划评审成员评审（成员包括测试负责人、项目经理、项目开发人员），并收集所有评审成员的意见。在预计的工作日内完成项目测试计划的修订，定稿后分别发予项目经理和项目开发人员。

 2.   性能需求评审阶段（与功能需求评审为同一时间）

需求组提交软件需求说明书后，项目测试负责人参加《软件需求说明书》评审会，评审前在预计的工作日内填写完《性能需求评审记录》并发给需求分析人员（需求分析组应在评审会召开前3天提前通知质量组）。监督需求分析人员提交定稿后的需求说明书。

 3.    测试设计阶段

项目测试人员根据定稿后的软件需求说明书设计性能测试用例。指定的同行测试人员在预计的工作日内完成性能测试用例评审，项目测试人员在预计的工作日内根据内审意见完成修订，并提交给评审组（项目需求分析人员，项目开发人员）。项目测试人员收集评审组意见在预计的工作日内完成修订，形成性能测试用例正式稿。

 4.    测试准备阶段

本阶段完成性能测试工具的安装、配置工作，并根据性能测试用例设计的测试数据准备好测试数据。

 5.    首次执行测试阶段

测试负责人根据软件的功能性缺陷的修复情况安排首次测试执行时间。原则是软件功能确保实现正确后方可进行性能测试，否则不予开展。测试人员在预计的工作日内完成首次测试用例执行，并提交性能缺陷报告至缺陷管理系统，同时填写测试记录表-《报告页》标签中的“测试填写内容”和《任务明细》标签中的“执行结果” ，并提交给项目测试负责人做测试总结。测试总结完提交给项目经理审阅性能测试执行结果，项目经理在预计的工作日内参照《缺陷管理工具使用指南》对缺陷报告进行预处理。（见《开发组处理缺陷流程》章节）

 6.    回归测试阶段   

开发人员在预计的工作日内提交性能调优后的软件版本和测试记录表，项目测试人员在预计的工作日内根据测试记录表中提交的性能缺陷修复记录来验证软件性能缺陷的修复情况，并填写测试记录表-《报告页》标签中的“测试填写内容”和《任务明细》标签中的“执行结果”，同时检查指定的缺陷解决人是否正确处理缺陷状态（参照《缺陷管理工具使用指南》-“开发组处理缺陷流程”章节）。项目测试负责人检查测试人员在预计的工作日是否及时做回归测试，是否正确处理缺陷状态（参照《缺陷管理工具使用指南》-“质量组处理缺陷流程”章节）。

注：性能测试过程中可省去发布测试。软件发布到用户现场之前须验证所有功能点是否正常，因为在软件修复的过程中可能存在一种现象：就是修复旧的缺陷可能引入新的缺陷。而软件系统若通过性能回归测试（测试环境和测试数据务必接近用户环境），可省去性能发布测试。

 7.    测试总结阶段

软件通过发布测试后，由项目测试负责人撰写性能测试报告，测试报告文档名称及内容符合《测试报告模板》规范。项目测试负责人在预计的工作日内完成撰写后发予项目经理。

 8.    软件维护阶段

软件发布给用户使用后，项目组收集用户反馈的修改意见，安排专人将那些开发组接受的修改意见录入缺陷管理系统以便统一管理。同时通知项目测试负责人安排测试人员做回归测试。测试人员在预计的工作日内完成软件的回归测试，相关的工作规范参照第6点。

 

本文讲述的是用controller设计测试场景，运行模式选择“模拟用户真实场景”，这时如何设置最大quality并发操作的时长duration。

   用LoadRunner做负载测试时，controller默认设置duration=5分钟，这个duration值指的是 最大quality并发运行测试脚本的时长。在实际的项目测试中，我碰到这样的情况：一个asp.net+sql server2005开发的OA系统某查询模块，大约可能发生并发操作的人数在100左右。100人并发运行测试脚本5分钟，5分钟之内OA系统没任何异常，超出5分钟后，OA系统响应部分虚拟用户的页面请求的时间变得很长（以至超时），偶尔OA系统还会报“服务不可用”的错误（http 状态码=503）。这样的效果还是开发人员优化代码调优性能后的最好结果。特别在负责调研用户需求的分析人员也不十分清楚这个模块的并发操作时间会持续多久的情况下，作为测试方该如何判断测试通过？测试人员在设计测试场景的时候，如何设定duration？

若系统能顶过最大quality并发运行duration值指定的时长，就算通过性能测试。

  

   Loadrunner里的思考时间，即用户两种操作之间可能存在的间隔时间，它是决定对服务器施压大小的因素之一。举个例子来说，实际用户在浏览网页时，不可能像机器一样不停的点鼠标向服务器发出各种请求，总会在操作和操作之间有一定的间隔。发出某查询请求后，会查看查询结果（这个时候对服务器未产生任何压力），然后看完了第一页，就会发出看下一页的请求。那这个用户看查询结果所用的时间就是前后两次请求之间的思考时间。

   Loadrunner在录制脚本的时候，会把用户实际操作中产生的思考时间录下来。至于在脚本回放时，采用哪种思考时间策略则需在Run-time Settings－Think Time窗口中设置。选项包括：

Ignore think time：忽略think time，即使录制的脚本添加有think time，脚本回放的时候也不会执行。

Replay the think time：下有３个子项

·As recorded：按照录制到的执行。

·Multiply recorded think time by：录制到的think time乘一个系数，此处指定一个系数

·Use random percentage of the recorded think time：设置思考时间的上限与下限。录制到的思考时间 X 指定的百分比，

·Limit think time to：为think time设置一个上限，不管上面的如何设置，执行的时候，取值都不会操过这个上限。 

一般情况而言，测试脚本执行中包含think time能更接近真实的用户场景。考虑到不同的用户可能产生不同的思考时间（反应快的思考时间短，反应慢的思考时间长），所以我常选择指定上限与下限的百分比，思考时间将在这个范围内随机抽取。

也许将思考时间设置大点，会在一定程度上减小对被测机器施加的压力，但我想，还是从现实的角度去考虑多点，因为只有测试场景尽可能地接近真实用户操作场景，测试结果才更有意义。另外有个使用经验就是，如果录制脚本时定义了多个事务，但最好在事务里插入think time，这样能让不同事务的响应时间曲线能明显的区分开，测试人员可以很方便的看到各曲线的变化趋势。否则响应时间相近事务响应时间曲线会发生重合。但最后统计事务响应时间时，务必记得减去这个think time

  

    测试报告是提供给开发组或其他关注性能测试结果的读者的文档，其核心内容是性能测试用例执行结果的分析。性能测试人员通过对监控数据详细而深入的分析，从而对系统的性能表现做出客观的评价。我所定制的模板内容如下

 

 

 

系统性能测试报告模板

 

 

版本历史

日期	版本	说明	修订人
2008-11-17	1.0	新建	XX

 

1．      编写目的

            描述本篇性能测试报告的涉众利益，即为了什么目的而编写

 

2．      参考文档

列出编写性能测试报告所需的所有参考资料，包括文档的标题、文件编号、版本，以及这些文件资料的来源。

序号	名称/版本	修订日期	来源

 

3．      测试资源

3.1    环境资源

序号	用 途	硬件环境	软件环境

 

3.2    人力资源

工作任务	测试人员	工作日
编写测试计划
设计测试用例
执行测试
编写测试报告

 

 

 

  

 

 

 

4．      术语定义

简要说明本次性能测试中所涉及的专业术语的定义

5．      性能测试用例执行分析

5.1                     预期指标性能测试

5.2                     负载测试(单业务)

5.3                     负载测试(组合业务)

5.4                     评估系统性能测试用例

6．      测试结果综合分析及建议

6.1                     硬件方面

6.2                     软件方面

根据本人所在公司可能有的性能测试目的，我定制了性能测试用例模板，包括三个页签：

1、《预期性能指标测试用例》——用户对系统响应时间提出明确的性能需求，性能测试以验证响应时间是否符合需求为目的，一般测试对象为一些查询、统计模块等（测试时有可能是一个用户，也有可能是多用户并发）。

2、《负载测试用例》——以系统调优为目的做性能测试,通过对系统不断施压,找出系统瓶颈作为调优的依据，包括负载测试（单业务）和负载测试（多业务），测试时必然是多用户并发操作。

3、 《评估系统性能测试用例》——用户未提出明确的性能需求,测试的目的仅仅是对系统做性能评估。测试时将利用LoadRunner的性能指标评估功能。

详细模板内容参见附件，同时也附上测试案例分析图

    网上提供的测试过程相关文档模板内容大同小异，如何定制性能测试过程文档的内容？以下模板是本人参考了软件国标GB相关文档和一些测试前辈的经验后所建，不追求天马行空虚无缥缈的内容，只需把该交代的信息传达给文档的读者即可。

    系统性能测试过程文档包括性能测试计划、性能测试用例、性能测试报告。下面按过程中的环节顺序展示文档模板

 

测试的时间	测试对象
单元测试阶段	算法复杂的核心模块
集成测试阶段	组合模块
系统测试阶段	子系统(应用服务器/数据库/中间件)或整个系统
验收测试阶段	整个系统

 

 

 

 

 

 

 

 

 

性能测试类型	含 义
压力测试	对被测系统施加压力，监测系统运行情况
负载测试	找出系统处理极限的临界点（通常有参考对象）
大数据量测试	针对系统的存储、传输、统计查询等业务进行大数据量测试
配置测试	通过改变各项资源参数进行测试，为系统调优提供依据。如调整oracle的内存参数，操作系统的虚拟内存等等
疲劳测试(强度测试)	让系统在特定压力下运行较长的一段时间(通常以天为单位)，检测系统运行是否稳定，是否出现异常。主要用于系统稳定性评估

 

 

 

 

 

 

 

 

6．测试资源

6.1    环境资源

搭建性能测试环境所需要的软、硬件资源

 

6.2    人力资源

描述性能测试团队的人员安排和职责

7．    测试启动与结束准则

7.1  启动准则

描述性能测试执行的进入准则，必须满足哪些预备条件

7.2  结束准则

描述性能测试执行结束的标准

①  有明确的、强制的性能需求：直到系统性能满足预期性能指标

②  无明确、强制的性能需求：所有测试用例执行完毕

8．进度安排

描述性能测试的进度安排，包括各项子任务的日期和内容，包括编写性能测试用例、准备测试环境、工具培训、编写性能测试报告等。

建议：插入project 甘特对象

 

 

严格来说，这并非LoadRunner的使用技巧，但我觉得，一个应用程序性能问题的解决方案也应该被收集，下次对其他系统做性能测试若碰到类似的性能问题，可以为开发人员提供一个可行的解决方案。

被测软件用asp.net开发，在对使用率较高的查询模块模拟并发测试时发现，系统不能承受区区20人并发操作查询（数据库记录数达中等规模业务量），报outofmemory内存溢出的异常，系统崩溃，用户无法继续使用。

为了解决这个性能瓶颈，开发人员先后调整查询sql语句，IIS配置，但一直不能解决。最初怀疑是sql查询语句耗费资源太大（监控到的全表扫描率很高）导致内存溢出，但在调整sql语句使全表扫描率大为降低后仍不能解决问题，随后调整IIS配置也于事无补。因为一直查不到原因，所以软件的性能调整一直拖延。不过最终问题还是被解决。导致系统报内存溢出的异常是查询结果分页，开发人员修改代码后系统的性能表现很平稳及优越。修改前后，前台展现方式的区别是：

 

修改前：从数据库里把所有查询结果读出来再分页

修改后：在数据库里对查询结果先做分页然后再显示到客户端

被测系统的导航目录采用树形控件（即TreeView控件），通过展开和折叠各节点，用户可以方便地访问到各级菜单。录制后回放第一次没问题，但再次回放LR报错：Error -27995: Requested link ("Text=娌规枡璐规湀搴︾粺璁?) not found（Text后的乱码是菜单名）。一旦LR出现了这样的错误，就意味着虚拟用户不能访问某个菜单链接，自然也无法做后续的业务操作从而给系统加压。这个报错之所以棘手是因为它不是每次都出现。录制的脚本首次回放一般不出现该错误，再次回放则必然出现。原因不明，也不知道如何杜绝。这种报错很麻烦，脚本必须重新录制了才能回放，导致脚本不可重用。

搜索百度网也查不到解决方案，问题未能彻底解决。