对于在线应用，尤其是面向互联网海量用户的在线应用，服务出现故障造成的损失越来越大以至于不可容忍。而整体IT系统，包括网络、服务器、操作系统及应用层面则变得越来越复杂，传统的基于配置的健康检查手段往往难以起到充分的作用，因此，全链路压力测试作为一种基于真实环境与实际业务场景的测试手段，通过模拟海量的用户请求，研究整体IT系统对访问压力的响应情况越来越受到重视。另一方面，在容量管理活动中，通常需要检查验证系统业务容量和服务容量，也期望进行局部或全局的压力测试。
但由于运维能力与成熟度的原因，并非所有用户都有能力或决心在生产环境中进行全链路压测，一方面是缺少工具的全面支撑，另一方面是担心对生产系统的影响与污染，从而是退而在准生产或测试环境中进行全局或局部测试。
但这种非生产环境中的测试通常会与生产环境中的测试结论产生较大的偏差。为了减少偏差这种偏差，使测试环境中的结论能够对生产系统的优化产生有意义的指导作用，通常可以采用统计分析的方法建立数学模型，并基于模型给出系统在生产环境中的表现。
经验上，业务容量和服务容量通常与系统资源容量（CAPcpu、Capmem、Capnet）、资源使用率（usage%），以及请求响应时间（Tr）有关，假设我们希望确定在生产环境的特定运行环境下，在特定请求响应时间要求之下，当资源使用率不高于特定阈值时，系统每秒钟能够响应的业务请求或服务请求的数量。在进行统计学实验时，需要注意一下内容。
1. 采用相同的请求数据和加压方式。不论是采用录制的访问流量还是模拟的客户请求，在进行实验时，均应采用相同的请求数据和加压方式，从而使多次的实验结果具有可比性。
2. 由于采用统计分析的方式获得有效的结果可能需要上百次的独立实验数据，建议采用混动工程平台自动化的进行实验并记录实验结果，以减少重复性工作，避免因为人为错误导致实验失败。
3. 对实验结果数据需要进行前期处理，以去除明显偏离的异常数据，在一个特定的实验场景中可进行多次实验并取历次实验结果的平均值作为最终实验结果。
4. 选择与容量直接相关的参考量作为建模数据项，如对于CPU密集型应用，CPU的型号和数量可以直接作为建模数据项，而网络带宽是否对性能产生直接或显著的影响，可以考虑进行相关性分析，如果相关度较低，即可以忽略该数据对容量的影响。
假设我们已经确认了系统容量在CPU型号不变的情况下与CPU数量，CPU利用率相关，则可以设计实验并将数据记录到如下表格中。
对于单机应用可以采用下述表格：
在表格中填写在指定配置下，当CPU利用率达到特定值时的QPS。利用每行数据可以建立特定配置下QPS与CPU负载的关系模型；利用每一列数据，可以建立在特定负载下，QPS与CPU配置数量的关系模型。假设通过上述实验发现在CPU配置数量为2时具有较好性价比，进而可以进行群集化部署的性能实验。
当采用群集方式部署应用时，可以采用下述表格：
同样在表格中填写指定配置下，当CPU利用率达到特定值时的QPS。利用每行数据可以建立特定配置下QPS与CPU负载的关系模型；利用每一列数据，可建立在特定负载下，QPS与应用群集配置的关系模型。假设通过上述实验发现在群集数量小于12时，QPS与应用群集配置规模具有接近线性的关系，而在群集数量进一步增加时，性能增长不明显。
相似的，通过多次的不同配置的实验，可以将链路上不同影响因素与应用整体性能QPS以及对资源容量的使用建立关联关系模型。进而建立整体管理模型。将实际配置与对资源容量占用的容忍能力带人整体关系模型可以得出在特定的部署单元，在特定的资源容忍能力下，应用系统达到的最大业务容量。
通过统计学方法仿真全链路压测具有对生产环境无影响的特点，降低了对生产环境的影响，但需要进行大量的实验与实验数据的处理，在缺少混沌工程平台支持的条件下，通过人工实验往往难以达到预想的效果。
