为什么要进行压力测试
问题一：请问高手们，软件系统负载压力测试的主要目的是什么？ 首先，你的问题本身不够准确。负载测试和压力测试是不同的两种性能测试方式。
1、先说压力测试，压力测试是为了确定系统的瓶颈或者最大使用极限的。为了考察系统在极端条件下的表现，极端条件可以是超负荷的交易量和并发用户数，方法是分别模拟一定数量的用户并发访问系统，记录并分析系统响应时间；
2、再说负载测试，负载测试是为了测试软件系统当负载逐渐增加时，系统各项性能指标的变化情况。站在用户的角度去观察在一定条件下系统的性能表现。这些考察指标一般为响应时间、交易容量、并发容量、资源使用率等。
再说下两者的区别：压力测试一般设置的 *** 点策略是100%VU同时增加，指标要求是系统正常运行，负载测试一般不设置 *** 点，每几秒钟增加一定的VU数，记录系统平均响应时间。当前业内普遍的标准是2/5/10原则，2s以内为优秀，5s以内可以接受，10秒是极限。
不知道回答的是否您需要的答案，能否为您解决问题。
问题二：为什么要进行性能测试? 原因有三：
川. 开发者的水平各有不同，有的写出来的东西性能高，有的低，所以需要统一测试一下。
2. 编程工具本身也有性能问题，用这样的工具开发出来的软件也要确认一下是否达到了需求所要求的性能指标，比如响应时间应该控制在多少秒以内。
3. 性能测试，强度测试都是为了测试系统的稳定性，稳定性好，软件的质量就好，买的钱就多。
问题三：为什么要进行性能测试 要找系统性能瓶颈
要找扩容方案
要看看是否达到上线标准
要预估线上问题
问题四：我们在做软件压力测试时，往往要增加比负载测试更多的并发用户和交易，这是为什么？ 其它如响应时间，吞吐率没测过不知道值，一般情况下会是多少呢？
响应时间得看客户那边的要求，一般是>
问题五：压力测试和负载测试的区别] 负载测试：在一定的工作负荷下，给系统造成的负荷及系统响应的时间。
压力测试：在一定的负荷条件下，长时间连续运行系统给系统性能造成的影响。
1.性能测试（Performance Test）：通常收集所有和测试有关的所有性能，通常被不同人在不同场合下进行使用。关注点：how much和how fast
2.负载测试（Load Test）：负载测试是一种性能测试，指数据在超负荷环境中运行，程序是否能够承担。
关注点：how much
3.压力测试（Stress Test）： 压力测试是一种性能测试，他在系统资源特别低的情况下软件系统运行情况，目的是找到系统在哪里失效以及如何失效的地方。包括：
Spike testing（尖峰冲击测试）：短时间的极端负载测试
Extreme testing（极端测试）：在过量用户下的负载测试
Hammer testing（锤击测试）：连续执行所有能做的操作
E.g.举个跑步的例子进行解释。
1.性能测试，表示在一个给定的基准下，能执行的最好情况。例如，在没有负重的情况下，你跑100米需要花多少时间（这边，没有负重是基准）？
2.负载测试，也是性能测试，但是他是在不同的负载下的。对于刚才那个例子，如果扩展为：在50公斤、100公斤……等情况下，你跑100米需要花多少时间？
3.压力测试，是在压力情况下的性能测试。对于刚才那个例子，如果改为：在一阵强风的情况下，你在负重或没有负重的情况下，跑100米需要花多少时间？
性能测试是动力，负载测试载重，压力测试强度.
问题六：为什么要对压力容器进行压力实验 因为压力容器是按国家GB150标准来设计、制造、检验、验收。
压力试验只是属于检验的方法，测试这台设备是否合格。
问题七：为什么在风险管理中需要情景分析和压力测试 同一种风险在不同的场景和压下表现是不一样的。
例如：某个员工舞弊的风险，在家庭出现变故或者家庭出现金钱紧张的时候，风险是不一样的。
问题八：中考为什么要进行压力测试 ？三类压力工作岗位工作中面临压力是正常的，只不过有些岗位要经常面临压力，且压力比较大。为此面试官针对这类岗位应聘设计相应的压力面试题，以测试候选人承受压力的能力。这些岗位大概三类：第一类是中高级的管理岗位，他要面临上下左右、内外的沟通压力，随时随地来自各方面的压力。第二类是销售人员，尤其是大客户销售，要直接与客户进行深度沟通，而客户的需求都是变化的。第三类是特殊专业技术岗位，所面对环境瞬间变化，会产生压力。这三类岗位的应聘者都有可能会遇到压力面试。三类压力工作环境现实工作环境当中，我们会有很多时候处在压力中，因此从压力环境来分也有三类情况。第一类，紧急环境：让你迅速办一件事情，其程度超出一般，特别紧急。第二类，矛盾环境：处在这种矛盾当中该怎么把事情办好？尤其是协调工作，面临着几种甚至十多种工作要素冲突，如何解决？第三类，陌生环境：心理学上讲，每个人都有自己的舒适区，而一旦离开舒适区进入陌生环境就会产生压力，比如：新换岗位，新来了领导，新派了一项从没有接触过的工作任务等等。
压力测试流程
一、压测流程 可参照上篇压测对抗流程 二、压测需求 需要明确需要压测的环境 需要压测的接口，其中包含接口的入参 需要明确接口的预计qps 需要明确线上机器配置 三、压测准备 3.1、服务端开发准备： 1.根据需要测试的接口，决定需要部署哪些相关依赖服务 2.测试接口对应的服务、接口 3.相关配置 4.相关数据库 5.需要的机器整理，其中包含机器的配置，需要几台机器 3.2、前端开发准备： 1.测试的接口和服务应用 2.域名 3.需要准备的机器 4.根据需要测试的接口，决定要部署哪些相关依赖 3.3、测试准备： 1.准备压测的测试方案和测试计划 2.通过接口确认压测的场景，其中包含每一个接口需要测试的场景，预计接口需要的压测线程。通过测试场景确认测试方案。 3.根据测试计划准备测试脚本 4.根据每一个接口的情况准备对应的测试场景。 5.根据测试场景准备需要的测试数据。其中会包含登录账号相关，接口返回有数据相关等。建议可以将线上的数据库直接copy一份到压测环境中 6.测试申请施压机器的权限 7.施压机上准备压测需要跑的工具 四、压测方案和计划 4.1、编写压测方案和计划 1.压测方案和计划的模板查看 2.在测试方案中将信息进行整合和处理，其中包含需要测试的接口，每一个流程对应的时间节点。 3.测试方案和测试计划确定后需要跟对应的人员（包含服务端开发、前端开发、测试人员、前端运维、服务端运维等）进行评审，确认最终的流程的时间节点。 4.根据测试计划中的时间输出对应的结果。其中包含服务券和前端代码部署、机器申请和部署、测试的测试脚本输出 4.2、测试编写测试脚本 1.确认测试接口是否依赖于登录，是否需要登录信息 2.确认需要测试的接口属于atop接口还是http接口。 3.确认需要编写哪些脚本 4.调试测试脚本5. 自动化脚本或者jmeter脚本编写，可查看jmeter使用 4.3、测试验证测试脚本 1.在日常环境对测试脚本进行验证，确定脚本能够正常跑 2.对测试接口需要的准备数据进行整理 3.对测试接口需要的断言进行准备 4.4、施压机上对压测环境的验证 1.将测试脚本中对应的域名和数据等换成压测环境的数据 2.在压测环境中对环境和脚本进行验证 3.与开发调试压测环境中的问题，并调试脚本问题 4.5、在压测环境中进行模拟压测 1.使用一个接口进行模拟压测，确认需要收集的图标信息、结果是否满足预期 2.确认施压机和压测机器是否正常，是否需要更换 3.确认需要采集数据的采集 4.确认断言方式是否ok 五、压测开始 5.1、正式压测： 1.开始正式压测，将各路人马（开发、运维、DBA等人进行封闭压测） 2.针对压测的接口进行决定接口压测的顺序 3.压测中需要逐渐增加线程数量 4.在压测过程中观察实时的qps和报错相关，并通知开发进行查询对应的接口响应时间。 5.根据接口的链路分别通知对应的人员进行查看压测过程中其接收时间、响应时间等。 5.2、当次压测结果分析： 1.当次接口压测结束后，对结果进行分析，确认压测后的qps、报错率、10%、50%、90%用户的响应时间 2.开发寻找对应浪费的时间，当场进行优化后，可以针对此接口在进行压测，以便找到性能瓶颈问题。 3.压测结果最终是需要找到最大的qps和开始出现报错的并发数 4.当前线程数对应的线程数，如没有达到对应的qps要求，可根据qps进行决定增加多少线程数。若线程数增加后，qps没有提高，大致已经找到qps的极限。 5.3、稳定性测试： 1.找到比较稳定的qps对应的线程数，进行稳定性测试 2.稳定性测试与压测的区别在于持续的时间。 3.可通过稳定性测试进行观察持续性调用接口时系统的表现。 4.后续可根据稳定性测试和压测的qps进行计算出对应的每日能够承受的日活量。 六、压测后测试报告整理 1.测试报告整理 a.对此次压测进行整理测试报告 b.测试报告中需要记录压测对应的时间节点、此次压测对应的qps、此次压测中的错误率 c.此次压测10%、50%、90%用户的响应时间 d.压测过程中出现的毛刺时间节点 e.压测过程中曲线不正常对应的原因。 f.此报告需要开发、测试同步进行整理 g.测试记录压测数据和图标 h.开发记录对应系统的cpu使用率、负载、数据库负载等信息。 i.测试报告模板
