最近两周对公司的产品做了一次全面的系统压测以及瓶颈分析。今天抽空做一下总结和回顾。
干净的测试环境。
一个干净的测试才能为后续做变量控做好基础准备工作，如果环境不够干净很可能出现数据并非预期或者有各种突变点。
测试目标要做好讨论以及多方确认。
本次测试任务主要是要测试哪个接口、哪个模块、哪个功能点需要提前明确，并且和其他的相关部门做好确认。如果没有明确的测试目标胡乱测试一番是没有任何意义的。
测试系统指标监控
做好测试环境 cpu、mem、net、disk、load、qps、latency等指标的监控。确保监控进程在空载的时候对整个系统的 cpu、mem 、net等资源占用做到最低。一般认为监控进程应该是对整个系统无感或者是占用1% cpu资源以下为佳。
测试方法制定
测试数据需要尽量采用真实数据为佳，亦或者模拟一批数据需要尽量贴近真实数据，包括数据格式、数据范围、数据量等方面。
一般需要制定一个测试矩阵方可做出一份详尽的测试报告。如下图，要有横向与纵向的对比。
集群1 集群2 集群3 集群4 集群5 参数1 参数2 参数3 参数4 测试流程制定
测试流程需要做到模拟真实业务流程，如无法模拟器需要按照最佳负载情况做长时间测试、多组测试数据平均为准。
异常报警
由于整个测试流程可能会持续数小时到数天不等，后台跑的脚本需要主动对测试数据结果正确性做一定的校验。如发现数据有异常需要尽快发送报警给对应的测试人员，以免出现测试数据不正确等问题。
测试工具选择
一般对于http 接口类测试建议选择 wrk 等高性能测试工具。
对于数据库测试建议选择官方提供的 benchmark 等，如官方没有提供可根据业务特点来编写符合业务场景测试用例来做测试。
测试脚本编写
测试脚本编写主要注重逻辑控制，变量检查，job 调度，压力控制这几点。满足以上几点的脚本即可满足要求。
测试的过程需要做什么
观察系统各项指标
观察cpu、net 等是否会随着不同的测试任务出现明显的分界点，如没有出现则可能是测试任务选择有误，需要停止测试重新编写测试任务。
测试后的分析，改进以及回测
火焰图分析
这个是作者目前遇到最好的性能瓶颈分析工具。非侵入式做数据分析对整体性能瓶颈分析非常友好，缺点是数据统计是基于采样式的，对于不常命中分支不太友好。可使用跟踪点来做性能分析。
局部小功能测试
如发现模块功能有可能出现性能瓶颈，需要将改功能独立做单独的性能测试。去除其他影响因子会更容易发现性能瓶颈点。
测试报告
测试完成之后必须要做一份或简要或详细的测试报告，做到雁过留痕。
测试中一些问题的QA
在测试中发现有一些数据点有明显的异常，比如qps忽然飙高，是什么问题？
qps飙高的时候是否有非正常返回，比如http中是否有404 400 5xx 等字段。
当时的压测机或者被压机是否有其他的进程在运行，导致资源占用。
数据库是否在执行扩容、缩容、合并等行为
测试中如果发现偶尔有超时、异常等情况出现该怎么办？
这种情况常见于数据接口压力过大，建议调整参数降低压力。保证不出现错误。
测试中发现qps并没有出现线性增长，但是压测机与被压机均没有出现cpu 负载变满等情况改如何排查？
这时候需要看一下系统的其他资源是否成为瓶颈，容易成为瓶颈的是disk、net等。
是否是接口写了大量的日志导致了写日志占用大量的时间。
总结
测试是一个辛苦的、重复性高的工作，需要有耐心才能把这件事做好。
测试目标在整个过程要牢记，大多数工程师会在测试的过程中偏离目标陷入到一个小点去做深入挖掘中，反而不利于整个测试工作进展。
测试代码编写也要尤其注重异常分支的处理，防止在错误的测试接口、逻辑上花费太多的时间。
能自动化跑的功能、逻辑尽量自动化跑。方便后续做二次测试等工作。参考低一点。
参考
