性能测试过程中容易遇到哪些问题？

做任何事情，事前有准备就可以成功，没有准备就会失败。说话先有准备，就不会词穷理屈站不住脚;行事前计划先有定夺，就不会发生错误或后悔的事。

一、 在测试工作启动前

(1)没有对测试背景和当前项目情况进行足够的了解。

因为没有对项目当前情况有足够的了解，所以在心中形成了一个错误的测试方案(即分别通过接口压测的方式对两套相同配置不同项目版本的服务进行测试。)，但实际上测试环境仅有当前一套测试环境且部署的为新版本服务。

二、 在测试工作启动初期

(1)没有搞清测试目标

因为没有搞清测试目标，所以没有明确测试方向，不明确测试所需着重记录的参数，就更不能有针对性的对其进行测试并获取目标参数。

(2)没有制定明确的测试计划

因为没有制定测试计划，所以在测试工作执行在执行时时间分配错乱，没有明确测试操作的方案导致方案多次变动，延误工期。

三、 测试启动中期

(1)将工作重心放在了脚本编写

将过多的精力投入在了脚本编写中，为给调试和其他环节预留出时间。测试不只写完脚本即万事大吉，这只是众多环节中的一环，需环环相扣，每一环都顺利完成才能完成一次测试。

(2)测试脚本没有进行真实调试，对脚本所使用的模块不求甚解

每次测试脚本编写完成后，仅对脚本功能进行了验证。也就是只保证了功能可用，但忽略了应用在测试工作中的真实场景。类似于接口压测脚本没有顾虑到各接口传输速率的问题，导致下游接口所需数据不足;数据库sql写入脚本中的线程应用也不求甚解，只学会皮毛就照猫画虎，没能理解使用的逻辑方式，所以线程模块用的乱七八糟，直接导致脚本运行失败。因为没有对脚本进行真实场景调试，所以在测试执行后 就会出现各种问题。则需要一边修改 一边调试 一边执行。大大影响工作进度。调试工作应在非工作时间进行或在进度时间范围进行。不应占用测试执行时间。

(3)多次调整测试方案

我的初始方案是针对服务进行接口性能压测，后来开发建议直接对数据库进行测试，则又开始对数据库进行测试，再对数据库的测试出现断路后，又采取了小颗粒维度对接口进行性能测试，此测试方案可行但需要大量的时间。我在采取这种方案的时候并没有预见到这种风险，显然这种高耗时的方案并不适用于我当前已延误工期的情况。最终仍回归最初的单一接口性能压测方式，完成报告。

a、因为没有计划和方案，所以选取哪种方案自我并没有一个坚定的认知很容易动摇;

b、其次因为对性能测试相关知识掌握的不足，所以在面对开发提供的各种方案都容易被动摇，认为他们说的更合理，但实际并没有对这些方案进行认真的思考和评估。

(4)没有提前做性能基准测试

因为没有在压力测试正式开始前对业务进行基准测试，所以对各个接口的基本表现没有一个大致的了解，所以出现了脚本执行中权重比例错误的低级错误。

(5)在最后一次测试时，没有对服务器进行监控

a.对linux系统操作不熟练，操作监控服务的时间成本较高

b.没有设计好具体的监控方案，不知如何更高效的监控服务器

c.对自己降低了要求

四、 测试收尾工作：

出现工作冲突

应在测试工作开始前，明确测试执行时间区间，项目组内沟通，保证测试环境可正常使用。

以上内容为大家介绍了性能测试过程中容易遇到哪些问题，本文由多测师亲自撰写，希望对大家有所帮助。https://www.duoceshi.com/xwzx-hydt/2077.html