这两天在论坛逛了好久，看了一些网友的评论，我最后还是决定先学习QuickTest

  在这里我要非常的感谢sunqiang1024在论坛上提供的9.2的安装程序和破解补丁，我花了一个小时下载，半个小时安装就可以用了，再次感谢

   既然下定决心装了QTP，就要用心的学习下去，我决定给自己一年的时间，再这一年的时间里，我不会再去学别的类似的测试工具。

   接下来还是先花一个星期的时间熟悉熟悉软件

 

 

 

 

     不知不觉中，做测试已经一年多了，一年了，对测试有了个基本的认识，但这一年里，我基本从事的是手工测试，现在我们公司的产品线很长，而且基本没个月都要发布新的版本，一个月有四分之三的时间是在手工点鼠标做回归测试，实在受不了，我觉得公司是该引进自动化测试的时候了，为了早日摆脱重复的点鼠标还是自己先摸索下吧

     以后每天要花一之两个小时来学习自动化测试（风雨无阻），坚持每天把学习心得或成果写出来（最多可以隔一天).

     为了早日摆脱手工，为了高薪（有点土），加油1

测试是一门武功，流程是套路、工具是武器，有简单的花拳秀腿，也有深奥的少林武功！测试好比战争，知己知彼，方能百战不殆！测试好比破案，精心推断，方能柳暗花明！有人说世界不缺少美，而是缺少发现，我看：其实软件不缺少问题，而是缺少发现！以精深的少林武功、用艺术工程的眼光、战争破案的缜密思维去发现软件世界“美”吧！

 

LoadRunner中的90％响应时间是什么意思？这个值在进行性能分析时有什么作用？本文争取用最简洁的文字来解答这个问题，并引申出“描述性统计”方法在性能测试结果分析中的应用。

 

为什么要有90％用户响应时间？因为在评估一次测试的结果时，仅仅有平均事务响应时间是不够的。为什么这么说？你可以试着想想，是否平均事务响应时间满足了性能需求就表示系统的性能已经满足了绝大多数用户的要求？

假如有两组测试结果，响应时间分别是 {1，3，5，10，16} 和 {5，6，7，8，9}，它们的平均值都是7，你认为哪次测试的结果更理想？

假如有一次测试，总共有100个请求被响应，其中最小响应时间为0.02秒，最大响应时间为110秒，平均事务响应时间为4.7秒，你会不会想到最小和最大响应时间如此大的偏差是否会导致平均值本身并不可信？

为了解答上面的疑问，我们先来看一张表：

在上面这个表中包含了几个不同的列，其含义如下：

CmdID   测试时被请求的页面

NUM      响应成功的请求数量

MEAN    所有成功的请求的响应时间的平均值

STD DEV      标准差（这个值的作用将在下一篇文章中重点介绍）

MIN              响应时间的最小值

50 th(60/70/80/90/95 th)          如果把响应时间从小到大顺序排序，那么50％的请求的响应时间在这个范围之内。后面的60/70/80/90/95 th 也是同样的含义

MAX      响应时间的最大值

我想看完了上面的这个表和各列的解释，不用多说大家也可以明白我的意思了。我把结论性的东西整理一下：

1.      90％用户响应时间在 LoadRunner中是可以设置的，你可以改为80％或95％；

2.      对于这个表，LoadRunner中是没有直接提供的，你可以把LR中的原始数据导出到Excel中，并使用Excel中的PERCENTILE 函数很简单的算出不同百分比用户请求的响应时间分布情况；

3.      从上面的表中来看，对于Home Page来说，平均事务响应时间(MEAN)只同70％用户响应时间相一致。也就是说假如我们确定Home Page的响应时间应该在5秒内，那么从平均事务响应时间来看是满足的，但是实际上有10-20％的用户请求的响应时间是大于这个值的；对于Page 1也是一样，假如我们确定对于Page 1 的请求应该在3秒内得到响应，虽然平均事务响应时间是满足要求的，但是实际上有20-30％的用户请求的响应时间是超过了我们的要求的；

4.      你可以在95 th之后继续添加96/ 97/ 98/ 99/ 99.9/ 99.99 th，并利用Excel的图表功能画一条曲线，来更加清晰表现出系统响应时间的分布情况。这时候你也许会发现，那个最大值的出现几率只不过是千分之一甚至万分之一，而且99％的用户请求的响应时间都是在性能需求所定义的范围之内的；

5.      如果你想使用这种方法来评估系统的性能，一个推荐的做法是尽可能让你的测试场景运行的时间长一些，因为当你获得的测试数据越多，这个响应时间的分布曲线就越接近真实情况；

