游戏性能测试如何开展

首先解释游戏性能测试含义：

性能（performance）：是系统实现其功能的能力。例如，响应时间、吞吐能力、事务处理数；

性能测试：是指在特定负载情况下，确定系统的响应速度和稳定性的表现。它也可以研究、测量、验证系统的其他特征，比如可扩展性、可靠性和资源使用率。通俗的讲：通过模拟生产运行的业务压力量和使用场景组合，测试系统的性能是否满足生成性能要求，即在特定的运行条件下验证系统的能力状况。

按手游构成特点，将性能测试分为客户端性能、服务器性能两大块。

性能测试的关键指标

客户端性能的关键指标有：CPU占用率、内存占用率、流量耗用量、FPS（每秒传输帧数） 

服务器端性能的关键指标有：响应时间、并发用户数、吞吐量等；

如何做性能测试

明确测试目标；

了解性能测试需求；

编写性能测试计划；

分析性能测试需求；

编写性能测试方案、设计测试场景；

相关资源准备(人力资源、硬件资源、软件资源)；

测试程序开发；脚本维护、测试数据准备、测试监控准备；

执行性能测试并收集测试结果；

分析结果；

系统调优及再测试；性能测试五大误区

4性能测试工具推荐

简单推荐2款工具，分别给玩家和开发者。

1    玩家：安兔兔等跑分软件

可以快速将app性能跑出一个整体分。但有个致命问题，无法单独查看单独某个功能、某个时间点的具体数值。缺点是无法定位问题。

2    开发者：WeTest性能测试（腾讯WeTest官方出品）

提供Android版本和云端版本2种性能测试方案，这里着重介绍下本地版本，使用3步即可：

1)     打开WeTest性能测试页面下载WeTest App，并安装；

2)     运行手机上的WeTest App，选择游戏后点“开始测试”；

3)     上传并查看报告

结束测试后，打开WeTest App点击“上传”按钮。

登录wetestqqcom点击“我的主页”里面，左侧的“手游测试报告”，在页面中就会出现“性能测试”结果报告，，就可以查看完整的测试报告；

常用的性能指标

吞吐量 固定时间间隔内的处理完毕事务个数。通常是1秒内处理完毕的请求个数，单位：事务/秒（tps）。

平均吞吐量一段时间内吞吐量的平均值。无法体现吞吐量的瞬间变化。

峰值吞吐量一段时间内吞吐量的最大值。是用来评估系统容量的重要指标之一。

最低吞吐量一段时间内吞吐量的最小值。如果最小值接近0，说明系统有“卡”的现象。

70%的吞吐量集中区间通过统计15%和85%的吞吐量边界值，计算出70%的吞吐量集中区间。区间越集中，吞吐量越稳定。

响应时间一次事务的处理时间。通常指从一个请求发出，到服务器进行处理后返回，再到接收完毕应答数据的时间间隔，单位：毫秒。

平均响应时间 一段时间内响应时间的平均值。无法体现响应时间的波动情况。

中间响应时间一段时间内响应时间的中间值，50%响应时间，有一半的服务器响应时间低于该值而另一半高于该值。

90%响应时间一段时间内90%的事务响应时间比此数值要小。反应总体响应速度，和高于该值的10%超时率。是用来评估系统容量的重要指标之一。

最小响应时间响应时间的最小值。反映服务最快处理能力。

最大响应时间响应时间的最大值。反映服务器最慢处理能力。

CPU占用率1-CPU空闲率，表示CPU被使用情况，反映了系统资源利用情况。

对于游戏开发者的实际情况来说，充足的测试时间并不是每次都可以保证的，而且对于模拟机器人的开发过程本身又是一个很大的投入。这里再推荐一个压测工具，云端IDE内置了对HTTP、标准TCP和PB协议的解析器，无需写脚本，只需要编写自定义协议就行了，链接：http://wetestqqcom/gaps/

阿里云服务器ECS如何选择？很多新手用户并不知道PTS是什么，如果你不知道如何选择阿里云服务器ECS产品，性能测试PTS可以很好的帮助你快速对云服务器进行压力测试，从而助你选择适合自己的阿里云服务器ECS，下面是性能测试PTS详解！

