网络游戏性能测试规划（拟稿）

目录

1．性能测试整体实施方案概述. - 2 -

1.1     五个阶段（CMM质量成熟度模型相似）：... - 2 -

1.2     现阶段性能测试的问题（排名不分先后）：... - 2 -

1.3     前期预计需要解决问题：... - 3 -

1.4     后期逐步需要解决问题：... - 3 -

2.    性能测试需求. - 4 -

2.1     前期性能指标：（需与研发共同确定）... - 5 -

2.2     后期性能指标（待新的测试方案完全建立后，与研发共同确定）... - 6 -

3． 性能测试总体目标. - 6 -

3．1    性能测试开展的标准... - 6 -

3．2  性能测试结束的标准... - 6 -

4．  性能测试技术方案. - 7 -

4．1    服务器拓扑架构... - 7 -

4．2    性能测试方法... - 8 -

4．2．1     性能测试现有方案... - 8 -

4．2．2    性能测试改善方案... - 9 -

1．性能测试整体实施方案概述

整体性能测试方案概述，此次规划是性能测试的初期规划。本次规划的目的是针对现有测试流程及测试方法，制定新的更加规范的测试体系优化测试方法提高测试效率。作为初期的性能测试规划，我们将初步分为以下四个阶段进行实施。从根本解决现有方案的瓶颈问题，规范测试步骤使测试数据更加准确、真实、可靠。

1.1      五个阶段（CMM质量成熟度模型相似）：

 

1.       模式分析阶段（使用原始测试方案，提出新的测试需求，提出可逐步改善性能测试需求模型，尝试性的使用初步确立的新测试方案）

2.       模式改进阶段（使用新的测试方案，提出符合现有测试流程改善建议重新定义更佳完善的性能指标，逐步确定和完善性能测试需求模型）

3.       模式持续改进阶段（针对不同测试目的，使用较为固定的测试方案，确立可控的测试需求，定义较为固定的性能测试模型、提出可持续改进的过程，建立持续改进机制。

4.       模式定性阶段（针对一个时期内的测试需求模型进行较为准确统计与归纳，确立成型的测试体系，深入的划分可持续改进的区域，形成规范的测试体系，提出有效的度量方法）

5.       模式探索阶段（针对单位年时间内测试需求模型改进数据统计，探索下一个单位年预计可持续改进区域，建立性能测试产品价值链模型（为产品生命周期的各个阶段提供可靠性能测试数据支持）

1.2           现阶段性能测试的问题（排名不分先后）：

1.       GameServer服务器异常死机

2.       GameServer服务器周期性死机

3.       如何通过几组性能测试数据，确定GameServer服务器是否能稳定持续运行144单位个工作日（既：24（小时/天）×6（天））

4.       GameServer服务器负载测试（机器人登陆的最大瓶颈、负载的峰值[数值、时间]、效率[cpu、Memory、磁盘的I/O消耗情况]）

5.       GameServer服务器排查性验证（启动服务时不加载某些model、不开启某些地图等）

6.       ……

1.3    前期预计需要解决问题：

1.       常规性测试：

Ø         GameServer服务器负载测试

Ø         GameServer服务器稳定性测试（既：模拟数据增长到144小时所需要的数据量，从而在短时期内对额定单位时间进行预估）

