﻿<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:trackback="http://madskills.com/public/xml/rss/module/trackback/" xmlns:wfw="http://wellformedweb.org/CommentAPI/" xmlns:slash="http://purl.org/rss/1.0/modules/slash/"><channel><title>IT博客-我的ITblog我作主　　关注→　『伊波拉』→　测试　SzDlinXie- ITblog　　  　　   -随笔分类-游戏软件测试</title><link>http://www.cnitblog.com/szdlinxie/category/4517.html</link><description>·√·  本ITblog站点记录相关的软件技术文档、网络技术杂志、测试技术杂谈等技术文档的管理站点.联系方式：MSN：dowling@sunlike.cn   QQ:94595885</description><language>zh-cn</language><lastBuildDate>Sun, 02 Oct 2011 20:18:35 GMT</lastBuildDate><pubDate>Sun, 02 Oct 2011 20:18:35 GMT</pubDate><ttl>60</ttl><item><title>网络游戏测试过程</title><link>http://www.cnitblog.com/szdlinxie/archive/2006/12/19/20769.html</link><dc:creator>szdlinxie</dc:creator><author>szdlinxie</author><pubDate>Tue, 19 Dec 2006 03:08:00 GMT</pubDate><guid>http://www.cnitblog.com/szdlinxie/archive/2006/12/19/20769.html</guid><wfw:comment>http://www.cnitblog.com/szdlinxie/comments/20769.html</wfw:comment><comments>http://www.cnitblog.com/szdlinxie/archive/2006/12/19/20769.html#Feedback</comments><slash:comments>0</slash:comments><wfw:commentRss>http://www.cnitblog.com/szdlinxie/comments/commentRss/20769.html</wfw:commentRss><trackback:ping>http://www.cnitblog.com/szdlinxie/services/trackbacks/20769.html</trackback:ping><description><![CDATA[
		<table cellspacing="0" cellpadding="0" width="558" border="0">
				<tbody>
						<tr>
								<td valign="center" align="right" colspan="2" height="32">
										<div class="style7" align="center">
												<span style="FONT-SIZE: 12pt">
														<b>网络游戏测试过程</b>
												</span>
										</div>
								</td>
						</tr>
						<tr>
								<td valign="center" align="right" bgcolor="#000000" colspan="2" height="1">
								</td>
						</tr>
						<tr>
								<td valign="center" align="right" colspan="2" height="20">
										<div align="center"> </div>
								</td>
						</tr>
						<tr>
								<td valign="top" align="right" colspan="2" height="10">
								</td>
						</tr>
						<tr>
								<td valign="top" align="right" width="2%" height="10">
										<div align="left">
										</div>
								</td>
								<td valign="top" align="right" width="98%" bgcolor="#ffffff">
										<div class="daxiao14" align="left">
												<div align="left">
														<p>
														</p>
														<p>
																<strong>游戏测试起因</strong>
																<strong>
																</strong>
														</p>
														<p>近几年来，网络游戏成了网络最新的弄潮儿，从盛大之传奇般的掘起，吸引了无数公司的眼球。但由于随着玩家的品位的升高，代理费用的上升，单一的代理国外游戏的模式已经很难在国内立足，而有中国传统文化特色的网络游戏则在国内大受欢迎，比如剑侠情缘，大话西游等一些国内的精典之作已经进入了一流网游的阵营。与此同时随着大家对网游稳定性，可玩性要求的升高，网络游戏测试开始成为大家关注的话题。</p>
														<p>
																<strong>游戏测试与软件测试的区别</strong>
																<strong>
																</strong>
														</p>
														<p>游戏测试作为软件测试的一部分，它具备了软件测试所有的一切共同的特性：</p>
														<ul>
																<li>测试的目的是发现软件中存在的缺陷。 
</li>
																<li>测试都是需要测试人员按照产品行为描述来实施。产品行为描述可以是书面的规格说明书，需求文档，产品文件，或是用户手册，源代码，或是工作的可执行程序。 