阿里云开发者社区最近推出了一个“ ECS 选款利器！PTS助您快速上云 ”活动，PTS性能压测包仅需099/月起，真实模拟，免去繁琐的搭建和维护成本！现在您可以只支付10块钱不到的试用成本，即可体验使用 PTS 来帮助 ECS 进行容量规划选择合适规格的整个流程！

完成动手实验的同学，即可参与抽奖活动，小米手环 6、蓝牙键盘、掌上游戏机、笔记本支架、 数据线、优惠券等丰富奖品等您来拿！限量 1500 份，抽奖即得，百分百中奖哦！

性能测试PTS（Performance Testing Service）是具备强大的分布式压测能力的SaaS压测平台，可模拟海量用户的真实业务场景，全方位验证业务站点的性能、容量和稳定性。

PTS旨在简化性能压测本身的工作。

PTS目标是将性能压测本身的工作持续简化，使您可以将更多的精力回归到关注业务和性能问题本身。在PTS平台上，您可以用较低的人力和资源成本，构造出最接近真实业务场景的复杂交互式流量，快速衡量系统的业务性能状况，为性能问题定位、容量配比、全链路压测的流量构造提供最好的帮助。进而提升用户体验，促进业务发展，最大程度实现企业的商业价值。

业务场景

PTS广泛应用于各种压力测试和性能测试场景，包括但不限于以下场景：

PTS孵化于服务阿里巴巴全生态五年以上的单链路、全链路压测平台，是阿里巴巴内部最佳实践的输出。该平台对内除了支持日常的外部流量压测之外，同时支持了大大小小的促销活动，如天猫双11、双12和年货节等。

压测流程

PTS提供全面高效的压测流程：

压测流程说明：

1在PTS控制台上，准备压测API数据，构造压测场景，定义压测模式、量级等；支持随时启停压测，压测过程中可调速。

2压测启动后，PTS后台的压测控制中心将自动调度压测数据、压测任务和压测引擎。

3通过随机调度全国上百个城市和运营商的内容分发网络CDN （Content Delivery Network）节点，发起压测流量。保证从虚拟用户并发量、压测流量的分散度等维度都接近真正的用户行为，压测结果更加全面和真实可信。

4通过压测引擎向您指定的业务站点发起压测。

5压测过程中，通过集成云监控、ARMS（应用实时监控服务）产品，结合PTS自有的监控指标，实时采集压测数据。

6在PTS控制台，实时展现压测数据，进行过程监控；压测结束后，生成压测报告。基于整个压测场景的性能表现，定位性能问题、发现系统瓶颈。

压测创建方式

PTS支持以下4种方式创建压测场景（或称压测用例），如下图所示：

说明：

方式一：PTS自研零编码可视化编排，使用自研强大引擎压测。

方式二： 使用PTS自研云端录制器，零侵入录制业务请求并导入1中的自研交互中进行进一步设置。

方式三： 将导入脚本压测 1中的PTS自研交互中，使用PTS自研引擎。

方式四：JMeter压测并使用原生JMeter引擎进行压测，PTS提供自定义的压力构造和监控数据汇聚等产品服务。

其中，方式一、二、三由于使用了PTS的自研引擎，具备RPS（Requests per Second）吞吐量压测模式、秒级启动、实时控制、定时压测和流量遍布全国运营商网络的差异化能力。

方式一是PTS最核心的一种压测场景创建方式，所有资源包均可使用。其他几种创建方式面向不同规格资源包开放。

适用于多业务场景

不论您处于哪个行业，在以下业务场景（但不限于），PTS都是您值得信赖的性能测试工具。

适用行业广泛

PTS应用行业广泛，涉及电商、多媒体、金融保险、物流快递、广告营销、社交等等。

PTS服务阿里巴巴全生态多年，支持了天猫双11、双12、年货节等大促活动。植根于电商行业的PTS，对电商的典型业务模型支持得更友好，压测来源更广泛，脉冲能力和流量掌控能力更强。

PTS自商业版发布以来，吸引了来自多媒体、金融保险、政务等众多行业的用户，以其强大的压测场景编排能力和报表能力，帮助用户快速发现问题，进行针对性地调优，提升了系统承压能力。

适用于多种网络环境

