理想中的性能测试
用一句歌词形容理想中的性能测试，我站在草原望北京，一望无际国泰安宁。。。
产品经理提供性能测试场景，并发数，以及期望的业务处理能力和响应时间。
研发同学提供详尽的接口文档，配合测试同学生成测试数据。
测试同学很顺利的完成性能测试工作提供测试报告。
研发同学按照测试报告完善产品性能。
真是一片和谐安宁的幸福景象。。。
现实中的性能测试
现实中的很多公司其实都是这样搞性能测试滴。。。
产品经理说，需要对产品进行性能测试，测试人员自己定吧，然后。。。然后就没有然后了！
测试向研发同学要接口文档，其实大多数情况下是没有接口文档的，听到最多的回复是，编码任务太重了，没时间写接口文档；部分幸运的测试同学要到了接口文档，但是按照文档里面的内容，是根本调不通接口的！
这怎么做性能测试呢？
这怎么做性能测试呢？
这怎么做性能测试呢？
很不凑巧的是，老板发现产品很慢，不分青红皂白，对着性能测试同学一顿喷！
tmd，不干了! 不干了? 可是现在工作太难找了，没有收入怎么活？
自救，改变思路
分析产品经理无法提供性能测试的场景，并发数，以及期望的业务处理能力和响应时间的本质原因是什么？很简单！是他真的不知道！！！我们手机里装的应用，那都是app中的翘楚，百分之八十普通小厂的应用（就是你我公司的产品）其实是很少有人问津的，通常打点监控做的也不完善，产品也自然很难获取到用户的真实使用数据信息。
至于研发同学不提供详尽接口文档的原因也很简单，主要有两点：
1.确实忙，没时间写
2.接口变得太快了，维护不过来！
怎么破？
怎么破？
怎么破？
核心就是我们测试人员尽可能少地来打扰研发和产品，我们测试自己干！
简单的说就是，直接从产品页面使用入手，抓住用户体验这个key，从两方面入手：
1.单用户做页面的性能测试，发现页面的资源（如图片、脚本、样式表的加载）以及页面请求的响应时间等性能问题；
2.对某页面中所有的接口进行压力测试。
具体方法如下：
前端性能测试
可以使用google的工具lighthouse，直接发现页面中的资源，如图片、脚本、样式表的加载问题，大家可以参考文章：
https://blog.csdn.net/liwenxiang629/article/details/133271065
页面抓包压测所有接口
实现也非常简单粗暴，通过fiddler等抓包工具，获取产品页面中的所有请求，然后进行压测！
这里有几点注意：
1.不要再生产环境中测试，因为你真的不知道会产生什么影响
2.测试前一定要跟研发打招呼，告诉他们我们要压测了，把抓取的接口发给研发让他们确认（给定反馈时间，不反馈，直接压，出问题了，研发的锅）看看是否会影响生产数据，把有风险的接口屏蔽
3.没有指标的性能测试，在测试报告也没必要明确写哪个接口就是慢，我们可以采取同页面中接口比较的方法，例如一个页面中，我们用10个用户压测时发现，页面的整体响应时间就已经超过5秒了，然后这个页面中有10个接口（1-10），其中，接口5 和接口6 响应时间都在3s 以上，而其他接口都在200ms左右，那么很显然接口5和6是需要被进一步分析的！
4.最后把所有测试接口的处理能力和响应时间进行统计，然后发到业务群里，我们也没必要说接口是否不达标，只表达我们已经进行了测试并展示了结果，至于是否需要优化那就产品经理和研发自行判断把。从我的实践经验来看，还是有一定效果的，因为我们并没有单独对哪个接口进行测试，而是选择了页面中的所有接口，页面响应的快慢是用户直接能够感受到的，而影响页面性能的接口研发是需要处理的（这个无锅可甩），大家也可以在自己的项目中尝试一下
我的每一篇文章都希望帮助读者解决实际工作中遇到的问题！如果文章帮到了您，劳烦点赞、收藏、转发！您的鼓励是我不断更新文章最大的动力
标签：圣诞节,性能,接口,研发,巨献,测试,文档,性能指标,页面 From： https://blog.51cto.com/liwen629/8970811