互联网应用程序有的一个鲜明特征就是，用户会大量使用，很多用户真实使用，很有成就感，不会像传统企业做的很多软件没人使用，一方面必须保证程序7*24小时正确可用，随时有问题、bug随时要处理，另外一方面程序要保证高性能，性能无论到什么时候都是用户体验关键要素。要保证这两点就需要有完备的测试流程体系。

电商618、双11大促性能测试更是极其重要，根据预估大促时流量，进行压测如果性能能够达到预估值，那么当前容器、机器资源是可以的，如果达不到就要根据压力测试情况进行优化、扩容、降级预案等一系列操作。

非大促平时线上程序测试，一个是单元测试，单元测试一般是程序研发人员自己搞，这个必不可少。一个是业务逻辑测试，因为当下开发迭代速度非常快，几天就会优化上线个版本，需要业务人员与开发从两个角度一起测试业务逻辑，以确保线上逻辑完全正确。新业务上线前要预估流量，然后根据单机能够承受流量*容器、机器数量达到预估流量多一些就可以了。

互联网应用特点就是用户特别多，就会导致会有一些边界情况测试不到，会导致程序bug或者逻辑不是预期，推荐系统上的话就是达不到预期点击、浏览、gmv转化目的。这个就需要线上日志配合查找，但线上日志打得太多又回导致服务性能差，打太多日志反而很难帮助定位问题，因为太多查找有问题那条找不到。

对于上边说的这种情况，我们设计开发了一个日志白名单服务，通过配置管理界面配置用户信息，当用户信息与配置相同时，记录着个用户详细每一步日志，用于快速定位线上问题。对于非白名单用户不记录详细信息。白名单日志平台支持按属性、以及全文检索，能够方便快速定位线上问题。

单机或单个容器能够承受流量是一个很重要数据，因为它*机器数量就是线上最大流量，例如一个服务单机可以处理1w/m请求量，那么十台机器就可以处理10w/m请求量。这个在618、双11大促过程中是一个关键压测流程，必不可少流程。

对于新应用提前是无法进行单机流量直接通过上面这种摘机器压测的，我们设计开发了单机压测工具，专门用于新机器压测以及拆机器线上流量达不到线上服务最大量情况。单机压测工具实现原理是通过多线程，每个线程中循环调用线上微服务节点，不断增加量达到线上服务处理最大值，一般是cpu、内存、网络等使用达到80%，或者jvm中线程数好几千，程序性能下降，从而得出单机流量最大值。

平时时候逻辑测试、以及压力测试大概就是上边情况已经基本包括。大促时单机压力测试与平时没有差异，差异在压力测试就是上下游以及全链路压测。

上下游压测与单机压测是互补关系，上下游压测可以比较准确模拟实际线上情况。上下游压测，一般可以用LoadRunner编写脚本进行多机器压力测试直到达到线上目标为止，一般脚本要有一定大小用户pin包，避免用太少pin线上有缓存达不到压测目的，再有大促时如果机器资源达不到，上下游可以降一下级再压测一轮，确保在现有资源下降级是没有问题的。

上下游压测就需要提前准备，半夜进行压测，提前不准备会导致程序脚本有些问题，数据有写问题耽误压测进行，人员众多浪费大家时间，这是这几次大促都遇到一个问题吧。

再有就是现在很火的全链路压测，由最外层cdn复制流量发压最能准确模拟线上流量情况。以及京东全链路压测军演系统(ForceBot)架构解密详细解读全链路压测，这是个大工程，需要中间件、业务系统、网络等多个部门组共同实现。

写这些文章一个是总结经验教训，进行一下复盘，为以后在做相同事时可以拿出来看，再有就是希望对看到文章朋友，遇到类似问题时有一点帮助吧。