二 性能测试流程这里简要说下我希望的，或者是我向往的，呵呵
1、性能测试需求了解
这里我们需要去做很多事情，需要去了解需求，已上线的系统，我们需要知道服务的线上数据，比如上面说的pv，在线用户数等等，这个是指导我们性能测试的基础，是我们的底线，这个如果不准确，后果可想而知。而且
我个人觉得需要尽量精细，
当然不是让你去抠是100还是101，这个可能就是数量级上的误差了。另外很多人可能都觉得，没上线的新系统，我们怎么评估，没有数据？这个其实有很多种
方法了，比如我们预期希望有多少人要用，多大的压力，或者从以往的数据进行评估，我们目前能够使用将要上线系统服务的用户数是多少等等，这些角度都可以帮
助我们去定位我们的基准压力数据。这里的用户数是指抽象意义上的，不是一个实质的用户，也可以想象成是请求或者什么。
另外我们还需要取了解被测系统的框架，了解他使用的语言，根据被测系统的类型，被测系统的框架分析可能存在的性能消耗在哪个方面，需要重点监控什么指标，根据使用语言的特性，结合经验有针对性的方案设计。
2、性能测试方案设计
这个是相当重要的一个环节了，上面我们已经了解了。
在之前的需求了解过程中，我们已经确认的需要重点监控的一些指标，那么这里我们需要将用例和场景进行组合，让系统暴露出问题，选择用例上，显然我们不会像
功能测试的方法，应该选择有代表性的，比如一个图片存储系统，可能功能上会满足多种格式，多种大小的图片进行上传功能，但是仅有一种格式会进行压缩，同时
允许上传的最大的图片为1M，那么就是在着这情况下，对于系统的压力最大，我们可能需要选择这个用例进行测试；另外，我们还需要结合系统实用场景，有数据
支持，在发布后，系统上上传500K的图片的次数最多，那么这个也是我们需要选择的用例了。同时，在测试场景的设计中，也有很多种，比如我们需要知道系统
能不能支撑上线后的高压力，所谓的高峰场景，往往采用压力测试，给系统施加较大的压力，观察系统表现。同时，
web服务的系统往往需要24*7
不间断提供服务，那么稳定性往往也是不可少的；还有一些类似破坏性的场景，给系统施加难以承受的压力后，减小压力，观察系统的恢复能力等等。
在这里作为新人，我建议最好可能在设计方案完成的时候，可以找一些专家帮忙review，这个完全是对
工作负责人的做法，同时也能后很好的提高自己，专家
会根据自己的经验给出很多建设性的建议，自己能够
学习到很多东西，是提高的大好机会，同时能够保证自己的方案不会出现较大的偏差，一定不需要不好意思，这
样是百利而无一害的：）
3、性能测试准备
这里单独拿出来说是发现，在测试实际实施的过程中，会遇到很多困难，需要做好准备，很多风险往往发生在这个阶段。
方案已经完成，那么需要进行测试用例和脚本的准备了，不管你使用的什么性能测试工具，请在真正测试之前进行预测，同样如果需要的话，请找人review你
的脚本，脚本在调试的时候一定需要有检查点，看下你的测试脚本是否生效，不然到测试执行时才发现问题，对你的进度会有很大挑战。
测试环境的准备，这个不知道大家会不会遇到环境的问题，首先基础软件的熟练使用是必要的，linux操作系统的操作，还有被测系统的部署，这些都需要提前
准备好，同时需要你的硬件环境尽可能的好，尽可能的和生产环境保持一致和独立，这样便于后期测试发现问题进行定位。
4、性能测试执行
执行应该是最简单的一步了，将设计好的场景用例跑一变，也就是一些性能测试工具的使用，监控软件的使用了，这个都是熟练工种，我只想说，请每次都对自己要
求高一点，不要一成不变的用一种工具，即便是一种工具，也有很多可以让你的测试更方便的方法，每次都能提高一点点。
5、性能测试结果生成
结果的生成就是对系统的一个基础判断了，往往是一份报告了，判断系统是否满足需求，报告的宗旨就是用最明白的话告诉需要关注的人他们关注的结果，把重要的写在前面等等。
6、性能测试结果分析
这点可能和5是和在一起的，实际往往没这么分明，进行结果分析也就是定位瓶颈了，这个往往很需要技术，以
java系统为例，当发现系统的瓶颈可能出在某种
硬件资源上，就会去打印一些线程信息，看下gc情况，分析系统的哪个类
、方法、sql消耗cpu时间，占用较多内存等等，这个也有一些profile工具，常见的也有java
profile、yourkit等等，用是很容易的，看懂结果还是需要自己多多琢磨和学习，需要加强对被测系统的理解了。
7、性能测试调优
调优么，当发现了一些性能问题，已经能够定位到哪些地方比较消耗性能的情况，也就是去做时间和空间的取舍了，考虑在某个node上，我们的关键点在于我需要快还是我需要稳定，找到他们的平衡点
