从零开始构建性能测试技术体系

前几天知识星球一位同学找我咨询过性能测试相关的问题，我在文章《性能测试的实践痛点和解决方法》中分享了性能测试实施过程中常见的一些痛点和解决方案，后台很多同学反馈确实帮他们提供了很多思路。其中有位同学留言问了这样一个问题：有没有比较完整的性能测试技术体系？该如何构建性能测试的技术体系？

在我近十年的软件测试工作生涯中，性能测试、全链路压测以及由其延伸的稳定性保障工作，是我最为擅长的技术领域。从个人的实践经验来说，我认为性能测试技术体系的构建，大致要分为四个阶段，分别是：日常化、自动化、工具化和平台化。

日常化

很多做性能测试的同学，在工作中面临的最大问题是性能测试无法成为日常测试工作的一部分，即性能测试作为质量保障的一种手段，却无法融入正常的需求版本迭代流程中。最常见的例子就是一句话需求，比如：这几个接口压测一下，出一份报告；或者线上出了性能问题，才火急火燎的找测试同学，对系统进行压测，再排查定位问题。

要构建性能测试的技术体系，最基础也是最核心的部分，就是将性能测试融入软件研发交付流程中，即但凡涉及到系统迭代或者变更，都需要经过评估甚至性能测试，才能发布上线。否则性能测试只会成为不重要的救火队员角色，疲于奔命却没时间去沉淀，更不要说构建测试体系了。

自动化

在传统的性能测试方法中，每次性能测试(需求迭代或项目维度)都需要重新评估需求，然后准备对应的测试数据和压测脚本，在我看来除了增加多余的工作量，实际的作用和价值并不明显。

正常情况下，大部分公司的业务和系统不会有高频次大范围的变更，即比较核心的业务链路和场景相对是稳定的。在这种情况下，对核心业务场景(比如 P0+P1 场景)进行性能测试全量覆盖，是一种比较可行的方式。通过自动化的执行方式，不仅能提高验证效率，还可以大大缩短信息反馈耗时，即快速得到迭代后系统性能变化的结果，做到快速评估和反馈，这样也有助于帮助研发同学快速修复，提高线上交付效率。

工具化

性能测试体系的构建，除了压测工具之外，还需要丰富和完善其他方面的工具。比如：

• 造数工具：性能测试最耗时的部分应该是准备阶段，其中最麻烦的应该是准备测试数据并验证其可用性，因此提升造数据的效率是工具化很重要的一部分。常见的造数方法有线上数据导出脱敏、调用 API 生成、录制回放以及通过生成器模式进行封装。

• 故障案例库：其实导致出现性能问题的根因总结下来就那么几种，只不过实际表现为多种方式，比较好的方式是对日常工作中发现的性能问题和故障进行汇总分析，通过 FMECA 的方式搭建故障案例库，进而形成研发和测试规范。

• 监控分析工具：影响性能的因素是多种多样的，除了常见的基础资源监控，还应该考虑丰富链路追踪、堆栈分析、内存分析、线程分析以及缓存和数据库监控等各个方面的工具建设。

平台化

当性能测试融入到日常的软件研发迭代流程中，并且通过自动化的方式覆盖了大部分场景后，接下来就需要考虑将流程+执行+工具+案例融合为平台，将性能测试过程管控起来，通过平台对外提供标准完善的功能，这个时候性能测试就可以视作是一种服务，为整个技术团队提供服务稳定性保障和技术效率的服务。

当然，落地平台化有几点需要考虑，比如团队规模大小、需求迭代频次、业务和系统复杂性以及技术团队本身的基础技术设施的建设程度。如果团队规模较小，且技术团队的基础设施建设一般，平台化就不用考虑了。

构建性能测试技术体系的最大制约，就是无法直观体现自己的价值，且建设过程耗时较久，对技术的深度和广度要求也比较高。个人认为，如果要从零开始构建性能测试技术体系，单纯的技术能力是一方面，团队的执行力和想办法让测试结果获得认同，也是很关键的因素。