Ø         GameServer服务器异常死机（Cpu瓶颈、内存泄漏问题[如：[obj对象总数、每个地图能承受的obj最大总数、obj对象开销细分统计]、磁盘I/O瓶颈。

Ø         ……

2.       排查性测试：

Ø         验证新功能及对某个模块进行加载或关闭操作，对GameServer服务器造成的性能影响

Ø         GameServer周期性异常时间（根据：一个阶段的收集的数据，整理服务器在现有的发布周期内[如:每周五发布新的活动与修改Bug内容]服务器负载的变化情况，从而进一步确定产品的周期内的性能质量情况。（为周质量数据控制提供参考依据）

Ø         ……

1.4       后期逐步需要解决问题：

Ø       定义在统一的性能测试模型（PTGM）下，针对不同的测试类型建立可控的测试场景，形成较为规范的测试文档（阶段性的输入、输出文档）与体系。

Ø       在前期的性能测试基础上，为产品研发部、质量控制小组提供多方位性能测试数据统计与分析，给出较有意义的测试报告。力图帮助各单位小组尽可能的减少产品的实施成本，缩短单位人日消耗。

Ø       GameServer压力性测试(如:组织模拟真实用户进行并发操作,以得到现阶段服务器性能质量参考值,对服务器健康情况进行估计)

Ø       RoleDBServer压力性测试(疑问:客户端哪些指令和操作(动作)需要与角色服务器或Pays服务器进行数据交换)

Ø       GameServer容错性测试（如：模拟意外断线、亚健康网络主干环境、

Ø       大数据量验证、数据包攻击（假设：存在外挂或恶意数据）、错误数据（如：模拟一段时间内发生意外宕机的错误代码，以验证周期错误的回归比率、为产品版本基线控制改进提供理论依据）等）

Ø       ……

2. 性能测试需求

备注：采用研发需要哪些性能参量，前期与后期两个部分，指标（性能）与测试场景（阶段）的关系。由于现有的测试方案，主要通过使用Linux命令来对GameServer服务器进行监测。由此，在未启动自动化测试方案前，我们还需要通过原始的测试方案进行数据监控，这样我们可参考的性能指标就较自动化方案略微减少。

2.1  前期性能指标：（需与研发共同确定）

System	%User Time	系统上所有处理器执行非内核操作的平均响应时间的百分比，该值反映了用户有作业的时间比率。
	CPU context switches	CPU上下文切换。在vmstat的结果中该值显示为cs。
	CPU us	CPU的实际消耗百分比（CPU占有率）。
Memory	Free(KB)	可用物理内存数
	Swap(KB)	已使用的虚拟内存数量
	Cache(KB)	文件系统缓存
‚Process	%CPU Usage	被处理消耗的处理时间数量。（PID对应的消耗）
	Resident Size(KB)	进程保留的使用内存量。如果该值在测试过程中持续增长，很可能意味着该版本发生了内存泄漏。
‚Processor	%Idle Time	CPU总的空闲时间。如果该值持续低于10%，表明瓶颈可能使CPU。
	%User Time	非内核操作的CPU时间。如果系统使用大量算法或较复杂的计算，该值可能会比较大
	%IOwait Time	CPU消耗在等待I/O处理上的时间，此值结合I/O的计数器考虑
ƒPhysical Disk	The Number of disk operations per second	显示每个磁盘每秒的被操作次数。
	Percent of time the is busy	指所选磁盘驱动器忙于为读写或写入请求提供服务所用的时间的百分比
	Reads(Writes) per sec	物理磁盘上每秒读、写的次数。两者相加应小于磁盘设备最大容量。在iostat的结果中，该值显示为r/s和w/s
	Average Number of Transactions waiting for serviced	指读取（写入）请求（列队）的平均数。在iostat的结果中，显示为wait.

 

该计数器的值来源于vmstat应用的输出结果

‚该计算器的值来源于top命令的输出结果

ƒ该计算器的值来源于iostat命令的输出结果

    前期性能指标（在特定测试类型、测试场景的指标和阶段对应关系，与研发共同确定）

1．  启动期（关注的数据、计算的数据、收集的数据）

2．  稳定期（关注的数据、计算的数据、收集的数据）

3．  结束期（关注的数据、计算的数据、收集的数据）

2.2  后期性能指标（待新的测试方案完全建立后，与研发共同确定）

3．性能测试总体目标

3．1 性能测试开展的标准

1． Ø          测试环境搭建没有问题。

2． Ø 测试数据准备充分。

3． Ø 测试人员和测试资源充足。

Ø         程序通过单元测试（保证性能测试场景与用例可以正常运行）

Ø         测试过程无因其它事件引起的重大变化。

3．2  性能测试结束的标准

1． Ø          测试数据收集完整。

2． Ø 有条件展开后续条件分析。

Ø         可为下一步方案提供理论依据。

4．  性能测试技术方案

4．1 服务器拓扑架构

4．2 性能测试方法

4．2．1   性能测试现有方案

       从以上测试流程中，我们可以知道在现有的测试方案中我们较关注话题主要集中在以下几个方面：

1.         产品版本（Alpha/Checklist）

2.         发布内容（Alpha：计划发布的内容/Checklist：确认发布的内容）

3.         场景设计（根据性能测试目的，设计简要的测试案例）

4.         数据分析（根据性能测试数据，对版本质量进行一定控制）

由此，我们来分析现有测试方案中的测试流程步骤与测试类型：

第一步：确认测试目的，根据产品开发小组提供性能测试需求，确定本次测试所要完成的最终目的。

现有的问题：测试目的不够清晰，没形成有指导意义的文档进行统一规划与管理。

第二步：准备技术方案，在明确测试目的基础上，对产品开发小组提出性能需求进行进一步论证，提出技术解决方案、拟定测试计划。

现有的问题：没有特定技术方案（未定义明确的测试类型），没有形成标准的测试计划。

第三步：准备测试环境，根据拟定的测试规划，按照现有人员结构、软/硬条件准备测试环境。

现有的问题：不能有效对技术方案进行评估与审核（需要的人员、设备的估算），在测试环境搭建完成后，不能有效的测试环境过程与结果进行验证。

第四步：设计测试场景，根据拟定的测试规划设计有针对性测试案例、准备测试数据。

现有的问题：缺少成型的设计文档，不能较好对测试结果进行估量，以至于测试时间较长，数据不能充分反应需求所涉及的问题。

第五步：执行测试收集测试数据，根据拟定测试场景，按照测试计划的时间与周期执行测试。按照事先拟定的测试数据规格进行有效的收集。

现有的问题：测试数据收集较为繁琐（主要是在测试进行中进行收集），不利于长期统计与分析。没有发布统一的数据收集的格式标准，对后期的测试分析制造了一些难度。

第六步：分析测试结果，根据以收集的测试数据，进行简要的数据分析。

现有的问题：针对以存在的测试数据没有进行统一的管理与存放，我们很难对一个时期的版本进行较为完善的统计与比较。

现有测试方案中的问题归纳：

1.         缺少完整的测试思路（测试目的、测试流程、测试场景）

2.         缺少标准的测试文档（配置管理、流程产出）

3.         缺少完善的评估标准（性能指标、度量体系）

4.         缺少数据的收集归纳（配置管理、测试文档）

4．2．2   性能测试改善方案

引入PTGM性能测试模型：

PTGM模型是一个结构化的过程模型，下图展示该模型的示意图：

为什么要引入PTGM模型？考虑到性能测试工作中自动化的引入和使用，在PTGM模型中我们明确了“测试工具的引入” 阶段，用以处理和测试工具引入的相关过程；由于性能测试的需求获取和分析、测试团队组建等工作与功能测试存在不同的侧重点，因此在过程模型中增加了一个独立“测试前期准备”阶段；另外，与功能测试相比，性能测试的测试设计和开发明显会有区别，因此将“测试设计与开发”阶段作为一个过程中的重要阶段。

1.         测试前期准备工作

a)         系统基础功能验证

