适用范围
适用于所有需要性能测试的项目。
对性能测试实施过程中非常重要、关键的相关技术进行分析，主要包括：系统环境、测试指标、业务模型、数据量、测试模型、测试类型、脚本（API）、场景、监控、瓶颈分析、调优和性能测试分布式云化压测工具。
系统环境
分析
系统环境分为生产环境、测试环境等。两个环境的方案各有其优缺点，生产环境衡量的精准度较高，参考效果更好，但是需要清理相关的测试数据（同时要保证数据删除的完整性，基础数据的构造参考后续数据量部分）。
或者BI统计的时候过滤，或者更彻底的方案是参考阿里首创的全链路压测方式，生产环境的压测尽量挑选在低峰期进行，避免对生产业务造成影响。
单独的测试环境风险可控，难点在环境的构建上，规模和生产一致的成本也是最高的，所以一般而言有通过等比构建（1/2，1/4，1/8等），甚至是生产环境中部分应用独立部署测试集群，数据库共用的方式。
此外测试环境需要从生产环境中导入脱敏的基础数据，例如至少是最近半年或者1年的，保持其整体的数据关联性，这个对于压测的准确度和参考性也很重要。
风险
测试环境的风险主要体现在跟生产的差异度，测试结果的参考价值会打一定程度的折扣，可以视自身情况选择合理的方式，例如看重入口网络的检验的，可以测试环境和生产环境共享入口。
对测试环境系统平台、中间件、数据库等不熟悉和不了解，也会导致瓶颈不易分析、不易调优。
规范
测试环境搭建
在熟知以上问题的前提下，测试环境搭建应尽量满足如下规范：
测试环境架构与生产环境架构完全相同。
测试环境机型与生产环境机型尽量相同，云化的资源确保是同规格ECS或者容器。
测试环境软件版本与生产环境软件版本完全相同，版本主要包括：操作系统、中间件相关、数据库、应用等。
测试环境参数配置与生产环境完全相同，参数主要包括：操作系统参数、中间件参数、数据库参数、应用参数。
测试环境基础数据量与生产环境基础数据量需在同一个数量级上。
只能减少测试环境机器台数，并且需要同比例缩小，而不能只减少某一层的机器台数。
理想的测试环境配置是生产环境的1/2、1/4。
测试环境调研
测试环境调研，需要调研如下内容：
系统架构：系统如何组成的，每一层功能是做什么的，与生产环境有多大差异，主要为后面进行瓶颈分析服务和生产环境性能评估，这个很重要。
操作系统平台：操作系统是哪种平台，进行工具监控。
中间件：哪种中间件，进行工具监控和瓶颈定位。
数据库：哪种数据库，进行工具监控和瓶颈定位。
应用：启动多少个实例，启动参数是多少，进行问题查找和瓶颈定位。
可以配合APM工具（如ARMS）进行中间件、数据库、应用层面的问题定位。
测试指标
分析
测试指标一般分为业务指标、资源指标、应用指标、前端指标。
业务指标：如并发用户数、TPS（系统每秒处理事务数）、成功率、响应时间。
资源指标：如CPU资源利用率、内存利用率、I/O、内核参数（信号量、打开文件数）等。
应用指标：如空闲线程数、数据库连接数、GC/FULL GC次数、函数耗时等。
前端指标：如页面加载时间、网络时间（DNS、连接时间、传输时间等）。
风险
不同用户对指标类型和期望值是不一样的，需要提前针对不同角色的人员进行指标调研、设定阈值，测试出系统在阈值下的性能，瓶颈定位及调优。若您未提前关注测试指标，将会导致测试结果不是相关人员需要的，结果是无效的。
规范
业务指标
业务响应时间（Response Time）：这个指标所有相关人员都明白其含义，业务部门更需要此指标的具体值，一般情况下，不同系统的业务响应时间期望值是不同的，建议１秒以内，像淘宝系统业务RT基本在几十毫秒以内。
业务处理能力（Transaction Per Second）：具体指标为TPS（Transaction Per Second，即系统每秒处理事务数），这个指标是衡量系统的处理能力的一个非常重要的指标。
TPS可以参照同行业系统和结合具体业务，中小企业TPS值为50~1000笔/秒，银行TPS值为1000~50000笔/秒，淘宝TPS值为30000~300000笔/秒。
成功率：这个指标是衡量系统处于压力下，业务的成功率，一般业界成功率要大于99.6%。
资源指标
一般情况下，系统资源指标也不能超过瓶颈值，例如CPU资源利用率≤75%，内存无SWAP，磁盘和网络I/O不能自动处理。
理想的情况下，当系统压力上不去的时候，资源成为瓶颈（正常情况下，非其他瓶颈情况下导致），这样的话加资源，系统处理能力还会上升的，但是遗憾的是，很多系统性能测试资源都没达到瓶颈的时候，压力就上不去了。
业务模型
分析
系统有很多业务，每种业务逻辑和业务量是不一样的，消耗系统的资源也不一样，因此业务种类、业务占比决定了系统的处理能力，业务模型在性能测试中起着关键性的作用。
以电商场景为例，不同的促销形式和主推的类目决定了不同的容量整体配比，那么精准地将流量落地在PTS上进行压测拿到系统的木桶最短板可以更好的利用机器资源达到业务目的。
风险
业务模型中业务和占比选取不对，跟生产差异非常大，直接导致测试结果没有任何参考价值，并且容易误导对系统处理能力的判断。
有些业务的业务量虽然占比很低，但一旦突变，对系统也是致命的，这些业务在性能测试中也需要关注。
规范
系统中的典型业务如何选取一般情况下遵循的规则是选取业务量高的、经常使用的、有风险的、未来有增长趋势的业务作为系统的典型业务。
已经上线的系统可以通过高峰时段历史业务量和生产问题性能来评估，对于即将上线的系统可以通过调研和单交易资源消耗的结果来评估。
已上线系统
搜集生产上不同高峰时间段的业务种类和业务量，每个时间段的业务种类和业务量是否有很大的差异，如有的话，必须有多个业务模型，差异不大的，可以只用一个业务模型。
搜集生产上高峰时间段资源消耗和资源异常的时间点，从中捕获资源消耗高和异常的原因，可能是由于某种”不起眼”的业务导致。
搜集生产问题，进行分析，如果是由于某种业务导致而且以前性能测试的时候忽略此笔业务，那么这笔业务的风险是非常大的，需要后续性能测试将此业务加入到业务模型中。
未上线系统
通过调研，确定业务种类和业务占比。
通过调研，确定是否在业务促销等活动中，某些业务有突变的可能。
通过测试结果，确定每笔业务的资源消耗，如果某些业务虽然占比低，但资源消耗非常大，那么需要适当的调整此业务占比。
数据量
分析
数据量主要包括基础数据量（或者叫历史数据量、垫底数据量、数据库中已有的数据量）和参数化数据量，数据量在性能测试中起到非常重要的作用。
对于在数据库中只有几条记录和有几亿条记录里面查询信息，那么结果肯定相差非常大的。随着业务量的增长，记录也越来越多，因此使用性能测试环境时，需要保持跟生产上相同级别的数据量。
如果采用在生产环境中插入测试账户的方式，可以一定程度解决环境真实性和基础数据量同量级的问题。阿里全链路压测的方式对于基础数据量的要求和上述类似。
然后，我们在测试的时候需要考虑参数数据量的大小和数据分布的问题。
风险
如果基础数据量跟生产环境的基础数据量不在同一个数量级上，将会导致相关指标例如响应时间比生产上快很多，不真实，甚至导致测试结果没有参考意义。如果参数化数据量过少、未考虑数据分布的情况，将会导致测试结果不真实，甚至测试结果没有参考意义。
生产环境中插入测试账户的方式，需要考虑数据准备的完整性问题，还有清理的逻辑需要完整。全链路压测的方式需要投入较大的改造成本，同时包括后续的持续迭代维护。
规范
基础数据量
如果是测试环境，基础数据量需要跟生产环境基础数据量保持在同一个数据量级上，一般情况下需要考虑未来三年数据量增长趋势，如果增长过快需要在测试环境造非常多的数据。
参数化数据量
参数化数据量尽可能的多，必要的情况下，可以清除缓存或者用写代码的方式提供参数化。
参数化数据分布，如果业务有明显的地域等分布的特征，需要考虑数据分布的情况。
测试模型
分析
测试模型是在业务模型的基础上演变而来的，一般情况测试模型和业务模型是相同的，但是由于某种业务无法模拟或者安全原因，需要去掉此笔业务，重新计算占比得出。
风险
参照上述业务模型风险。
去掉的业务如果有风险，那么需评估此笔业务的风险，风险大的情况下，需采取其他解决方案。
规范
参照上述业务模型规范。
测试类型
分析
测试类型主要分为负载测试、压力测试，其中包括单交易基准测试、负载测试、压力测试、混合交易负载测试（容量测试）、业务突变测试、混合交易稳定性测试、混合交易可靠性测试、批量测试、批量测试对混合交易影响测试等。
每种测试类型针对不同的目的，可以根据生产系统现实情况进行选择。
风险
缺少某种测试类型，将会导致现实生产系统某种场景没有测到，发生风险，例如：系统崩溃、响应时间慢等。
规范
如果时间充足，建议大部分测试类型都需要测试一下，也可以参考以下规范：
单交易基准测试：可选
单交易负载测试：可选，未上线系统建议做负载，看资源消耗
混合交易负载测试（容量测试）：必须
混合交易压力测试：可选
业务突变测试：可选
混合交易稳定性测试：必须
混合交易可靠性测试：可选
批量测试：可选
批量测试对混合交易影响测试：可选
本文内容不用于商业目的，如涉及知识产权问题，请权利人联系51Testing小编(021-64471599-8017)，我们将立即处理
