---

前言

业务背景：
很简单，项目第一次在银行生产环境上线，对核心交易进行压测，找出核心交易是否有瓶颈，对于整个专业的性能测试过程来讲，要求算简单的了。下面我们说所的是关于一个指标达标的定位，优化的过程，即ART响应时间。

ART是个啥：“平均事务响应时间”显示的是测试场景运行期间的每一次事务执行所用的时间，通过它可以分析场景运行期间应用系统的性能走向。

例如随着测试时间的变化，系统处理事务的速度开始逐渐变慢，这说明应用系统随着时间的变化，整体性能将会有下降的趋势。

可能影响ART的指标有至少以下这些：

业务方面：
简单来说就以下两个：
1、用户量，用户量多了不受影响，那这个系统真的很牛X，当然我说的是大批量用户激增，或者日积月累大批量用户引入。正常系统都会被其影响响应时间。

2、业务复杂度提高，这个好理解，业务复杂了以前三步能搞定的事儿，需要六步搞定，肯定也会受到影响。

系统方面：这个比较多，性能测试中真正去调优的过程，恰恰是以下方式的倒叙。

系统资源，硬件资源过小，不足以支撑现有用户量，或者递增，激增用户及业务量；
系统资源配置，中间件配置，数据库配置，应用server配置，配置项可能包含的点：Linux系统参数，如文件句柄，端口回收机制。中间件连接数，数据库连接数，应用server框架及其部署方式，熔断机制，流控机制，应用日志级别等。

代码处理方式，代码逻辑方式；
数据库效率，SQL效率；
测试时的加压方式，性能测试脚本合理性，参数合理性，测试数据分布的合理性；

ART 分析：
分析之前，经常有人问你，你的交易响应时间是多少，TPS能到多少（这东西不在这儿说了），我们的系统性能差，应该如何分析响应时间呢。响应时间的长短如何定义呢。

以下几点非常重要：
1、性能测试是必须以性能测试目标（测试指标）为导向的测试（当然功能测试也应该是，但是好像功能测试最后可以妥协），否则没有任何意义。

2、有了第一点的意识，就必须知道你的目标在哪，ART值的多少就是你的其中一个很重要的测试指标。

3、指标一定是测试开始前分析出来的，数据量化出来的，如果你是脑洞的，你的测试就是最大的漏洞，测试结果对系统的影响也很有可能是破坏性的。

性能测试有多折磨人，显而易见了，因为就一个ART的结果你就要通盘考虑以上所有的，何况还有更恐怖的TPS。当然价值与成就感也不言而喻了。需要强调的是这种成就感和价值，这对于研发和测试起到的作用是同等的，且积极的。

分析定位：
要想准确定位ART是多少，那我们怎么入手，怎么分析呢，因为我们的系统有N个系统模块，还不算银行系统有多少次交互，和有多少个系统。

那么方法论来了：拆分，细化，排序外。逐一来讲一下：

1、拆分
无论你有多少个系统，多少个模块，我们都要在开始测试前拆分出来，认清楚你的交易路径经过了多少个系统，本次测试一笔交易要经过网关系统，账户模块，支付模块，及银行网关系统。

2、细化
清楚了交易路径，我们就要进行细化交易，细化到最简单的交易路径，比如我们的目的只是为了测试自己的充值逻辑是否有瓶颈，事实是测试过程中，充值，提现，都在基准负载测试中无法达标（我们定的目标是500ms-800ms以内）。

以充值交易为例，剔除其他任何指标的影响，只是支付模块进行了充值逻辑的处理，那么我们主要关注的就应该是这个模块。

3、排序
有了交易路径，有了主要测试核心目标模块（支付模块），我们要定位充值交易的响应时间耗时，都合理的在哪里消耗掉了。

响应时间ART定位准确尊从以下步骤：
收集性能目标；（也就是调查用户对响应时间的满意值）；
量化性能目标（包括分解性能目标、量化各部分性能目标）；
确定系统功能和交易路径；
满足性能目标。

下面是我整理的2023年最全的软件测试工程师学习知识架构体系图

一、Python编程入门到精通

二、接口自动化项目实战

三、Web自动化项目实战

四、App自动化项目实战

五、一线大厂简历

六、测试开发DevOps体系

七、常用自动化测试工具

八、JMeter性能测试

九、总结（尾部小惊喜）

只要你愿意为之奋斗，任何事情都有可能实现。每一次失败都是成功的必经之路，坚持下去，你会发现自己比想象中更强大。不要停止前进，即使路途艰辛，未来一定值得期待。

只要你心中有梦想，就不要停下奋斗的脚步；只有坚持努力，才能迎来更好的自己。让梦想成为你前进的动力，永不放弃，勇往直前，一定会收获成功的果实！

只有在你勇敢面对困难和挑战时，才能真正看到自己的潜力。所以不要害怕失败，不要逃避困难。用你的坚强和毅力去征服每一个难关，最终你会在奋斗中发现更好的自己！