6.      在确定性能需求时，你可以用平均事务响应时间来衡量系统的性能，也可以用90％或95％用户响应时间来作为度量标准，它们并不冲突。实际上，在定义某些系统的性能需求时，一定范围内的请求失败也是可以被接受的；

7.      上面提到的这些内容其实是与工具无关的，只要你可以得到原始的响应时间记录，无论是使用LoadRunner还是JMeter或者OpenSTA，你都可以用这些方法和思路来评估你的系统的性能。

 

事实上，在性能测试领域中还有更多的东西是目前的商业测试工具或者开源测试工具都没有专门讲述的——换句话说，性能测试仅仅有工具是不够的。我们还需要更多其他领域的知识，例如数学和统计学，来帮助我们更好的分析性能数据，找到隐藏在那些数据之下的真相。

欢迎各位同行高手灌水拍砖 ^_^

 

今天有同行在blog上留言，问“想从功能测试转向性能测试，但不知道需要哪些了解哪些知识，及怎样进行一个系统的学习”。这类问题之前也被问到很多次了，所以这次干脆整理一下，发个主题供同行们参考。如果需要补充，也欢迎大家留言一起讨论。

如果想真的做好性能测试，需要学习的东西还是比较多的。简单列一下吧。

1. 精通性能测试的基本概念，过程，方法论，了解性能工程；
e}YI~a)Z02. 精通1个商业性能测试工具+1个开源性能测试工具，知道工具可以做什么，不可以做什么，以及工具使用中常见的问题和解决思路；51Testing软件测试网c;t/Y+c"U D+N
3. 扎实的计算机专业基础知识，包括计算机组成原理、操作系统、数据库原理、计算机网络原理；
;o7A?u CLJE04. 熟悉至少1个常用的数据库产品，例如SQL Server或者 Oracle，能进行一般的数据库管理操作，熟悉SQL脚本的使用，熟悉常用的数据调优工具和常用的counter；
:_X6mG$P9P05. 熟悉至少一个操作系统的原理，Windows或者Linux都可以，熟悉操作系统的体系架构、操作系统的重要基础概念，以及内存管理、存储/文件系统、驱动/硬件的管理、网络协议的实现及构成、性能的监控方法和原理，熟悉常用的counter；
w/mj)mOd$y06. 熟悉至少一个web server 产品，例如apache，了解一般的配置和常用的counter；51Testing软件测试网$Ex5I)KJ:TPH?
7. 熟悉至少一个应用服务器产品，例如tomcat，了解一般的配置，熟悉常用的服务器性能监控方法和原理，熟悉常用的counter；51Testing软件测试网.I#_xY'A0O
8. 至少熟悉TCP/IP协议，熟悉HTTP协议，至少见过并了解三层、四层交换或者路由器的使用和配置。了解常用的与网络性能相关的counter；51Testing软件测试网q*n0xg:A,dJWFPR
9. 了解一般的大型企业应用的部署架构和应用架构；51Testing软件测试网&UFm R(qz
10. 了解知名大型web应用、高并发量、高流量、实时响应要求高的超大规模网站的架构和优化历程；51Testing软件测试网:BOC}/qI o
11. 熟悉统计学的基础知识、常用分析方法以及实验设计方法，了解数学建模相关的知识；
`B#F;b0z;VK}x012. 熟悉专属行业的业务知识和用户场景，例如电信行业的OSS系统所涉及的业务知识和用户场景，证券交易系统所涉及的业务知识和用户场景；
S$A+{"v)CV4YM:n@!pv013. 大量的实际性能测试及优化经验；51Testing软件测试网
} A8NJ3@s9DEI r
14. 积极的参与到各类圈子、社团的讨论和交流、分享中。

暂时先想到了这么多，有兴趣的朋友可以一起讨论一下，相信每个人都有自己不同的经历和感想，可以跟其他人分享一下，提供参考。
T:Ze4` a { ]#},lI6@1}051Testing软件测试网*\1u5A-V? l
另外，我之前也整理发布过不少性能测试方面的资料，从入门级的文章到 升级的必读都有一些，有兴趣可以参考。

资料收集：高并发 高性能 高扩展性 Web 2.0 站点架构设计及优化策略 51Testing软件测试网R!aB8Ef!v.O
http://www.cnblogs.com/jackei/archive/2007/10/07/915931.html

最全,最强的软件测试资料汇总 (性能测试,性能调优,功能测试,自动化测试,测试管理,测试工具,测试用例设计,缺陷分析预防,前沿测试技术...)
3QzkI(W \J {0http://www.cnblogs.com/jackei/archive/2007/02/06/641647.html

   做功能测试快一年了，是该做些改变的时候了，我要在今天启航，向性能测试启航