网络游戏测试过程.docx

网络游戏测试过程.docx

《网络游戏测试过程.docx》由会员分享，可在线阅读，更多相关《网络游戏测试过程.docx（28页珍藏版）》请在冰豆网上搜索。

网络游戏测试过程

网络游戏测试过程 

游戏测试起因

近几年来，网络游戏成了网络最新的弄潮儿，从盛大之传奇般的掘起，吸引了无数公司的眼球。

但由于随着玩家的品位的升高，代理费用的上升，单一的代理国外游戏的模式已经很难在国内立足，而有中国传统文化特色的网络游戏则在国内大受欢迎，比如剑侠情缘，大话西游等一些国内的精典之作已经进入了一流网游的阵营。

与此同时随着大家对网游稳定性，可玩性要求的升高，网络游戏测试开始成为大家关注的话题。

游戏测试与软件测试的区别

游戏测试作为软件测试的一部分，它具备了软件测试所有的一切共同的特性：

测试的目的是发现软件中存在的缺陷。

测试都是需要测试人员按照产品行为描述来实施。

产品行为描述可以是书面的规格说明书，需求文档，产品文件，或是用户手册，源代码，或是工作的可执行程序。

每一种测试都需要产品运行于真实的或是模拟环境之下。

每一种测试都要求以系统方法展示产品功能，以证明测试结果是否有效，以及发现其中出错的原因，从而让程序人员进行改进。

 总而言之，测试就是发现问题并进行改进，从而提升软件产品的质量。

游戏测试也具备了以上的所有特性，不过由于游戏的特殊性，所以游戏测试则主要分为两部分组成，一是传统的软件测试，二游戏本身的测试，由于游戏特别是网络游戏，它相当于网上的虚拟世界，是人类社会的另一种方式的体现，所以也包含了人类社会的一部分特性，同时它又是游戏所以还涉及到娱乐性，可玩性等独有特性，所以测试的面相当的广。

 我们称之为游戏世界测试，主要有以下几个特性：

游戏情节的测试，主要指游戏世界中的任务系统的组成，有人也称为游戏世界的事件驱动，我喜欢称为游戏情感世界的测试。

游戏世界的平衡测试，主要表现在经济平衡，能力平衡（包含技能，属性等等），保证游戏世界竞争公平。

游戏文化的测试，比如整个游戏世界的风格，是中国文化主导，还是日韩风格等等，大到游戏整体，小到NPC（游戏世界人物）对话，比如一个书生，他的对话就必需斯文，不可以用江湖语言J。

游戏测试概述

很多人有这样一个观点：

“就是在软件开发完毕后，再进行测试。

”殊不知，这种关点是有悖于软件开发的生命周期的，软件缺陷的发现必须是越早越好，这样才可以有效的规避风险，而在“最后进行测试”的测试观念的指导下测试工作必将会产生很多问题，这种观念的错误在于：

生命周期中的“测试阶段”表明在该阶段测试工作是主要的工作，而不是说，测试工作只发生在“测试阶段”。

通常，到了测试阶段，测试的主要任务是运行测试，形成测试报告。

而想要提高游戏的质量，则必需要做到测试的早期介入，诸如测试计划，测试用例的确定以及测试代码的编写等等都是要在更早的阶段进行。

如果你把测试完全放在最后阶段，就错过了发现构架设计和游戏逻辑设计中存在严重问题的最好时机，到那时，要修复这些缺陷将很不方便，因为缺陷已经扩散到系统中去了，所以这样的错误将很难寻找与修复，代价更高。

要了解如何测试游戏必需了解如何做游戏，了解它的开发过程，才能真正的测好游戏。

游戏要成功，其基本的必要条件有三。

分别为Vision（设计）、technology（技术）和Process（过程）。

三个条件，缺一不可如图所示：

图：

游戏开发三大基石

Vision则是对游戏还没有实现的总体上的把握，前瞻性的理解与策略的考量。

Technology：

有了vision，如果没有技术的话，则各种美妙的想法只能停留在虚无缥缈的阶段，通过技术来实现Vision。

Process：

有了Vision作为指导，有了技术作为保证，也不一定能够把好的想法转换成高质量的游戏。

要创造高品质的游戏，尚缺重要的一环，即过程，制造游戏是一个非常是一个长时间的动态过程。

