1. 新增接口并发测试后，会导致接口中的编号重复

       我们在功能测试期间往往很难发现此类缺陷，即并发测试过程中，出现编号重复的情况，有些编号如果是唯一性的，代码层面没有做好控制的话，并发测试期间就会导致编号重复，在生产环境中出现该问题将造成严重的后果。例如沐沐在性能测试过程中就遇到了并发期间订单号重复的情况。所以尽量要在功能测试期间，识别出此类业务场景，通过并发测试的方式，验证是否会出现编号重复的情况。

2. 新增接口并发测试后，各项性能指标正常，但是列表无法加载出数据

      在对新增场景并发测试后，验证各项性能指标都符合性能要求后，沐沐建议登录系统，验证对应查询列表是否可以正常加载出数据，往往很多时候，研发人员不会主动加索引，列表有较大数据量时，就会出现加载缓慢甚至加载不出数据的情况。所以应该及时反馈出此类性能瓶颈，对查询列表进行性能调优（一般都是数据库加索引）。

3. 性能测试执行过程，CPU波动异常

      性能测试执行过程中，我们会监控CPU使用率，沐沐发现对接口进行第一次并发测试时，CPU波动较为异常，但是第二次执行并发时CPU监控图表曲线就会较为稳定，和架构师沟通后，不专业的分析结论为服务器需要预热，突然的高并发就会导致CPU异常波动。因此，沐沐建议在性能测试执行过程中，第一次执行可以先设置短时间并发（例如30s）,CPU较为稳定后，再执行正常时间的并发，这样需要CPU监控截图时，数据会比较正常。其次，完成一个性能测试执行后，不能立马开始执行下一个场景，应该通过htop命令或者top命令观察服务器平均负载（load average）是否还原到正常水平。

4. 查询场景，平均响应时间（RT）较长

      性能测试过程中，较多的性能问题都是查询场景响应时间较长，大数据量时，查询列表甚至会加载不出数据。并发测试期间，可以在数据库开启慢日志监控或者是在线的运维监控平台去定位响应时间较长的服务接口以及对于的慢SQL，例如定位到耗时较长的SQL后，可以Explain分析查询是否添加索引，索引是否生效等。针对于较大数据量的查询场景（并且没有频繁的新增、删除时），添加索引往往也无济于事，需要降低查询时对数据库的访问压力，因此往往会采用redis缓存或者ElasticSearch等方式来提升查询性能。

5. 可视化图表场景，统计类平均响应时间（RT）较长

      性能测试过程中，我们会对可视化类的图表进行性能测试，即为多接口的并发测试。沐沐在以往的测试过程中发现，此类测试场景往往是统计类的接口响应时间较长，可能会出现跨表或者垮库统计的情况，因此作为测试人员需要提前规避此类问题，例如在需求评审阶段，面对可视化图表的各类统计，就可以提前抛出问题，让产品人员和研发人员参与讨论，统计维度是否合理，潜在的性能瓶颈是否可以在设计阶段提前规避。

      The more we share，The more we have.

      希望这篇文章对大家有用...