在开始完全性能测试之前，必须需要保证我们将要设计的用例其功能是完全正确的，并在在性能测试开展周期中不会发生较大的调整。如需要进行设计变更或设计重构，则不满足性能测试基础条件以至测试部有条件拒绝接受该版本的测试。

b)        组建测试团队

根据特定需要筛选合适的测试团队。

c)        测试工具确认

需要根据被测试系统的了解和对测试过程初步规划，给出测试工具列表：

被测试环境	系统工具功能需求建议
操作系统 环境	测试工具是否运在本操作系统上
	测试工具是否支持对本操作系统的支持
应用服务器 环境	测试工具是否支持对本应用服务器的监控
数据库环境	测试工具能否支持本数据的监控
应用使用 协议	本系统使用哪些协议
	哪些协议需要在性能测试脚步录制中使用
	测试工具能否执行需要进行录制和产生负载的协议
网络环境	是否需要测试工具支持防火墙
	是否需要测试工具支持负载平衡
测试管理 支持	测试工具是否能够提供方便的测试结果分析和管理

2.         测试工具引入

a)         工具选择

b)        工具应用技能培训

c)        确定工具应用的过程

3.         测试计划（重点展开）

a)         性能测试领域分析

性能测试应用领域分为：“能力验证”、“规划能力”、“性能调优”、“发现缺陷”。

