游戏测试入门.docx
《游戏测试入门.docx》由会员分享，可在线阅读，更多相关《游戏测试入门.docx（37页珍藏版）》请在冰豆网上搜索。
游戏测试入门
游戏测试入门
游戏测试
要了解如何测试游戏必需了解如何做游戏，了解它的开发过程，才能真正的测好游戏。
游戏要成功，其基本的必要条件有三。
分别为Vision（设计）、technology（技术）和Process（过程）。
游戏情节的测试：
主要指游戏世界中的任务系统的组成。
游戏世界的平衡测试：
主要表现在经济平衡，能力平衡（包含技能，属性等等），保证游戏世界竞争公平。
游戏文化的测试：
比如整个游戏世界的风格，是中国文化主导，还是日韩风格等等，大到游戏整体，小到NPC（游戏世界人物）对话，比如一个书生，他的对话就必需斯文，不可以用江湖语言。
游戏测试
游戏设计与测试：
设计阶段是做测试案例设计的最好时机。
很多组织要么根本不做测试计划和测试设计，要么在即将开始执行测试之前才飞快地完成测试计划和设计。
在这种情况下，测试只是验证了程序的正确性，而不是验证整个系统本该实现的东西。
而测试则会很明确，因为测试计划已经写的很明确，需要测试那些游戏系统，但是还需要了解系统的组成，而设计阶段则是设计系统的过程，所有的重要系统均是用UML状态图进行了详细的描述，比如用户登陆情况。
游戏测试-策划测试
游戏测试
测试过程不可能在真空中进行。
如果测试人员不了解游戏是由那几个部分组成的，那么执行测试就非常的困难，同时测试计划可以明确测试的目标，需要什么资源，进度的安排，通过测试计划，既可以让测试人员了解此次游戏测试中那些是测试重点，又可以与产品开发小组进行交流。
在企业开发中，测试计划书来源于需求说明文档，同样在游戏开发过程中，测试计划的来源则是策划书。
策划书包含了游戏定位，风格，故事情节，要求的配制等等。
从里面了解到游戏的组成，可玩性，平衡（经济与能力），与形式（单机版还是网络游戏），而测试在这一阶段主要的事情就是通过策划书来制定详细的测试计划，主要分两个方面一是游戏程序本身的测试计划，比如任务系统，聊天，组队，地图等等由程序来实现的功能测试计划，二是游戏可玩性有测试计划，比如经济平衡标准是否达到要求，各个门派技能平衡测试参数与方法，游戏风格的测试，三是关于性能测试的计划，比如客户端的要求，网络版的对服务器的性能要求。
同时测试计划书中还写明了基本的测试方法，要设计的自动化工具的需求，为后期的测试打下良好的基础。
同时由于测试人员参与到策划评审，对游戏也有很深入的了解，会对策划提出自己的看法，包含可玩性，用户群，性能要求等等并形成对产品的风险评估分析报告，但这份报告不同于策划部门自己的风险分析报告，主要从旁观者的角度对游戏本身的品质作充分的论证，从而更有效的对策划起到控制的作用。
游戏测试-经典解析
游戏测试
在团队中若是有资深的测试人员要具备的一项基本的素质就是可以针对UML的用例图，时序图，状态图来设计出重要系统的测试案例，只有重要系统的质量得到充分的测试，游戏程序的质量才可以得到充分的保证。
一个用户登陆游戏系统的时序图。
从这里我们可以很明确的了解玩家是如何验证并登陆系统的，在这个过程中要与那些对象进行交互，比如这里我们就是三个系统之间的交互，客户端（玩家部分），网关，账号服务之间的一个时序变化关系，为了能够完整的对这个流程进行测试，我们必需设计出可以覆盖整个流程的测试案例，并考虑其中可能的非法情况，因为这个时序图只是考虑了用户正常登陆成功的情况，并没有考虑密码错误，通信失败等许多可能存有的情况，并形成完整的测试案例库，从而对登陆系统的系统化测试做了充分的准备。
同时通过这张图，性能分析人员还可以分析出可能存的性能瓶颈，比如这里可能有的瓶颈如下，总网关是否可以达到多少用户的并发，是如果达不到，是否可以采用分布式部署或是支持负载平衡，三者之间的网络带宽的比例分配，账号服务器是否可以承载多个网关的连接请求，最大连接请求可以达到多少等等，同时会针对这些风险做性能测试的设计，并提出自动化测试的需求，比如模拟玩家登陆的压力工具等等。
性能测试与优化：
最后要单独提一下的是性能优化，在单机版的时代，性能的要求并不是很高，但是在网络版的时代，则是两个完全不同的概念，主要包含了以下几个方面：
应用在客户端性能的测试、应用在网络上性能的测试和应用在服务器端性能的测试。
通常情况下，三方面有效、合理的结合，可以达到对系统性能全面的分析和瓶颈的预测。
不过在测试过程中有这样一个原则，就是由于测试是在集成测试完成或接近完成时进行，要求测试的功能点能够走通，这时你首先要进行优化的是数据库或是网络本身的配制，只有这样才可以规避改动程序的风险。
同时性能的测试与优化是一个逐步完善的过程，需要前期的很多的工作，比如性能需求，测试工具等等，不过由于前期工作的完善，这些都在前期完成了。
游戏测试-设计评审
游戏测试
在设计评审时，测试人员的介入可以充分的对当前的系统构架发表自己的意见，由于测试人员的眼光是最苛刻的，并且有多年的测试经验，可以比较早的发现曾经出现的设计上的问题，比如在玩家转换服务器时是否作了事务的支持与数据的校验，在过去设计中由于没有事务支持与数据的校验从而导致玩家数据丢失,而这些风险可以在早期就规避掉。
上面所说的是对游戏程序本身的测试设计，对于游戏情节的测试则可以从策划获得，由于前期的策划阶段只是对游戏情节大方向上的描述，并没有针对某一个具体的情节进行设计，进入设计阶段时，某个游戏情节逻辑已经完整的形成了，策划可以给出情节的详细设计说明书，称为任务说明书，通过任务说明书我们可以设计出任务测试案例，比如某一个门派的任务由那些组成，我们可以设计出完整的任务测试案例，从而保证测试可能最大化的覆盖到所有的任务逻辑，如果是简单任务，还可以提出自动化需求，采用机器人自动完成。
集成测试阶段：
集成测试是对整个系统的测试。
由于前期测试与开发的并行，集成测试已经基本完成，这时只需要对前期在设计阶段中设计的系统测试案例运行一下就可以。
我们主要的重心在集成测试中的兼容性测试，由于游戏测试的特殊性，对兼容性的要求特别高，所以我们采用了外部与内部同部进行的方式，内部我们有自己的平台试验室，搭建主流的硬软件测试环境，同时我们还通过一些专业的兼容性测试机构对我们的游戏软件做兼容性分析，让我们的游戏软件可以跑在更多的机器上。
游戏测试-可玩性测试
游戏测试
游戏可玩性测试：
游戏可玩性测试也是非常重要的一块，主要包含四个方面：
1、游戏世界的搭建，包含聊天功能，交易系统，组队等可以让玩家在游戏世界交互的平台。
2、游戏世界事件的驱动，主要指任务。
3、游戏世界的竞争与平衡。
4、游戏世界文化蕴涵，游戏的风格与体现。
这种测试主要体现在游戏可玩性方面，虽然策划时我们对可玩性作了一定的评估，但这是总体上的，但一些具体的涉及到某个数据的分析，比如PK参数的调整，技能的增加等一些增强可玩性的测试则需要职业玩家对它进行分析，这里我们主要通过三种方式来进行：
1、内部的测试人员，他们都是精选的职业玩家分析人员，对游戏有很深的认识，在内部测试时，对上面的四点进行分析。
2、利用外部游戏媒体专业人员对游戏作分析与介绍，既可以达到宣传的效果，又可以达到测试的目的，通常这种方式是比较好的。
3、利用外部一定数量的玩家，对外围系统的测试，他们是普通的玩家，但却是我们最主要的目标，主要的来源是大中院校的学生等等，主要测试游戏的可玩性与易用性，发现一些外围的Bug。
4、游戏进入到最后阶段时，还要做内测，公测，有点像应用软件的beta版的测试，让更多的人参与测试，测试大量玩家下的运行情况。
游戏中的场景测试
场景测试就是基于场景的测试。
什么是场景，就是一段假想出来的在现实中可能发生的故事（有联系的连续行为），用来帮助人们理解一个问题或者系统。
举一个简单的例子说明：
玩家背包满时去领取道具，这就是一个场景。
为什么要使用场景测试？
1. 便于学习产品
对游戏测试而言，除了需要熟悉所测试功能外，还需要对周边的系统功能，甚至整个游戏有较深入的了解。
如果能假想自己是一个玩家，模拟玩家可能的操作，这样就能减少从单一功能点角度出发去了解一个功能的枯燥性，并且可以提升对功能系统内部以及功能点之间关联的理解程度。
2. 将需求文档和测试联系起来
在策划文档中，会对规则进行详细的定义和说明，但是，对于这些规则下的玩法则需要在测试中体现出来。
测试人员除了要对策划案中所列出的规则进行测试外，还需要考虑玩家所有可能的操作。
由这些操作，就组成了我们测试的场景。
3. 暴露产品设计上的缺陷
缺陷不仅仅是存在于代码层面上，产品设计上也可能会有不合理的地方。
我们常用的测试方法，一般都是针对如何发现代码问题的，在发现设计上的缺陷方面有局限。
要发现设计上的问题，就需要从玩家的角度出发，结合玩家的玩法，设计出特定的场景，在这样的场景下进行测试。
4. 探索产品的用法
对游戏测试，规则是死的，玩家是活的。
玩家的行为是不可预期的，玩法是多种多样的。
把规则转化为玩法，建立对应的测试场景，就可以预先把这些可能的玩法在测试时过一遍，更有利于保证我们游戏产品的质量。
这些场景还可以保留下来，作为既定玩法，还能应用于其他系统功能的测试中。
5. 将需求相关的问题引出到台面上
场景测试能有效暴露出产品设计上的缺陷。
需求是抽象的，有时只有在实际的运行过程里面才能暴露出问题。
这个实际的运行过程，就是场景测试。
综上，在游戏测试时，引入场景测试，对提升游戏的品质是十分必要的。
创建游戏场景的方法
1.写出功能系统中对象的生命历程。
2.列出可能的玩家群体，分析他们的兴趣和目标。
3.考虑恶意玩家，他们可能怎么攻击你的游戏，怎么利用现有规则。
4.列出系统事件，考察系统怎么处理这些事件。
5.列出特殊事件，考察系统怎么容纳这些事件。
6.列出收益并创建端到端的任务来检查他们。
7.与玩家沟通，找出原有功能or系统中他们最不满意的地方。
8.与玩家一起参与，观察他们是怎么玩游戏的，经常做些什么。
9.参考本游戏中类似的系统会做什么。
10.研究对这个系统以前版本和竞争对手的不足。
11.创建模拟的外网玩家群体（可使用随机导入外网账号的方式），使用这个模拟玩家群体，模拟外网真实情况。
一个完美的场景测试应包含几个特征：
1.一个基于真实玩家怎么玩游戏的场景，包括玩家的动机。
2.场景具有感染力，有影响力的干系人会促使让这个场景测试失败的原因得到修复。
3.场景要可信，不仅在真实的世界中可能发生，而且将很可能发生。
4.场景包含对游戏的复杂的操作，或者复杂的环境或者一套复杂的数据。
5.测试结果容易评估
场景测试不是盲目的，想到哪个场景就测试哪个，而是需要事前规划出一系列的可能场景，设计出在该场景下的测试用例，最后按照用例来执行测试。
下面就介绍一种场景测试用例的生成方法。
使用用例场景设计测试用例
为了方便测试，我们一般会根据所测试功能的大小，将其划分成一个或几个在逻辑上相对完整的功能流程（按照UML的定义可称为用例）。
对用例进行分析后，我们就可以整理出用例的场景，再针对这些场景，设计出场景测试用例。
将要测试的用例按照实际情况排出经过用例的路径，确定出基本流和备选流，列出所有从开始到结束的可能路径，从而形成测试可用的，有特定意义的用例场景。
举个例子来说明如何生成用例场景：
上图中经过用例的每条不同路径都反映了基本流和备选流，都用箭头来表示。
基本流用直黑线来表示，是经过用例的最简单的路径。
每个备选流自基本流开始，之后，备选流会在某个特定条件下执行。
备选流可能会重新加入基本流中（备选流1和4），还可能起源于另一个备选流（备选流2），或者终止用例而不再重新加入某个流（备选流2和3）
遵循上图中每个经过用例的可能路径，可以确定不同的用例场景。
从基本流开始，再将基本流和备选流结合起来，可以确定以下用例场景：
场景1 基本流
场景2 基本流备选流1
场景3 基本流备选流1备选流2
场景4 基本流备选流1备选流3
场景5 基本流备选流1备选流4
场景6 基本流备选流3
场景7 基本流备选流4
注：
为方便起见，场景2、3和4只描述了备选流1指示的循环执行一次的情况。
当我们的场景确定好以后，就要确定出每一个场景的测试用例。
生成测试用例的方法很多，这里就不一一累述了。
就说一下大的原则吧：
1. 基本流的全面测试除了正面的测试用例外，还必须包括负面测试用例，以确保只有在符合条件的情况下才执行基本流。
2. 对于每个备选流而言，至少存在一个负面测试用例。
3. 每个场景只具有一个正面测试用例和负面测试用例可能是不充分的。
举一个结合游戏的实例
假设有这样一个活动：
玩家在特定npc处点击菜单后，可从一系列道具中随机获得一件。
某些道具有上限限制。
每个玩家只能领一次。
当随机到某些道具的时候，需要有走马灯提示。
用例：
与npc对话，领取道具
分析领取道具的整个基本流程顺序，得出基本流：
步骤1
与npc对话，选择领取菜单
步骤2
检查已领取状态：
检查玩家是否已经领取过奖励了
步骤3
检查背包：
检查背包空间是否足够
步骤4
随机道具：
根据既定规则，随机要发给玩家的道具
步骤5
标记已领取：
对验证码和玩家做已领取的标记
步骤6
发放道具：
把随机到的道具加到玩家背包中
步骤7
记录log：
记录领取时间，角色名
再考虑到玩家在领取道具的过程中可能出现的情况，得出备选流：
备选流1-玩家领取过奖励
在基本流步骤2中，如果是已经领取过奖励的玩家，即使用有效的验证码，也不能再发放道具
备选流2-玩家背包空间不足
在基本流步骤3中，如果玩家背包空间不足，给出提示，不发道具
备选流3-随机到达到上限道具
在基本流步骤4中，如果随机到的道具已到达发放上限，需要重新随机
备选流4-玩家活动贵重道具
在基本流步骤6中，如果玩家随机到了贵重道具，则发送走马灯消息
用例图解：
按照从“开始用例”到“结束用例”流经的路径，得出以下场景：
场景1-成功领取
基本流
场景2-已领取过奖励的玩家再次领取
基本流备选流1
场景3-背包空间不足的玩家领取奖励
基本流备选流2
场景4-随机到已达上限的道具
基本流备选流3
场景5-玩家领取到贵重道具
基本流备选流4
场景6--随机到已达上限的道具，再次随机，并得到贵重道具
基本流备选流3备选流4
三种网络游戏的性能测试方法
进入游戏行业也有一段时间了，在日常的工作中对游戏的性能测试也产生了一些想法，因此写出来与大家讨论讨论。
网络游戏行业现在越做越大，面也越来越广了，依我的观点主要分为以下几个方面：
1、传统的c/s架构的网络游戏；
2、现在越来越风靡的b/s架构的网络游戏；
3、越来越多的wap网络游戏
那么我接下来就上面所说的3种网络游戏的性能测试怎么去做，发表一下自己的想法。
第一种传统的c/s架构的网络游戏
这种网络游戏历史最悠久，也是目前最主流的网络游戏类型。
这类游戏需要用户下载客户端，然后通过客户端来访问服务器进行登录和游戏。
这类游戏的性能测试方法大体有三种：
一目前较常规的做法就是由自主研发一个机器人程序，模拟玩家登陆与游戏。
这种方法的好处一是操作方便，对执行性能测试的人员无要求，二是能够较真实的模拟出玩家的部分操作。
但是缺点也不少，如对开发人员要求较高，因为不仅需要模拟用户访问服务器，还需要收集多种数据，并且将数据进行实时计算等，成本较大，而且也不易维护。
除此之外，机器人发生问题的时候，维护起来也不够方便。
在复杂架构下不利于判断瓶颈所在位置。
最重要的是一旦机器人开发进度拖迟或者出现致命bug，性能测试将无法进行。
二使用现成的性能测试工具来进行性能测试。
可以使用工具来模拟用户与服务器交互的底层协议来进行测试。
这种方法的优点是灵活方便、易于维护，开发成本小。
增加删除性能点及其容易，发生问题也能立即维护。
开发成本相对于机器人来说减少很多，并可以较容易的判断性能瓶颈所在的位置。
这种方式的缺点也有不少，如对性能测试人员的要求比较高，需要根据用例来编写模拟用户与服务器之间的协议交互脚本。
对于模拟真实性方面也比机器人程序差些。
三使用最广泛，且与上面两条不冲突，那就是进行封测、内测、公测等开放性测试方法。
这种方法是最真实的啦：
）。
让广大的玩家在测试服务器中进行游戏，帮助游戏公司找到游戏中的bug的同时，也对服务器的压力进行的真实的测试。
第二种b/s架构的网游
b/s架构的网游现在越来越流行，现在越来越多的人喜欢上了这种类型的网游。
它没有传统的c/s架构的网游那种炫目的效果、唯美的画面，也没有传统网游那种直观的人物动作，但是却吸引了越来越多的上班族去玩它。
因为它有着传统的c/s架构的网游所没有的优势，那就是方便，简单，要求低。
只要可以上网，只要有浏览器，就可以进行游戏。
无需下载客户端，无需担心机器配置不够，也无需长时间去投入，就可以享受到网游的乐趣。
这类游戏的性能测试方法大体有两种：
一、使用工具来模拟用户访问，这个和其他的b/s架构的软件产品一样。
通过各种工具，各种协议来模拟用户访问服务器，与服务器进行交互。
二、和传统的c/s架构的网游一样，它也有封测、内测、公测等活动，让广大的玩家为游戏公司进行性能测试。
第三种wap网络游戏
wap网游现在也是越来越多了。
这类游戏的性能测试方法大体有两种：
一使用模拟器在电脑上模拟wap环境，然后使用工具来进行性能测试。
使用的协议可以是wap，也可以是soap等其他协议。
二与其他两种网游一样，都少不了开发性测试这个环节。
以上就是我这些日子来对网游性能测试的想法，希望对大家有用。
战争策略类Webgame的设计测试方法
首先需要着重指出的一点是，本文所针对的仅是当前最流行的战争策略类Webgame，对于其它类型Webgame并不适用。
事实上，在当前的Webgame市场上所充斥的这些战争策略游戏的高度同质化，已经使得我们在很大程度上对于Webgame品质的好坏丧失了判断力。
究竟一款Webgame设计成什么样子才能够成功，这个问题是行业内没有任何一个人可以回答的了的。
在当前以运营和宣传能力作为评判一款Webgame成败的标准是一种很可行和可信的方法，但是对于Webgame的设计者和开发者（尤其是策划），这样的现状却是致命的。
究竟我们如何去设计一款Webgame，应当遵循什么样的设计原则？
在找到这个问题的答案前，我们的游戏设计者被迫处在一个迷茫期中。
事实上，本文无意于去找到这一设计原则，仅仅是尝试在开发过程中寻求一些减少和避免设计失误的方法。
数值设计被认为是战争策略类Webgame设计中最难的一环，其原因就在于我们对于数值设计的评价标准知之甚少。
从表面上看，Webgame的数值设计是存在有很大的随意性的，尤其是作为Webgame核心的各项时间和资源增长速度的设计，由于它们对于各个玩家来讲是公平的，而且相互之间往往很难看出直接的数值关联，因此很多对此并不精通的游戏策划在设计它们时往往过分随意。
而隐藏在这种随意背后的，往往就是灾难性的游戏进程。
无论是资源生产速度和资源消耗速度的不匹配，游戏战略进程和玩家部队生产速度的不匹配，主城和分城建设因不同资源和科技起点造成的数值漏洞，都属于容易带给玩家很严重的游戏体验挫折，但并不容易在设计阶段快速发现的问题。
因此，在战争策略类Webgame的设计开发过程中，我们需要引入设计测试的方法。
传统的软件测试和游戏测试更加偏重的都是程序漏洞（一般称为Bug）而不是设计漏洞。
究其原因，很重要的一点就是测试的测试文档（或称测试用例）是基于既有的设计文档的，测试的评判标准是实现的程序（游戏）是否符合既有的需求文档。
但是在这一过程中，设计的错误往往被忽略。
大量的设计漏洞由于测试不充分而没有在游戏开发测试阶段被发现，而是被保留到了正式的外部测试阶段。
尤其是一些后期的数值型漏洞，往往是在游戏开始公测甚至于正式运营后才暴露出来的。
由于游戏数值的普遍关联性，以及玩家角色积累的连续性，在这一阶段暴露出的设计漏洞能否被弥补，弥补需要多少时间都成为了未知数。
因此，在游戏开发过程中，我们需要针对设计漏洞的测试流程和测试方法。
事实上，在游戏行业的开发过程中，针对单一玩法，单一流程的设计测试（或者叫内容测试）是存在的，而且也可以说是比较到位的，但是，战争策略类Webgame的特殊性就在于它的设计漏洞往往出现在多个系统，多个玩法，多个流程共同作用的一个混合的玩家游戏过程中，而不是存在于某一个个体中，这样的，传统的基于模块的测试方法在应对战争策略类Webgame时往往是很不充分的。
那么，Webgame测试中还需要什么样的测试方法呢？
很简单的，就是测试者（事实上，这个测试者的角色建议以游戏策划而不是专门的游戏测试人员担任）以不同的游戏阵营和游戏角色加入游戏，整体体验游戏进程，并且记录各种体验性数据（一般为混合性数据，即不存在于游戏数值策划文档内的数据，例如玩家主城升级到X级所需的整体时间，玩家从进入游戏到开出第一座分城所需要的时间等）。
我们来看一个近期比较火热的战争策略类Webgame：
《热血三国》中所出现的两个最为严重的，也是游戏设计者在近期更新中着重解决的两个设计漏洞：
1.游戏中后期很容易出现资源堆积现象（尤其是石头和铁），继而频繁的发生“人祸”。
一个玩家因故两天不上游戏就可能导致接近致命的非PVP损失。
2.玩家频繁刷十级NPC城快速提升声望。
我们会注意到，以上的设计漏洞恰恰反映了两种最常见的容易在设计开发测试流程中被忽略的漏洞：
一是多个混合系统长时间作用所发生的混合效应（漏洞一反映了资源生产，资源储存，资源消耗和人祸系统四个系统共同作用过程中的配合问题）；二是单一系统的效果没有直观反应出其漏洞（十级NPC城的掠夺收益是在游戏策划的规划之内的，但他并没有清晰的意识到这一规划到底会导致什么样的整体结果）。
而对于绝大部分在游戏中进行到这一阶段的玩家而言，这些漏洞都是显而易见的。
同样的，我们可以意识到，如果我们有这样一个基于玩家整体游戏过程的测试的话，那么很多问题是可以在游戏面世之前被发现和解决的。
当然的，另一个问题也摆在了我们面前：
战争策略类Webgame以游戏进程缓慢，周期长为主要特征，难道我们的一环测试需要测试者连续去玩上几个月么？
是否还需要游戏测试者24小时在线？
因此的，我们接下来要指出的，就是这一基于设计的测试所应采取的正确方法。
1.在游戏开发早期预留速度调整和用于中断的游戏控制接口。
对于测试过程来讲，测试者有需要简化和跳过一般玩家的长时间等待过程，但又要保持在这一过程中的数据可以与游戏正常运行时一般玩家同步变化，这就需要游戏开发过程中为测试预留出可以控制游戏速度的接口。
需要控制的游戏速度主要包括：
玩家资源获取的速度，建筑单位的建筑速度，科技研发速度，军队和其他物品的生产度，以及玩家单位在地图上的移动速度等。
需要特殊指出的是，由于测试者测试的是当前数值体系下的数值平衡问题，因此不应该提供给游戏测试者改变两个速度间相对比例的接口，换言之，游戏测试者需要的仅仅是一个调整游戏整体运行速度的接口。
另一方面，游戏测试者会有测试玩家离开游戏一段时间后游戏状况变化的需求，以及游戏测试者本人因为下班，休息或其他原因暂时离开游戏的需求，因此需要在程序上提供给测试者一个暂时中断游戏进行的接口。
这两个接口应该在
升级会员 