1、成员结构
以常规的测试团队人员来划分（仅功能测试层面）：1个Leader＋Ｎ个功能测试人员（一个比较好听的名字：游戏测试工程师，Ｎ可能会等于0）＋1个配制管理（此角色有的团队Leader负责，或者程序负责），这是一个常规的标准配制。依据项目的规模人数上有可能会有变动。
一般项目的人员数配制参考
· 端游项目：1Leader+4~5功能测试人员+1配制管理
· 页游项目：1Leader+2~3功能测试人员＋0?1配制管理人员
· 手游项目：1Leader+1~2功能测试人员＋0?1配制管理人员
2、内容划分
· Leader：负责整个项目的测试工作划分，风险评估，测试难点分析，报告产出，测试进度把控
· 功能测试人员：依据个人负责的模块，进行版本中的功能测试/配制表测试/交叉测试。
· 配制管理人员：发布供测试人员使用的版本，版本文件管理。更新测试环境的测试版本。搭建测试环境
3、文档&BUG
· Leader:项目立项初期，需要编写整个项目的测试计划、测试策略；项目开发过程中，缺陷总结报告、版本总结报告
· 功能测试人员：依据需求文档，编写测试用例，维护测试用例，执行测试用例，提交bug，跟进bug
· 配制管理人员：不停的发布版本，更新版本，取Log
4、常见问题
项目没有缺陷管理工具，作为一名测试人员，要怎么维护缺陷？
· 强烈不推荐使用Excel来维护缺陷。现在市面上的缺陷管理工具很多，免费的也有，破解的也有，作为游戏测试人员，一定要学会用工具来管理缺陷，而不是合适Excel来维护（不是诋毁Excel，只是维护缺陷太蛋疼）。如：禅道、Jira
· 当然有人会说，我们项目人家原本就没有缺陷管理工具，让开发和策划去使用工具，人家不愿意看，也不想用。这个时候，就要放你们的Leader出去，跟策划和程序去沟通，工具只会提高效率，不会增加他们的额外工作。而且工作来管理的话， 后面缺陷的统计和管理也会事半功倍的。
程序员、策划对测试人员提交的缺陷修改不及时？我的工作经常受阻
· 方法一：死缠烂打，效果比较明显。经常去烦他，他受不了就会去看你提交的缺陷。
· 方法二：找自身的原因，是否每次你提交的缺陷描述，人家都能正确的重现问题。有时不是别人不想改，只是看了一下没看懂，不想花时间。每个人都有自己的工作的?
· 方法三：私下与自己配合的人员把关系搞好，有啥问题好沟通，好基友么，有啥都好商量。
· 方法四：向上级汇报。如果你真碰到了那种工作没积极性，不好好配合，也不好沟通的人。没有啥不好意思的，你这样被拖着，只会影响自己的工作。
测试人员提交的bug被否定，怎么办？
· 第一次被否定，找相关的负责人再沟通下，如果还确认是问题，请看下面
· 多思考下自己提交的是不是真的问题。如果确认是问题，请坚持一会。但不要太久，游戏原本就是制定一个规则，但里面有时，真的没有真正的对错。
· 如果真是问题，那出现的几率是多少？如果真的几率太低的话，就放一放吧，等后面再出现，再让负责人来修改。不要被一个问题卡住
相关文章：