</li>
																<li>每一种测试都需要产品运行于真实的或是模拟环境之下。 
</li>
																<li>每一种测试都要求以系统方法展示产品功能，以证明测试结果是否有效，以及发现其中出错的原因，从而让程序人员进行改进。 </li>
														</ul>
														<p>总而言之，测试就是发现问题并进行改进，从而提升软件产品的质量。游戏测试也具备了以上的所有特性，不过由于游戏的特殊性，所以游戏测试则主要分为两部分组成，一是传统的软件测试，二游戏本身的测试，由于游戏特别是网络游戏，它相当于网上的虚拟世界，是人类社会的另一种方式的体现，所以也包含了人类社会的一部分特性，同时它又是游戏所以还涉及到娱乐性，可玩性等独有特性，所以测试的面相当的广。 我们称之为游戏世界测试，主要有以下几个特性：</p>
														<ul>
																<li>游戏情节的测试，主要指游戏世界中的任务系统的组成，有人也称为游戏世界的事件驱动，我喜欢称为游戏情感世界的测试。 
</li>
																<li>游戏世界的平衡测试，主要表现在经济平衡，能力平衡（包含技能，属性等等），保证游戏世界竞争公平。 
</li>
																<li>游戏文化的测试，比如整个游戏世界的风格，是中国文化主导，还是日韩风格等等，大到游戏整体，小到NPC（游戏世界人物）对话，比如一个书生，他的对话就必需斯文，不可以用江湖语言J。 </li>
														</ul>
														<p>
																<strong>游戏测试概述</strong>
														</p>
														<p>很多人有这样一个观点：“就是在软件开发完毕后，再进行测试。”殊不知，这种关点是有悖于软件开发的生命周期的，软件缺陷的发现必须是越早越好，这样才可以有效的规避风险，而在“最后进行测试”的测试观念的指导下测试工作必将会产生很多问题，这种观念的错误在于：生命周期中的“测试阶段”表明在该阶段测试工作是主要的工作，而不是说，测试工作只发生在“测试阶段”。通常，到了测试阶段，测试的主要任务是运行测试，形成测试报告。而想要提高游戏的质量，则必需要做到测试的早期介入，诸如测试计划，测试用例的确定以及测试代码的编写等等都是要在更早的阶段进行。如果你把测试完全放在最后阶段，就错过了发现构架设计和游戏逻辑设计中存在严重问题的最好时机，到那时，要修复这些缺陷将很不方便，因为缺陷已经扩散到系统中去了，所以这样的错误将很难寻找与修复，代价更高。</p>
														<p>要了解如何测试游戏必需了解如何做游戏，了解它的开发过程，才能真正的测好游戏。游戏要成功，其基本的必要条件有三。分别为Vision(设计)、technology(技术)和Process(过程)。三个条件，缺一不可如图所示：</p>
														<table width="614" border="0">
																<tbody>
																		<tr>
																				<td width="172"> </td>
																				<td width="254">
																						<img height="128" src="http://www.51testing.com/emagzine/lib/NO3/7/pic1.jpg" width="254" />
																				</td>
																				<td width="174"> </td>
																		</tr>
																</tbody>
														</table>
														<p align="center">图：游戏开发三大基石</p>
														<ul>
																<li>Vision则是对游戏还没有实现的总体上的把握，前瞻性的理解与策略的考量。 
</li>
																<li>Technology：有了vision，如果没有技术的话，则各种美妙的想法只能停留在虚无缥缈的阶段，通过技术来实现Vision。 
