测试性能场景

性能测试二三事

性能测试，于我们而言，是老生常谈的话题。曾经一提到这类测试，大伙首先想的是用什么工具去做？一切都围绕工具做文...

性能测试，于我们而言，是老生常谈的话题。曾经一提到这类测试，大伙首先想的是用什么工具去做？一切都围绕工具做文章。

这个惯性误区导致我们在很多时候，虽然执行了性能测试、提交了性能测试报告，但开展得不深入，于问题定位、性能调优等没有显著帮助，使得伙计们依然被各种线上性能问题纠缠。

怎么破呢？

今年一季度，我们借着16夏服务切版和MONGO升级，实施了一次真正的性能测试撞线！

测试小伙伴们从中体会到：性能测试不该是建立在某一个工具上的应用，而是一个独立的测试体系。1.有章可循

这次，我们经过多方参考服务产品的性能测试案例、深入性能测试精髓，再结合自己的产品特性，从无到有，规划了性能测试的工作流程（此处有掌声）！！

一改以往仅仅围绕工具、缺乏被测对象分析的性能测试。

同时，我们也认识到，性能测试结果的分析不应只停留在结果，应该更进一步，深入分析、提出改善，推进系统不断完善、优化。

当流程已定义好，接下来如何开展呢？

这里我们不谈工具，只谈方法，小编从上图中选取了两个非常重要的环节，着重谈谈如何做“性能测试场景设计”和“测试结果分析”。

2.场景设计

曾经，我们的场景设计更多是围绕着“并发量”做各种考虑，对用户实际数据量及组合应用场景缺乏调研，使得性能测试结果欠缺了实际的指导意义。

本次测试，我们的第一步，就是对历史运维数据和用户行为进行了深入分析，并对系统数据流转和接口实现机制做了深刻了解。

前者是通过运维调查和系统日志分析来得到参考值，后者则通过解读接口文档、走查代码和日志信息去获取。这些都将作为并发用户数据设计以及各种场景设计的支撑。

有了数据支撑，我们才能从几个维度设计有针对性的场景。

下面，以本次“行编申请数据”为例，解读如何根据用户现实场景做性能测试的场景设计：

根据几个维度进行了场景设计，其中并发量、典型的组合场景都是由运维调查得到的，历史最大数据量则是从系统日志得到的，并发量和数据量的组合场景的设计，基本是按照最大并发用户数量的百分比来设计，直到达到最大并发用户数量。

3.测试结果分析

理论上，分析性能测试结果，我们应该很容易知道系统的性能情况。但，做性能测试，并不是简单的知道性能情况就好。

深入了解清楚系统的实现情况、结合实测结果，给出建议及改善点，更是性能测试的意义所在。

当测试结果给出了很多数据，我们怎么去分析系统瓶颈在哪里呢？一般是按照这样的思路，

第一步，看业务指标：响应时间、错误率是否满足目标。如果其中有一个有异常，要先排除性能测试脚本本身和外围依赖系统是否有瓶颈，例如是否中间件配置的连接池的参数设置不合理，造成的瓶颈；

第二步，再去关注网络、数据库的性能和连接数，例如网络负载均衡、操作系统和数据库设置不合理引起的性能问题；如果还是正常，最后才是关注系统本身的指标，例如程序设计不合理（串行处理、请求的处理线程不够），造成系统在大量用户方位时性能低下而造成的瓶颈。

由此可见，性能测试问题的原因及其定位比较复杂，性能测试所需要做的就是根据各种情况因素综合考虑，抽丝剥茧，一步一步深入，最后协助开发人员、运维人员一起定位并解决性能瓶颈。

以本次“在线检查”性能测试为例，解析如何做测试结果分析：

测试结果分析：现有平台，可支持100个客户端的并发在线检查和100个客户端的并发检查；现有平台，数据量1000以上并发100是，部分客户端检查或提交失败。对该情况，首先排查了测试脚本、系统CPU、内存使用趋势，并未发现异常情况，而后检查网络和数据库使用情况发现，fos服务在处理大量耗时检查任务时，数据库处理检查时间长，导致前端提交检查HTTP请求等待超时。
下一步建议：后续进行fos服务对HTTP请求的响应以及数据库处理能力的测试，以获取fos所支持检查、批处理，内部处理能力以及数据库并发处理能力； fos服务增加对耗时任务的预警功能，减少客户端请求的等待、超时失败的现象。

瞧，这次性能测试不但推进了问题挖掘和系统改善、找到了更合理的进程和线程设置，还帮助运维找到了相对合适的mongo设置。赞一个。

再从系统实际线上反馈来看，作业季已经运作了一个月，仅发生了一次服务卡顿，原因是一个小概率场景，即同步访问历史库和作业库的场景我们的设计和测试都没有考虑到，导致流出到了生产。

而之前作业季容易出现的常规作业并发卡顿已经不再出现、本次系统重大升级可能存在的不安定隐患也一次也没有发生，吼吼吼，足以说明我们的切板、升级和质量验证工作都是很成功滴！小伙伴的辛苦没有白费。

我们可以把这次性能测试当作一个成功的开始，日后还得通过不断完善场景设计，确保覆盖度，有技术和能力保证系统稳定上线。

同时，仅作验证性测试还远不够，软件性能测试应该是执行（且监控）－>分析—>调优不断进行的过程，即监控是为分析提供更多的参考数据，分析是为了进行调优，调优是解决当前系统存在的性能瓶颈，为用户提供更愉悦的体验。

做到让用户“愉悦”还有很长的路要走，后面也希望在这个专题看到更多小伙伴的畅所欲言!