今天和同事交流关于性能测试的东西，以前也做过性能测试，突然想写点自己关于如何做性能测试的认识。
基于B/S架构的系统，利用loadrunner做性能测试，利用nmon监控系统资源（用linux自带的top，vmstat等命令也可以，写一些简单的shell脚本就行了）。
那么到底该怎么去做性能测试呢？
1、首先要了解被测系统的结构和有关知识的储备。
了解了被测系统，在后期性能出现异常的时候，定位就相对容易一些；而且知道在测试的过程中需要监控什么。
一个简单B\S系统结构图：
该系统有一下及部分组成：
APP：一台nginx，兼做web和应用服务器
Memcached：负责做数据缓存
lucene：负责做搜索
RabbitMQ：负责某些业务的队列处理
mysql：数据库服务器，一个主库，一个从库
从以上系统结构来看，要搭建和维护性能测试环境，需要的一些必要的知识。
对于APP：需要了解nginx的相关知识，怎么修改配置，在哪里看日志
对于Memcached：怎么搭建Memcached，怎么查看命中率，Memcached的作用是什么
lucene:这个lucene是干什么用的，要怎么配置
RabbitMQ：MQ要如何配置，都那些业务用到了MQ。
Mysql：如何配置主从，为什么要配置主从，主从如何同步等等
在搭建环境的过程中肯定会遇到这样或那样的问题，要自己找资料，或者相关的开发人员一起解决，并注意做笔记，防止以后同样的问题再出现。
2、了解了系统结构，开始搭建测试环境，并准备数据。
测试环境尽量要和生产环境的结构保持一致，还有配置文件等也要保持一致，这样能保证性能测试的结果更加真实和接近生产环境。
数据准备一定要充足，而且数据量要大于等于生产环境，这样能更真实的模拟生产环境。比如对一个select语句而言，10W的数据，和1000W的数据，查询时间肯定有差别。如果数据量太小就不能反映真实情况下性能了。（可以把线上的数据导入到测试环境，但是要注意把用户比较隐私的数据都替换掉）
如果有可能的话，测试环境的数据要比生产环境多出20%，做一些性能上边的冗余，防止发生突然的性能尖峰。
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，要大家共同协作，才能做好性能测试。
限于水平有限，用疏漏之处，多多包涵。
最新内容请见作者的GitHub页：http://qaseven.github.io/
