web游戏测试资料Word格式.docx
《web游戏测试资料Word格式.docx》由会员分享，可在线阅读，更多相关《web游戏测试资料Word格式.docx（45页珍藏版）》请在冰豆网上搜索。
将需求相关的问题引出到台面上
场景测试能有效暴露出产品设计上的缺陷。
需求是抽象的，有时只有在实际的运行过程里面才能暴露出问题。
这个实际的运行过程，就是场景测试。
综上，在游戏测试时，引入场景测试，对提升游戏的品质是十分必要的。
创建游戏场景的方法
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指示的循环执行一次的情况。
当我们的场景确定好以后，就要确定出每一个场景的测试用例。
生成测试用例的方法很多，这里就不一一累述了。
就说一下大的原则吧：
基本流的全面测试除了正面的测试用例外，还必须包括负面测试用例，以确保只有在符合条件的情况下才执行基本流。
对于每个备选流而言，至少存在一个负面测试用例。
每个场景只具有一个正面测试用例和负面测试用例可能是不充分的。
举一个结合游戏的实例
假设有这样一个活动：
玩家在特定npc处点击菜单后，可从一系列道具中随机获得一件。
某些道具有上限限制。
每个玩家只能领一次。
当随机到某些道具的时候，需要有走马灯提示。
用例：
与npc对话，领取道具
分析领取道具的整个基本流程顺序，得出基本流：
步骤1
与npc对话，选择领取菜单
步骤2
检查已领取状态：
检查玩家是否已经领取过奖励了
步骤3
检查背包：
检查背包空间是否足够
步骤4
随机道具：
根据既定规则，随机要发给玩家的道具
步骤5
标记已领取：
对验证码和玩家做已领取的标记
步骤6
发放道具：
把随机到的道具加到玩家背包中
步骤7
记录log：
记录领取时间，角色名
再考虑到玩家在领取道具的过程中可能出现的情况，得出备选流：
备选流1-玩家领取过奖励
在基本流步骤2中，如果是已经领取过奖励的玩家，即使用有效的验证码，也不能再发放道具
备选流2-玩家背包空间不足
在基本流步骤3中，如果玩家背包空间不足，给出提示，不发道具
备选流3-随机到达到上限道具
在基本流步骤4中，如果随机到的道具已到达发放上限，需要重新随机
备选流4-玩家活动贵重道具
在基本流步骤6中，如果玩家随机到了贵重道具，则发送走马灯消息
用例图解：
按照从“开始用例”到“结束用例”流经的路径，得出以下场景：
场景1-成功领取
场景2-已领取过奖励的玩家再次领取
场景3-背包空间不足的玩家领取奖励
基本流备选流2
场景4-随机到已达上限的道具
场景5-玩家领取到贵重道具
场景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.在游戏开发早期预留速度调整和用于中断的游戏控制接口。
对于测试过程来讲，测试者有需要简化和跳过一般玩家的长时间等待过程，但又要保持在这一过程中的数据可以与游戏正常运行时一般玩家同步变化，这就需要游戏开发过程中为测试预留出可以控制游戏速度的接口。
需要控制的游戏速度主要包括：
玩家资源获取的速度，建筑单位的建筑速度，科技研发速度，军队和其他物品的生产度，以及玩家单位在地图上的移动速度等。
需要特殊指出的是，由于测试者测试的是当前数值体系下的数值平衡问题，因此不应该提供给游戏测试者改变两个速度间相对比例的接口，换言之，游戏测试者需要的仅仅是一个调整游戏整体运行速度的接口。
另一方面，游戏测试者会有测试玩家离开游戏一段时间后游戏状况变化的需求，以及游戏测试者本人因为下班，休息或其他原因暂时离开游戏的需求，因此需要在程序上提供给测试者一个暂时中断游戏进行的接口。
这两个接口应该在游戏开发早期即预留，这样可以让游戏设计者在第一个可运行版本出来时即可开始初步的数值测试。
事实上，考虑到当前Webgame主流使用的页面脚本的后台开发模式，游戏策划可以在早期进行的测试应该是非常方便和快捷的。
2.为游戏设计测试提供自动化的脚本式的测试机器人。
无论我们的游戏在实际的玩家界面和功能上是否支持玩家连续指定多个任务（Ogame默认允许玩家安排长达10个的任务序列，其他战争策略类Webgame则大多将这一点作为收费点），游戏开发者都应该为游戏设计测试开发这一功能。
这将大大有助于提高设计测试的效率，并为一个测试人员同时测试多个角色，多个流程提供可能性。
为了达到这一目的，一个可能的程序架构原则是尽量粒子化各个玩家单一过程（例如升级1座兵营或者升级1级民房），并至少在开发测试过程中为各个玩家单一过程提供外部的驱动接口，从而从外部直接接受玩家的脚本式的测试指令集。
这一指令集的一个可能的形式是：
（官府（ID：
1）升级到2级；
建造民房（ID：
2）；
民房（ID：
2）升级到2级…………）。
当然，如果测试人员能够略有一点程序基础，将会大大有利于这一自动化测试流程的建立。
3.提供便于非开发人员使用的单一玩家日志。
事实上，我是支持在游戏的正式界面中为一般玩家提供查看个人行为日志的功能的，并且非常建议在服务器上尽量保留玩家的玩家行为日志，这将成为日后游戏设计者进行基于玩家游戏行为的数据分析和挖掘的基础，这一思路在传统的互联网运营和设计中是非常普遍的，但在游戏行业并没有得到足够的重视。
但至少，在游戏开发测试过程中，需要为游戏的设计测试人员（他们往往是非技术开发人士）提供便于他们使用的玩家日志。
这一日志将成为他们发现问题，以及发现问题成因的根本来源。
以前面讲到的《热血三国》的设计漏洞为例，玩家日志中频繁出现的人祸将成为游戏设计测试人员发现设计漏洞的一个重要着眼点。
事实上，在游戏的正式运营过程中，对游戏日志进行数据分析和总结，也是找到游戏设计漏洞的一个重要方法。
4.明确需要进行测试的玩家行为模式。
由于游戏设计测试往往是以10倍甚至100倍于一般玩家游戏过程的速度在进行的，因此的，我们需要更加明确我们需要关注的玩家行为模式有哪些，并将其映射到我们的测试环境下，来进行有针对性的行为模式模拟。
典型的需要关注的玩家行为模式包括：
（1）深度游戏玩家。
他们可以在自己需要的任意时刻保持在线，而且每天可以保持12个小时甚至更长的在线游戏时间。
对于这样的玩家，我们需要模拟的是长时间连续操作的游戏过程，以及一个模拟玩家每日在线12小时以上的周期性游戏过程。
（2）办公室型玩家。
他们每天白天可以基本保证长时间在线，但是他们每天的在线时间往往局限在上班时间的9小时内。
对于这样的玩家，我们需要模拟的是一个每日在线9小时以下的周期性游戏过程。
（3）夜晚玩家。
以学生和从事某些行业的工作者为主的，他们每天的主要游戏时间在晚上下班（放学）后的几个小时。
对于这样的玩家，我们需要模拟的是一个每日在线5小时以下的周期性游戏过程。
（4）不定时玩家，这些玩家可能以在校学生以及其他低端玩家为主体，他们往往以网吧为主要上网地点，游戏时间非常不固定，日上网时间也可能发生很大的波动。
对于这样的玩家，我们可以模拟一个以随机时间驱动的游戏过程。
（5）双休日及节假日现象。
双休日意味着会有一大批玩家频繁的出现连续两天半（即从周五下
班到周一上班）的离线情况，而节假日则意味着会出现（但不会频繁出现）大批玩家连续3天~7天不上线的情况。
事实上，只要游戏测试人员在游戏测试过程中有意识的停止一段时间的游戏操作，很容易模拟这一现象。
事实上，前文中《热血三国》的第一个设计漏洞恰恰出在了对于双休日及节假日现象的忽略。
5.明确需要达到和避免的玩家体验和游戏局面。
我们希不希望玩家每次在线都有事可作？
我们希望玩家被卡在建设时间还是资源上？
我们希不希望玩家的资源很容易达到城市的储存上限？
在各种玩家行为流程下，我们希望各种负体验设置（例如天灾人祸）以多大频度发生？
诸如以上的设计目标越明确，测试时越能做到有的放矢，测试效果也会越好。
事实上，如果设计测试者能够将这些设计目标量化为明确的数值目标，那么我们的程序开发者完全可以将这些设计目标作为游戏系统的报警机制，从而在这些设计目标被突破时直接给予游戏设计测试者以反馈。
这样的测试流程效果会大大好于盲目的体验式测试。
另一点需要指出的是，由于设计测试过程往往处在一个高速的非正常的游戏过程中，因此诸如“玩家建造一个建筑所需时间造成的体验”这样的问题是不适合于在我们的测试过程中去解决的。
建议对这一测试过程不够了解或者存有疑虑的朋友可以去尝试一下Ogame的第三方服务器，该第三方服务器提供了管理员随时手动管理游戏速度的功能（事实上，这一功能的开发难度基本可以忽略），从而使得我们可以很直观的体验游戏中一个玩家整体的发展流程。
一个额外的话题是，当你在游戏中发现以100倍速升级一个科技需要几十个小时时，大概你也会感觉到在标准的游戏过程中这会带给玩家什么样的体验了。
深度解析：
游戏文案策划
文案策划主要负责的内容是游戏文字相关部分的工作，包括游戏“内”和游戏“外”。
表面上看来，游戏文案策划的工作似乎不是游戏的核心，但实际上游戏文案策划却是游戏文化中相当重要的组成部分，缺少他们，游戏文化的魅力将大打折扣。
他们是将游戏世界付诸文字，将其具象化的实施者，同时他们还是游戏周边化的重要参与者。
光有好的文笔并不足以成为一名出色的游戏文案策划。
一般而言是先有游戏，再有游戏文案策划，需要其在有限的创作范围和时间内完成任务。
游戏文案策划还需要合作的协调性、对游戏性的了解、收集分析资料等多方面能力。
好的游戏文案策划,不光要有过人的想象力、创造力，还要学会使用一些必要的资料。
策划一个历史游戏的时候，兵器的名字你就不能靠想象，而是靠翻阅历史资料。
但仅仅查阅是不够的，一个好的游戏剧情设定和剧情不是靠各种资料拼在一起，灵活运用资料需要时间的积累。
根据不同公司架构及不同项目内的职业分工，一般而言，其工作范围主要包括以下内容：
游戏“内”
按照游戏主策划的设计要求，设定、撰写游戏的世界观并具体展开，以达到游戏主策划的世界观设定要求等。
游戏“外”
撰写玩家手册、宣传新闻、各类公告、论坛文章、网媒平媒文章以及市场需求等文档；
根据游戏剧情设计的内容，撰写游戏周边小说等文字读物，丰富游戏周边内容等。
就国内情况而言，文案策划的职位多半只在RPG类型或具有RPG风格的游戏项目的开打中才具备。
故本文所述的内容，也主要以RPG游戏的角度出发，同时集中于游戏“内”的相关工作。
一、文案策划的工作
在国外，除系统与世界观、背景剧情等结合极其紧密的游戏外，剧情、脚本和对话大都由专业的作家或专职游戏作家写好；
某些具体的特殊对话，则由关卡设计师和游戏设计师一起讨论后进行调整。
当然，如果策划经验比较丰富，游戏剧情和对话会由他们直接完成。
至于那些剧情对游戏内容影响不大，剧情只是以游戏内容表现为中心进行搭建的游戏，可能会在游戏各项内容确定之后再找人撰写脚本。
无论哪种情况，关卡设计师都对文案部分内容拥有一定的权力，可以根据自己关卡的需要对具体对话和剧情描述进行调整。
那么在游戏开发中，文案策划具体的工作内容有哪些呢？
1．建构游戏世界观
无论电影还是小说都需要一个背景舞台，游戏也是一样。
于是需要有人来讲述这个世界的来龙去脉及现况。
然后才能在上面展开故事、玩家也才能在这个世界上游弋。
这一部分就叫做世界观搭建。
就游戏而言，世界观是灵魂也是铁则，游戏中表现出来的一切都不可与世界观相悖。
升级会员 