游戏产品的质量则是要靠动态过程的动态质量来进行保证。

过程由很多复杂的相互牵制的环节与部件组成，如果任意的环节或者是部件出了问题都会对最终的产品形成质量上的影响。

因此对这个动态的过程，一定要有规划与控制，以保证按步就班，按质按时完成工作。

游戏测试与开发过程的关系

CMM（Software Capability Maturity Model）软件成熟模型，大家都比较熟悉了，但在实施的过程中却存在这样那样的问题，对于游戏开发就更没有一个固定的路可以讲了，我们的团队是一个长期的游戏开发团队，对游戏开发有着很深的认识，我们认为游戏的Process（过程）实际上也是软件过程，不过是特殊的游戏软件开发过程，各个生命周期还是相通的。

所以我们总结一套以测试作为质量驱动的、属于自己的开发过程。

下图是游戏的迭代式开发过：

游戏迭代式开发与测试

由于网络游戏的生命周期也是3、4年，所以采用迭代式的开发过程，既可以适应网络游戏本身这种长周期的开发，又可以利用RUP的迭代式开发的优点与CMM的里程碑控制，从而达到对游戏产品的全生命周期的保证。

在游戏开发过程中，通用软件的需求分析阶段被策划所代替，但起的作用是一样的，明确游戏的设计目标（包括风格，游戏玩家群），游戏世界的组成，为后期的程序设计，美工设计，测试提出的明确的要求。

由于开发是一个阶段的过程，所以测试与开发的结合就比较容易，从图上我们可以看到测试的工作与游戏的开发是同步进行的，每一个开发阶段中测试都进行了参与，能够深入的了解到系统的整体与大部分的技术细节，从而从很大程度上提高了测试人员对错误问题判断的准确性,并且可以有效的保证重要游戏系统的稳定。

游戏策划与测试计划

测试过程不可能在真空中进行。

如果测试人员不了解游戏是由那几个部分组成的，那么执行测试就非常的困难，同时测试计划可以明确测试的目标，需要什么资源，进度的安排，通过测试计划，既可以让测试人员了解此次游戏测试中那些是测试重点，又可以与产品开发小组进行交流。

在企业开发中，测试计划书来源于需求说明文档，同样在游戏开发过程中，测试计划的来源则是策划书。

策划书包含了游戏定位，风格，故事情节，要求的配制等等。

在策划评审中我们的高级测试人员可以参与进来，得到详细的游戏策划书，从里面了解到游戏的组成，可玩性，平衡（经济与能力），与形式（单机版还是网络游戏），而我们测试在这一阶段主要的事情就是通过策划书来制定详细的测试计划，主要分两个方面一是游戏程序本身的测试计划，比如任务系统，聊天，组队，地图等等由程序来实现的功能测试计划，二是游戏可玩性有测试计划，比如经济平衡标准是否达到要求，各个门派技能平衡测试参数与方法，游戏风格的测试，三是关于性能测试的计划，比如客户端的要求，网络版的对服务器的性能要求。

同时测试计划书中还写明了基本的测试方法，要设计的自动化工具的需求，为后期的测试打下良好的基础。

同时由于测试人员参与到策划评审，资深的游戏测试人员与产品经理由于对游戏也有很深入的了解，会对策划提出自己的看法，包含可玩性，用户群，性能要求等等并形成对产品的风险评估分析报告，但这份报告不同于策划部门自己的风险分析报告，主要从旁观者的角度对游戏本身的品质作充分的论证，从而更有效的对策划起到控制的作用。

游戏设计与测试

设计阶段是做测试案例设计的最好时机。

很多组织要么根本不做测试计划和测试设计，要么在即将开始执行测试之前才飞快地完成测试计划和设计。

在这种情况下，测试只是验证了程序的正确性，而不是验证整个系统本该实现的东西。

而我们的测试则会很明确，因为我们的测试计划已经写的很明确，需要测试那些游戏系统，但是我们还需要了解系统的组成，而设计阶段则是设计系统的过程，所有的重要系统均是用UML状态图进行了详细的描述，比如用户登陆情况。

用户登陆情况

在我们的团队中资深的测试人员要具备的一项基本的素质就是可以针对UML的用例图，时序图，状态图来设计出重要系统的测试案例，只有重要系统的质量得到充分的测试，游戏程序的质量才可以得到充分的保证。

