性能测试的实践痛点和解决方法

昨天有同学找我咨询了一个性能测试相关的问题，他说：

他们公司的性能测试实践目前基本成为了形式主义，除了版本迭代时候的单系统单接口压测，没有其他亮点，领导也不重视。想做一些异常测试和高可用测试，体现自己的价值，但又不知道从何入手，该怎么解决当下不被重视的现状？

其实很多测试同学可能都会面临这样的问题，辛辛苦苦加班干活儿，结果绩效一般般，升职加薪也没啥机会，久而久之工作状态下降，搞得自己心气儿没了。

上面的案例中，我个人觉得问题其实主要出在了两方面：没找准目标+没做出亮点。性能测试到底要解决什么问题，如何体现性能测试的价值，目标和价值的关系是什么。只要搞清了这三点，那问题迎刃而解。

但要搞清楚这三点，最终还是要回归到实际的性能测试场景中，只有解决了实践过程的痛点，那目标和价值的关系就很容易捋清了。

性能测试面临的痛点

结合个人的实践经验来说，在性能测试实践中，最常见也是最大的痛点有如下四点：

性能目标不合理：最典型的不合理的地方就是一句话需求。领导或者开发说系统要上线了，你把这个系统/接口压一下，明天给我报告，然后就没了。为什么要压测，要解决什么问题(请求慢还是客户要求)，预期的性能指标是多少，要啥没啥。这其实就是不同岗位对于同一件事的不同认知带来的差异。

性能测试组织难：性能测试涉及到服务部署，硬件资源，参数配置，数据准备等各项工作，限于实际的团队组织架构，这些事往往需要运维、研发、DBA 来配合执行。但在实际场景中，由于团队墙的天然因素，加上各角色的 OKR/KPI 导致的价值目标不一样，基本都是由测试人员来推动发起这件事。目标都不统一，又何谈高效的落地实践呢。

监控系统不完善：现在大多数系统都是分布式微服务架构，系统的请求调用链及其复杂和亢长，请求链路中任何一个环节出现问题都可能导致测试的结果不达预期，这就要求性能测试过程中需要有完善的监控体系来支撑性能测试的快速实践。但在很多企业中，对系统的监控能力往往局限在局部，或者生产环境有监控，测试环境基本裸奔。缺少系统性的监控，对问题不具备持续追踪的能力，这也是性能测试面临的一大痛点。

性能结果不真实：这也是一个很典型的问题，领导问你生产环境要不要扩容升配，扩多少，性能测试同学往往被问住。大家容易忽略的一点是，测试环境的结果只代表当前环境，无法直接换算到生产环境，而且很多公司连单独的性能测试环境都没有，又何谈自己的测试结果能对线上部署有直接的辅导和参考作用呢。

四大痛点的解决方法

要解决上述的性能测试实践的四大痛点，可以从如下几个方面来实施。

工具问题：压测工具是否简单易用可扩展，能否支撑高并发？监控工具是否完善，链路追踪工具是否快速准确，问题分析工具是否能辅助技术人员快速发现问题？性能测试环境是否独立，单机配置是否和生产等配等比缩容，基础数据量级是否满足实际的业务场景？这些都是性能测试开展的基础前置条件，如果这些问题能解决，那测试实施过程就没那么难了。

策略问题：压测模拟的并发数是否和线上一致？压测的场景是否和需求要求的一致？压测的参数化数据是否和实际的用户请求模型保持一致？压测执行过程中，是否考虑到了数据的铺底和缓存预热？很多同学做性能测试只会模拟并发压测，却忽略了这些会直接影响实际测试结果的策略和场景。

沟通问题：压测活动的组织由测试同学来推动这个没问题，但关键是和其他团队的技术同学沟通时，是否将双方的利益和目标达成了一致？举个例子：线上服务挂了，运维最紧张；线上故障复盘，开发也要承担责任；而性能测试就是要提前发现存在的可能引起线上故障的性能问题。沟通时以共同的目标驱动，以实际的利益沟通，往往更高效也更容易达成合作。

管理问题：这其实就是上面我提到的目标和认知问题。在开展压测之前一定要搞清楚本次压测的目的是什么，要解决什么问题，预期指标是多少，这些才是成功开展性能测试的前提。

业务和技术相辅相成

作为技术同学，一定要明白的一点是：技术并产生不直接利益，但系统出现问题则大多是先问责技术团队。业务目标的实现会为公司带来直接的利益，技术的存在价值就是支撑业务目标的高效达成。

比如双十一大促，在峰值流量冲击下，系统能稳定运行，让用户正常的下单付款，这样业务营收目标达成了，技术自然可以讲自己的产出和价值。再比如近两年很多公司都在搞降本增效，线上流量不变的前提下，通过性能优化提高系统性能，就可以对线上服务进行降配缩容。成本降低，变相的等于业务利润提高，这也是技术的价值。

技术团队一定要对业务和技术的关系有统一的认知，勇于承担业务运营的支撑者和辅助者的角色，从实际的业务和需求痛点出发，解决问题，最终才能体现自己的价值。