</li>
																<li>Process：有了Vision作为指导，有了技术作为保证，也不一定能够把好的想法转换成高质量的游戏。要创造高品质的游戏，尚缺重要的一环，即过程，制造游戏是一个非常是一个长时间的动态过程。游戏产品的质量则是要靠动态过程的动态质量来进行保证。过程由很多复杂的相互牵制的环节与部件组成，如果任意的环节或者是部件出了问题都会对最终的产品形成质量上的影响。因此对这个动态的过程，一定要有规划与控制，以保证按步就班，按质按时完成工作。 </li>
														</ul>
														<p>
																<strong>游戏测试与开发过程的关系</strong>
																<strong>
																</strong>
														</p>
														<p>CMM（Software Capability Maturity Model）软件成熟模型，大家都比较熟悉了，但在实施的过程中却存在这样那样的问题，对于游戏开发就更没有一个固定的路可以讲了，我们的团队是一个长期的游戏开发团队，对游戏开发有着很深的认识，我们认为游戏的Process(过程)实际上也是软件过程，不过是特殊的游戏软件开发过程，各个生命周期还是相通的。所以我们总结一套以测试作为质量驱动的、属于自己的开发过程。下图是游戏的迭代式开发过：</p>
														<table width="614" border="0">
																<tbody>
																		<tr>
																				<td width="17"> </td>
																				<td width="569">
																						<img height="392" src="http://www.51testing.com/emagzine/lib/NO3/7/pic2.jpg" width="569" />
																				</td>
																				<td width="14"> </td>
																		</tr>
																</tbody>
														</table>
														<p align="center">图：游戏迭代式开发与测试</p>
														<p>由于网络游戏的生命周期也是3、4年，所以采用迭代式的开发过程，既可以适应网络游戏本身这种长周期的开发，又可以利用RUP的迭代式开发的优点与CMM的里程碑控制，从而达到对游戏产品的全生命周期的保证。</p>
														<p>在游戏开发过程中，通用软件的需求分析阶段被策划所代替，但起的作用是一样的，明确游戏的设计目标（包括风格，游戏玩家群），游戏世界的组成，为后期的程序设计，美工设计，测试提出的明确的要求。由于开发是一个阶段的过程，所以测试与开发的结合就比较容易，从图上我们可以看到测试的工作与游戏的开发是同步进行的，每一个开发阶段中测试都进行了参与，能够深入的了解到系统的整体与大部分的技术细节，从而从很大程度上提高了测试人员对错误问题判断的准确性,并且可以有效的保证重要游戏系统的稳定。</p>
														<p>
																<a class="style5">
																		<strong>
																				<font size="2">游戏策划与测试计划</font>
																		</strong>
																</a>
														</p>
														<p>测试过程不可能在真空中进行。如果测试人员不了解游戏是由那几个部分组成的，那么执行测试就非常的困难，同时测试计划可以明确测试的目标，需要什么资源，进度的安排，通过测试计划，既可以让测试人员了解此次游戏测试中那些是测试重点，又可以与产品开发小组进行交流。在企业开发中，测试计划书来源于需求说明文档，同样在游戏开发过程中，测试计划的来源则是策划书。策划书包含了游戏定位，风格，故事情节，要求的配制等等。在策划评审中我们的高级测试人员可以参与进来，得到详细的游戏策划书，从里面了解到游戏的组成，可玩性，平衡（经济与能力），与形式（单机版还是网络游戏），而我们测试在这一阶段主要的事情就是通过策划书来制定详细的测试计划，主要分两个方面一是游戏程序本身的测试计划，比如任务系统，聊天，组队，地图等等由程序来实现的功能测试计划，二是游戏可玩性有测试计划，比如经济平衡标准是否达到要求，各个门派技能平衡测试参数与方法，游戏风格的测试，三是关于性能测试的计划，比如客户端的要求，网络版的对服务器的性能要求。同时测试计划书中还写明了基本的测试方法，要设计的自动化工具的需求，为后期的测试打下良好的基础。同时由于测试人员参与到策划评审，资深的游戏测试人员与产品经理由于对游戏也有很深入的了解，会对策划提出自己的看法，包含可玩性，用户群，性能要求等等并形成对产品的风险评估分析报告，但这份报告不同于策划部门自己的风险分析报告，主要从旁观者的角度对游戏本身的品质作充分的论证，从而更有效的对策划起到控制的作用。</p>
														<p class="style6">
																<a class="style5">
																		<font size="2">游戏设计与测试</font>
																</a>
														</p>
														<p>设计阶段是做测试案例设计的最好时机。很多组织要么根本不做测试计划和测试设计，要么在即将开始执行测试之前才飞快地完成测试计划和设计。在这种情况下，测试只是验证了程序的正确性，而不是验证整个系统本该实现的东西。而我们的测试则会很明确，因为我们的测试计划已经写的很明确，需要测试那些游戏系统，但是我们还需要了解系统的组成，而设计阶段则是设计系统的过程，所有的重要系统均是用UML状态图进行了详细的描述，比如用户登陆情况。如图2：</p>
														<table width="614" border="0">
																<tbody>
																		<tr>
																				<td width="36"> </td>
																				<td width="529">
																						<img height="298" src="http://www.51testing.com/emagzine/lib/NO3/7/pic3.jpg" width="529" />
																				</td>
																				<td width="35"> </td>
																		</tr>
																</tbody>
														</table>
														<p align="center">图2用户登陆情况</p>
														<p>在我们的团队中资深的测试人员要具备的一项基本的素质就是可以针对UML的用例图，时序图，状态图来设计出重要系统的测试案例，只有重要系统的质量得到充分的测试，游戏程序的质量才可以得到充分的保证。比如上图中就是一个用户登陆游戏系统的时序图。从这里我们可以很明确的了解玩家是如何验证并登陆系统的，在这个过程中要与那些对象进行交互，比如这里我们就是三个系统之间的交互，客户端（玩家部分），网关，账号服务之间的一个时序变化关系，为了能够完整的对这个流程进行测试，我们必需设计出可以覆盖整个流程的测试案例，并考虑其中可能的非法情况，因为这个时序图只是考虑了用户正常登陆成功的情况，并没有考虑密码错误，通信失败等许多可能存有的情况，并形成完整的测试案例库，从而对登陆系统的系统化测试做了充分的准备。同时通过这张图，性能分析人员还可以分析出可能存的性能瓶颈，比如这里可能有的瓶颈如下，总网关是否可以达到多少用户的并发，是如果达不到，是否可以采用分布式部署或是支持负载平衡，三者之间的网络带宽的比例分配，账号服务器是否可以承载多个网关的连接请求，最大连接请求可以达到多少等等，同时会针对这些风险做性能测试的设计，并提出自动化测试的需求，比如模拟玩家登陆的压力工具等等。</p>
														<p>同时在设计评审时，测试人员的介入可以充分的对当前的系统构架发表自己的意见，由于测试人员的眼光是最苛刻的，并且有多年的测试经验，可以比较早的发现曾经出现的设计上的问题，比如在玩家转换服务器时是否作了事务的支持与数据的校验，在过去设计中由于没有事务支持与数据的校验从而导致玩家数据丢失,而这些风险可以在早期就规避掉。上面所说的是对游戏程序本身的测试设计，对于游戏情节的测试则可以从策划获得，由于前期的策划阶段只是对游戏情节大方向上的描述，并没有针对某一个具体的情节进行设计，进入设计阶段时，某个游戏情节逻辑已经完整的形成了，策划可以给出情节的详细设计说明书，称为任务说明书，通过任务说明书我们可以设计出任务测试案例，比如某一个门派的任务由那些组成，我们可以设计出完整的任务测试案例，从而保证测试可能最大化的覆盖到所有的任务逻辑，如果是简单任务，还可以提出自动化需求，采用机器人自动完成。</p>
														<p class="style6">
																<a class="style5">
																		<font size="2">游戏测试与开发</font>
																</a>
														</p>
														<p>开发与测试一直有人认为是不可以平行进行的，必需要先开发后测试，但是软件的开发过程又要求测试必须早期介入，但在这里这种矛盾得到了很好的解决。我们采用了每日编译，将测试执行和开发结合在一起，并在开发阶段以编码--测试--编码--测试的方式来体现。也就是说，程序片段一旦编写完成，就会立即进行测试。普通情况下，先进行的测试是单元测试，但是一个程序片段也需要相关的集成测试，甚至有时还需要一些特殊测试。特别是关于接口测试，像游戏程序与任务角本、图片的结合，大家都认为需要提前测试，通过每日编你可以把已经写好的程序片段接合起来，形成部分的集成测试，从而有效的体现的接口优先测试的原则。同时由于软件测试与开发是并行进行的，并且实行的是软件缺陷优先修改的策略，所以很少会出现缺陷后期无法修改的情况，并且由于前期的测试案例的设计与自动化工具的准备，我们不需要投入太多的人力就可以极高的保证游戏软件的产品质量，特别是重要系统的质量。由于我们的游戏程序是每日不断的完善，所以集成测试也在同步的进行之中，当开发进入最后阶段时，集成测试也同步的完成了。这里有一个原则，也就是我前面所说的，测试的主体方法和结构应在游戏设计阶段完成，并在开发阶段进行补充(比如在游戏开发中会有相应的变动，或是某个转移变地址的变化，这就需要实时的更新)。这种方法会对基于代码的测试（开发阶段与集成阶段）产生很重要的影响，但是不管在那个阶段，如果在执行前多做一点计划和设计,都会大幅度的提高测试效率，改善测试结果，同时还有利于测试案例的重用与测试数据的分析，所以我们的测试计划是在策划时就形成了，为后继的测试形成了良好的基础。</p>
														<p class="style5">
																<a>
																		<strong>
																				<span class="style5">
																						<font size="2">集成测试阶段</font>
																				</span>
																		</strong>
																</a>
														</p>
														<p>集成测试是对整个系统的测试。由于前期测试与开发的并行，集成测试已经基本完成，这时只需要对前期在设计阶段中设计的系统测试案例运行一下就OK了。我们主要的重心在集成测试中的兼容性测试，由于游戏测试的特殊性，对兼容性的要求特别高，所以我们采用了外部与内部同部进行的方式，内部我们有自己的平台试验室，搭建主流的硬软件测试环境，同时我们还通过一些专业的兼容性测试机构对我们的游戏软件做兼容性分析，让我们的游戏软件可以跑在更多的机器上。</p>
														<p class="style6">
																<a class="style5">
																		<font size="2">游戏可玩性测试</font>
																</a>
														</p>
														<p>游戏可玩性测试也是非常重要的一块，主要包含四个方面：</p>
														<ul>
																<li>游戏世界的搭建，包含聊天功能，交易系统，组队等可以让玩家在游戏世界交互的平台。 