比如上图中就是一个用户登陆游戏系统的时序图。

从这里我们可以很明确的了解玩家是如何验证并登陆系统的，在这个过程中要与那些对象进行交互，比如这里我们就是三个系统之间的交互，客户端（玩家部分），网关，账号服务之间的一个时序变化关系，为了能够完整的对这个流程进行测试，我们必需设计出可以覆盖整个流程的测试案例，并考虑其中可能的非法情况，因为这个时序图只是考虑了用户正常登陆成功的情况，并没有考虑密码错误，通信失败等许多可能存有的情况，并形成完整的测试案例库，从而对登陆系统的系统化测试做了充分的准备。

同时通过这张图，性能分析人员还可以分析出可能存的性能瓶颈，比如这里可能有的瓶颈如下，总网关是否可以达到多少用户的并发，是如果达不到，是否可以采用分布式部署或是支持负载平衡，三者之间的网络带宽的比例分配，账号服务器是否可以承载多个网关的连接请求，最大连接请求可以达到多少等等，同时会针对这些风险做性能测试的设计，并提出自动化测试的需求，比如模拟玩家登陆的压力工具等等。

同时在设计评审时，测试人员的介入可以充分的对当前的系统构架发表自己的意见，由于测试人员的眼光是最苛刻的，并且有多年的测试经验，可以比较早的发现曾经出现的设计上的问题，比如在玩家转换服务器时是否作了事务的支持与数据的校验，在过去设计中由于没有事务支持与数据的校验从而导致玩家数据丢失,而这些风险可以在早期就规避掉。

上面所说的是对游戏程序本身的测试设计，对于游戏情节的测试则可以从策划获得，由于前期的策划阶段只是对游戏情节大方向上的描述，并没有针对某一个具体的情节进行设计，进入设计阶段时，某个游戏情节逻辑已经完整的形成了，策划可以给出情节的详细设计说明书，称为任务说明书，通过任务说明书我们可以设计出任务测试案例，比如某一个门派的任务由那些组成，我们可以设计出完整的任务测试案例，从而保证测试可能最大化的覆盖到所有的任务逻辑，如果是简单任务，还可以提出自动化需求，采用机器人自动完成。

游戏测试与开发

开发与测试一直有人认为是不可以平行进行的，必需要先开发后测试，但是软件的开发过程又要求测试必须早期介入，但在这里这种矛盾得到了很好的解决。

我们采用了每日编译，将测试执行和开发结合在一起，并在开发阶段以编码--测试--编码--测试的方式来体现。

也就是说，程序片段一旦编写完成，就会立即进行测试。

普通情况下，先进行的测试是单元测试，但是一个程序片段也需要相关的集成测试，甚至有时还需要一些特殊测试。

特别是关于接口测试，像游戏程序与任务角本、图片的结合，大家都认为需要提前测试，通过每日编你可以把已经写好的程序片段接合起来，形成部分的集成测试，从而有效的体现的接口优先测试的原则。

同时由于软件测试与开发是并行进行的，并且实行的是软件缺陷优先修改的策略，所以很少会出现缺陷后期无法修改的情况，并且由于前期的测试案例的设计与自动化工具的准备，我们不需要投入太多的人力就可以极高的保证游戏软件的产品质量，特别是重要系统的质量。

由于我们的游戏程序是每日不断的完善，所以集成测试也在同步的进行之中，当开发进入最后阶段时，集成测试也同步的完成了。

这里有一个原则，也就是我前面所说的，测试的主体方法和结构应在游戏设计阶段完成，并在开发阶段进行补充（比如在游戏开发中会有相应的变动，或是某个转移变地址的变化，这就需要实时的更新）。

这种方法会对基于代码的测试（开发阶段与集成阶段）产生很重要的影响，但是不管在那个阶段，如果在执行前多做一点计划和设计,都会大幅度的提高测试效率，改善测试结果，同时还有利于测试案例的重用与测试数据的分析，所以我们的测试计划是在策划时就形成了，为后继的测试形成了良好的基础。

集成测试阶段

集成测试是对整个系统的测试。

由于前期测试与开发的并行，集成测试已经基本完成，这时只需要对前期在设计阶段中设计的系统测试案例运行一下就OK了。

