一个51上的朋友原创的，性能测试启动阶段其实是性能测试中最中最重要的部分。不过很多人都忽略了这点，认为性能测试就是利用工具进行脚本编写，场景和用例设计，结果分析等。其实不然，第一步如果连基本的需求和被测对象的分析都没有做好，后续的步骤注定不会是一帆风顺的。
这一张性能测试启动阶段的分析脑图则将启动阶段需要做的工作，牵涉到关键人物和需要关注的内容，需要完成的事情都列的一目了然。可谓极品中的极品。如果这些前期工作做到位了，后面的性能测试肯定也就八九不离十了。
【更新】图片太小，提供原版大小的图片下载，然后放大就可以了。
Download
性能测试工具LoadRunner一直是51testing论坛上关注度最高的话题，也是问题最多的版块，每天都有几十上百的帖子问着关于同样的入门的话题，一直没有时间系统的总结一下，发现Pent老弟关于这个问题的思考和总结，写的相当的不错，转载一下，原文链接
随着软件测试行业的逐渐发展，性能测试也变得火热起来。从各大测试论坛和测试交流群的交流主题的热门程度来看，性能测试已经成为大家非常感兴趣的话题。性能测试作为软件测试行业技术性相对较高的工作（自动化测试、白盒测试、性能测试）来说，个人觉得其操作门槛还是不低的。对于测试新手来说入门有一定的难度，做的好就更加不容易了，可能花了不少时间而实际收获不大。因此觉得有必要来专门探讨一下性能测试的门槛，以及如何更好的迈进这个门槛。
先来分析一下一些关于性能测试入门级的常见问题：
1、请问怎么做象PhotoShop这类单机程序的性能测试；
2、用Delphi开发的程序，应该用什么协议来录制脚本；
在利用LoadRunner进行性能测试的时候，经常不知道某个HTTP代码的涵义，现在转载一篇文章，详细介绍了每种类型的HTTP返回码解释，仅供参考。
HTTP服务器状态代码定义（Status Code Definitions）
1.1 消息1xx（Informational 1xx）
该类状态代码用于表示临时回应。临时回应由状态行（Status-Line）及可选标题组成， 由空行终止。HTTP/1.0中没有定义任何1xx的状态代码，所以它们不是对HTTP/1.0请求的 合法回应。实际上，它们主要用于实验用途，这已经超出本文档的范围。
1.2 成功2xx（Successful 2xx）
表示客户端请求被成功接收、理解、接受。
200 OK
请求成功。回应的信息依赖于请求所使用的方法，如下：
GET 要请求的资源已经放在回应的实体中了。
HEAD 没有实体主体，回应中只包括标题信息。
POST 实体（描述或包含操作的结果）。
(more…)
在利用LoadRunner进行性能测试的时候，Windows服务器的资源是经常需要监控的对象。其实除了LoadRunner提供的计数器，似乎Window服务器并不像Unix或者Linux提供众多的性能监控方法，比如Top或者vmstat等。另外有很多第三方的工具可以选用以增强Windows服务器的监控途径，下面是一些工具的列表。
【监视类】
CPUMon v2.0
CPU性能监视工具。可以获取CPU计数器信息。该版本集成了Perfmon。
http://www.sysinternals.com/ntw2k/freeware/cpumon.shtmlDebugView v4.31
截取Win32设备驱动程序发出的消 息，允许通过本机或网络查看和录制调试信息而不打开一个活动的调试器。
http://www.sysinternals.com/ntw2k/freeware/debugview.shtml
响应时间（response time）
响应时间，是指系统对用户操作的反馈时间。我们可以举一个163邮箱登录的例子：
我们如何来测试邮箱的登录响应时间呢？我们首先进入mail.163.com网页，输入合法的用户名和密码，点击“登录”，直到登录后的邮箱界面完全显示出来为止。那么响应时间从什么时候开始计算呢？是我们输入用户名的时候，还是点击“登录”的时候？
显然，我们应该从按下“登录”按钮的那一瞬间开始计时，到登录后页面完全显示出来为止，这才是真正的用户登录时间，而不包括用户输入用户名和密码的时间以及思考停顿的时间（think time）
登录响应时间其实包括3个部分：网络传输时间，服务器处理时间，浏览器显示时间
即登录响应时间=网络传输时间*2+服务器处理时间+客户端显示时间
网络传输是双向的，所以要乘以2。网络传输时间又可以包括接入网的传输时间和互联网中的传输时间，它的大小和你所使用的上网方式有关，比如光纤一般要比adsl要快。
服务器包括web服务器和数据库服务器，服务器处理时间是我们测试的重点，也是我们能够控制的部分，因为最终用户用什么机器上网，什么接入方式上网我们是控制不了的。我们要重点测试服务器的处理速度如何，以及能否承受较大的压力，我们可以用工具（比如LoadRunner）来模拟大量用户同时登录访问服务器，来查看服务器的承载能力。
客户端显示时间，如何将服务器传过来的页面尽快地显示到浏览器上，是开发人员需要考虑的问题，这里面涉及到算法优化的问题，这也是开发人员容易忽略的地方。
由此可见，响应时间是可以分解成若干个时间段的，任何一个环节出问题都会影响到最终的响应时间，这就需要我们在实际工作中结合具体情况加以分析。
(more…)
经常在论坛或者MSN上问及测试报告应该怎么写,其实不同的公司或者不同的测试类型,测试报告的模板也不尽相同,性能测试作为测试中最重要的部分,测试报告的要求也比较高, 这是一份Mercury官方版的性能测试模板,希望对从事性能测试并且苦于没有测试报告模板的朋友提供一点帮助.
今天着重介绍几种事务响应时间图
事务响应时间(负载下)图
事务响应时间负载下图是正在运行的虚拟用户图和平均响应时间图的组合,他显示事务时间,该事务时间与场景或者会话步骤中任一给定时刻所运行的虚拟用户数目相关.此图可以帮助查看虚拟用户负载对性能时间的总体影响,对分析具有渐变负载的场景和会话步骤更为有用.
X轴表示正在运行的虚拟用户的数目,Y轴表示平均事务时间(单位是秒)
事务响应时间(百分比)图
今天介绍LoadRunner图表分析中最重要的事务图(Transaction Graph),运行场景或者会话步骤之后,可以使用一个或者多个事务图分析测试过程中执行的事务.事务图主要包括:
下面逐个进行介绍:
平均事务响应时间图
平均事务响应时间图显示再场景或者会话步骤运行期间每一秒内执行事务所用的平均时间. X轴表示从场景或者会话步骤开始运行以来已用的时间.Y轴表示执行每个事务所用的平均时间(单位秒).
对于每个粒度,此图以不同的方式显示.粒度越小,结果就越详细.但是要研究虚拟用户再整个场景或者会话步骤的总体行为,使用较高粒度查看结果将会更加有用. 例如,使用低粒度可以看到不执行事务的时间间隔.然后,如果使用较高粒度查看同一个图,将看到事务总体响应时间图.关于粒度的设置,这里不再详细介绍. (默认情况下,只显示已经通过的事务)
你可以再平均事务响应时间图中查看事务细分,方法是选择视图>显示事务细分图,或者右键单机事务,然后选择显示事务细分图.再事务细分树中,右键单机要细分的事务,然后选择细分<事务名>.平均事务响应时间图可以显示子事务的数据.
要查看事务或者子事务中包含的网页的细分,邮件单击此事务或者子事务,然后选择<事务名>的网页细分.
你也可以将平均事务响应时间图与正在运行的虚拟用户图进行比较,了解正在运行的虚拟用户的数目对事务性能时间产生的影响.
例如,如果平均事务响应时间图显示性能逐渐改善,则可以将其与正在运行的虚拟用户图进行对比,看性能时间是否因为虚拟用户的负载减少而得到改善.
如果定义了可以接受得最小和最大事务性能时间,则可以使用此图确定服务器性能是否再可以接受得范围,很多朋友再没有定义事务性能期望得情况下,进行测试,结果将是很难判断得,测试之前一定要一定得期望.
每秒事务总数图
每秒事务总数图显示场景或者会话步骤运行的每一秒中,通过的事务总数,失败的事务总数以及停止的事务总数.
X轴表示场景或者会话步骤开始运行以来已用的时间(单位秒).Y轴表示场景或者会话步骤运行过程中执行的事务总数.一般绿色表示成功执行的事务,红色表示失败的事务.
通过每秒事务总数,能够对于应用的的整体性能进行一定的比较和说明.但是该图每秒事务总数会受到很多因素的影响,包括步间隔时间,思考时间等.
下面是平均事务响应时间图:
下面是每秒事务总数图:
你正在浏览的汇总是: 性能测试
| M | T | W | T | F | S | S |
|---|---|---|---|---|---|---|
| « Oct | ||||||
| 1 | 2 | |||||
| 3 | 4 | 5 | 6 | 7 | 8 | 9 |
| 10 | 11 | 12 | 13 | 14 | 15 | 16 |
| 17 | 18 | 19 | 20 | 21 | 22 | 23 |
| 24 | 25 | 26 | 27 | 28 | 29 | 30 |
