终于有机会又重新接触性能测试，测试计划-脚本录制-场景设计-结果分析-测试报告，一切看起来是那么的有条不紊，可在具体的实践中，我却感觉像个没头苍蝇一样四处乱撞.......

　　总结一下此次测试的不足之处：

　　1、测试计划中，对真实用户场景模拟不全面。

　　这次测试目的是调优，使上班登记功能满足客户的需求。我在设计场景时，只考虑到使用集合点，通过大并发数来模拟用户。

　　前辈分析：上班登记这一业务为多用户集中在短时间内完成，还应增加场景，使多用户在一定时间内完成此业务，才能更好的模拟真实场景。看来还是想的不够全面。

　　2、场景设计中，对用户并发数，没有进行准确的压力评估。

　　开始时，我总是想着测出系统支持的大并发数好了。一直往上加用户，直到写测试报告，才发现我的测试过程完全没有按照计划来做，后变成了根据测试结果来写测试计划。哎...还是思路不够清晰。尤其是对于大并发数的预计。不过后来从前辈那儿学了一个公式不知道准确不准确，拿来跟大家分享一下：

　　计算平均的并发用户数：C = nL/T

　　并发用户数峰值：C’≈C+3√C

　　公式（1）中，C是平均的并发用户数；n是login session的用户数量；L是login session的平均长度；T指考察的时间段长度。

　　例如：系统大用户在线数为900，系统在现有配置下应支持并发用户数为900×2/10=180；

　　后总结，性能测试是一项完整的工程，一定要有一个详细的计划来指引工作的进行。测试计划必不可少，测试计划越详细越好！

　　朋友建议我把详细的测试过程也放上来，下面再简单描述下，希望大家能多提意见：

　　测试目的：系统上下班登记业务能够满足当前用户的需求。

　　测试策略:根据用户实际业务情况，上班登记业务多集中在上班前后10分钟内，并发操作较多，在测试过程中设置了两种场景。

　　场景一：并发测试，180用户到齐后同时签到。

　　场景二：用户在线测试，300用户在10分钟内完成上班签到。

　　LoadRunner中场景设置：

　　场景一：设置集合点，每10秒上2个用户（上用户速度较慢，保证所有用户都能正常登录系统）所有用户跑完停止。

　　场景二：不设置集合点，每2秒上一个用户，所有用户跑完停止。

　　注：在测试过程中，可以按照50、100.....依次递增上用户。

　　每次结束后，注意分析数据库服务器、应用服务器windows资源情况是否正常，以及应用服务器后台是否报错。