这是一个经常被测试人员忽略的环节，在接到测压任务后，基于种种其它因素的考虑，测试人员往往急于进度，立即投入到具体的测试工作去了，测试、记录、分析，忙的不亦乐乎，工作进行了一半才发现，或是硬件配置不符合要求，或是网络环境不理想，甚至软件版本不对，一时弄得骑虎难下，这都是没有做好测试准备惹的祸。那么我们应该如何做好性能测试的准备工作呢？ 做软件项目有需求调查、需要分析，做测试也一样。在拿到测试任务后，首要的任务就是分析测试任务，在开始测试前，我们至少要弄清以下几个问题： a) 要测试什么或测试的对象是谁？ b) 要测试什么问题或我们想要弄清楚或是论证的问题？ c) 哪些因素会影响测试结果？ d) 需要怎样的测试环境？ e) 应该怎样测试？ 只有在认真调查测试需求和仔细分析测试任务后，才有可能弄清以上一系例的问题，只有对测试任务非常清楚，测试目标极其明确的前提下，才可能制定出切实可行的测试计划。
调研需求 了解客户的标准 例如我们做的是一个公司内部的CRM系统 基本上只有销售和一些上司在用 大概使用人数在120人左右，基本的使用时间在上班时间，并且集中在早上十点左右，通过调研50人集中在10点--11点间访问crm系统了解客户信息，并且每个人期间向服务器发送请求数不超过50 这样我们就可以估算出一些有用的信息 比如登陆并发用户数 假设他们都在10点2分前登陆了 系统 ， 那么120秒内120人 每秒1个人 哇哇 这还不够并发，我们再来狠点 让120个 30秒登陆 那么并发数就4人/秒，具体是并发数多少这就要设计到具体的业务场景了和客户需求了，客户说我要做一个购物网站，你给我分析下，好，假设网站有500万的会员，按照性能测试惯例 并发用户一般占到该功能使用人数的20%左右 500万很多吗 其实不多 有些会员可能只是在浏览网页 并不需要去登陆，我们网购过的人 都有经验 只有在付钱的时候才想起来登陆 假设500万会员中 一天从早上9点到晚上12点 是会员的活跃期，其中有20%r的人 会登陆购物，100万会员 在15个小时内登陆 那么平均下来每秒才18个用户 ，肯定会有人说不对 这只是估计 况且 大部分都是下午买东西，这就要去调研 我们只能把并发数控制在一个范围内 并且要给适当的场景，去模拟才能达到真正的效果，例如100万中 有50万人都会在下午2点--4点去购物，这时候我们的并发数4166个/秒 。 哇 怎么这么多 服务器会不会崩溃啊 别担心 大型门户网站和购物网站的架构都才要集群设计，里面有几十台甚至上百台服务器去负载这些压力 假设我们有20台Web服务器 去均分这4166个请求 下来每天服务器才208并发 对于高性能服务器 这点并发请求数 还不够撒牙缝。
所以我做性能测试前一定要了解被测系统的情况和客户的需求，定下一个大概范围去做。
一个实际的例子
为了便于大家的理解，我们先来看一个性能需求的例子，让大家有一个感性的认识，本文后面的讨论也会再次提到这个例子。
这是一个证券行业系统中某个业务的“实际需求”——实际上是我根据通过网络搜集到的数据杜撰出来的，不过看起来像是真实的 ^_^
l 系统总容量达到日委托6000万笔，成交9000万笔
l 系统处理速度每秒7300笔，峰值处理能力达到每秒10000笔
l 实际股东帐号数3000万
这个例子中已经包括几个明确的需求：
l 最佳并发用户数需求：每秒7300笔
l 最大并发用户数需求：峰值处理能力达到每秒10000笔
l 基础数据容量：实际股东帐号数3000万
l 业务数据容量：日委托6000万笔，成交9000万笔——可以根据这个推算出每周、每月、每年系统容量的增长模型
如何获得有效的性能需求
上面提到了“有效的”性能需求的一个例子和三个条件，下面来我们将看到有哪些途径可以帮助我们获得相关的数据——这些方法我在实际的工作中都用过，并且已经被证实是可行的。这几种方法由易到难排列如下：
1. 客户方提出
这是最理想的一种方式，通常电信、金融、保险、证券以及一些其他运营商级系统的客户——特别是国外的客户都会提出比较明确的性能需求。
2. 根据历史数据来分析
根据客户以往的业务情况来分析客户的业务量以及每年、每月、每周、每天的峰值业务量。如果客户有旧的系统，可以根据已有系统的访问日志，数据库记录，业务报表来分析。要特别注意的是，不同行业、不同应用、不同的业务是有各自的特点的。例如，购物网站在平时的负载主要集中在晚上，但是节假日时访问量和交易量会是平时的数倍；而地铁的售票系统面临的高峰除了周末，还有周一到周五的一早一晚上下班时间。
3. 参考历史项目的数据
如果该产品已有其他客户使用，并且规模类似的，可以参考其他客户的需求。例如在线购物网站，或者超市管理系统，各行业的进销存系统。
4. 参考其他同行类似项目的数据
如果本企业没有做过类似的项目，那么可以参考其他同行企业的公布出来的数据——通常在企业公布的新闻或者成功解决方案中会提到，包括系统容量，系统所能承受的负载以及系统响应能力等。
5. 参考其他类似行业应用的数据
如果无法找打其他同行的数据，也可以参考类似的应用的需求。例如做IPTV或者DVB计费系统的测试，可以参考电信计费系统的需求——虽然不能完全照搬数据，但是可以通过其他行业成熟的需求来了解需要测试的项目有哪些，应该考虑到的情况有哪些种。
6. 参考新闻或其他资料中的数据
最后的一招，特别是对于一些当前比较引人关注的行业，涉及到所谓的“政绩”的行业，通常可以通过各种新闻媒体找到一些可供参考的数据，但是需要耐心的寻找。例如我们在IPTV和DVB系统的测试中，可以根据新闻中公布的各省、各市，以及国外各大运营商的用户发展情况和用户使用习惯来估算系统容量和系统各个模块的并发量。
二 要测试什么问题或我们想要弄清楚或是论证的问题？对系统以及需求有了大致了解后 我们接下来我去分析问题，比如客户说了 我希望我提交订单后在10秒内能够得到响应，那么客户的需求就是从页面向系统发送请求再到系统向数据库发送查询请求到数据库返回信息系统把返回数据展现页面总共的时间是10秒内 这样具体分析后我们就可以对这个点做相应的用例去测试了，这里叙述的并不完全请见谅 例如多少个用户在线，或者多少二哥用户并发提交订单，在什么样的环境下 比如带宽 服务器的性能数量等等 都制约着整个系统的性能，这就要我们去具体的设计不同场景。在这里我们只是讨论如何分析客户给的需求。
三
c) 哪些因素会影响测试结果？
就这是我刚才讨论的内容，客户的带宽，服务器的性能和数量 ，服务器的带宽，用户并发数的多少 等等 都会影响到测试结果~
四 需要怎样的测试环境
比如我们只是软件开发公司，我们的客户是财大气粗有很大好设备，但是我们小软件公司，每个人就一台烂笔记本和公司那几台破的不能再破的服务器，我们怎么做性能测试呢，怎么设计测试呢，在有限的条件下我们怎么样才能最出一个合理的评估呢
如果是用IIS做应用服务器的话，单台可承受的最大并发数不可能达到10万级，那就必须要使用集群，通过多台机器做负载均衡来实现；
如果是用websphere之类的应用服务器的话，单台可承受的最大并发数可以达到10万级，但为性能考虑还是必须要使用集群，通过多台机器做负载均衡来实现；那么，你只要集群的服务器足够多，10万并发数当然可以达到了。通常有1个简单的计算方式，1个连接产生1个session，每个session在服务器上有个内存空间大小的设置，在NT上是3M，那么10万并发就需要300G内存，当然实际使用中考虑其他程序也占用内存，所以准备的内存数量要求比这个还要多一些。还有10万个用户同时在线，跟10万个并发数是完全不同的2个概念。这个楼上已经说了。但如何做这个转换将10万个同时在线用户转换成多少个并发数呢？这就必须要有大量的历史日志信息来支撑了。系统日志需要有同时在线用户数量的日志信息，还需要有用户操作次数的日志信息，这2个数据的比例就是你同时在线用户转换到并发数的比例。另外根据经验统计，对于1个JAVA开发的WEB系统（别的我没统计过，给不出数据），一般1台双CPU、2G内存的服务器上可支持的最大并发数不超过500个（这个状态下大部分操作都是超时报错而且服务器很容易宕机，其实没什么实际意义），可正常使用（单步非大数据量操作等待时间不超过20秒）的最大并发数不超过300个。假设你的10万同时在线用户转换的并发数是9000个，那么你最少需要这样的机器18台，建议不少于30台。当然，你要是买个大型服务器，里面装有200个CPU、256G的内存，千兆光纤带宽，就算是10万个并发用户，那速度，也绝对是嗖嗖的。
谢谢 http://www.cnblogs.com/jackei/archive/2006/11/16/561846.html 文章很精彩。
我总结下 假如我们只有1台服务器，假设我们的项目需要5000个并发，但是我们手头没那么牛的机器，没关系
1台双CPU、2G内存的服务器上可支持的最大并发数不超过500个 如果系统能满足1台机器500个并发的请求 那么正式环境下那么多集群的服务器肯定能抗的过去，这是一个数学分析问题 学过概率论的同学一定会明白其中的奥秘，我就不详说了 今天性能测试第一节课 到此为止 欢迎各位批评~~~~