在做性能测试之后需要知道些什么

　　之前写过一篇《在做性能测试之前应该知道什么》有博文，自我感觉讲的不好，举了两个例子，和做性能测试之前需要知道的一些要点。离我的题目有差距。二则觉得讲的不全。其实，要做性能测试需要知道的东西太多了。岂是一篇博文都能说全的。在这里表示一下愧疚之情。

　　好多测试新手，在做完性能测试之后，不知如何对测试数据进行分析。在这里我想谈谈一些性能测试参数的相关知识。当然，也不是一篇博文就能说清道明的。只希望在你的测试道路上能给你一丝帮助。

　　不怕啰嗦的再次忠告，那想成为测试高手的新人，多学学基础知识。别把过多的时间放在研究新工具的使用上。工具何其多，原理差不多。不要本末倒置了。也算是自我提醒吧!

　　性能测试常见指标

　　性能测试说白了就是通过工具模拟多个用户对被测系统进行访问。然后查看系统对于多个用户发来请求的处理能力。

　　左边的两个小人表示两个用户，向右边服务器发送请求，然后得到服务器的响应信息。

　　首先，我们要保证向服务器发送的请求的正确性，当然用户向服务器发送错误的请求，服务器也会个客户端响应信息，但响应的是报错信息;所以，为了保证测试数据的有效性，我们的要保证发送请求的正确性。

　　为什么一般的性能测试要在局域进行?

　　一般我们的性能测试都是在局域网中进行的。为什么一定要在局域网中进行呢?因为局域网中不受网络限制。这个说法不能绝对。但是一般测试工具的用户并发量是不会受到局域网带宽的限制，除非你做的是十万，百万级别的用户并发。相信懂一点网络知识的人都知道，当你上网很慢的时候，比如打开某某网站很慢，你肯定会骂电信的网络不给力，而不会骂这个网站响应速度不给力。因为，请求信息的耗时大部耗在传输过程中。

　　所以，刚做测试时，我们群里热议论，如果我们每个人都开一个压力工具对百度网站进行加压。百度，服务器会不会挂掉。有测友说这样是不道德人。呵呵!其实，完全不必有这个担心。就一般人家用的带宽，我确保，你向百度服务器发送的请求大部分都死在半路上，就算不死到了百度服务器已经不能叫并发了。何况百度服务器的集群技术以及其他各种分压技术。所以，做性能测试不了解被测系统的架构，以及各种技术的性能。很难做出有效的测试报告。

　　下面我们看看性能测试的一些技术指标。

　　Work Load = Virtual Users

　　工作负荷 = 虚拟用户数

　　对服务器产生多大压力，可以由多少用户同时对服务器发送请求来衡量。也就是服务器的性能可以看它同时处理多少用户发送来的请求来衡量。

　　虚拟用户数可以用进程或线程的方式进行模拟。

　　response time 响应时间

　　从客户端将数据包发出，到接收到服务器端发来的请求。这个过程的总体时间叫response time

　　这个时间用来衡量的处理请求的速度(抛出网速限制的前提下)

　　throughput ~Ti & To

　　这个表示，吞吐量，吞吐量越大表示系统性能越强。1个用户跑100天和10个用户跑1分钟。当然是1个用户跑100天的吞吐量大。所以，我们要想看系统的性能应该用“吞吐率”，就是单位时间的吞吐量，比如吞吐量/秒。

　　站在服务器端，T-in表示“吞”;T-out表求“吐”

　　Ti：T-in 主要衡量客户端的能力，看客户端往服务器发送的请求数据包的吞吐率。

　　To： T-out 主要衡量的服务器端的能力，看服务器处理返回请求数据包的吞吐率。

　　Hits/Request

　　网页点击数/请求

　　Response/Successful Response

　　响应/成功的响应

　　Request与Response是对应，一个请求对应一个响应。但当客户端对服务器的压力达到一直程度后，不是每一请求都能得到响应的。去年末火了个最牛B的“电子商务”网站。12306(铁路网上订票系统)，虽然有很差的用户体验，但每天还是大把的人拼命的登录(过年回家的人伤不起)，甚至用外挂登录。见有网友云云点击(请求)了几十几百次才订票(响应)成功。所以，成功响应率也是很重要的一个指标。客户端发送一千个请求的成功得到响应的几率。

原文转自：http://www.uml.org.cn/Test/201309092.asp