我们主要的重心在集成测试中的兼容性测试，由于游戏测试的特殊性，对兼容性的要求特别高，所以我们采用了外部与内部同部进行的方式，内部我们有自己的平台试验室，搭建主流的硬软件测试环境，同时我们还通过一些专业的兼容性测试机构对我们的游戏软件做兼容性分析，让我们的游戏软件可以跑在更多的机器上。

游戏可玩性测试

游戏可玩性测试也是非常重要的一块，主要包含四个方面：

游戏世界的搭建，包含聊天功能，交易系统，组队等可以让玩家在游戏世界交互的平台。

游戏世界事件的驱动，主要指任务。

游戏世界的竞争与平衡。

游戏世界文化蕴涵，游戏的风格与体现。

这种测试主要体现在游戏可玩性方面，虽然策划时我们对可玩性作了一定的评估，但这是总体上的，但一些具体的涉及到某个数据的分析，比如PK参数的调整，技能的增加等一些增强可玩性的测试则需要职业玩家对它进行分析，

这里我们主要通过三种方式来进行：

内部的测试人员，他们都是精选的职业玩家分析人员，对游戏有很深的认识，在内部测试时，对上面的四点进行分析。

利用外部游戏媒体专业人员对游戏作分析与介绍，既可以达到宣传的效果，又可以达到测试的目的，通常这种方式是比较好的。

利用外部一定数量的玩家，对外围系统的测试，他们是普通的玩家，但却是我们最主要的目标，主要的来源是大中院校的学生等等，主要测试游戏的可玩性与易用性，发现一些外围的Bug。

游戏进入到最后阶段时，还要做内测，公测，有点像应用软件的beta版的测试，让更多的人参与测试,测试大量玩家下的运行情况。

可玩性测试是游戏重要的一块，只有玩家的认同，我们才可能成功。

性能测试与优化

最后要单独提一下的是性能优化，在单机版的时代，性能的要求并不是很高，但是在网络版的时代，则是两个完全不同的概念，主要包含了以下几个方面：

应用在客户端性能的测试、应用在网络上性能的测试和应用在服务器端性能的测试。

通常情况下，三方面有效、合理的结合，可以达到对系统性能全面的分析和瓶颈的预测。

不过在测试过程中有这样一个原则，就是由于测试是在集成测试完成或接近完成时进行，要求测试的功能点能够走通，这时你首先要进行优化的是数据库或是网络本身的配制，只有这样才可以规避改动程序的风险。

同时性能的测试与优化是一个逐步完善的过程，需要前期的很多的工作，比如性能需求，测试工具等等，不过由于前期工作的完善，这些都在前期完成了。

这里我只做原则性的描述。

数据库的优化的原则主要是这样的，首先是索引进行优化，由于索引的优化不需要对表结构进行任何改动，是最简单的一种，又不需要改动程序就可能提升性能若干倍，不过要注意的是索引不是万能的，若是无限的增加会对增删改造成很大的影响。

其次是对表，视图，存储过程的优化。

不过在分析之前需要知道优化的目标，客户行为中那些SQL是执行的最多的，所以我们必需借助些SQL的跟踪分析工具，例如SQLProfile,SQLExpert,等工具，这样会迅速的定位问题。

关于网络的优化，这里我所说的并不是针对网络本身的优化，而是对游戏本身的网络通信的优化，所以它是与程序的优化是结合在一起的，首先也是发现问题，通过Monitor与Sniff先定位是什么应用占用了较多的网络流量，由于网络游戏的用户巨大，所以这也是一个重在的问题。

对于程序的性能优化，最主要的是找到运行时间最长的函数，只有优化它，性能才有大幅度的提升，具体的方法我就不做详细的描述了。

 件测试员自身素质的培养及测试技巧

一、软件测试员自身素质培养 

（1） 首先，应对软件测试感兴趣和对自己有自信，如果具备了这两点，那么在开发过程中不管遇到什么样的困难，我相信你一定能克服。

（2） 善于怀疑，世界上没有绝对正确的，总有错误的地方，具有叛逆心理，别人认为不可能发生的事，我却认为可能发生。

别人认为是对的，我却认为不是对的。

　　（3） 打破砂锅问到底的精神，对于只出现过一次的bug，一定找出原因，不解决誓不罢休。

