按照測試計劃，我對本次項目進行測試實施：

用户界面UI测试

• 测试范围：背景、颜色、字体、形状、按钮
• 测试目标：核实各个窗口风格（包括颜色、字体、提示信息、图标、TITLE等等）都与基准版本保持一致，或符合可接受标准，能够保证

  用户界面的友好性、易操作性，而且符合用户操作习惯

• 工具与方法：在pc上运行程序，看是否符合功能需求

功能测试

• 测试范围：控制、效果、音效、特效、通知、弹框
• 测试目标：核实速度及方向准确性，特殊效果时的界面弹框及击杀音效等是否符合功能需求
• 工具与方法：运行代码，逐一检测各项功能的可行与稳定

基本概述

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

1. 测试的目的是发现软件中存在的缺陷。
2. 测试都是需要测试人员按照产品行为描述来实施。产品行为描述可以是书面的规格说明书，需求文档，产品文件，或是用户手册，源代码，或是工作的可执行程序。
3. 每一种测试都需要产品运行于真实的或是模拟环境之下。
4. 每一种测试都要求以系统方法展示产品功能，以证明测试结果是否有效，以及发现其中出错的原因，从而让程序人员进行改进。

测试流程

1. 游戏开发公司通过各种调查、评估，确定自己要开发游戏的范围或者项目。比如确定音乐类，或者MMORPG等等。然后测试就需要对市面上的此类游戏(主要是比较热门的此类型游戏)进行测试，测试分工分别去玩和开发项目相同类型的游戏。比如音乐类:一个去玩劲舞团、一个去玩DJ……以此类推。然后通过一段时间的游戏，对这个游戏做出一个全面的测试报告:可玩性、功能方面、画面、性能、所需配制、社群体系等等。(产品说明书的形成)
2. 游戏开发阶段，随着游戏文档说明、策划案例的编写和游戏初期版本的形成。就可以去编写最早期的测试规范、测试计划和测试用例等等。其实游戏测试的用例相对软件测试的用例会庞大很多，游戏本身就是一个比软件功能多很多的软件，自然用例分的地方也会多很多，可以分:单人、多人、主流程、对局里等等。(产品设计文档、测试文档初期形成)
3. 随着游戏初期版本的形成，公司会联系游戏运营商共同去合作开发此游戏。也就是去找客户了，当然有的大型公司自产自销就另当别论了。有了合作伙伴，其实是客户。客户自然会对游戏提出种种需求，对版本提出各种意见，还有各个版本交纳的时间和游戏内测公测时间等等细节。(进度表、客户需求形成)
4. 根据客户的种种需求，游戏会进行变化。经常是新出的版本和上一个版本会有天壤之别，感觉不是一个游戏。策划也会出来很多新的文档，这时候就要对文档进行测试，也就是静态测试。很多人认为静态测试没用，个人感觉静态测试很重要。虽然我在的公司不重视……扯远了。这个时期测试会比较忙，又要进行静态测试，又要写测试用例，还要进行功能测试、性能测试、压力测试，然后还要对客户进行游戏的演示。每个版本提交时候更是要疯狂的测试，每到这时候基本上要一直加班，基本11点前没到过家。然后还要和客户方的测试进行交流，回答人家的各种问题等等，测试用例、测试报告要提交给人家，各种回归测试等等，反正是忙的一塌糊涂。
5. 经过一段时间的版本更新，进入到了内测后期和公测阶段。这时候会出一些游戏相关的东西，比如GM TOOLS等等，还要对此进行详细的测试。其实GM TOOLS单拿出来都能叫软件测试了!

可玩性测试

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

1. 游戏世界的搭建，包含聊天功能，交易系统，组队等可以让玩家在游戏世界交互的平台。
2. 游戏世界事件的驱动，主要指任务。
3. 游戏世界的竞争与平衡。
4. 游戏世界文化蕴涵，游戏的风格与体现。

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

1. 内部的测试人员，他们都是精选的职业玩家分析人员，对游戏有很深的认识，在内部测试时，对上面的四点进行分析。
2. 利用外部游戏媒体专业人员对游戏作分析与介绍，既可以达到宣传的效果，又可以达到测试的目的，通常这种方式是比较好的。
3. 利用外部一定数量的玩家，对外围系统的测试，他们是普通的玩家，但却是我们最主要的目标，主要的来源是大中院校的学生等等，主要测试游戏的可玩性与易用性，发现一些外围的Bug。
4. 游戏进入到最后阶段时，还要做内测，公测，有点像应用软件的beta版的测试，让更多的人参与测试，测试大量玩家下的运行情况。