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，要大家共同协作，才能做好性能测试。
限于水平有限，用疏漏之处，多多包涵。