测试目的是明确验证系统在固定条件下的性能能力，属于“能力验证”领域。

测试目的是了解系统性能能力的可扩展性和系统在非特定环境下性能表现能力，属于“规划能力”领域。

测试目的是通过测试（发现问题）－调优（参数调整）－测试（验证调优结果）的方法提高系统性能能力，属于“性能调优”领域。

测试目的是通过性能测试手段，发现应用的缺陷，属于“发现缺陷”领域。

应用领域	性能测试目标	性能目标
能力验证	验证系统在给定环境中的性能表现	重点关注基础性能指标，如：CPU、内存、I/O等
规划能力	验证系统的性能扩展能力，找出系统能力扩充的关键点，给出善其扩展能力的建议	业务的性能瓶颈，基础性能指标的峰值
性能调优	提高系统的性能表现	重点关注的关键业务性能指标
发现缺陷	发现系统中的缺陷，可针对系统的模块进行划分，逐步排查出问题的原因	按照实际需求，进行恒定

 

b)        用户活动剖析与业务建模

根据游戏性能需求，我们将针对大众玩家行为模式分析，进行数字化业务建模。

网络游戏业务建模方法：（初步设想）

从系统角色数据库、Paysys数据库中采集所需要分析的玩家行为模式。

如：系统周期性登陆频率（模拟测试场景的设计）；

系统登陆峰值分布（模拟测试场景的设计）；

系统登陆每单位用户消耗（模拟测试场景设计）；

游戏玩家常规活动采集（模拟测试场景设计）；

游戏玩家常规活动使用频率（模拟测试场景设计）。

c)        确定性能目标

采集性能需求，如：需求文档、打包申请等

明确测试领域，如：能力验证、规划能力、性能调优、发现缺陷

基本性能阀值：

CPU << 70%

内存瓶颈 << 1.5G

磁盘I/O page rate << （一定时期观察后得出）

......等

d)        制定测试时间和测试计划

根据性能活动持续的时间，为每个活动阶段给出可能的时间估计，最终形成时间上的计划，一般使用类比分析方法，使用Project进行实际控制与管理。

4.         测试设计与开发

a)         测试环境设计

针对不同的测试领域，设计对应的测试环境。这里重点展开，我们即将使用到的常规测试中的“能力验证”领域的测试设计：

首先明确该领域的测试是在特定的环境中进行部署，包含以下几个方面：系统软/硬件环境、数据环境设计、环境维护等。

数据环境设计，建立基础数据模型，定义空数据量、大数据量等（如：系统运行在一个已有50，000条数据的数据库中和一个几乎为空的数据库环境下，其执行查询、插入和删除操作效率和响应时间显然是不尽相同的。

软/硬件环境：

	应用服务器	数据库服务器
机器型号
CPU
Ｍemory
Disk
网卡
操作系统
数据库
系统版本

客户端环境（加压机：机器人所运行的环境）

	客户端（1）
机器型号
CPU
Ｍemory
Disk
网卡
操作系统
客户端软件
防毒软件
测试工具软件
机器人版本

网络环境

网络类型	带宽	设备	数量
局域网	100Mbps	Xingnet nes-1016 16 port N-way Switch	1

网络拓扑结构图

          数据库及服务器参数：

参数名	建议值
数据库连接池最大值
Servlet高速缓冲	启用
允许线程分配超过最大线程大小	不允许

 

b)        测试场景设计

测试场景模拟的一般是实际测业务运行的剖面，其包括业务、业务比例、测试指标的目标以及需要在测试过程中进行监控的性能计数器。

基础数据量	场景编号	对应功能点	并发数	机器人发布比例（单位％）	场景目标	运行 方式	监控 指标	监控 方式和工具
0年数据量		1.    test1 2.    test2	150			每3分钟增加5个用户直到150个		通过LoadRunner工具采集结果、部分数据辅助手工采集进行分析
		3.    test1

 

c)        测试用例设计