</li>
																<li>游戏世界事件的驱动，主要指任务。 
</li>
																<li>游戏世界的竞争与平衡。 
</li>
																<li>游戏世界文化蕴涵，游戏的风格与体现。 </li>
														</ul>
														<p>这种测试主要体现在游戏可玩性方面，虽然策划时我们对可玩性作了一定的评估，但这是总体上的，但一些具体的涉及到某个数据的分析，比如PK参数的调整，技能的增加等一些增强可玩性的测试则需要职业玩家对它进行分析，这里我们主要通过三种方式来进行：</p>
														<ul>
																<li>内部的测试人员，他们都是精选的职业玩家分析人员，对游戏有很深的认识，在内部测试时，对上面的四点进行分析。 
</li>
																<li>利用外部游戏媒体专业人员对游戏作分析与介绍，既可以达到宣传的效果，又可以达到测试的目的，通常这种方式是比较好的。 
</li>
																<li>利用外部一定数量的玩家，对外围系统的测试，他们是普通的玩家，但却是我们最主要的目标，主要的来源是大中院校的学生等等，主要测试游戏的可玩性与易用性，发现一些外围的Bug。 </li>
														</ul>
														<p>游戏进入到最后阶段时，还要做内测，公测，有点像应用软件的beta版的测试，让更多的人参与测试,测试大量玩家下的运行情况。</p>
														<p>可玩性测试是游戏重要的一块，只有玩家的认同，我们才可能成功。</p>
														<p class="style3">
																<a class="style5">
																		<font size="2">性能测试与优化</font>
																</a>
														</p>
														<p>最后要单独提一下的是性能优化，在单机版的时代，性能的要求并不是很高，但是在网络版的时代，则是两个完全不同的概念，主要包含了以下几个方面：应用在客户端性能的测试、应用在网络上性能的测试和应用在服务器端性能的测试。通常情况下，三方面有效、合理的结合，可以达到对系统性能全面的分析和瓶颈的预测。不过在测试过程中有这样一个原则，就是由于测试是在集成测试完成或接近完成时进行，要求测试的功能点能够走通，这时你首先要进行优化的是数据库或是网络本身的配制，只有这样才可以规避改动程序的风险。同时性能的测试与优化是一个逐步完善的过程，需要前期的很多的工作，比如性能需求，测试工具等等，不过由于前期工作的完善，这些都在前期完成了。这里我只做原则性的描述。</p>
														<p>数据库的优化的原则主要是这样的，首先是索引进行优化，由于索引的优化不需要对表结构进行任何改动，是最简单的一种，又不需要改动程序就可能提升性能若干倍，不过要注意的是索引不是万能的，若是无限的增加会对增删改造成很大的影响。其次是对表，视图，存储过程的优化。不过在分析之前需要知道优化的目标，客户行为中那些SQL是执行的最多的，所以我们必需借助些SQL的跟踪分析工具，例如SQLProfile,SQLExpert,等工具，这样会迅速的定位问题。</p>
														<p>关于网络的优化，这里我所说的并不是针对网络本身的优化，而是对游戏本身的网络通信的优化，所以它是与程序的优化是结合在一起的，首先也是发现问题，通过Monitor与Sniff先定位是什么应用占用了较多的网络流量，由于网络游戏的用户巨大，所以这也是一个重在的问题。对于程序的性能优化，最主要的是找到运行时间最长的函数，只有优化它，性能才有大幅度的提升，具体的方法我就不做详细的描述了。<a></a></p>
														<p>
																<strong>总述</strong>
														</p>
														<p>游戏测试是一个新的领域,它既有通用测试的特点,又有自己的特点,有许多未知的路要走,每天都在总结,希望给大家带来一些帮助,同时在这里也谢谢所有支持我的同事。</p>
														<p>
														</p>
												</div>
										</div>
								</td>
						</tr>
				</tbody>
		</table>
