《全栈性能测试修炼宝典 JMeter实战》—第2章 2.3节性能测试成功与失败要素

本节书摘来自异步社区《全栈性能测试修炼宝典 jmeter实战》一书中的第2章，第2.3节性能测试成功与失败要素，作者road_testing软件测试组 组稿 , 陈志勇 , 马利伟 , 万龙，更多章节内容可以访问云栖社区“异步社区”公众号查看。

2.3　性能测试成功与失败要素

性能测试上手难度比较高，是一门融合测试、开发、运维、需求调研、架构、协调管理等综合技能的学科，掌握一门性能测试工具对于性能测试来说只是万里长征的第一步，没有一定的需求、开发和运维专业能力，往往会吃一些苦头。

性能测试有几大难点：

（1）需求分析；

（2）场景设计；

（3）性能诊断调优。

（4）环境搭建和模拟

往往很多性能测试从业者在需求分析方面没有做到位，不能准确地预估用户行为；在场景上不能复现用户操作，无法把需求体现在脚本和场景设计上，无法模拟真实的系统负载；这种状态下做出的性能测试往往结果良好，上线出问题，导致整个项目团队狼狈不堪，整个公司手忙脚乱。

性能诊断调优是一门有效利用和协调硬件软件的“艺术”，从oracle exadata诞生之初在软件层面的优化就可以有200倍至10000倍之多。

但是性能诊断和调优是有时间和经济成本的，也是需要全面的it知识体系的专家或者团队才能比较全面地挖掘出系统的性能问题并给出调优方案。

很多性能测试初学者总觉得性能测试就是写个脚本，弄几台机器应付，出个报告就行了。通常关注并发多少，响应时间多少，能跑通吗等问题认为并发越大，响应时间越快，那性能一定就越好，实际上我们需要对系统进行一系列复杂精密的工作才能开始性能测试执行，经过n次回归，找到瓶颈的具体原因，优化再验证。

下面讲解性能测试重要关注点。

1．评估系统，需求分析

对性能测试进行需求分析，通常情况下我们很多功能测试人员会直接依赖需求人员或者项目经理的口述或者有缺陷的文档。实际上，大多数情况下我们需要自己来引导相关的运维人员和需求人员给出具体的需求数据，并对这些数据进行二次分析，得出我们真实的性能需求。

对于初次上线的系统，我们需要用同行的系统数据，进行用户行为分析和商业数据结构的估算为前提，利用性能估算法推算。得到的负荷和响应时间数据可以被用于验证所计划的模型的能力，并帮助作出决策。

对于已经上线的系统，我们可以通过运维人员获取tps和时间的比例分布图、用户数和时间的分布图、数据库er关系图、容量数据等，直接精确得出目前的系统的用户行为和业务数据关系，进而得出我们需要的性能需求。

2．场景设计、用例设计

充足的需求调研与分析之后，我们要在测试场景中尽可能真实地复原系统负载。

通过需要我们要决定哪些功能要参与性能执行，如何参与？这就是用例设计。

如何有效地组织测试用例就是场景要做的事，按业务分布、业务量、业务时段、业务角色来综合分配用户数、执行时间、执行比例等。看似简单，实际操作起来还是比较麻烦的。

3．测试执行、是否通过

模拟不同负载执行测试场景来识别系统弱点：做好各种监控，甄别各种问题；验证系统的稳定性。下面是我们在执行时常见的需要关注的指标，如图2-4所示。

4．性能诊断优化

性能诊断知识面要求甚广，系统日益复杂，单打独斗的日子已经远去，依靠团队力量才能够高效完成诊断任务。性能测试从业者要具备良好、敏感的性能意识，能够把遇到的问题初步分类，协助各开发团队完成问题定位、分析调优。所以首先要是一个好的协调者，还是一个技术面广的技术人员，具备跨领域知识，如开发、运维、数据库、缓存等。