接口性能测试实战小结（附点评）

百度搜索：小强测试品牌

本文来自小强测试品牌学员作品，欢迎大家多多投稿，也期望各位学员再接再厉！

背景

---

有一个接口http的接口，GetPaymentURL，传递参数很简单，就是一个sessionID（类似于订单号），这个接口本身并没有什么东西，但是他调用了另外一个模块钱包的接口，钱包最终会返回一个paymenturl等信息给到GetPayment这个接口。

一句话，GetPyamentURL只时负责传递参数给到钱包的接口，主要业务逻辑都是在钱包里面，最终由钱包把结果返回给GetPaymentURL ，拿到结果后再做简单的处理，把结果返回出来。

小强点评：明白一个接口的逻辑是非常重要的，实际中我发现很多人只关注技术，却不关注业务逻辑，导致很多一步可以完成的事情偏偏走了N步，得不偿失啊！

问题

---

当时遇到一个情况，调用getpaymenturl接口有时非常慢（只是1个用户进行调用，100次内有27次是20秒以上，最长的都达到30秒以上。我这只是单个用户进行请求啊，怎么能这么慢），但是直接调用钱包的接口非常快。而且都是在同一网络下用一个用户分别进行测试100次，都是在我们公司的内网发出请求的请求。

小强点评：我就想说棒棒哒，哈哈

分析

---

首先，因为直接调用钱包接口，响应正常。所以我觉得问题应该是在getpaymenturl这里。

我利用LR，把getpaymenturl的结果分析了一下，发现buffer time非常长，进一步分解，得到server time很慢，net time是正常的。所以我怀疑是不是GetPaymentURL接口本身的server端问题，导致慢。但又觉得说不过去啊，这个接口只是做了简单的传递，怎么会这么慢，不太可能？所以我觉得还是保留一下网络的原因。

然后我又想，不对啊，为什么直接调用钱包接口，都正常，说明网络是正常的。后来与同事确认后，后来发现直接调用钱包接口走的是公网（开发给我的测试地址是公网的），而getpaymenturl应该走的是专线。虽然最终都是到达同一台服务器进行处理，但是他们走的网络节点是不一样的。所以现在我更加肯定，网络+VPOS都有可能有问题。

小强点评：分析逻辑严谨，能放能收。抓住网络路径的不同找突破口

这里还有一个小故事。VPOS一开始其实用的是公网地址，然后我们这边的一个同事，配置了一个什么代理，就是无论VPOS用什么公网地址，都会被这个代理，转一下，最终跳到一个固定的地址，然后再从这个地址转出去，再到钱包。

这样搞，显然不行，一是对于这种涉及到钱的交易，肯定是走专线地址的。 而是即使走公网，为什么还绕了这么大一圈子，通过配的什么代理，兜一圈再出去。。。

于是立马，让同事修改成为指向钱包的专线地址，重新测试了一下，结果一切正常。

虽然结果有点大跌眼镜，既不是网络原因，也不是VPOS服务端的原因，而是莫名其妙的被兜了个大圈子，导致响应时间较慢。

这是最终用单个用户请求了200次的结果：

小强点评：为什么性能测试好玩？就是你会发现有时候你玩他，有时候他玩你啊，就和大家为啥都爱看悬疑推理破案片一个道理，所以耐心、坚持、逻辑思维真心很重要。不过这里我建议用的工具要保证一致性，毕竟每个工具的统计原理不一样，如果换着用会对数据的比较造成一定的干扰。这里学员用了jmeter，而上面用的是loadrunner。

总结

---

1. 遇到这种接口很慢的情况，无非就是网络+Server端的原因。

2. 对于这种接口调接口的情况（某个接口本身封装了另外一个接口），可以进一步拆分。比如直接调用钱包的接口，看看他是否正常，如果他本身就有问题，那肯定是要首先分析钱包的接口。 如果钱包接口本身没有问题，那就要分析是不是getpaymenturl本身接口的问题

3. 遇到问题，要与相关人员进行确认。

小强点评：这里的总结看起来短短几字却透出了我一直传达的一个信息，那就是分析问题要学会分层拆分！只有把大的拆成小的我们才能慢慢找到突破口，很多人觉得分析难不会分析，本质就两点，一点是基础不够扎实，二点就是不会拆分，不知道该怎么一步步拆解。

如果对你有一丢丢帮助，转发+点赞=支持