从零开始落地性能测试-下
本篇接上一篇内容，重点介绍性能测试相关工具选型和流程建设，以及如何从零开始落地性能测试的过程。看完本篇，各位测试同学可以参照本篇文章中的内容以及案例，尝试在工作中开展性能测试实践。
三、性能测试工具选型和流程建设
压测工具选型
工具选型一直是很多新手面临的困境，选对了工具，效率加倍；选错了就会痛苦不已。下面是几个适合不同场景和不同阶段测试同学可以直接上手的工具，供参考：
工具名称 | 特性和脚本开发 | 适用场景 | 不足（对于新手） |
|---|---|---|---|
Wrk | 特性：体积小、安装便捷、纯命令行脚本开发：脚本参考官方文档的demo | 适用于新服务研发自测或粗略的性能评估 | 不适合日常压测 |
Locust | 特性：体积小、安装便捷、可视化界面配置脚本开发：简单脚本参考官方文档的demo或其他教程即可开始压测（需要写代码） | 满足日常压测和小团队使用 | 二次开发成本高 |
Jmeter | 特性：体积小、安装便捷、支持拖拽、扩展组件多、可视化界面配置脚本开发：简单脚本参考官方文档的demo或其他教程即可开始压测（大部分场景无需写代码） | 满足团队和企业级日常压测所需 | 企业级使用需要二次开发和包装 |
Gatling | 特性：体积小、安装便捷、多协议支持、扩展性较好脚本开发：简单脚本参考官方文档的demo或其他教程即可开始压测（需要写代码） | 满足团队和企业级日常压测所需 | 企业级使用需要二次开发和包装 |
Loadrunner | 特性：体积巨大、安装繁琐、功能齐全、可视化界面配置脚本开发：简单脚本参考官方文档的demo或其他教程即可开始压测（大部分场景无需写代码） | 满足团队和企业级日常压测所需 | 企业级使用要钱 |
监控分析工具选型
不同视角性能
在性能测试实践过程中，完善的监控可以带来极大的便利。无论是性能指标观察还是问题定位分析和排查，监控都可以辅助技术同学更快更好地解决问题。但有一点需要注意：要根据不同的业务场景、技术架构以及问题表现来关注分析不同的指标，而不是只关注自己看到的。
下面的表格，我列举了在考虑系统性能时，不同角色关注的一些常见的监控指标，仅供参考。
不同视角 | 关注指标 |
|---|---|
性能测试同学 | TPS/ART/99RT/Error% |
研发工程师 | QPS/99RT/YGC/FGC/OOM |
运维工程师 | CPU%/Memory%/Net Work/Disk IO |
数据库工程师 | 锁/索引/慢SQL/命中率 |
上表中所列出的指标，仅代表日常工作和压测时比较关注的通用指标。但在实际的项目和场景中，需要根据具体情况去监控分析更多的指标，切记不要生搬硬套。
理解监控分层
下面是一个常见的微服务架构简易模型：
软件系统为用户提供服务，其背后是由多个软硬件组合支撑的，缺一不可。如上图所示，软件系统的复杂性导致了当它出现性能问题时，影响性能的因素可能是其中任意一个组件。因此在性能测试中，要关注不同层级的指标。
下表是不同层级我们需要关注的一些监控指标：
腾讯云开发者