不论您的业务位于公有云、专有云、混合云或者自建IDC中，只要能够通过公网访问，PTS都能够通过遍布全国上百个城市和各运营商的CDN节点发起压测流量，最大程度地模拟真实业务场景。

适用于使用HTTP/HTTPS/WebSocket等协议的客户端

PTS本身的GUI模式支持HTTP/HTTPS协议的压测，无论您的客户端是自研的App、移动端网页、PC端网页、微信小程序还是C/S结构的软件，都可以使用PTS进行压测。PTS同时集成了开源JMeter，支持更多的协议和场景，例如您可以通过“JMeter + WebSocket插件”的方式，对使用WebSocket协议的客户端进行压测（在PTS上传相应的插件JAR文件即可），其他协议以此类推。

下面以电商典型业务场景为例，为您介绍如何在PTS中编排压测场景。

什么是压测场景

要发起一次性能压测，首先需要创建一个压测场景。压测场景中包含一个或多个并行的业务，每个业务包含一个或多个串行的请求。

示例

淘宝网需要对产品A和B相关的页面（即存在多个API）进行压测，假设其主要业务场景为：

业务A：浏览产品A。

业务B：购买产品B（登录 → 浏览产品B → 加入购物车 → 提交订单）。

那么在压测场景中的设置如下。

串联链路1：浏览产品A 和串联链路2：购买产品B是并行关系。

根据业务逻辑，一部分用户在浏览产品A，另一部分用户在进行购买产品B的一系列操作，即两个业务是同时发生的，所以将它们设置为两个串联链路，压测中会并行发起请求。

串联链路中的多个API是串行关系。

根据业务逻辑，串联链路2：购买产品B中的一系列用户行为是存在先后顺序的，所以将这些存在先后关系的API添加到一个串联链路中，PTS压测中会按照顺序发起压测。

综合来看，在压测中，示例中的浏览产品A的API和登录的API，会同时发起压测流量。更多性能测试PTS场景示例，可参考阿里云帮助资料： 性能测试 PTS>最佳实践

Windows服务器中自带的性能监控工具叫做Performance Monitor；

在开始-运行中输入‘perfmon’，然后回车即可运行。

Monitor本身也是一个进程，运行起来也要占用一定的系统资源。所以你看到的资源的使用量应该比实际的要稍微高一点。这个工具在帮助管理员判断系统性能瓶颈时非常有用；

举个列子来说，今天有个用户抱怨说他们项目组的服务器（这是一台虚拟机）运行起来非常慢，但也不知道具体问题出在什么地方。任务管理器里显示CPU和内存的使用量都不算高，但服务器的相应就是非常慢；

Monitor，让其运行一段时间后（因为参考平均值会比较准确），发现average disk queue的值比较高，这就说明物理服务器的硬盘负荷太重，I/O操作的速度跟不上系统的要求。关掉虚拟机，将其转移到另一台硬盘负载比较小的主机上，再打开虚拟机。

分析性能情况

1、内存泄露判断

虚拟内存字节数（VirtualBytes）应该远大于工作集字节数（Workingset），如果两者变化规律相反，比如说工作集增长较快，虚拟内存增长较少，则可能说明出现了内存泄露的情况。

对于Workingset、Private Bytes、Available bytes这些计数器，如果在测试期间内数值持续增长，而且测试停止后位置在高水平，则也说明存在内存泄露。

Windows资源监控中，如果Process\PrivateBytes计数器和Process\WorkingSet计数器的值在长时间内持续升高，同时Memory\Available

bytes计数器的值持续降低，则很可能存在内存泄漏。

2、CPU使用情况

一般平均不要超过70%，最大不要超过90%（好：70% 、坏：85%、 很差：90%）。

3、tps（每秒处理事务的数量，在SOAPUI中进行统计）

一般在10-100，不同应用程序具体值不同。

贴一篇我们内部的文章：

随着浏览器功能的不断完善，用户量不断的攀升，涉及到web服务的功能在不断的增加，对于我们测试来说，我们不仅要保证服务端功能的正确性，也要验证服务端程序的性能是否符合要求。那么性能测试都要做些什么呢？我们该怎样进行性能测试呢？

性能测试一般会围绕以下这些问题而进行：

