今天收到Jackei兄发来的一封邮件，内容是一位同行向他提出的“关于项目中的能提供的参考统计数据向测试期望转化的”问题，我觉得很有代表性，在这里贴出来，以方便讨论。
您好！目前的项目中遇到些问题，想向您请教：
我目前在某门户项目中管理性能测试部分。目前需要指定测试方案，手头能有的数据如下：
1，每日访问量10万人次（技术建议书中提出）；
2，目前在网系统每天的页面访问量（按各业务统计）；
3，能满足同时在线人数2000人的访问（合同中描述）。
在我与业务部门交流后，制作了三种综合访问量（是访问量而不是访问频度）分布模型以体现系统在三中典型时刻的访问分布需求，分别是：平衡模型（月中），偏重查询模型（月初），偏重业务办理模型（月末）。脚本采用了了能具有代表性的典型业务流程。
现在的问题一直困扰我：
1，由于合同中提出需要支持2000人同时在线，那么我是否应该将并发的用户量设置为200（按在线人数的10%为并发人数计算）？
2，为每个脚本设置的虚拟用户数是否应该等于访问量模型中所定义的比例？
3，除了加压过程的缓增策略外，是否需要考虑突发性的大并发加压策略？
对于问题1，如果按照10%理论的话，是否需要考虑有一部分人只登录进系统但是不进行操作，因为不动作的用户毕竟需要占用资源（服务器内存等），也就是说除10%是时时活动用户，还需要一定的非活动用户当做"背景"。
对于问题2，由于每个操作的完成/响应时间不同，所以必然导致的是，如果按访问量模型为每个操作/脚本定义分派虚拟用户数进行测试，则测试结果中实际的访问量比例必然偏模型中访问量比例。除非设置集合点（我用的是LR），但是，这样同时大同时并发会否使服务器不堪重负而崩掉？
对于问题3，实在没什么好说的了，因为我实在是没这方面经验，想听听您的意见。
谢谢您了！
又附目前我做的方案中的一些信息：虚拟用户数1000；脚本中带不同程度的THINKTIME；每10秒增2个用户；脚本一共9个，静态页面访问1个，登录1个，业务绑定1个，查询4个，投诉1个，业务办理1个。其中跟业务办理相关的是后两个。登录，绑定，查询都是查询类的。
目前测试的结果来看，查询类对系统瓶颈最大（系统资源占用高，事务响应速度慢），采用PORTAL实现（我感觉是设计缺陷），主要是过接口从外围系统中拿信息。业务办理相对性能好的多，是WAS实现的，主要是插数据库操作。