明确压力测试的目标
通常来说（注意是通常），压力测试的目标有这么几点：
1、评测系统是否满足压力支撑的要求
要评测系统是否满足压力支撑的要求，同样要做的就是需要明确定义系统需要支撑多大的压力，例如：
机器的配置：CPU、内存、硬盘、etc.
网络条件：100M
操作系统：Linux core: 2.6
当并发数为10用户时，系统应能在20ms内响应完毕（这个时候的TPS为500），系统的load需在2以下；当并发数为100用户时，系统应能在50ms内响应完毕（这个时候的TPS为2000），系统的load需在4以下；当并发数为200用户时，系统应能在80ms内响应完毕（这个时候的TPS为2500），允许其中有千分之一的出错率，系统的load需在6以下，在压力测试的过程中，只要其中的任何指标未达到，均可判定系统尚未达到压力的目标。
实际的压力测试的这个指标会比我这里举的例子复杂很多，例如还需要考虑网络流量、内存消耗、IOPS、连接数等等。
这里面压力测试隐藏的目标是为容量规划提供一定的指导，例如目前的系统在某种配置的情况下单台机器能承受的最大并发数为100用户，那么如果系统的高峰压力是1000的话，如果系统支撑无损水平扩展的话就意味着需要10台这类配置的机器，这一步同样是经过测试的。
2、预估系统上线运行的状况
毕竟通常压力测试环境和线上的环境是会有很大的不同的，压力、数据量、硬件环境等，基本上只能是根据线下的环境的情况进行一定比例的对比后计算来预估，这里面很重要的是要预估系统上线后正常情况下的表现状况、一定的增长比率后的运行状况以及风险点（例如当并发用户数增长到多少时、系统load到多少时可能会出现问题）。
这一个目标我觉得非常难达到，但随着经验，我相信是可以做到的，如果能做到这种效果的话是会有很大的帮助的。
以上这个两个目标基本是压力测试都要达到或希望达到的，而具体有可能会因为系统的业务的具体情况会制定其他不同的目标。
制定压力测试方案
这步是压力测试整个过程中最难的步骤之一，为了能够测试出系统是否符合压力支撑的要求以及评估上线的表现，通常我们会希望搭建出和生产环境完全相同的环境，但这就是最麻烦的一点了，基本上是不太可能的，因此通常能采取的方法会是：
1、做等比例的缩放
按照生产环境的情况做一定比例的缩放，例如生产环境的数据量为1亿条，那么测试环境等比缩放到5000w条，生产环境的处理速度的情况...；
2、更差环境、更高压力的测试
采取比生产环境更差的机器配置、网络环境来进行测试，例如ebay的要求是能够承受10x的压力。
3、仿真测试
据资深人士言，仿真测试要做到基本是不太可能的，仿真测试首先要求的是收集到生产环境中的运行状态的数据，然后在测试环境中编写程序来做到模拟生产环境运行的效果，这个难度基本是非常高的。
我自己现在做压力测试更多采取的做法是以上三种方法的合集。
在确定了测试方法后，就基本可以确定压力测试的环境了，环境确定好后需要做的是压力测试的案例或场景了，在压力测试的案例中需要涵盖正常场景以及异常的场景，正常场景是非常容易做出来的，只是需要根据生产环境收集的数据（例如不同级别的用户比例通常是7:2:1）或预估的数据来搭建相应的测试案例，异常场景则是比较复杂的，需要考虑很多的因素，例如数据库出现异常、网络出现异常等，这里我觉得通常的做法是画出正常场景的处理流程，然后划分交互边界的信任边界，对于所有的第三方交互都认为是不可信任，例如不能信任调用数据库是一定会快的，或一定会成功的，在异常场景中应涵盖这些信任边界的异常状况的测试，这些对于高可用性的系统而言是非常重要的，几个9的成败就在此了，^_^，当然，高可用性又是个更复杂的话题，不在这里讲。
在压力测试方案中还需确定的是考评的指标，通过会包括：tps、系统load等等。
进行压力测试
相对来讲，在有了压力测试方案后，这一步并不是什么太复杂的事情，只是需要选择一个和压力测试方案比较符合的工具来执行，例如jmeter、loadrunner等，当然，这些工具相对来说也是比较复杂的，而且之间的差距也是比较大的，至少目前来看，jmeter和loadrunner的差距还是不小的，尤其是需要进行高压力的测试时。
文章来源于领测软件测试网 https://www.ltesting.net/