1 什么情况下需要做性能测试？

2 什么时候做性能测试？

3 做性能测试需要准备哪些内容？

4 什么样的性能指标是符合要求的？

5 性能测试需要收集的数据有哪些？

6 怎样收集这些数据？

7 如何分析收集到的数据？

8 如何给出性能测试报告？

性能测试的执行过程及要做的事儿主要包含以下内容：

1 测试评估阶段

在这个阶段，我们要评估被测的产品是否要进行性能测试，并且对目前的服务器环境进行粗估，服务的性能是否满足条件。

首先要明确只要涉及到准备上线的服务端产品，就需要进行性能测试。其次如果产品需求中明确提到了性能指标，那也必须要做性能测试。

测试人员在进行性能测试前，需要根据当前的收集到的各种信息，预先做性能的评估，收集的内容主要包括带宽、请求包大小、并发用户数和当前web服务的带宽等

2 测试准备阶段

在这个阶段，我们要了解以下内容：

a 服务器的架构是什么样的，例如：web服务器是什么？是如何配置的？数据库用的是什么？服务用的是什么语言编写的？；

b 服务端功能的内部逻辑实现；

c 服务端与数据库是如何交互的，例如：数据库的表结构是什么样的？服务端功能是怎样操作数据库的？

d 服务端与客户端之间是如何进行交互的，即接口定义；

通过收集以上信息，测试人员整理出服务器端各模块之间的交互图，客户端与服务端之间的交互图以及服务端内部功能逻辑实现的流程图。

e 该服务上线后的用户量预估是多少，如果无法评估出用户量，那么可以通过设计测试执行的场景得出这个值；

f 上线要部署到多少台机器上，每台机器的负载均衡是如何设计的，每台机器的配置什么样的，网络环境是什么样的。

g 了解测试环境与线上环境的不同，例如网络环境、硬件配置等

h 制定测试执行的策略，是需要验证需求中的指标能否达到，还是评估系统的最大处理能力。

i 沟通上线的指标

通过收集以上信息，确定性能测试用例该如何设计，如何设计性能测试用例执行的场景，以及上线指标的评估。

3 测试设计阶段

根据测试人员通过之前整理的交互图和流程图，设计相应的性能测试用例。性能测试用例主要分为预期目标用户测试，用户并发测试，疲劳强度与大数量测试，网络性能测试，服务器性能测试，具体编写的测试用例要更具实际情况进行裁减。

用例编写的步骤大致分为：

a 通过脚本模拟单一用户是如何使用这个web服务的。这里模拟的可以是用户使用web服务的某一个动作或某几个动作，某一个功能或几个功能，也可以是使用web服务的整个过程。

b 根据客户端的实际情况和服务器端的策略，通过将脚本中可变的数据进行参数化，来模拟多个用户的操作。

c 验证参数化后脚本功能的正确性。

d 添加检查点

e 设计脚本执行的策略，如每个功能的执行次数，各个功能的执行顺序等

4 测试执行阶段

根据客户端的产品行为设计web服务的测试执行场景及测试执行的过程，即测试执行期间发生的事儿。通过监控程序收集web服务的性能数据和web服务所在系统的性能数据。

在测试执行过程中，还要不断的关注以下内容：

a web服务的连接速度如何？

b 每秒的点击数如何？

c Web服务能允许多少个用户同时在线？

d 如果超过了这个数量，会出现什么现象？

e Web服务能否处理大量用户对同一个页面的请求？

f 如果web服务崩溃，是否会自动恢复？

g 系统能否同一时间响应大量用户的请求？

h 打压机的系统负载状态。

5 测试分析阶段

将收集到的数据制成图表，查看各指标的性能变化曲线，结合之前确定的上线指标，对各项数据进行分析，已确定是否继续对web服务进行测试，结果是否达到了期望值。

6 测试验证阶段

在开发针对发现的性能问题进行修复后，要再执行性能测试的用例对问题进行验证。这里需要关注的是开发在解决问题的同时可能无意中修改了某些功能，所以在验证性能的同时，也要关注原有功能是否受到了影响。

想看原文或者有测试其他相关的问题可以关注下 搜狗测试 微信公众号，我们上面有不少关于性能测试分享~