网站建设系统认证系统,wordpress防护屏蔽国外ip,重庆网站维护制作,徐州库云平台之前有同学交流过#xff0c;在测试执行过程中他并不清楚测试得到的结果到底能不能满足这次活动的需求。经过追问#xff0c;发现他连本次活动规则涉及的模块和接口都不是十分清楚#xff0c;像这样的测试就是没有做性能测试目标的分析。虽然说做了性能测试#xff0c;但几…之前有同学交流过在测试执行过程中他并不清楚测试得到的结果到底能不能满足这次活动的需求。经过追问发现他连本次活动规则涉及的模块和接口都不是十分清楚像这样的测试就是没有做性能测试目标的分析。虽然说做了性能测试但几乎可以说是无效测试因为没有做目标分析的性能测试会与真实的活动场景相差甚远。
举一个典型案例一次大促前在性能测试过程中测出来的数据指标都还不错然而大促时并没有达到测出来的指标服务就宕机了。在分析原因后我们发现有一个接口平时访问量很低所以并没有纳入性能测试的范围。但这个接口存在大 Key在大促中达到中间件流量阈值导致了网站的不可用。
所以说测试目标极其重要是性能测试执行的先决条件。
制定目标可以确定既定的测试范围内需要达到的性能预期结果。制定目标后你才会对本次性能测试的核心目标有清晰的认知并指导你进行后续的测试活动包括测试所需要的资源以及测试的停止条件等。
在回答如何制定性能测试指标之前要搞清楚我们衡量性能测试的指标都有什么通过本讲的学习你将会对性能测试指标如 TPS、响应时间、报错率有更深入的了解不仅仅知道它们各自代表的含义还会知道它们是如何制定出来的。
衡量指标 1TPS
衡量性能测试的指标很多人会说是并发。并发指同一时间节点发生的事情但这个同一时间并不是一个标准的度量也不是我们性能测试直接测量出来的指标。在性能测试中往往是通过在工具中增加虚拟用户数得到的接口每秒的调用量去衡量。
在实际生产中无论是网关还是服务通常都是记录一定时间内的访问请求次数所以在业内性能测试往往以 TPSTransactions Per Second作为最重要的度量指标因为它具备可度量和通用性的特质。
可度量指 TPS 是真实客观且明确的衡量指标通用性指无论在运维角度还是测试角度TPS 都可以达成一致的定义。
衡量指标 2响应时间
除了 TPS第二个比较重要的衡量指标是响应时间。响应时间和用户体验密切相关我们往往把一次请求从客户端发出到返回客户端的时间作为响应时间。在实际工作中我们会以 TPS 的量级来限制响应时间必须在多久之内。以下图 1 为例从最左侧的客户端到最右侧的数据持久化再返回到客户端这样一个来回的过程就是一次完整的请求响应时间。 图 1请求响应的过程图
上图描述的是在正常情况下的响应流程但当你有了一定的性能测试实践之后你会发现这样的过程并不是绝对的。比如有的业务第一次在数据库请求到数据后应用层本地缓存会将数据存储在应用服务器上也就是接下来在缓存有效时间内不会再去数据库取数据而是在应用层得到数据后就会直接返回所以响应时间会比第一次低不少这也是随着性能测试的进行响应时间变低的原因之一。
衡量指标 3报错率
这个指标也是比较重要的报错率的计算方式是在统计时间范围内不符合返回期望的请求数除以总共的请求数。在测试中这一指标不符合期望的话一般体现在对结果的校验上我一般会分为三个层面进行校验
状态码的校验这在性能工具中不需要特别设置如 4XX、5XX 这样的状态码会直接报错业务层面的校验为了保证业务的基本准确性会通过返回的数据包进行校验数据库校验 相对于业务测试性能测试的每一次请求不会都做数据库校验这样会影响性能测试结果我一般会在一轮性能测试之后去统计落库数据的数量和状态是否正常。
以测试登录为例
如果用户名和密码不匹配会返回一段错误报文不需要走正确流程中的校验逻辑如果用户名和密码匹配一般会有多层校验。
这二者存在较大的差别在实际压测过程中也存在业务没有校验但已经发生错误的情况这是不能及时发现的。
如何制定性能测试的指标
综上所述衡量性能最重要的三个指标是TPS、响应时间、报错率。那如何制定性能测试的指标呢你的依据是什么呢我列举几个面试者的常见回答
我是根据二八原则老板说我们百万日活80% 的用户在 20% 的时间段里访问响应时间是根据业内的 2-5-8 来制定我是根据竞品数据分析他们产品的 PV 应该是百万级所以我们的产品也是这么制定的这个指标是业务定的他们和开发讨论过应该没什么问题。
以上回答不仅从道理上讲有些牵强而且也没有任何制定性能测试可以参考的有效信息。性能测试是一项非常严谨的工作通过间接或者普适规则不可能满足具体特定的分析所以对这个问题的理解基本可以判断一位同学是否真正做过性能测试。
那有人会问“你是如何做性能测试目标分析的呢”
性能测试的目标可以分为 4 种。
第一种是以衡量系统的处理能力为核心目标。这一般是性能测试的主要目标用来评估当前系统的处理能力和容量方面的规划。我认为评估这个目标最重要的是对数据的客观分析那我们需要什么样的数据呢
对于每一个接口都会有访问计数这是目前业内比较常见的也是衡量接口访问能力最准确的指标之一。一般大公司会自己开发相应的监控工具发展中的公司也会使用一些开源或者商业工具进行监控。有了工具之后我们应该从哪些维度去统计这些数据呢
通常我们会通过时间维度和服务维度来统计。
时间维度
根据经验我们一般会考虑以大促当天的访问量来测试但从分析的角度一般前后半个月的时间都应该考虑在测试范围内。
首先我们需要确定大促前后哪些天数的访问量是比较高的这里我会先以天作为维度如图 2。可能你比较疑惑为什么其他节点也比较高呢 图 2大促前后访问量
想想一些电商大促的具体活动场景就不会感到奇怪了。现在很多电商如京东的“双十一”活动可能从 11 月 1 日就开始了其中穿插了一些品类活动和推送所以有流量冲高的情况也是比较正常的。因此我一般会对最高峰和次高峰都进行分析。
当我们选取了天数之后再以小时为维度确定哪些时间节点的访问量是比较高的。图 3 中我选取了其中一天按照小时分布再统计。这样一来我们就得到了时间维度上需要的数据。 图 3各小时访问量
服务维度
那什么是服务维度呢以目前比较流行的电商微服务架构为例我一般会做服务级别的拆分。先画一个示意图方便你对微服务有个简单了解。 图 4微服务架构图
网关一般是请求进入应用层的第一个入口也是统计网站入口访问量的方式之一。当我们的请求通过网关之后会下发到各个业务应用服务如图 4 中所示的服务 A、B、C我会按照确定的时间节点去统计各个服务的访问量数据。完成服务级的访问数据统计之后我会继续按照时间维度统计服务下的接口访问数据。你可以看到每个服务和每个接口的调用比例都不一样如图 5 所示。 图 5各个服务的调用比例
曾看到有的同学使用 JMeter 写性能测试脚本时用接口串联的方式编写比如登录 → 浏览商品 → 添加购物车这样一个流程的方式。这也就默认登录的用户浏览了商品后都会添加购物车这是一种典型的自动化测试的思维在性能中不会存在这样的同等分布。
一般来说在同一个时间点都会有不同的比例比如早晨 8 点有 1.2w 次登录请求、4w 次浏览商品的请求而下午这个数据就会产生变化。所以我会按照服务入口将接口调用也统计出来结合时间维度和服务维度做出性能测试的常见模型。
说到这里可能会有两个问题。
问题一选取了这么多时间节点应该会产生多个比例模型吧我们需要对每一个比例模型都进行测试吗
确实会产生多个比例模型而且每个都需要测试因为线上存在这样的访问趋势我们应当都要覆盖。
问题二你上面说的步骤好多感觉需要很多时间听说流量复制能一键解决
流量复制是不能解决指标制定的问题的并且在落地过程中还会花费大量的时间和人力成本所以关于目标的制定和分析我们需要一步一步进行花费一定的时间是难以避免的并且线上未来的访问趋势只能尽可能覆盖无法完全预测到。这一讲不对这部分内容展开描述如果有兴趣可以了解下 goreplay、jvmsandbox 等技术。
上面是描述指标分析的第一种类型也是最常见的类型从处理能力的角度去说如何制定性能测试的目标。那是否还有其他类型的性能测试目标呢
我们来看第二种性能测试目标。一个项目刚刚上线用户访问量还不是很高这时我们会更关注系统的健壮性如内存泄漏、并发死锁、超卖问题这些也需要在性能测试方向上进行。
值得一提的是完成这部分性能测试并不需要在生产上进行在线下性能测试环境也可以模拟甚至能够更早更快地发现问题。我们都明白在测试领域提早发现问题修复成本是最低的。如果你在上线后才发现这些问题然后再去修复修复完还要经过多轮的业务测试这样一来不管是时间成本还是人力成本都会大幅度增加。
第三种目标是系统的稳定性。
关于如何维护系统稳定性一直是一个比较大的话题。性能测试也是保障稳定的一部分我认为性能测试场景中的稳定性测试包含 2 个方面。
一个是正确率这不一定要在高并发下完成但我们要保证业务长时间运行的正确率能够达到 99.9999% 以上另一个是处理能力可以选取性能测试场景中的混合场景来执行这部分会在第 08 讲中详解这里我们需要观察两点
整体处理能力是否稳定会不会存在处理能力的下滑接口之间的比例是否稳定随着时间的进行接口之间的访问比例会不会偏离。
第四种性能测试目标是专项能力是否达标。
刚刚列举的几乎都是以业务接口为测试目标其实在实际的压测活动中也存在中间件甚至硬件的性能测试比如 Nginx、Kafka、防火墙等。这些往往不会作为最终的性能测试目标但会在全链路排障和专项测试中有所涉及。这部分的性能测试基本上是用来判断当前的环境配置的节点数以及配置所能达到的最大处理能力为全链路性能测试提供数据支撑。
总结
在性能测试领域最直接的衡量指标是 TPS、响应时间和报错率三者相互依赖不能孤立地只分析某一项指标。
性能测试是一项严谨的工作我们要熟悉制定的方法一切以数据作为基础拒绝在实践中凭感觉拍板的现象。基础数据建设也是性能工作的一部分当我们拿到数据之后需要根据上文描述的时间维度和服务维度去分析原则上分析的颗粒度越细越好。
