一个典型的性能测试案例

有同学问了我这样几个问题：

需求场景：一个新系统迁入需要做压测，该系统会以灰度的方式并入正式系统，且迁入前后场景占比存在一定变化，对库存的缓存数据也存在一定影响。
问题一：针对迁入新系统场景，如何设计性能测试方案？
问题二：在选取压测场景时，只占很小占比的场景是否需要压测？
这是一个典型的性能测试案例，且几个问题都切中了性能测试的核心，即场景选择和数据准备。基于上述信息，我们对这个案例展开分析，看看如何制定性能测试方案和选取压测场景。

我们先对该案例进行简单的需求分析。

一般来说，新系统并入都会对原有系统造成影响，毕竟多了全新的调用方，且其性能和稳定性未经过实际的业务考验。

业内较为常见的方式，都是以灰度(通过网关调度，先放10%流量走新系统的逻辑，观察一段时间没问题，再逐步放大百分比，直至完全迁入)的方式进行平滑切入。

这样做的好处是即使出现问题，也能及时切回来，不影响线上其他系统运行。

如上述案例所描述，我们在需求分析时，需要重点关注这几点：1-迁入前后的性能和稳定性变化；2-压测场景的选择要符合真实业务场景；3-压测和基准数据需要匹配对应的场景。

接下来，针对上面三个关注点，展开进一步阐述。

问题一：如何设计性能测试方案？

新系统会对原有系统造成影响，业内通常选择灰度的方式接入。灰度的百分比，一般是按照1%-10%-20%-50%-100%梯度递增，直至新系统完全接入。

新系统在接入前必须保证自己的功能正确性、系统健壮性和异常容错性，因此新系统在上线交付前必须完成完整的几轮测试，其中就包括性能测试。

因此，我们在制定性能测试方案时，可以将本次性能测试分为三个阶段：

迁入前：老系统的基准性能测试和线上容量测试、新系统的基准性能测试。
迁入中：观察不同灰度下，核心业务场景和主流程的性能变化是否符合预期。
迁入后：接入后，对全场景(特别是涉及新系统调用)进行性能基准和容量测试。
这里需要重点关注两点：1-迁入中如果系统负载超过阈值，需要及时扩容(或者关闭灰度入口)；2-线下压测环境做新系统迁入灰度情况下的压测，一般选择三个梯度(10%/50%/100%)。

问题二：如何选取迁入后的压测场景？

如何选择压测场景，是很多新手一直困惑的问题。其实除了很特殊的情况，否则一般情况下，你只需要遵循如下几个原则去选择压测场景即可。

核心场景：与本次压测需求强相关的业务场景。
主流程场景：业务主流程场景，要考虑新改动对它的影响。
占比较大的场景：比如电商下单业务，创建订单/订单支付/订单列表/订单详情占比很大(低于1-5%的一般不选)。
正向+数据实时一致性场景：正反向(创建/取消订单)，数据实时一致性就是数据要及时落库，参与逻辑和状态校验。
常规的性能测试中，选择压测场景这一问题，同学们完全可以参照上述四个原则。

扩展问题：如何准备压测涉及到的数据？

数据准备是性能测试最核心的事项之一，如果数据不符合真实业务场景，那性能测试的结果就完全不具备参考价值。

以上述案例为例，新系统迁入后，由于业务场景和链路有所变化，势必会影响数据的分布(缓存/数据库)。很多同学在这种情况下容易犯的错误就是沿用原来的缓存数据，或者直接将新数据写入缓存，追究便捷省事。

正确的做法是，压测时先按照新流程走一遍数据落库动作(新系统完全接入后同样要走这个逻辑)，然后按照选取的压测场景开展性能测试。

同样，在新系统接入线上开启灰度前，需要将基准数据同步到缓存中(如用户登录态/商品库存)，避免新的逻辑对系统造成短期压力，触发监控告警。

如上就是我对这个性能测试案例的分析和建议，供大家参考。