　　（4） 保持一个良好的心情，否则可能无法把测试作好。

不要把生活中的不愉快的情绪带到工作中来。

　　（5） 做测试时要细心，不是所有的bug都能很容易的找出，一定要细心才能找出这些bug。

　　（6） 灵活一些，聪明一点，多制造一些容易产生bug的例子。

　　（7） 在有条件的情况下，多和客户沟通，他们身上有你所需要的。

　　（8） 设身处地为客户着想，从他们的角度去测试系统。

　　（9） 不要让程序员，以“这种情况不可能发生”这句话说服你，相反，你应该去说服他，告诉他在客户心里，并不是这样的。

　　（10） 考虑问题要全面，结合客户的需求、业务的流程、和系统的构架，等多方面考虑问题。

　　（11） 提出问题不要复杂化，这一点和前面的有点矛盾，如果你是一新手，暂时不要管这一点，因为最终将有你的小组成员讨论解决。

　　（12） 追求完美，对于新测试员来说，努力的追求完美，这对你很好，尽管有些事无法做到，但你应该去尝试。

　　（13） 幽默感，能和开发小组很好的沟通是关键，试着给你的开发小组找一个“BUG杀手”，或对他们说“我简直不敢相信，你写的程序居然到现在没有找到BUG”。

　　（14） 到此是不是对测试很有兴趣呢？

不过我要告诉你，测试过程中有酸甜苦辣，其中的滋味只有你知道，也许你会感到枯燥，要学会放松自己，去溜冰或做你喜欢做的事，不过，别放弃，因为你的自信告诉过你“你会是很优秀的测试员”不是吗？

　　二、浅谈软件测试之技巧 

　　软件测试虽然辛苦，但是掌握了一定的技巧之后将使你事半功倍。

（1） 边界测试，测试用户输入框中的数值的最大数和最小数，以及为空时的情况。

（2） 非法测试，例如在输入数字的地方输入字母。

　　（3） 跟踪测试，跟踪一条数据的流程,保证数据的正确性。

　　（4） 在开始测试时应保证数据的正确性，然后在从系统中找出各种BUG。

　　（5） 接口测试，程序往往在接口的地方很容易发生错误，要在此模块测试勿掉以轻心。

　　（6） 代码重用测试，在开发过程中有些模块功能几乎相同，程序员在重用代码时可能忘记在原有代码上修改或修改不全面，而造成的错误。

　　（7） 突发事件测试，服务器上可能发生意外情况的测试。

　　（8） 外界环境测试，有些系统在开发时依赖于另外一个系统,当另外一个系统发生错误时, 这个系统所受到的影响的情况。

　（9） 在程序员刚修复Bug之后的地方,再找一找，往往程序员只修复报告出来的缺陷而不去考虑别的功能在修改时可能会重新造成错误。

　　（10） 认真做好测试记录在做完一天的测试记录之后,第二天再根据第一天的测试记录重复测试你会发现有未修正的错误。

　　（11） 文字测试，如果在系统中有用词不当的地方，我想这是不应该的。

　　（12） 系统兼容测试，例如有些程序在IE6能运行正常，到IE5下不能运行。

有些程序在WIN2000下能运行，而到WIN98却不能运行。

像一些很特别的用户去使用系统，你很有可能发现BUG。

　　（13） 用户的易用性测试，往往用户的需求是不断的变化的，而其中的一部份变化的原因，是有用户操作上不方便引起的。

刚接到这个题目的时候也有一些犯难，：

测试流程在不同的公司都会有微小的差异，而这些差异就有可能会决定测试流程是否是真正适用。

在不同公司，不同的现状情况引入适合的测试流程，就好像如同在《寻秦记》中提到的剑圣，他的三个徒弟剑法的风格类型完全不一样同，这一点上，因材施教是非常重要的。

其实在动笔撰写本文的时候之前，我一直觉的感受到很大压力很大，这其中最重要的原因莫过于怕误人子弟了，。

测试流程的制定不是一门科学，而有时看起来，它更像一门艺术，一个好的测试管理者其实在面对不同的公司，不同的研发阶段，会采用不同的测试流程, 。

或是而同样的测试流程，为了真正达到执行的效果，执行的方法也可能不一样。

