前言
编写目的
- 编写出一份可在日常工作重复使用的测试用例库，提高工作效率。这件事情最早在2013年就提了，只是一直未能真正去做，中间只零零散散完成了很小一部分。回顾以往的工作内容，发现自己还是写了很多的测试用例的，有不少重复的，加上现在的工作内容总是需要应对新的游戏产品，做这件事所能带来的效益就变得更为明显了。
- 提供一个分享交流的基点。很多人都觉得游戏测试简单，甚至认为就是玩游戏，从业选择上测试也确实是很多人的次级选择。但从我个人工作的经历来说，游戏测试还是有很多值得交流的思想，可以分享的经验的。水平高也好，低也罢，明明白白地说出来，提供一个讨论的平台，也许会吸引一些感兴趣的人的。
- 锻炼自己系统性的表达能力。我个人有记录的习惯，从2009年工作至今，写了不少工作日志、读书笔记、想法总结等等，内容大多粗浅、零散，不好拿来示人。正好借着写这本书的机会，将一些个人想法和方法描述出来，也是做一个整体的梳理。
- 普及基础的测试方法和流程。一方面希望大家能够更容易发现游戏的bug，从而倒逼游戏开发商重视产品质量，提升游戏体验；另一方面也是希望将来的游戏开发能够更加规范高效，避免纠结太多的细节问题，把心思和精力更多地放在玩法设计和交互体验上来，做出更好玩的游戏。
内容结构
请注意：本书中所有涉及到测试（甚至部分非测试）的工作方法，都遵循这样的TDD测试驱动的思想：
- 明确目标，划定范围；
- 结果预期，追求量化；
- 组织结构，细化流程；
从测试驱动思想当中，我们其实不难看出，所谓的测试方法的设计不是最难的，最难的是如何建立对测试对象清晰、准确的认知！你越清楚你要测的是什么，你就越容易知道该怎么去测它。
整本书的内容主要分为四块：
- 介绍一些游戏测试的相关概念：游戏基础的结构、测试的工作流程、如何写测试用例、如何提交bug等。
- 游戏中常见功能的测试用例：例如登录创角、背包、任务、副本等，一些重要的测试点以及测试思想会再强调和解说一下。
- 分享个人经历的一些较为奇葩的问题：大部分是功能设计方案的问题，其实主要是工作方法和工作态度导致的。
- 最后聊一聊质量管理：如何把控产品质量，如何做项目管理。
Q&A
有关测试用例对应的游戏类型的说明
测试用例库针对的游戏类型主要是基于手机移动端的MMORPG。选择移动端，是因为适用范围广，PC端的游戏开发周期较长，新手可以有更多的时间去学习和摸索；而选择MMORPG是因为其最具代表性，在中国市场也是所有大型游戏中最容易上手和被接受的类型，可以说MMO是一切游戏演化的最终形态。
有关测试用例模版格式的说明
测试用例库最终的呈现方式还是excel表格，毕竟是强调实用，表格下载下来之后，根据实际项目内容和自身的需要进行调整就可以了，然后填写测试结果，很便于执行。 首先，测试点是按照功能模块来划分的，然后每个功能模块中的测试用例分为1、2、3三级。1级表示的是这个功能的主要流程或核心内容，是一定不能出错的；2级表示涉及到比较隐晦的实现逻辑，通常是最容易出现严重bug的地方；3级是对程序实现的方式乃至整个程序框架的探索，进一步了解产品特性，可能会有意外收获。测试计划中常说的单服测试，就是要确保1级和2级用例的通过；集成测试一般要覆盖到1+2+3级，这样才能确保不会有遗留；最后发布测试也是快速验证1级用例的正确性，因为发布之前可能功能有所修改或修复一些bug影响到原来正常的功能。 其次，每条测试用例主要包含四个部分：测试的目标（你要验证什么），前置条件（测试之前需要准备怎样的环境或达成什么条件），执行步骤（如何去操作进行验证），预期结果（期望执行后获得怎样的结果）。这四个部分构成的就是科学的做事流程：猜想→实践→比对结果→再猜想或确认结果（这里最好是个循环图）。当然，还有其他的部分，例如相关的功能名称、设计文档、相关的设计和开发人员、用例编写人及编写时间、用例备注、测试结果的记录等，具体如下图：（这里需要放一个测试用例库的模版图）
有关用例内容和覆盖度的说明
首先要说明的是，所有的测试用例都是我从头开始，一个字一个字写出来的，绝不存在任何抄袭的情况，也不是拿以往的工作文档来改写的，不存在泄漏商业机密的问题，所有东西都是基于发布过的产品内容。我是先整理了以往八年的日志记录，从中梳理出了自己做过的所有功能测试，然后选出最通用的模块，从测试点重新总结需求，只保留最基本的功能目的，然后再基于需求重新写测试用例，而且我可以保证，我写的内容跟我当初所做的是一致的，不会用一些没有实践过的理论来忽悠大家。当然，这其中也必然存在问题，第一个是内容受限于我个人经验经历，水平有限；第二个是时隔太久，有些内容整理和思考必然会有错漏，如有发现还请告知，一定第一时间修改。 一般没有什么较为特殊设计的功能，基本能涵盖到80%~90%，即便有特殊的内容，应该也不会违背一些常规的测试点。
有人说玩游戏有什么用？甚至认为玩游戏不好
首先，简答来说，玩游戏确实没什么用，我不会扯什么可以开发智力，调节情绪。玩游戏带来的更多的是一种体验，就像看书、绘画、影视一样，而游戏会将各种感官综合起来，再给予良好的反馈互动，让你可以参与其中，喜欢游戏的人就只是喜欢。现在电子游戏像一些古老的游戏一样，被认可为了一种体育竞技，“更高更快更强”已经不仅仅只是我们肉体的追求了。 那些说玩游戏不好的，甚至指责游戏是电子毒品，令人沉迷，有一定的道理。但说实话，这个世界上没有了游戏，沉迷的人还会继续沉迷于小说、动漫、电视剧等，沉迷的人只是缺少自控能力，跟沉迷的事物不相干，这跟毒品的生理依赖性还是不同的。我也承认现在确实有一些游戏制作粗暴不说，还想尽办法从玩家那里捞钱，但这本身也不是游戏的错，我觉得是玩家本身素质还不够高的问题。就像以前看过的一集美剧中，导演兼男主向观众吐槽，现在拍的剧根本不是他想要的，在他看来太糟糕了。而导致这样结果的原因是因为你们这些观众，你们愿意接受这种粗制滥造的东西，愿意花大量的时间和金钱去看这样的东西，那导演和演员只会去满足你们。游戏也是如此，玩家愿意为了追求一时的爽快感，愿意在垃圾游戏里花钱，享受他人羡慕嫉妒恨的目光，游戏开发商说到底也是生意人，他们当然就愿意做更多快餐游戏来收割金钱了。这样的厂商一多，游戏同质化就越发的严重，于是导致渠道为王的现象，同样的游戏产品，谁被放在更吸量的地方，谁就能赚取更多的金钱。于是渠道愈发地强势，进一步挤压游戏开发厂商的生存空间，最后玩家能看到的都是千篇一律的烂游戏。这跟国内的网络小说、电视剧、电影、甚至是音乐都是相同的问题。虽然现在提倡所谓的内容为王，但千万不要觉得大家开始重视内容生产商了，其实说白了，渠道发现钱不好赚了，就放松了收割，等待“猪肥了”之后，再进行一轮收割。只要用户本身的质素不提升起来，这样的事情永无止尽。 当然，我本人其实对于游戏一直抱有一个幻想，将来的游戏在体验的真实性和参与的自由度上做出极大的突破，也许将来每个人都可以选择在自己喜欢的游戏里生活、学习、历险，仿佛平行宇宙那样，每个人甚至可以经历几世，几种不同的人生。
会不会需要很长时间才能完成，甚至最终半途而废
很有可能，但我也依然决定继续尝试下去，如果最后真的半途而废了，我希望是因为自己找到了更重要的事情去做，而不是因为觉得太过困难而放弃的。如果我真的放弃了，大概也只能说明我只能做到这种程度，我也更加实际地知道了自己的极限。
既然要写测试用例库，我是不是应该针对每种游戏类型，甚至每个具体的游戏写测试用例呢？以数量来取胜？
我觉得这个想法值得试一下，这是我某一天早上突然想到的，因为觉得测试用例库为了确保其实用性，就只挑了一些比较通用的模块来写测试用例，但实际上，不少测试点也包含在不同的游戏类型中，如果真的想要实现库的量，那就真的得拼命上了哦……
如果有人说这个写的这么烂，还这么多错误,有关内容错误或提建议的说明
也许是不够好，但应该还不够至于到烂的程度，至少我带过的十几个人都是按照这种方法来的，而他们在加入新的团队后都还能用这套方法上手工作，所以应该还是可用的吧。至于担心被别人指责，是会比较在意，人之常情嘛。但我解决的办法就是预想下这样的情况，然后把这种担忧写下来，再自问自答自己的一些想法和心理准备，这样即便将来真的遇到这种情况，回头一翻看笔记，发现在预料范围内，反而就没有那么难受了。人最大的恐惧来源于未知，最多的伤害来自于忘记。 同时我会留下自己的邮箱，也可以留言吐槽，我都会尽快回复和进行改正。如果你的建议切实可行，我会给予一定的回报。
有关测试个人成长和职业发展潜力的讨论
这个问题会在质量管理中的人员管理部分去细说，请点击传送门。