外卖聚合服务性能测试总结

上周对目前开发的外卖聚合服务进行了一周的负载及压力测试，收获了一些经验，也积攒了一些教训，和团队中的小伙伴们一起对一款互联网产品上线前的压力测试有了系统的了解与实践，在这里分享一下心得，也借此感谢小伙伴们跟我一起破了连续加班9天的最长记录，如果“有幸”被领导看到，记得给我们加个鸡腿儿，哈哈。

既然要求加鸡腿儿，那就得先用成果来说话。

这个结果，着实让小伙伴们颇为兴奋了一阵子，不过天天看《甄嬛传》宫心斗的我，必须适时地泼一下冷水：压测改善后性能提升的有多高，就说明你们当初写的代码有多烂。。。

话虽这么说，一个团队中人员经验有高低，习惯有好坏，代码质量难免参差不齐，所以做好压力测试，一来可以提高产品质量，二来可以帮助大家发现开发中的问题，还是非常重要的。所以随着测试技术的发展，许多公司也单独把性能测试独立出来，建立专门的性能测试小组或团队，在实施的过程中建立独立的流程与规范。反思我们一个月前的那次压力测试，在性能需求模糊的情况下，随便找了一个性能测试工具就开始进行性能测试了，在这种情况下得到的性能测试结果自然很难体现系统真实的能力，与系统真实的性能也相距甚远。

这次我们的测试规范了流程，具体如下：

性能需求分析

性能需求分析是整个性能测试工作开展的基础。在这个阶段要确定测试的目标和范围。测试目标应该借助于有行业经验的开发人员、领导的经验，按照客户的要求来定；测试范围则主要分析系统的功能模块进行调研与分析。

作为外卖聚合服务，本项目的

• 测试目标：能够支撑订餐高峰期的并发量。根据百度对“大客户”的定义（单店日订单量大于1000），根据外卖数据分析，订单高峰为中午和晚上的2个小时，即平均每分钟为1000/2/60=8单，若按100家店来计算，平均每秒钟为8*100/60≈14单。

• 测试范围：高频且对并发有要求的接口有两类：输入：美团和饿了么的推单接口；输入：由聚合服务向ERP推单的接口。

性能测试计划

确定性能测试的需求之后，就要制定性能测试计划。测试计划的大概内容包括：

• 项目的简单背景描述：支撑客户外卖业务，保持订单高峰期服务的稳定性，提升服务性能的极限；

• 本次性能测试的需求与目的：参照性能需求分析；

• 测试环境的准备：使用阿里云ECS(1核8G，SLB带宽无限制，使用集团网络，预测会有限流)；

• 测试数据的准备：编写测试脚本

• 人员配置：开发人员、运维人员、需求人员

• 测试时间：一周

测试环境搭建