　　实施测试流程一般都是有两个原因，：

一是软件质量出现的了问题，虽然在某种程度上已经得到解决，但仍需要通过测试，把预防措施的方法找到并固化下来；还有另一个原因则种是软件研发的规模壮大，要求做的在流程上更加清晰，可靠更好。

我个人从我自己的角度出发最怕以下一某些情况是让人非常头疼的，：

一种情况是，是今天刚看了一本书，被告知说这样做是规范应该这样制定的，而明天就要引入进来，完全不考虑公司的实际情况；另一种情况是“苏联模式”，二是那种即某某大公司的测试流程如此制定是这样做的，我们也要采用相同的方法这样。

其实流程没有最好的，只有适合自己的，规范的测试流程不一定会帮助研发成功，反而在某些情况下会弄不好羁绊到自己自己的工作。

现在大多数测试人会犯一个共同的错误，往往——把流程设计的得很完美，但没有可操作性很差，无法帮助对于软件公司真正的目的——研发，并没有起到应有的作用成功，久而久之测试的重要性就无从谈起，测试团队也渐渐在公司变成次要部门，成为打杂的得不到应有的重视。

在流程的设计过程中，最重要的问题在于是目当前项目的特点是什么，产品经常出什么样的哪些问题，需要做什么怎样的调整，现有测试团队能不能做这样的能否做作出调整，研发团队是不是会不会能接收接受?

首先谈谈项目特点，按照项目特点，大致可以一般来说分成两类，：

一种是长期进行的项目，这种项目有基本的框架，有核心的技术，应用比较稳定，这种项目要注重测试用例的积累与复用，同时也适合做单元测试，自动化测试的积累； 

另一种是变更频度更高，灵活，规模不大的项目，如果做自动化测试则会出现二次开发的时间大于手工测试的时间，而且项目结束后测试用例在长期中也没有任何复用，在自动化测试人员普遍成本比较高的情况下，所以反而更适做功能测试。

虽然这两者可能在长远的目标上并不一致，但是引入测试管理平台，从测试需求，、测试设计，、缺陷管理等方面入手则是测试团队必备的技能。

一个好的测试流程必需要有好的系统平台的支撑，如果你把测试流程设计的得很完美，跟如同小学语文教科书一样，但执行这样的流程在起来现有的资源的情况下是未免不现实，倒并非说详细的流程是洪水猛兽，只是对于一家软件公司来说，资源的限制仍然是瓶颈所在的。

，那流程也就没有意义，一般来说一个执行的得好的测试流程必然会有好的平台，就像我以前所在国内的几家很有声名的软件公司，其测试平台要不是么是采购的，就要么是自己开发的，但最主要是要适合自己一套适合自身特点的流程平台起了非常积极的作用。

在这里也给大家建议一些好的测试平台，比如Mercury Interactive的Test Director，、IBM的TestManager,、Silk的一些缺陷管理平台，这些平台大多都能充分满足测试团队的要求其实都能满足大家的要求。

，当然，还有一些免费的开源工具也是可用的。

但从长远的角度看，我还是更建议大家读者使用那些不仅仅只是满足缺陷管理的工具，而是要应该选择能集成测试需求，、测试设计，、测试用例，、缺陷管理的工具，最好也能满足自动化的集成的，什么样的产品能满足就不多说了，免得有打广告之嫌J，而商业软件，如MI或IBM的产品在这些方面都有较好的表现。

　　项目特点决定流程的长期目标，但对于不同产品类型的公司，可能出现的问题往往会不一样同。

，比如说在金蝶的EAS-BossBOSS，、或是在金山做的游戏软件，、亦或还是在阿里巴巴做电子商务，作为测试管理者，就要具体的问题都应该区别对待。

对于EAS-Boss这样大型的软件产品，团队的规模比较大，核心技术比较稳定。

但对于这样的这样的产品有以下一些特点：

由于产品比较大，手工测试时重复的工作量特别大； 

引擎与产品框架比较稳定； 

编译与发布的流程比较固化； 

由于团队的规模比较大，接口特别多，集成测试风险特别高；。

　　这样种产品的测试，主要是把大量的重复频度比较高的功能测试转化为自动化测试角本脚本，在开发过程中要注意，核心引擎与稳定的产品部分，尽可能使用测