(1)测试应用程序的可靠性
在系统崩溃后总结之前失败的压力测试时，我忽视的第一个要点就是没有测试出应用程序在压力下的可靠性。压力测试除了对每个单独的组件进行压力测试外，更应该对带有其所有组件和支持服务的整个应用程序进行集中压力测试，以检查在巨大的工作负荷时，应用程序在峰值情况下是否可靠的执行操作。例如，当实际情况是平均每秒出现1个或2个中断的情形下，应当对每秒出现10个中断的情形来进行特殊的测试;又或者把输入数据的量提高一个数量级来测试输入功能是否可靠的响应。从本质上来说，压力测试是想要看在最大极限时程序是否可靠的运行。
(2)测试应用程序的并发性能
进行压力测试需要对实际的并发访问量有一个正确的预期估算，否则在负载远远大于事前预测的压力下系统将脆弱得不堪一击。导致系统崩溃的因素有很多，处理能力、存储速度、响应时间、网络带宽等无论哪部分出现短板拥堵、后果都可能导致全盘崩溃。
现在我明白，哪怕硬件条件达到了，如果软件的并行处理能力不足将会导致等候队列过长，响应时间变慢，系统崩溃也只是时间问题。简单说就是：压力测试是考察当前软硬件环境下系统所能承受的最大并发负荷，并帮助找出软件程序的瓶颈所在。
(3)测试应用程序的最大负载能力
压力测试的目的之一是找出应用程序能够支持的最大客户端数。通过多次的运行和对测试结果中正在运行用户数与错误用户的对比，然后根据可接受错误率就可得到该功能的最大负载访问的用户数。最大负载压力测试用来评估在超越最大负载的情况下系统将如何运行，这时的目标是要发现在高负载的条件下应用程序的缺陷(Bug)，例如内存泄漏等。因此，最大负载能力不但是应用程序一个重要的技术指标，也是客户评估和验收软件的一个关键指标。
如何进行高效的压力测试?
软件测试有两句通俗的话：开发是尽可能地让程序通过;而测试则是尽可能地让程序通不过。对于压力测试而言，测试效果好不好，测试计划的好坏是关键。所以，针对不同的情况，分析后有针对的进行测试，比起拿枪乱打、无的放矢显然要高效得多。
进行一次切实可行的压力测试并不像乍看之下那么简单，遇到的问题也可能非常微妙。例如，我的测试团队就经常遇到诸如“客户端每小时将要处理100个客户订单请求”等此类的需求，于是测试团队就试图把该需求转化为某种测试需求，执行这种测试需求的常见方法就是以死循环的形式对服务器进行反复请求，然后静观其效。然而，通常事情进行得并不顺利，原因在于这只是把需求表面化了，没有分析出测试需求的本质。高效的压力测试应遵循以下这几个步骤：
(1)确定测试目标
在确定压力测试目标中，我们要定义测试的对象，并对每一个测试对象给出清晰说明，也要定义测试结束的目标。为控制测试的有效性以及完成程度，必须定义准则和策略。准则必须是客观的，可量化的，而不能是经验或感觉。例如压力测试目标可能是测定终端用户处理事务的响应时间，它可能随用户的增加而增加，但要定义一个可接受时间。在确定压力测试目标过程中，最好能邀请客户、设计人员等一同对测试目标进行评审。
(2)制定压力测试计划
测试计划内容包括：定义测试资源、制定测试进度表、选择测试工具等。制定测试计划的目的是使压力测试有章可循并得到人力、物力等各方面的保证;在制定测试进度表时应考虑和开发进度相互协调;对于测试工具的选择应以满足测试目标为前提。所以，这并不是说测试工具提供的功能越多就越好，在实际的选择过程中适用才是根本。
(3)编写测试案例和设置测试数据
测试人员一般是根据测试案例进行实际的测试工作，因此测试案例的编写应做到客观全面、重点突出，也就是要求编写的测试案例应该尽可能模拟真实的负荷，不遗漏重要的测试内容。为了让所有的测试顺利执行，可采取数据驱动方式进行，同时应该对测试数据进行参数化。另外，一般不提倡在开发环境中进行压力测试，最好是另外构建测试环境。
(4)结果分析及测试报告
压力测试运行结束后，应把所有的数据汇总并记录到文件中，以方便对测试结果进行分析和得出结论。若测试失败，应先分析失败原因，如果是软件系统造成的，应返回给设计人员修改。如果测试结果不满足预期需求，应先对软件程序进行优化调理，然后再次运行测试，直到可以满足预期需求或调整已无法改善结果。
最后需要注意的是测试报告。报告应包括测试提要、测试环境和测试结果。提要应简单说明测试方法、策略、范围、内容;测试环境应包括资源开销、环境配置等;测试结果必须包括测试是否通过或拒绝，并要对测试结论进行说明，并对软件程序的性能做出评价。
文章来源于领测软件测试网 https://www.ltesting.net/
