这是一次比较仓促的性能测试，由于性能测试人员不足，紧急调动我们业务测试进行性能测试。当然了，这也是一次宝贵的经验。下面来详细说一下这

【资料图】

这是一次比较仓促的性能测试，由于性能测试人员不足，紧急调动我们业务测试进行性能测试。当然了，这也是一次宝贵的经验。下面来详细说一下这次性能测试的过程。

获取信息

这次性能测试的业务不属于我们日常测试的范围，是业务组需要在我们的平台上发布。我们对这些接口并不熟悉，因此，需要获取相关的文档来熟悉项目以及我们要压测的接口。主要包括：环境信息、接口文档、相关的业务流程以及一份以前的性能测试报告。

调试接口

我们的性能测试工具统一用Jmeter。调试接口分为两步：一是保证接口调通，二是进行业务串联。根据接口文档以及业务流程进行接口组合。这一步主要进行接口的调试，主要包括：接口入参的类型是否正确；入参与输出是否一致。

业务串联主要是对接口进行业务层面的删减、参数化、试跑。业务串联主要分为三类接口：注册、查询以及操作类。这期间遇到了一个问题：有一个注册接口需要用到身份证，一直注册就需要源源不断的身份证。这时候，我们想到了两个解决方案。一个是直接写在Jmeter的beanshell里面；一个是我们有身份证生成工具，可以生成后放在Execl或者txt文件里面读取。我们用beanshell完成封装，并且可以顺利获取。经过讨论，后一种的生成是一位大佬写的，暂时用后一种。

进行测试

我们根据现场反馈的数据进行换算。算出我们需要压测的最大并发数以及最小并发数。这中间有一个插曲，就是之前说的注册用户数。我们是按半小时跑，但是注册用户按照半小时跑，总用户数将远远超过现场最大用户数，在生产环境这样搞，可能会造成不必要的麻烦。经过讨论，我们改为轮次，注册接口每个并发跑30轮。

注册类接口改为了按轮次执行，但是还有其他查询接口，只能按时间来跑。这时候问题又出现了：注册接口产生的数据，查询和执行接口是要用到的。这时候的解决方案是把注册生成的数据提取出来，放在txt里面，跑查询和执行接口的时候，再读取txt。

在进行现场压测的时候，还有一个问题，就是生成的txt文件，身份证号生成过多时会大量重复。就临时换个我们自己写的beanshell，虽然也有重复，但是不超过0.1%，就一直用着跑了。

期间脚本没有再出现什么问题，一直到压测结束。

收获

这次压测，是一次理论知识实战的宝贵经验。主要感触有两点：一是要有足够的准备。这次好的一点就是，调试接口初期，业务开发能进行很好的配合，对接口问题进行积极处理，需要的文档、环境也能及时提供；二是在问题出来时，要有足够的预案：在身份证号生成这一个环节，如果没有足够的预案，好不容易申请的压测机会就要流逝，阻碍测试的正常进行。

这次的分享到这里就结束了，如果对于我们遇到的问题有更好的解决办法或者建议，可以私信或者留言哦！

END