在设计完成测试场景后，为了能把场景通过测试工具体现出来，并能用测试工具顺利进行测试执行，因此有必要针对每个测试场景规划出相应的工具部署、应用部署、测试方法和步骤，这个过程就是测试用例的设计活动。

基础 (数据量)	测试类型 （领域）	测试场景 （编号）	详细业务 (流程)	事务划分 (名称)	集合点 (名称）	脚本迭代 （次数）	设置思考 （时间）

 

4.         测试执行与管理

a)         建立测试环境

建立测试环境一般包括硬件、软件系统环境的搭建、数据库环境建立、应用系统的部署，系统设置参数的调整，以及数据环境准备几个方面的工作。

注意的问题：

服务器时间同步，可以使用Windows域机制实现同步机制

Unix主机之间可以用过ntp协议实现相互间的时间同步（man ntp）

混合服务器同步（Unix与Windows），使用NetTime开源工具实现同步机制。

测试环境检测列表：

条目名称	检测内容	责任人	维护方面
硬件环境	硬件环境是否与拓扑结构一致		硬件拓扑结构图
软件环境	软件环境是否与软件环境列表中描述的一致 应用部署是否成功 测试辅助工具是否部署成功 软件参数设置是否符合要求 是否按照性能测试需求加载了相应的程序文件 服务器启动（服务器日志是否显示完整）		软件环境列表 应用部署检查列表 测试辅助工具部署检查 软件参数设置表
数据环境	数据是否与数据要求描述表中一致 上一次测试是否引入额外的数据而没有清楚		数据要求描述表 数据维护脚本（Sql表结构、初始化数据、系统镜像）

 

b)        部署测试脚本和测试场景

保持场景与设计的一致性。

c)        执行测试和记录结果

我们除了使用LoadRunner进行自动化监控外，针对测试服务器的可变性，我们还将辅助手工的脚本收集工作。通过编写Shell、Perl脚本，收集服务器性能数据。主要工具如下：

1.         收集服务器运行日志（服务器性能资源，类似于LoadRunner）

2.         记录单个进程内存使用率

测试记录结果：

LoadRunner结果统一命名为（测试类型＋事务场景描叙＋当前日期＋GameServer服务器版本）

如：Routine_Ramp-up_ 2007-1-23 _@2332

后期考虑采用细分列表方式记录：

R_R_ 2007-1-23 _@2322

测试记录存放：

我们通过在VSS中建立游戏性能测试文件夹，具体存放目录如下

5.         测试分析

性能测试分析略，具体根据实际测试需求，结合LoadRunner Analysis分析器进行数据分析。

6.         详细改善过程

由此，详细过程改善方案：

第一阶段：在使用原始top命令记录的同时，结合LoadRunner进行自动化性能测试监控，在监测过程中逐步确定新的性能指标参数。

解决的问题：该阶段主要是使用LoadRunner等图形化检测工具，对GameServer(Linux CentOS)资源进行即时监控，监控分为两部分：1.是对测试环境游戏服务器进行有效监控，以对程序版本进行控制。2.是对网外环境游戏服务器进行长期监控，以根据外网出现的性能问题（时间点，消耗），辅助内网测试环境模拟其相同的测试场景重现性能问题。

第二阶段：使用QTP或者按键精灵等软件，录制机器人自动化测试测试脚本。与LoadRunner等检测工具配合使用，缩短常规性性能测试测试周期。

解决问题：该阶段主要是使用按键精灵等软件，录制全自动化测试脚本。该阶段分为以下几个阶段：1.是录制自动化测试脚本2.根据场景设计需求，调试自动化测试脚本3.结合场景设计方案，调整LoadRunner时间周期。4.逐步引入规范化性能测试流程。

第三阶段：根据一定时期的观测数据，以及新的测试需求变化。提出适合现有发展的技术方案。

解决问题：该阶段主要是调整现有的测试方案，并在一定程序上加强流程化的实施与建立，逐步确定适合游戏开发周期的性能测试方案。

第四阶段：根据后期出现的问题，优化测试方案。结合突发事件和常规性错误，调整测试类型，设计统一的测试场景，固化测试模型。

解决问题：该阶段主要是改善测试方案，固化测试模型。