如何做压力测试
一个压力测试的流程：
1、明确测试目标
2、制定测试计划
3、实施测试，收集参数
4、分析测试结果
5、给出优化方案
一 、明确测试目标：如果是客户的需求，那需要向客户确认，有清楚的性能指标参数，测试时就是保证系统达到该指标并能良好运转，即压力测试。如果是自己的系统需要有一个评估，那就需要完整的得到该系统的几个临界点，拿到完整的性能曲线，从而来分析部署情况，即为性能测试。不管是哪个，知道了需求，才能制定计划。
性能测试的目标是发现重大的系统瓶颈。你可以想象一个系统由一系列的瓶颈组成；发现并改善一个瓶颈往往会在其他地方产生一个新的瓶颈。例如，我曾为一运行微软Windows CE的器件部门工作。我们发现的第一大性能问题体现在某一具体硬件环境下的内存管理中。我们把问题分离出来，改善了内存分配的效率。尔后再次运行我们的测试，又找到了一个新的瓶颈，这次体现在网络吞吐量上（throughput）。解决了这个问题后，我们接着又为下一个瓶颈改善而工作，然后再下一个，直到整个系统都达到了性能目标。要记住的是：关键在于要尽早订立性能目标，否则你可能不知道什么时候该停止性能测试。
二、制定测试计划：确定使用什么工具，着重哪些参数，设置线程数，方法执行次数，执行时间，是否多个接口同时进行测试等等。
三、实施测试，收集参数：选一个施压工具，来向部署好的服务发起高并发请求，同时关注和收集性能参数。这个是我们花费时间最多的地方。通常该阶段需要反复执行，来得到想要的数据。通常来说，我们可以使用JMeter LR AB 自己写多线程等各种方式，之后介绍一下JMeter。
四、分析测试结果：即根据上一节的参数介绍来进行参数分析。
五、给出优化方案：如果是代码逻辑耗费cpu，就优化算法；如果是redis等数据库耗时，就增加节点，减少读取，读写分离，使用内存等；如果是外在条件限制，则与外部们沟通问题，共同优化等等。
一、如果是排水管道的话，不用做压力测试，但是必须做灌水试验，把各出水口堵住，从单进水口灌满水，过段看看水下降了多少，如果下降太多，需要检查下哪里漏水，一般都是管件与管材连接处，特别是弹性封圈（伸缩节），一般做个12-24小时，没有问题就可以使用了。
二、如果是室内承压水管的话，一般家里用到的都是PPR管子多，在装修完毕后不能马上使用，必须做压力测试，做压力时把所有出水口堵住（最好先剩一个出水口，增压时等有水流出再关闭，是为了将里面的空气排完），工具则需要用到增压泵和压力表等，注意增压过程至少要10分钟以上，冷水管不低于设计工作压力的1.5倍，但不低于0.8MPa,热水管不低于设计工作压力的2.0倍，但不低于1.5MPa，恒压观察，一小时后压力不得下降0.02MPa，若有下降，允许有三次补压机会，若压力下降明显，则需要停止测试，需要检查下哪里漏水，检查完了再试压，直到正常为止，一般也是管件与管材连接处漏水几率大，当然在使用前还要做管道消毒处理。如果不是自己安装的话，我还是建议你找正规点的装修公司吧，如果日后出了问题，都可以找到相关负责人。
进行压力测试需要一定的计划和工具，以下是一般的压力测试流程和步骤：
确定测试目标：定义明确的测试目标，包括要测试的应用程序或系统的功能、性能指标和性能要求。
确定测试环境：设置测试环境，包括硬件、网络、操作系统和数据库等，以模拟生产环境。
选择压力测试工具：选择适合你的应用程序的压力测试工具。一些流行的压力测试工具包括Apache JMeter、LoadRunner、Gatling等。
制定测试计划：确定测试的参数，如并发用户数、请求率、持续时间等。制定测试场景，模拟真实用户行为，包括浏览网页、提交表单、下载文件等。
准备测试数据：创建或准备测试数据，以确保测试过程中有足够的数据可用。
执行压力测试：使用所选的压力测试工具配置测试场景并运行测试。逐渐增加负载，监测应用程序性能并记录结果。
监测和分析：在测试运行期间，监测关键性能指标，如响应时间、吞吐量、错误率等。收集数据以后续分析。
性能优化：根据测试结果，识别性能问题和瓶颈。优化应用程序或系统，以满足性能要求。
重复测试：如果需要，重复测试以验证性能改进和问题修复是否有效。
生成测试报告：汇总测试结果并生成测试报告，包括性能指标、问题列表、建议的改进措施等。
决策和部署：根据测试结果，决定是否满足性能要求，是否可以部署到生产环境。
监测和维护：在生产环境中定期监测应用程序的性能，以确保它在时间推移中仍然满足要求。定期进行压力测试以检测潜在的性能问题。
在进行压力测试时，确保在测试期间仔细监测系统资源使用情况，如CPU、内存、网络带宽等，以及应用程序的日志和错误报告。这将有助于识别潜在的问题，并帮助你采取适当的措施来提高应用程序的性能和稳定性。
接下来我AUT的登录说一说怎么用LoadRunner和Jmeter来实现场景的设置达到测试的目的。（注：对服务器的检测不是本次测试的重点，本次测试主要收集并发访问用户数和发生错误用户数）
首先是对脚本的要求：
1、录制脚本（注意所有的脚本都应录制到Action中），自定义事务，事务从提交用户名和口令的脚本之前开始；
2、在定义事务开始的脚本前加入集合点；
3、在脚本中加入检查点，以登录成功的页面出现登录用户的ID即可；
4、参数化登录用户的身份；
其次是对场景设置的要求：
1、因为事先我们不知道将有多少用户访问是临界点，所以在测试过程中需要多次改变用户数来确定；
2、建议修改运行时设置，优化对服务器的访问；
3、计划的设置，每x时间后加载10用户（根据总用户数设置），完全加载后持续运行不超过5分钟（根据需要设置）；
4、集合策略，当运行中的用户数100%达到集合点时释放；
5、注意事项，需要注意几个时间：1）服务器响应超时时间；2）登录事务迭代一次所使用的时间；3）集合点等待超时时间；4）计划中设置的间隔时间。在我的测试中事务运行一次的时间不超过30秒，通过修改脚本使它的运行时间达到一分钟左右， 服务器响应超时时间、结合点等待超时时间、计划中设置的间隔时间都设置为了2分钟。
