因环境、开发语言、架构、业务场景的不同会导致在性能测试的过程中出现各种各样的差异性，其对应的性能分析方法也会稍有不同，在此可大致总结为两种办法。
性能分析入手分为两种办法
1、由内至外，监控资源到性能指标
通过监控观测被测系统的各项性能指标(CPU、内存、IO、网络、等硬件资源)来分析哪块存在性能问题，主要用于性能摸底或确定性能瓶颈时使用。
2、从上到下，整体分析到逐个击破
进行多轮负载测试，结合业务调用链路分析具体性能卡点，可采用一层一层的装配业务来进行调试，最终确定性能问题。
性能分析流程
以现在常见的应用架构为例，通常分为Web接入层(请求接入、负载均衡、页面渲染等)，逻辑层(业务逻辑实现、数据分析计算、复杂对象封装等)，持久化层(数据库调用、事务处理等)，我们在测试分析过程中也要结合对应架构对我们的分析数据做简单调整，下面介绍一下通常的性能分析过程。
- RT(响应时间)，时间对于用户体验来说至关重要，当发起负载时，响应时间也是最直接的体现系统性能的指标之一。
- TPS/QPS (每秒事务数) 当每秒事务数大时，响应时间小，通常代表系统性能良好，反之则需优化。
- 事务成功率，在脚本编写时对于业务的成功判定条件要加入相应断言，事务成功率降低大概率也意味着出现性能问题。
- 负载机资源利用，通常负载机的性能对模拟用户并发的效果是有影响的，建议在每次测试过程中同时监测负载机资源使用情况，如果存在负载较高情况可考虑分布式部署或者更换负载机再进行。
- 检查被测服务器资源消耗，现在服务通常分为IO密集型和计算密集型，两者侧重点稍有不同；确认在测试过程中服务器是否出现异常情况，是否已到达资源瓶颈。
- 检查中间件配置，如各项连接数、空闲等待时间等。
- 数据库资源使用分析，数据库相关内容及监控相对比较困难，除通用指标外通常还需要关注连接数、慢SQL等。
- 网络环境因素影响，在测试规范中通常要求负载机及被测服务器要处于同一网段，但仍会因为各种原因导致网络存在波动、阻塞等因素，如以上指标及配置均正常情况下，就需要考虑是否存在该风险。