本文从技术角度制定性能测试实施过程中关键技术规范。这些规范可以帮助PTS的用户更好地从技术上来规避系统上线后的风险、评估线上系统的真实能力、根据业务模型摸底线上能力以提前应对。
适用范围
适用于所有需要性能测试的项目。 对性能测试实施过程中非常重要、关键的相关技术进行分析，主要包括：系统环境、测试指标、业务模型、数据量、测试模型、测试类型、脚本（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）：一般情况下，不同系统的业务响应时间期望值是不同的，建议在1秒以内。像淘宝系统业务RT基本在几十毫秒以内。
TPS（Transactions Per Second，即系统每秒处理事务数）：TPS可以参照同行业系统和结合具体业务，中小企业TPS值为50~1000笔/秒，银行TPS值为1000~50000笔/秒，淘宝TPS值为30000~300000笔/秒。
成功率：这个指标是衡量系统处于压力下，业务的成功率，一般业界成功率要大于99.6%。
资源指标
一般情况下，系统资源指标也不能超过瓶颈值，例如CPU资源利用率≤75%，内存无SWAP。理想的情况下，当系统压力上不去的时候，资源成为瓶颈（正常情况下，非其他瓶颈情况下导致），这样的话加资源，系统处理能力还会上升的，但是大多情况，很多系统性能测试资源都没达到瓶颈的时候，压力就上不去了。
业务模型
分析
系统有很多业务，每种业务逻辑和业务量是不一样的，消耗系统的资源也不一样，因此业务种类、业务占比决定了系统的处理能力，业务模型在性能测试中起着关键性的作用。以电商场景为例，不同的促销形式和主推的类目决定了不同的容量整体配比，那么精准地将流量落地在PTS上进行压测拿到系统的木桶最短板可以更好的利用机器资源达到业务目的。
风险
业务模型中业务和占比选取不对，跟生产差异较大的情况下，会直接导致测试结果没有任何参考价值，并且容易误导对系统处理能力的判断。 有些业务的业务量虽然占比很低，但一旦突变，对系统也是致命的，这些业务在性能测试中也需要关注。
规范
一般情况下选取业务量高的、经常使用的、有风险的、未来有增长趋势的业务作为系统的典型业务。已经上线的系统可以通过高峰时段历史业务量和生产环境性能来评估，对于即将上线的系统可以通过调研和单交易资源消耗的结果来评估。
已上线系统
搜集生产上不同高峰时间段的业务种类和业务量，判断每个时间段的业务种类和业务量是否有很大的差异，如有较大差异，必须有多个业务模型，对于差异不大的，可以只用一个业务模型。
搜集生产上高峰时间段资源消耗和资源异常的时间点，从中捕获资源消耗高和异常的原因。
搜集生产问题，进行分析，如果是由于某种业务导致并且以往性能测试时忽略了此业务，那么这项业务的风险是非常大的，需要在后续的性能测试中将此业务加入到业务模型中。
未上线系统
通过调研，确定业务种类和业务占比。
通过调研，确定是否在业务促销等活动中，某些业务有突变的可能。
通过测试结果，确定每笔业务的资源消耗，如果某些业务虽然占比低，但资源消耗非常大，那么需要适当调整此业务的占比。
数据量
分析
数据量主要包括基础数据量（或者叫历史数据量、垫底数据量、数据库中已有的数据量）和参数化数据量，数据量在性能测试中起到非常重要的作用。 对于在数据库中只有几条记录和有几亿条记录里面查询信息，那么结果肯定相差非常大的。随着业务量的增长，记录也越来越多，因此使用性能测试环境时，需要保持跟生产上相同级别的数据量。如果采用在生产环境中插入测试账户的方式，可以一定程度解决环境真实性和基础数据量同量级的问题。 阿里全链路压测的方式对于基础数据量的要求和上述类似。 然后，我们还需要在测试时考虑参数数据量的大小和数据分布的问题。
风险
如果基础数据量跟生产环境的基础数据量不在同一个数量级上，将会导致相关指标不真实，例如响应时间比生产上快很多，不真实，甚至导致测试结果没有参考意义。 如果参数化数据量过少、未考虑数据分布的情况，将会导致测试结果不真实，没有参考意义。 生产环境中插入测试账户的方式，需要考虑数据准备的完整性问题，同时清理的逻辑需要完整。 全链路压测的方式需要投入较大的改造成本，同时包括后续的持续迭代维护。
规范
基础数据量
如果是测试环境，基础数据量需要跟生产环境基础数据量保持在同一个数据量级上，一般情况下需要考虑未来三年数据量增长趋势，如果增长过快需要在测试环境构造较多的数据。
参数化数据量
参数化数据量尽可能的多，必要的情况下，可以清除缓存或者用写代码的方式提供参数化。
参数化数据分布，如果业务有明显的地域等分布的特征，需要考虑数据分布的情况。
测试模型
分析
测试模型是在业务模型的基础上演变而来的，一般情况测试模型和业务模型是相同的，但是由于某种业务无法模拟或者安全原因，需要去掉此业务，重新计算占比得出。
风险
参照上文业务模型风险。
去掉的业务如果有风险，那么需评估此笔业务的风险，风险大的情况下，需采取其他解决方案。
规范
参照上文业务模型规范。
测试类型
分析
测试类型主要分为负载测试、压力测试，其中包括单交易基准测试、负载测试、压力测试、混合交易负载测试（容量测试）、业务突变测试、混合交易稳定性测试、混合交易可靠性测试、批量测试、批量测试对混合交易影响测试等。 每种测试类型针对不同的目的，可以根据生产系统现实情况进行选择。
风险
缺少某种测试类型，将会导致现实生产系统某种场景没有测到，发生风险，例如：系统崩溃、响应时间慢等。
规范
如果时间充足，建议大部分测试类型都需要测试一下，也可以参考以下规范：
单交易基准测试：可选
单交易负载测试：可选，未上线系统建议做负载，看资源消耗
混合交易负载测试（容量测试）：必须
混合交易压力测试：可选
业务突变测试：可选
混合交易稳定性测试：必须
混合交易可靠性测试：可选
批量测试：可选
批量测试对混合交易影响测试：可选
业务会话
场景
分析
（压测）场景是若干个基于HTTP/HTTPS的URL/API的组合，用于模拟现实生产环境中业务场景，包括施压模式、压力递增方式、运行时间等。 场景模拟需要跟生产上场景相一致，特别是在一段时间内，测试出来的各业务TPS占比跟生产上高峰时候业务占比一致。
风险
场景的风险主要体现在测试出来的业务TPS占比跟生产的业务占比不一致，在业务比例偏离严重的情况下，将会导致测试结果不真实或者无效，不能反映生产上的业务场景。
规范
测试结果中各业务TPS占比需跟生产上业务占比（业务模型）相一致，可以使用PTS特有的RPS模式（Requests Per Second，直接测试吞吐能力）来保证一致。 例如：A和B两个接口，占比为1:4，响应时间分别为1ms、100ms，那么只需要通过PTS给A和B两个接口按照1:4比例设置请求数（RPS）施压即可。如果使用传统的并发模式，A和B的并发需要经过换算确保比例是1:400，使得最终与生产上保持一致的业务模型。
监控
分析
监控的目的主要是为进行性能测试分析服务的，完善的对系统进行监控，针对瓶颈定位起到更优效果。 一般来说，需要针对操作系统、中间件、数据库、应用等进行监控，每种类型的监控尽量保证指标全面。
风险
没有完善的系统监控，将会导致性能分析无从下手，定位不出系统瓶颈，无法判断从哪进行调优。
规范
操作系统：CPU、Memory、Disk I/O、Network I/O。
中间件：线程池（Thread Pool）、数据库连接池（JDBC）、JVM（GC/FULL GC/堆大小）。
数据库：效率低下的SQL、锁等待/死锁、缓存命中率、会话、进程等。
应用：方法耗时、算法、同步和异步、缓存、缓冲。
瓶颈分析
分析
瓶颈定位的目的是对系统中存在的瓶颈点进行分析，为调优做准备，系统的性能瓶颈点主要分布在操作系统资源、中间件参数配置、数据库问题以及应用算法上。针对性地进行调优，有利于系统性能的提升。
风险
当系统的瓶颈点不能被分析出来以后，新业务上线或者核心业务就存在风险，这种风险有可能导致业务高峰的时候，系统性能体验差，甚至“崩溃”。
规范
分析系统的瓶颈点遵循的规则如下：
操作系统资源消耗：CPU、Memory、Disk I/O、Network I/O。
中间件指标：线程池（Thread Pool）、数据库连接池（JDBC）、JVM（GC/FULL GC/堆大小）。
数据库指标：效率低下的SQL、锁等待/死锁、缓存命中率、会话、进程等。
应用：方法耗时、算法、同步和异步、缓存、缓冲。
压力机：压力机资源消耗，一般情况下，压力机成为瓶颈点的可能性非常低。PTS压力机有保护和调度机制无需单独关注。
调优
分析
调优的目的是提升系统的性能，针对系统的“瓶颈点”分析，通过测试验证系统的性能有多大的提升。
风险
未进行调优的系统，系统上线后，可能会出现客户体验差的效果，甚至导致系统“崩溃”的风险。
规范
系统调优遵循的规则如下：
中间件调优：线程池（Thread Pool）、数据库连接池（JDBC）、JVM（GC/FULL GC/堆大小）。
数据库调优：效率低下的SQL、锁等待/死锁、缓存命中率、会话、进程等。
应用调优：方法耗时、算法、同步和异步、缓存、缓冲。
系统资源：系统资源（例如CPU等）占用率过高往往是由于应用和参数设置不合理导致的，并非系统资源不足。
性能测试分布式云化压测工具
简介
性能测试服务（Performance Testing Service，简称PTS）是Web化的SaaS性能测试平台，具备强大的分布式压测能力，可模拟海量用户的真实业务场景。
PTS的压力来源是遍布全球上百个城市和各运营商的CDN节点，相比业界产品的云主机发起更快速，来源更广泛，脉冲能力和流量掌控能力更强。PTS在功能上强调页面可视化编排，提供无需编码的复杂交互式压测、RPS压测模式、以及实时调控实时生效的调速能力。
PTS目标是将性能压测本身的工作持续简化，使您可以将更多的精力回归到关注业务和性能问题本身。通过PTS可以用较低的人力、资源成本构造最接近真实业务场景的复杂交互式流量，快速衡量系统的业务性能状况，为性能问题定位、容量配比、全链路压测的流量构造提供更好的帮助，进而提升用户体验，促进业务发展，最大程度实现企业的商业价值。
功能
压测场景构建
支持有序串行和并行编排压测的API，参数化上支持数据文件、系统函数、字符串和出参彼此之间的组合，对Cookie支持非常友好，还有丰富的指令扩展场景。调试功能可以便捷地进行复杂场景的数据流向的校验。
压测流量控制
支持并发和RPS模式，分钟内快速启动压测。误差较低，同时支持自动和纯手动模式，压测流量的调整秒级生效，支持千万的流量瞬时脉冲，多重机制确保压测流量及时停止。
监控和压测报告
压测数据包括各API的并发、TPS、响应时间、采样日志。
优势
稳定可靠
支持行业广泛，涉及电商、多媒体、金融保险、物流快递、广告营销、社交等多个领域。
功能强大
全SaaS化形态，无需额外安装和部署。
数据工厂功能，简单编码实现压测的API、URL的请求参数格式化。
复杂场景的全可视化编排，支持登录态共享、参数传递、业务断言，同时可扩展的指令功能支持多形态的思考时间、流量蓄洪等。
支持RPS、并发压测模式。
流量支持动态秒级调整，百万QPS亦可瞬时脉冲。
强大的报表功能，将压测客户端的实时数据做多维度细分展示和统计，同时自动生成报告供事后查阅。
压测API、场景均可调试，压测过程提供日志明细查询。
流量真实
流量来源于全球上百城市覆盖各运营商，真实模拟最终用户的流量来源，相应的报表、数据更接近用户真实体感。
施压能力强，支持较高RPS的压测流量。