LoadRunner第一次压测实践后的心得体会 & 收获

背景

前几天，我们产品有了一个压测任务，我老大用LoadRunner进行了一次压测后，老大跟我说：之后还需要再进行一次压测，于是打算交给我来实践。我摩拳擦掌：终于可以用LoadRunner来一次压测实战了！这是我的第一次压测。

今天压测已测试结束，压测结果也测试通过 & 符合要求了 。终于可以把我这几天的收获整理一波了~

收获

1、压测需要设计测试用例，有些Case其实是没必要的，可以跟多方review

2、要了解被压测的服务 、 并且积极与开发沟通 、了解被压测的背后实现，关注压测重点

3、压测不仅要看请求数，还要看：被压测的服务 CPU 、以及本机 CPU，关注占比多/少

4、怎么看压测瓶颈：Vuser 数增加，每秒请求数会对应增加，当 Vuser增加到某个点时，请求数反而下降了。可能就是压不上去了。

5、压测时遇到错误数，要先排查：是软件失败 还是服务失败

6、压测结果高低会由 多个因素影响：

环境配置：生产环境、测试环境 不同配置

软件配置：Vuser、运行时配置、压测时长（1分钟、5分钟、N分钟）

测试场景： 数据随机化 ， 缓存机制 、 场景复杂度都会影响压测结果 。 越单一的场景，压测结果相对较好 ，压测时，尽量接近/符合真实场景的数据，压测出来的结果也就越真实正确。

开发代码原因：代码是否存在Bug、代码问题会影响一定性能

压测代码原因：压测代码逻辑、是否跳转302

7、最后 ：保留压测截图、编写压测报告、给出压测结论 。

心得体会

这次最大的感悟：

之前没有接触过 性能测试 ，没有接触过 Loadrunner ，会觉得很神秘；

现在使用了 Loadrunner ，做了第一次压测，会感觉 ：使用工具的确只是入门而已，要学习的还有很多，性能测试我算是够着了，不那么神秘了。

压测的过程 ：压测 、等待、记录；可能有些数据没观察到，可能又需要重新压 ，一直循环。

要耐得住性子，多观察，多思考，多沟通，下次可能会做的更好。

---

这次压测很感谢我老大很耐心的手把手带我入门 ，把压测任务给到我， 让我有很多思考空间 ，收获颇多 。