在我刚知道性能测试时 想象能做性能测试的人都是工作了好些年（不再年轻），桌面上摆着两台电脑，每台电脑的屏幕都不断地在翻滚着数据信息，而他们能在闪烁的数据中发现异常数据。后来，我才知道，是我黑客帝国看多啦！
早前看到身边的人做性能测试都是用LoadRunner，让我一度以为没有这个工具就无法做性能测试，会了这个工具就能做性能测试，于是自己去啃这方面的书（家里LoadRunner的书超过4本）。经过血淋淋的教训，我知道，是我想多啦。
再后来自己加入了性能测试培训班，以为上了培训班，我就会做性能测试啦。后来，我知道，没有实践的理论都是空谈。
想做什么，最快途径是到能做的环境中去，环境很重要。
再后来因工作所需，开始接触了百万、千万的数据性能测试（暂时没有亿级别的，期望公司客户快速发展业务，给我个亿用户/数据，让我也能得瑟下），才知道性能测试真实面目，不受工具限制，不受理论限制，不受所谓的指标限制。
那么性能测试一般有多少步骤呢？本人总结了常用的8点（网上能找到更多，我加了些自己的理解。）
1）获取最常用场景
已有面向广大用户的系统，只要使用就能提取到性能测试点。
最直接的方式：自己可以去操作下。如：视频网站，首页（访问量占总访问量的50-70），内容详情页，各子导航等。
已有面向少数客户的系统，最快速的方式看下数据库表量，找出数据量大的表去问项目经理 数据是怎么产生的，也能获取到性能测试点。
如果不能访问数据库，则可以找使用系统的客户聊聊（找聊的人数不少于角色人数），听听他们是如何使用的 也能知道最常用的功能是什么。
如果是未上线的，就更好办啦，找项目经理/产品经理/技术负责人聊聊呗，听听他们对系统的规划、设想和设计。
2）获取最终性能目标
方式一：客户有明确要求。
先恭喜你，遇到一个有预期的客户。但也得提醒你注意，客户预期是否合理。
方式二：现有资源限制，想知道最大承载量。
方式三：啥都没有的。
从我目前的经历来看，这个最常见来着。（是不是也可以证明我经历少呢，无从得知，欢迎讨论）
这样的情况，只要自己用客户提供环境/公司环境，自己搭建一套最小系统，看最小系统的承载量啦。
3）设计性能测试用例
主写：测什么场景，用什么测，收集什么信息，用例执行达标的方式是什么。
其次：规划下用例执行顺序。
好吧，规划执行顺序像测试策略啦，但个人总觉得一提到测试策略就是高大上、繁琐的赶脚（请原谅我的浅薄），不适合我的笨脑瓜，还是直接简洁方式适合我，就放在测试用例设计中吧。
4）搭建测试环境和造数据
在很多公司这个都是研发或运维的事情，我个人意见：测试人员自己做来的好。
好处：等需要调整环境时自己可以直接上手，不需要去请教研发和运维呀，大大节省了沟通成本和缩短修改的时间。
建议使用Jenkins得到系统部署包，最好能用docker 直接得到测试镜像（如有兴趣可以看我的部署专题）
存储过程、shell脚本可以实现造数据。
能自己搞定的，尽量自己搞定，不依赖他人，才是活的更好，工作也是如此的。
5）将word形式的测试用例改成可执行的用例
怎么写脚本需要看你选的是什么工具来做性能测试。
如一个URL页面的性能测试，我通常就用开源ab,webench。（关于市面上云性能测试服务，但有去验证下，再来发表意见）
6）执行用例
这里有一点要提醒，常见的就是1个用例执行2小时，4个用例就是执行8小时，然后就认为自己一天能完成性能测试的执行，可往往第1个用例要花费双倍以上的时间（环境配置的微调）
7）收集结果
不是测试执行后才考虑这个问题，是在测试用例设计时就考虑好的，到执行时确认收集的结果是正确即可。
8）编写性能报告
在网上只有一搜索性能测试报告模版查到的就会是一个很多页数的模版。
个人不建议用这样的模版来汇报性能测试结果，我一般只有测试项对应着的性能测试指标，且用图表的直观地表达出性能上升期、峰值、稳定期。
当然也有人会问我：你的结果是怎么得出的，这时我才会解析测试结果是怎么来的。
我很少讲术语，可能是我太懒吧，也或许是我对讲术语没底气，望没有术语的这篇文章能给你带来收获，欢迎拍砖，纠正。
