3、了解需求，找出测试点
　　和产品、技术沟通需要做性能测试的业务；并了解相应的业务的性能指标，如页面的响应时间，TPS（事物处理）或者系统期望能承受多少并发等。
　　4、设计性能能测试用例
　　根据业务编写相应的性能测试用例。

　　功能
　　在线用户达到高峰时，用户可以正常发帖，保证200个以内用户可以同时发表帖子。
　　目的
　　测试系统200个以内的用户同时在线发帖。
　　方法
　　采用LoadRunner的录制工具录制一个邮件发送过程，然后对脚本进行优化，加上事物点，检查点等。过程中监视B端的响应，还有网络传输，web服务和数据库服务器的性能，并观察服务器相应服务的日志，检查MQ的状态，memcached服务器的状态和性能
　　预期结果
　　符合业务的预期，日志木有异常等（不详细列举）
　　5、编写并优化脚本
　　根据测试用例录制发帖的脚本，加入事物点、检查点、参数化，并回放，确保脚本没有问题，可以正常运行。
　　6、设计性能测试场景
　　设置一个渐进的场景10-30-60-100-150-200，这么做的目的防止一下子上去是200个并发，出了问题，不知道系统佳的并发是多少。
　　（上边的渐进场景不一定合理，只做示意）
　　7、启动监控，并开始跑性能测试场景
　　设置场景完毕后，开始在服务器端启动监控，然后开始启动场景。
　　8、监控场景执行，监控服务器的资源
　　loadrunner可以搜集一些性能测试数据，事物的pass数，fail数，error数，都要做统计。
　　监控服务器的资源，可以利用nmon，也可以是用linux自带的命令top，vmstat等。
　　也要监控服务器的日志输出，看是否有异常出现。例如：查看mysql的慢日志，nginx的日志等。
　　9、搜集结果数据，分析探讨
　　后对性能测试搜集的数据进行分析，找出性能测试的拐点。
　　10、对系统进行优化，并重复7-9步，直至测试结束
　　PS:性能测试不是一个人的事情，中间设计了，开发，产品，运维，QA，DBA，要大家共同协作，才能做好性能测试。
　　限于水平有限，用疏漏之处，多多包涵。