流量测试 + 传统性能测试，帮你高效保证系统质量

首先，这是一篇没有图片的文章。。。

相信我们进行性能测试的时候，都遇到过这样的问题：

1.你的性能测试方案是什么样的？

2.我们现在系统整体的性能状况如何

3.为什么你会设计这样的方案（如并发、迭代、思考时间、各种指标）

4. 你设计的这个方案假使过了，能保证生产不能出问题么？

很难回答，是吧。 因为你很难知道你这个方案是否真的能符合实际情况，就是满足了生产环境实际的情况。

如果我们真的能通过预测来满足每一次性能测试，历史上也就不会出现那么多著名的因为性能无法承载而宕机的事情了。

基于问题，我们发现，这个其实并不一定是我们设计的方案不对，而是我们就很难真实预测生产环境实际的情况，那么我们应该怎么做。

目前最主流的性能测试（针对系统承载）无非就两种：

1.基于目标分析、场景分析后的传统性能测试

2.基于流量回放的全链路性能测试

那么这2种性能测试具体适合什么场景？我们应该怎么将他们2个结合以便取得更好的效果，从而真正保证系统的性能和稳定性。我们可以一起来看看。

基于目标分析、场景分析后的传统性能测试

适合场景：

1.从0 - 1的构建项目

2.用户量少，流量回放所收集到的用户请求量少，涉及系统面广度不足

3.部分项目类型有一段时间内承载量提升巨大的可能，如电商，在一段时间内进行大促，此时流量就和之前经验已经不一样

详细分析 ：

假定我们现在做的是新项目，还没有上线，我们怎么做到基于流量回放的性能测试呢？所以，此时我们就需要用传统的性能测试手段，从需求分析、目标确定、方案确定、用例编写、测试执行、性能问题、性能调优、测试执行。经历一整套的性能测试流程，完整后上线。

这里面如果有人问，说：你们这个还是按照设想来设计的，怎么具体保证？没错啊，谁知道未来能发生的事情，所以大部分的这种阶段下的性能测试，我个人都会将目标设定的稍微高出原本的既定目标。高出太多也不行，承载不住，经常失败，耽误时间。

那么我们说说如何有效的获取测试数据， 不管是功能还是性能，或者其他性能测试，获取测试数据的大致方式无外乎3种 ：

1.项目已经上线，可以基于实际情况分析获取准确的数据

2.项目未上线，但是有可以对标的参照，获取对标物的数据

3.项目未上线，而且也无可参考，那么就只能基于需求、基于用户自己构造数据了

所以，在上述这样的情况下，我们就适合使用传统的性能测试来保证系统上线一段时间断内的稳定性。

发布后，尽快完成流量回放及生产环境监控的建立，便于获取更加准确的用户数据。

基于流量回放的全链路性能测试

适合场景：

1.项目已经发布

2.用户量已经成规模，且用户类型已经成型（这部分指的是，如果我们的系统针对不同的类型有不同的场景提供，那么单一类型量的增加，可能造成无法全面覆盖）

3.已经落地流量回放并且是一定时间以上的流量收集（流量收集的时间长短，将极大的影响覆盖面的广度是否足够）

详细分析 ：

假定我们的项目已经上线运作一段时间，且用户量已经取得不错的成效，那么面对未来可能的增长，或者成倍数的层长，此时最简单有效，也是最节省人力的就是流量回放了。

获取一段时间内的生产环境的实际流量，在测试环境中2倍，3倍甚至5倍的进行扩展，来观察系统是否足以支撑，这样的性能测试，是最“真实”的。

当然，这里面我们要注意一个问题，就是某一段时间内的流量回放代表的是当时的情况，以我们上文中说的电商大促，此时的流量回放就会不足以应付情况，那么还是要进行适当的传统性能测试来保证整体质量。

其次，流量回放本身带给我们的不仅仅是性能的测试，当然还有功能上的，甚至流量回放 + 传统接口测试，也共同保证了接口层面的整体质量，非常有效。

最后，再补充下性能测试的几点注意事项：

1.性能调优及后续的性能测试，要保证测试环境、数据和之前性能测试相同，避免因这个原因导致出现不同的情况，从而影响分析的有效性

2.传统性能测试和流量回放的性能测试，都应该进行数据的妥善保管，从而有效的重复利用

3.不管是哪种性能测试手段，性能测试人员都应该加强性能测试的整体能力。包括：问题定位、性能分析、场景分析、数据分析等等

另外，由于我们整体讲解的是针对系统级别或者Server级别的性能测试，前端的性能测试（Web、App）的同样重要，这个本文中并未涉及到具体的开展思路

后续我们会针对此文，首先给大家分享下，传统性能测试下的数据收集，更加适用于我们项目已经上线，但未有效建立起流量回放（这并不是测试一个部门的事情）下时，我们如何做