<img src ="http://www.cnitblog.com/szdlinxie/aggbug/20769.html" width = "1" height = "1" /><br><br><div align=right><a style="text-decoration:none;" href="http://www.cnitblog.com/szdlinxie/" target="_blank">szdlinxie</a> 2006-12-19 11:08 <a href="http://www.cnitblog.com/szdlinxie/archive/2006/12/19/20769.html#Feedback" target="_blank" style="text-decoration:none;">发表评论</a></div>]]></description></item><item><title>游戏软件的测试方法简述</title><link>http://www.cnitblog.com/szdlinxie/archive/2006/12/19/20768.html</link><dc:creator>szdlinxie</dc:creator><author>szdlinxie</author><pubDate>Tue, 19 Dec 2006 03:06:00 GMT</pubDate><guid>http://www.cnitblog.com/szdlinxie/archive/2006/12/19/20768.html</guid><wfw:comment>http://www.cnitblog.com/szdlinxie/comments/20768.html</wfw:comment><comments>http://www.cnitblog.com/szdlinxie/archive/2006/12/19/20768.html#Feedback</comments><slash:comments>0</slash:comments><wfw:commentRss>http://www.cnitblog.com/szdlinxie/comments/commentRss/20768.html</wfw:commentRss><trackback:ping>http://www.cnitblog.com/szdlinxie/services/trackbacks/20768.html</trackback:ping><description><![CDATA[
		<table cellspacing="0" cellpadding="0" width="558" border="0">
				<tbody>
						<tr>
								<td valign="center" align="right" colspan="2" height="32">
										<div class="style7" align="center">
												<span style="FONT-SIZE: 12pt">
														<b>游戏软件的测试方法简述</b>
												</span>
										</div>
								</td>
						</tr>
						<tr>
								<td valign="center" align="right" bgcolor="#000000" colspan="2" height="1">
								</td>
						</tr>
						<tr>
								<td valign="center" align="right" colspan="2" height="20">
										<div align="center"> </div>
								</td>
						</tr>
						<tr>
								<td valign="top" align="right" colspan="2" height="10">
								</td>
						</tr>
						<tr>
								<td valign="top" align="right" width="2%" height="10">
										<div align="left">
										</div>
								</td>
								<td valign="top" align="right" width="98%" bgcolor="#ffffff">
										<div class="daxiao14" align="left">
												<p>1. 测试的定义 </p>
												<p>   如果给个定义，我觉得：测试工作是，解决玩家所遇非正常问题的预测工作，同时也是不断调试平衡的一个长期观察任务。无论在什么时间段，功能实现、内测、公测等。测试都应该是分硬件与软件两部分测试。 </p>
												<p>2. 硬性问题 </p>
												<p>   硬件的BUG部分是指会引起不能让游戏流程进行的BUG。死机、画面出错等硬性问题。这种问题只要按照一定流程进行游戏，就会发生。但对一些会不断增加服务器负担的高级BUG，应该不会短期测试出来。而对这种在有计算机就出现的问题，现在的游戏在制作过程中都有可自动记录问题的LOG功能，所出现的BUG大多会被程序部门解决掉。部分的LOG功能可保留到正式客户端，以收集因为升级客户端，而不断产生的新问题。这里应该不会在讨论范围内吧。 </p>
												<p>3. 软性问题 </p>
												<p>    而软件的逻辑部分大多会在后期进行，比如公测。是各种功能的数值调整。主要为游戏的世界定义一个平衡。除了初级的数值设定外，内部测试人员很少有能把一个功能测试千万遍的。于是有可能产生出猫耍的老虎团团转，这种经典的寓言故事。策划及相关测试人员注重的应该是这部分的测试原理及方法。 </p>
												<p>   而这部分问题的测试，同硬性问题一样，需要一定流程及要求。而具体流程只有根据具体游戏来决定，大多是将问题分裂存放，并将理由归纳。但有几点是不变的。 </p>
												<p>3.1 平衡的目标 </p>
												<p>    而如何让各种设定不偏离主题，明确世界背景及制定等级概念应该是首要的。尤其在一些角色等系统十分复杂的情况下。那种变态ADD的规则，可由主角的5~6种基础属性影响到数十种战斗、非战斗技能。还可根据各种物品来休整这些数值。而无论如何。他们都有个明确的等级观念。从弱到普通，再到强，甚至到最强的龙。这是因为他们知道一个人，最强也不能强过龙。这样就给自己定下上限目标。 </p>
												<p>   所以，测试时首先不要去看玩家可选择的职业技能等等是否足够多。都会获得什么强大的技能、体力等等。先了解到这个世界里，各个种族之间的关系、职业的互补、各个角色的互相的关系，在整个世界中是什么位置，是否够合理、让常人可以现实中的逻辑去衡量，这个角色在游戏是否合理。之后才需要针对每个种族、每类职业、每个角色的平衡。最后到一个一个角色的测试。有人会说这是前期策划制定讨论的部分，没错，因为测试从这里就已经在策划的头脑中开始了。 </p>
												<p>   在这里定义的过程，正好与现实世界中相反。现实世界是总结出整体的平衡，而游戏世界则要定义平衡，再将世界整理成平衡的状态。<br />3.2 划分等级 </p>
												<p>   测试时同样要明确问题的严重等级，一个数值影响的事物越多，那他的严重等级越高。现在的MMRPG整个属性结构，基本都类似树形结构，之间也有着一些交错的枝叶。力量等最基本的角色属性，为根。这类属性会影响到的其他属性，最终到达游戏的胜负，任务的完成等等。而这些属性的等级自然也就十分明确。根为最高，枝叶最低。而修整树木永远不会从根开始。 </p>
												<p>   力量，最基础的属性，结合自己的命中率，对方的敏捷等，会影响物理攻击。同样也影响着可拿的武器。但如果这个人攻击力过高。那是谁的原因？是武器，还是角色的力量。需要修改那一个？那些角色的基础属性是最不能随便修改的。因此，还是武器吧。实在不行在从由属性引发的其他部分着手，如技能的熟练度等。越基础的部分，影响力越大，也最容易出错。角色的基础属性是一切测试的根源，同样也是最不能随便更改的一类。更不应该因为某个问题而被指明要求更改。而添加删除任何一个属性，更会让之前的测试工作有2/3付之一炬，也许更多。而对于各种武器，基本可以与角色测试分开。在角色属性有数十条的游戏中，武器更不会容易出现大的问题。 </p>
												<p>   严重等级之间从高到底可分为，角色，物品，技能。要修正这三大类属性，尽量在自己的范围内修正。不要妄想在其他级别动手，更别想在比自己之前高的级别里动手脚。而在这些属性里面同样还各种属性，就需要根据具体游戏进行划分测试。虽然这里以属性距离，但任务也同样如此，相互关连的任务网同样十分重要。只不过之前变化较属性掠少。 </p>
												<p>3.3 玩家是否付出与获得成正比 </p>
												<p>    现实世界中，没有可能可用捷径获得某一种事物、，只有拼搏。游戏世界里是否也是？获得一个强大技能之前，给角色的锻炼是否足够。让他足够珍惜这一种技能或物品。这是游戏中较为关键的一部分，多体现在任务上。时间、精力的消耗，是否足够让玩家获得物品时有足够的满足感。以及对得起测试人员的劳动。 </p>
												<p>3.4 记录、调整，总结 </p>
												<p>     软性问题应该同硬性问题一样拥有足够多的文档资料来记录，同时也方便对以往数值的效果再思考。这也应该是所有文档资料应该具备的，记录每次关键更新的工作。调整方面Sid Meier说过，每一次调整都要多一些。这样可以看到数值中的巨大差别，从中找到合适的数值。这几乎是知道Sid Meier的人都知道的一句话。（大意相似，具体内容没办法记起来，惭愧） </p>
												<p>    很多时候，测试时会直接将测试的内容按自己的想法修改。即便记录下来也是只要改好就好。其实很多时候这些修改都有一定规律，一些修正往往是没改变任何事情。多一些时间去探讨大家是否按照原来制定的目标去修正，会更合理的利用剩下的时间测试。同样，全部结束后的总结也会让下次制作时避免出现需要大量修正的设计。 </p>
										</div>
								</td>
						</tr>
				</tbody>
		</table>
<img src ="http://www.cnitblog.com/szdlinxie/aggbug/20768.html" width = "1" height = "1" /><br><br><div align=right><a style="text-decoration:none;" href="http://www.cnitblog.com/szdlinxie/" target="_blank">szdlinxie</a> 2006-12-19 11:06 <a href="http://www.cnitblog.com/szdlinxie/archive/2006/12/19/20768.html#Feedback" target="_blank" style="text-decoration:none;">发表评论</a></div>]]></description></item></channel></rss>