浅谈游戏测试
吴彬
2010-8-26
1
目录
2
网络游戏发展史
第一代网络游戏
第一代网络游戏（1969年-1977年）
4
5
第二代网络游戏
第二代网络游戏1978年--1995年，
6
7
第三代网络游戏
第三代网络游戏1996年--2006年
8
9
10
第四代网络游戏
无端游戏（WEBGAME）的兴起
11
中国网络游戏的发展史
12
黑暗之光
石器时代
千年、龙族
传奇、奇迹、天堂
魔兽世界、奇迹世界、卓越之剑等
2005
2000年开始代理潮
韩国
日本
韩国
韩国
美国、韩国
13
2001年开始国内原创
第四世界
金庸群侠传OL
大话西游OL
古龙群侠传OL
大话西游、天龙八部、完美世界，
征途、魔域等
14
15
游戏测试介绍
游戏测试产生的背景
17
游戏测试的起因
近几年来，网络游戏成了网络最新的弄潮儿，从盛大之传奇般的掘起，吸引了无数公司的眼球。但由于随着玩家的品位的升高，代理费用的上升，单一的代理国外游戏的模式已经很难在国内立足，而有中国传统文化特色的网络游戏则在国内大受欢迎，比如剑侠情缘，大话西游等一些国内的精典之作已经进入了一流网游的阵营。与此同时随着大家对网游稳定性，可玩性要求的升高，网络游戏测试开始成为大家关注的话题。
国内游戏测试的现状
19
20
游戏项目与软件项目的区别
21
游戏测试与软件测试的共性
23
传统软件的开发过程
接受订单
需求分析
设计文档
程序设计
程序实现
集成测试
阿尔法测试
贝塔测试
软件发布
传统软件的开发过程
游戏软件的开发过程
定位用户群
策划案测试
策划案
。。。。。
游戏发布
更新、维护
游戏软件的开发过程
25
游戏测试的定位和意义
游戏测试在开发中的定位是什么呢？玩游戏找bug？显然是错误的。
26
游戏测试的特性
27
游戏可玩性测试
游戏世界的搭建
游戏世界事件的驱动
游戏世界的竞争与平衡
游戏世界文化蕴涵
1.游戏世界的搭建，包含聊天功能，交易系统，组队等可以让玩家在游戏世界交互的平台。
2.游戏世界事件的驱动，主要指任务。
3.游戏世界的竞争与平衡。
4.游戏世界文化蕴涵，游戏的风格与体现。
28
工作原理
联动&关系
推广&引导
设计
过程
技术
要了解如何测试游戏必需了解如何做游戏，
了解它的开发过程，才能真正的测好游戏。
29
游戏测试的思维方式
使用面向对象的思想进行测试
面向对象的概念。
30
如何用面向对象的思想进行游戏测试?
我们的游戏是一个产品,是一个存在的实体,因此,我们把这个"实体"当做一个大的对象开始分析,整个游戏由哪些部分构成,而构成整个游戏的大的部分又由哪些组件构成,认真分析完这些以后就可以着手进行测试了,注意,这里说"可以进行测试了"意思不是马上就能进入测试,
“工欲善其事,必先利其器”---某位高人说的,我们做测试也是一样,分析完毕后,我们要做的还是分析 ， 不过这里的分析和之前的分析有点点区别,这里我们需要分析的是具体功能的关键测试点和风险点,测试不能盲目,打蛇要打七寸.....在这里我们就是把某个具体的功能作为一个对象，我们要分析组成这个功能的是哪些因素，一共有哪些测试点，哪些测试点是关键点，哪些是高风险点，一一列举出来,这样我们就一目了然了，然后就是我们打算采用何种方式来进行测试，这里就是方法了.测试的方式可能有很多种(比如在不同的操作系统下进行测试等),因此我们也需要一一列举，此外我们需要分析的还有测试过程中我们需要用到的具体测试手法、具体的数值、特定的环境等等这些就是属性，当然这些我们也必须整理出来。
将以上提到的对象、方法、属性整理成文档就是我们测试时所必须的测试用例了。当然，还是老话，测试用例的优劣是以覆盖面来评判的，这里就需要经验了，简单说就是靠累积以及学习。
在这里阐述的是一种测试的思想，个人觉得测试除了要有扎实的相关基础知识以便更深入的了解产品以外，更重要的是测试思想，具备了完善的测试思想才能有计划的完成每一步测试，从而提高测试的效率，保证测试产出的质量，也更好的保证产品的质量。
说回游戏测试，游戏开发是一个迭带的开发模式，因此测试工作往往会有很大的随机性，因此当我们接到一个新功能时，首先要明确我们要测得这个功能是做什么的，有什么用，这个功能怎么使用。OK，我们了解了这个功能是什么，能做什么就可以开始细化分析了：这个功能共由哪些子功能组成，这些子功能是否有自己的子功能点，一层层的分析下去，然后就是从最底层的功能点分析：这个功能什么情况下要发挥其功效，发挥其功效的因素有哪些，怎么样去发挥具体的功效，该功能有没有相应的容错机制，这些就是我们的详细测试点和测试手法。然后向上一层一层分析，一直到最顶层就是我们的功能完整的测试方针。这样我们就把面向对象的思想完全用到了测试中。
31
乐港游戏的研发流程
乐港游戏的人员构成
乐港游
戏团队
制作人
策划
美工
程序
QA
运营
市场（推广）
客服
乐港游戏测试流程
乐港游戏测试流程
测试项目前期准备阶段
2
测试计划制订及管理阶段
3
4
5
策划案评审及测试设计阶段
测试用例开发及管理阶段
测试执行及输出报告阶段
1
36
游戏测试各阶段工作量分配
游戏更新版本测试执行策略
游戏新版本
冒烟测试
执行人员分为二部分：该版本的主要开发人员，该版本的主要测试人员
39
随机测试
执行人员：如果时间充足项目组全体人员，如果时间紧张具有丰富的测试经验或对测试产品熟练的测试人员进行
40
回归测试
执行人员：测试人员
要点：1.各测试阶段发生的修改一定要在本测试阶段内完成回归，以免将错误遗留到下一测试阶段2.回归测试期间应对该版本冻结，将回归测试发现的问题同一集中修改，集中执行回归测试
41
测试组必须遵守的规范
BUG的严重等级定义规范
BUG的提交规范
测试设计规范
测试报告规范
测试报告发送范围规范
游戏测试完成条件
测试完成条件
测试进度
继续测试缺陷密度
测试成本
测试用例执行率
需求覆盖率
剩余缺陷等级及数量
质量保证部发展方向
价值体现
1）预防缺陷体系---节省公司开发成本
（2）研发项目的各里程碑质量控制—检验是否走对方向
（3）对公司产品的功能性、可玩性和稳定性进行全面测试和把关，尽可能的降低上线的缺陷---提高产品质量
（4）为高层提供服务：即部门将产品的风险评测报告提供给高层，由高层作出有关决策---给高层决策提供专业的依据
45
如何去控制产品风险？
监督组
测试组
46
产品风险控制
规范、流程、标准
部门建设
组织架构
定岗定职
内训机制
竞争上岗
工作考评
47
质量保证部新的组织架构
质量保证部经理
质量监督组组长
平台测试组长
自动化测试工程师
性能测试工程师
游戏测试组长
PQA工程师
游戏设计测试工程师
游戏性能测试工程师
游戏测试员
GQA工程师
测试设计工程师
游戏测试员
竞岗机制
（1）对目前空缺的职位进行竞岗述职。（一些技术性岗位需进行考试）
（2）项目测试负责人的竞岗 。
工作考评机制
进行工作评分制。（每个项目结束后进行对参与人员进行评分，评分内容包括：工作量，用例覆盖率，执行用例率，有效单，重要单，有效建议值，线上错误单）
部门内训机制
培训采用积分制，一个季度结束后发放培训经费。
一个小时积2分，一个小时奖励培训费25块钱。一个季度一结算。组长的绩效考核里面有5分为培训分。组长以下人员培训有加分最多加至5分
每次培训完成后有打分，得分在80分以上为有效培训
51
下期预告
《游戏测试精通系列讲座》
敬请期待
Thank You!
53
质保部工作过程
乐港科技有限公司
质保部工作过程
拟制部门：质量保证部
版本号：
项目测试流程
目 录
1. 目的和范围 4
目的 4
范围 4
2. 名词解释 4
3. 测试类别 4
4. 使用工具 4
5. 质保部工作过程 5
概要图 5
项目立项阶段 7
启动条件 7
质保部主要活动 7
确认事项 7
测试项目前期准备阶段 7
启动条件 7
主要活动 7
输出 7
测试计划制订及管理阶段 7
启动条件 7
输入 7
输出 8
策划案定稿阶段 8
启动条件 8
输入 8
主要活动 8
输出 8
测试设计及管理阶段 8
启动条件 8
输入 8
主要活动 8
输出 9
关闭标准 9
测试用例开发、管理及评审阶段 9
启动条件 9
输入 9
主要活动 9
输出 9
关闭标准 9
测试执行阶段 10
启动条件 10
输入 10
主要活动 10
输出 10
关闭标准 10
测试报告和总结阶段 11
启动条件 11
输入 11
主要活动 11
输出 11
线上反馈阶段 11
启动条件 11
输入 11
主要活动 11
目的和范围
目的
本规程的目的是规范部门工作，为部门工作过程提供详细的指引。确保公司质保部体系的正常、高效的运作，提高公司产品的质量
范围
本文档适用于乐港所有产品
名词解释
· 黑盒测试：不基于内部设计和代码的任何知识，而是基于需求和功能性
· 功能测试：用于测试应用系统的功能需求的黑盒测试方法
· 集成测试：一个模块的各个部件的联合测试，以决定它们能否在一起共同工作
· 系统测试：基于系统整体需求说明书的黑盒类测试，应覆盖系统所有联合的模块
· 回归测试：软件或环境修复或更正后的“再测试”
· Alpha 测试：在系统开发接近完成时对应用系统的测试；测试后，仍然会有少量的设计变更。
· Beta 测试：当开发和测试完全完成时所做的测试，而最终的错误和问题需要在最终发行前找到。
测试类别
测试开发使用前述的测试方法进行。整个测试开发工作分成二大部分：
· 功能测试开发。功能测试的开发，分成两大部分，即Test Requirement（测试需求）和Test CASE（测试用例）的开发
· Test Requirement。从策划案转化过来，并按照选择好的方法，通过分类、列举、等，对需求进行分析、细化，形成一个需求树
· Test Plan。通过将需求树转化成一个测试用例树，形成测试用例的框架。为测试用例的每个细目开发测试步骤、预期结果。
· 回归测试开发。回归测试的主要目的，是要确保新的版本，其变更的部分，不会影响到原有功能的正确性，性能满足应用的要求。回归测试的开发，不是完全重新开发，而是在原有测试用例库和脚本库的基础上，选择合适的测试集。在某些情况下，还可能出现原有测试用例库和脚本库不能覆盖最新变更的情况，需要新增测试用例和脚本。总之，回归测试，是一个基于变更的增量开发，相对而言是以测试执行和bug跟踪为主要活动的过程
使用工具
目前公司的使用工具如下：
· 配置管理工具：svn ，VSS
· 测试BUG管理工具：Mercury Quality Center
质保部工作过程
概要图
游戏软件测试开发、管理流程贯穿了项目的整个开发和测试生命周期，与整个游戏软件开发过程基本上是并行进行并相互协调的。测试流程图如下图所示：
项目立项阶段
由创新研究院评审决定项目开启
启动条件
项目召开立项会议，确定项目建立
质保部主要活动
质保部的质量监督组明确项目范围、项目方向、类型、项目目标、项目需求以及项目工作职责。
确认事项
质量监督组对几个里程碑版本开发计划确认。
测试项目前期准备阶段
质保部内部通过竞争上岗机制选出项目测试负责人
启动条件
项目的召开立项会议，确定项目建立
主要活动
· 项目测试负责人在测试管理工具：Mercury Quality Center 中建立项目空间——以项目名命名
· 给项目所有成员分配相对应的使用权限
· 项目空间中包含测试需求模块
· 项目空间中包含测试用例模块
· 项目空间中包含BUG管理
· 项目空间中包含测试执行模块
· 项目测试空间建立完成通知项目组相关成员
输出
项目测试负责人和项目测试管理空间
测试计划制订及管理阶段
启动条件
根据批准的项目的第一个里程碑开发计划安排和需求，组建项目测试组，确定项目测试必需的资源，确保测试工作有序、有效进行
输入
项目进度计划、概要需求
主要活动
· 分析项目概要需求，在测试计划中确定项目的测试方法和测试类型，如功能测试、性能测试、兼容性测试等
· 明确项目测试的目标和需求
· 项目测试负责人确定项目测试重点和测试范围
· 项目测试负责人确定测试所需人力资源配备，并确定相应职责工作
· 项目测试负责人初步估计测试项目工作量、成本。制定测试各阶段的进度安排，测试进度安排中要留有合理的测试用例管理、BUG管理的时间
· 项目测试负责人明确本项目测试中BUG管理，还应该包括测试阶段的BUG的处理准则
· 项目测试负责人估计项目测试过程中可能产生的风险或问题，并在测试计划中提出
· 形成测试计划文档并提交质量监督组审核并给予指导。
· 当项目开发计划或测试需求发生变更时，同时变更测试计划文档并重新提交质量监督组审核。
· 通过审核后的测试计划由项目测试负责人以邮件形式通知各相关人员
输出
测试计划
测试计划以邮件形式【测试计划】【质量保证部】XX项目测试计划通知所有项目主要负责人：CTO，制作人，质保部经理。
策划案定稿阶段
启动条件
策划案制作部内部定稿完成后，冻结制作部策划案文档
输入
制作部冻结后的策划案和其他相关设计文档
主要活动
· 制作部内部定稿完成后制作部以邮件形式通知质量监督组组长
· 质量监督组按照开发计划中涉及到的模块和功能点进行对比，检查是否有遗漏的策划案没编写。
·
质量监督组组长组织质保部内部策划案的评审，跟据策划案评审的checklist要点进行评审，策划案评审checklist见
· 通过之后制作部上传SVN。
输出
跟据策划案评审的checklist要点进行评审，一些设计上的问题根据模块整理成word文档通过邮件【工作反馈】【XX测试组】策划案评审反馈--及时反馈给主策，抄送给策划总监，GP
测试设计及管理阶段
启动条件
经过制作部和质保部定稿的策划案
输入
定稿后策划案和其他相关设计文档
主要活动
· 项目测试负责人组建该项目测试设计人员
· 项目测试负责人定义测试范围——测试任务、目标、策略
· 项目测试负责人建立测试框架，确保测试设计符合测试范围
· 项目测试负责人领导其测试设计人员分析需求，通过建立用例流程图来定义所有的测试需求
· 测试设计人员细化策划案，为策划案上的每一个模块功能点都创建一组详细的测试流程图，添加测试说明，设定其优先级
· 质量监督组对其测试框架和测试设计文档进行评审
输出
测试设计文档
关闭标准
测试设计评审批准通过
测试用例开发、管理及评审阶段
启动条件
评审通过的测试设计文档
输入
策划案、 测试设计
主要活动
活动1—用例设计
· 测试设计人员设计测试步骤。为需求树中的测试添加测试用例完成手工测试的开发。在测试用例中，按照测试用例编写规范，制定每个测试步骤，需要说明测试的操作及预期结果
· 测试设计人员设计测试编号。按照测试用例的详细编号规则制定
· 项目测试负责人创建测试覆盖。把每一个测试用例和对应的测试需求关联起来
· 测试项目负责人构造测试实验室。把应用分成要测试的一系列功能，通过分解需求树，覆盖最小需求路径，建立有层次结构的一系列测试单元
· 测试设计人员创造测试数据。分析测试用例，构造测试数据，确认这些测试数据是否符合测试目标
· 用例编写规范见规范
活动2—测试用例和测试点评审
· 质量监督组组织并参与TC的评审，跟据TC评审的checklist要点进行评审
·
TC评审checklist
· 会后测试设计人员及时补全用例和测试点
活动3—用例管理
· 项目测试负责人负责进行阶段测试用例的实施、跟踪及用例统计分析工作、改进测试用例等管理活动
· 当项目需求或设计变更引起测试需求变更时，测试设计人员及时将变更测试用例
· 新增测试用例批准后由测试设计人员执行
输出
测试用例
关闭标准
测试用例评审批准通过
测试执行阶段
启动条件
测试环境配备完善没有可以影响测试结果的其他因素存在，并且被测试系统提交测试前制作部内部已经进行了充分的单元测试，通过冒烟测试标准，测试需求已满足。
输入
测试用例、测试实验室
主要活动
活动1—测试执行
· 测试执行员运行QC测试实验室中测试单元的每一个测试用例
· 测试执行员在测试执行过程中，发现BUG，提交至QC项目中的缺陷管理空间中进行跟踪
· 测试执行员从用户的角度提出建议。
· 测试执行员在测试执行过程中每天递交给项目测试负责人当天测试情况
活动2—BUG管理和建议管理
· 测试执行员发现BUG并在BUG管理工具Mercury Quality Center 中记录，测试负责人审核BUG的有效性
· 测试执行员根据已经定义的BUG严重级别和优先级别来正确提交BUG
· 项目测试负责人跟踪BUG分配，以确保BUG没有被忽略
· 测试执行员验证BUG是否被修复，确定已经被修复，则关闭 确定未被修复，则重新打开并跟踪
· 项目测试负责人对于无法重现的BUG提高警惕，进行整理
· 项目测试负责人对于不需要修复和以后修复的BUG，需要再次确认，确保重大错误的遗漏
· 项目测试负责人负责根据不同阶段生成测试进展通报表，向项目组成员、GP、质量监督组、通报每天产生的BUG、BUG总数、BUG状态等有效信息 质量监督组组长根据这些数据调整测试策略和资源分配或者判断是否可以结束测试。对于争议的BUG项目测试负责人负责收集过滤，由项目测试负责人牵头组织讨论后进行裁决，并生成测试报告 以邮件形式发送给GP，主程，主策及相关人员和高管
·
BUG管理和建议管理规范
· 质量监督组监督和检查整个执行测试过程，监督项目测试负责人是否做以上工作。
· 质量监督组实时跟踪是否按测试计划实施测试执行活动
输出
BUGLIST（QC）和测试进度报告，由项目测试负责人不定期以邮件形式【工作报告】【XX测试组】XXXX进度汇报，发送给GP，质量监督组、主程，主策，抄送给其他相关负责人。
关闭标准
测试需求覆盖完全，测试用例，测试点执行全部通过
测试报告和总结阶段
启动条件
按照测试计划和测试用例完成本次测试工作
输入
BUG记录
主要活动
活动1－测试报告
· 项目测试负责人从BUG管理工具中统计分析BUG的数量、性质、分布情况，提取相关数据，并形成图表给出测试报告以邮件形式发给制作部相关人员
· 质量监督组针对图表评价产品质量
· 质量监督组评价测试过程本身。通过和测试计划的比较，对进度、工作量、测试需求和测试范围、测试用例的设计进行评价 。给出此版本的评测报告发给创新研究院及高管。
活动2—测试总结
· 质量监督组组织该项目测试参与人员总结分析测试过程中的问题
输出
测试报告，由项目测试负责人不定期以邮件形式【工作报告】【XX测试组】XXXX测试报告，发送给GP，主程，主策，主美，抄送给其他相关负责人
测评报告，由质量监督组根据项目测试负责人给出的报告为依据以邮件形式发送创新研究院和高管。作为评审的依据。
线上反馈阶段
启动条件
游戏产品上线之后
输入
线上客服反馈的QC上的BUG
主要活动
· 质量监督组整理线上BUG进行分析和统计（作为考核一个指标---漏测率）
12
�
<进程名称>�
<职能>�
�
�
�
�
�
�
�
项目功能测试总结
项目性能测试总结
<项目功能测试流程>�
束
结
行
执
计
设
动
启
项目
测试计划
在QC项目空间中
设计
项目功能测试用例�
评审项目测试设计
评审项目测试用例
功能测试执行、
性能测试执行
手工回归测试执行
�
预发布
是否通过测试
BUG管理流程�
项目测试流程结束�
沉淀项目功能测试产出
沉淀项目性能测试产出
在QC项目域中
建立
项目空间�
通过
通过
项目
测试设计
继续执行
项目测试阶段结束�
项目立项
评审项目
测试计划
通过
项目功能测试报告
修改
修改
预发布测试执行�
本项目
是否通过测试�
通过
文件编号
作 者
吴彬
文档版本
编写日期
2008-12-3
文档版本
编写日期
2009-11-12
XX项目
版本号
项目测试计划
编 写 人：
编写时间：
修订控制页
序号
版本号
修订日期
修订概述
修订人
审批人
备注
1
文档版本与产品版本相一致
填写修订日期
填写修订原因
填写修订人
填写审批人
2
2008-12-3
吴彬
3
4
5
6
7
8
9
目录
11
概述
12
测试需求分析
13
测试设计
功能测试范围
14
规划
应用测试前提
测试设备环境（软硬）
人力资源配备
测试时间计划
测试执行的评价标准
测试过程中产生bug的管理办法
45
测试产生文档
46
预计测试风险
5附件1
5附件2
5BUG严重等级分类
1 概述
[ 明确本次项目的测试方法和测试类型: 此文档主要描述XXXX（XXXX）项目的功能测试] 如：主要涉及的内容有功能测试详细计划：包括测试设计、测试硬件资源配置、QA人员配置、测试时间进度安排、测试接受标准、测试产出文档、测试风险预估；读者为QA人员，开发工程师，项GP及评审人。此文档随着项目的变更而发生变化。
2 测试需求分析
本项目包括新功能：
具体功能模块
3 测试设计
功能测试范围
· 项目名称
名称
描述
1.
2.
3.
4.
5.
6.
7.
8.
4 规划
应用测试前提
· 执行测试的前提：项目组将策划案提交给了TestTeam。
· 测试环境配备完善没有可以影响测试结果的其他因素存在。
· 子系统集成必须在充分的单元测试通过后进行。
· 开发人员提供可测试的版本。
测试设备环境（软硬）
· 软件环境
软件类型
软件名称
版本要求
支持作用
操作系统
Windows系列
WindowsXp
支持客户端测试
浏览器
IE，
Maxthon,
FireFox
以上
以上
以上
前台验证系统在多版本下的展现是否正确
数据库系统
My Sql
My 以上
支持图库数据的记录
Bug管理工具
QC缺陷管理
管理bug
· 硬件环境
配置名称
配置要求
配置支持方
客户端操作系统
功能测试：自己工作机器
数据库服务器
暂无
网络
ADSL 4M
公司局域网
· 本项目测试环境的配置图
人力资源配备
阶段名称
实践与职责
阶段负责人
测试计划
制定测试计划并跟踪
功能测试设计
进行测试需求分析设计
测试用例编写
编写测试用例
测试数据准备
准备项目中使用的测试数据
测试执行
进行功能测试执行
功能测试报告
发布功能测试报告
测试总结
发布项目测试总结
测试用例入库
将项目用例入库
测试时间计划
序
活动
子活动
计划开始时间
计划结束时间
参加人员
1
测试计划
2
测试设计
3
测试用例编写
4
测试用例评审
5
测试数据准备
6
冒烟测试
7
测试执行
8
测试报告
9
测试总结
测试执行的评价标准
测试结果分为2类:
通过：即测试执行人员对测试对象的测试结果认为合格即通过。用P(pass)表示。
不通过：即测试执行人员对测试对象的测试结果认为未达到需求设计的结果或出现bug则不通过。用F(fail)表示。
测试过程中产生bug的管理办法
原则：提交的bug一个工作日内修改，在修改后一个工作日内都要经过确认测试。而Normal以上的bug都必须Fix，时间允许的话所有bug都应Fix。为获得较准确的数据，上线后的bug也应该全部都提交到QC的缺陷模块中。
Bug修复时需要正确选择产生原因，并在注释中说明具体情况。具体操作可参见《Bug管理》文档。
BUG修复约定：提交的bug在一个工作日内修改，在修改后一个工作日内要经过确认测试。而当天5点前发现的Normal以上的bug必须在当天Fix。
测试受到开发进度的影响，如果由于开发进度的里程碑没有在预期时间内完成，测试进度也将顺延。
5 测试产生文档
《测试计划》、《测试设计》、《测试用例》、《测试记录》、《测试报告》
6 预计测试风险
序
风险内容
优先级别
缓解措施
1
测试环境不完备
很低
编码完成前须准备完成，与配配置管理员的协调。
2
测试人员对该项目的需求理解不充分
中等
加强与开发工程师的沟通交流。
3
需求变动频繁，导致测试时间缩短
低
加强需求评审。
4
前期开发延期，导致测试阶段时间被压缩
低
与GP协调解决，关注测试过程管理。
5
测试用例覆盖不完全
高
通过评审分析并找出需要回归得点，提高测试用例的有效性。
6
受其他项目影响，导致本项目进度制约
中等
与GP协调解决，关注并行项目进度，及时调整测试过程管理。
7
测试人员经验不足
中等
通过自我学习和互相交流，补充缺少的必要知识，尽快熟悉测试流程和方法
附件1
附1：风险发生的可能性
值
优先级别
描述
1
很低
发生的概率为＜20%
2
低
发生的概率为20%－40%
3
中等
发生的概率为40%－60%
4
高
发生的概率为60%－80%
5
很高
发生的概率为80%－100%
附件2
BUG严重等级分类
测试产生的Bug 分类如下
· 紧急。此bug影响的范围广泛，已经成为测试工作的瓶颈，导致其它的测试工作也无法继续下去。开发人员要尽快解决
· 高。此bug可导致重大的损失，如高风险的控制功能失效之类的bug。主要功能不能完成，但不会造成重大的损失，经济上的、公司形象上的、等等。
· 中。此bug导致一些辅助性的功能不能完成，或是出错，不影响主要的功能或业务。
· 低。此bug不影响业务的完成，也没有影响功能的实现。如一个提示信息的字体、颜色不对，等等。
· 建议类。
PAGE
- 5 -
PRD
评审材料
反馈人
必选角色 PDM,系分，需求提出者
可选角色 UI，需求方负责人
序号 主要检查点 主检人 检查结果 反馈问题
1 文档的说明性文字（蓝色字体）是否已去掉 自在 合格
2 文档是否用了最新的模版 自在 合格
3 PRD的前4项是否经过业务委员会评审，是否达成共识 自在 合格
4 PRD的整个内容是否经过产品委员会评审，是否达成共识 自在 合格
5 所需要沟通的部门（包括但不限于系统分析师、交互设计师、客服等）是否有遗漏，是否和各方达成共识，沟通的结果是否有记录 自在 合格
6 产品的效益成本分析、服务需求是否以数据和事实为依据在进行推断 自在 合格
7 名词术语前后是否一致，是否有清晰的解释 自在 合格
8 对产品功能是否有总体说明？说明是否清晰易懂 自在 合格
9 功能详情中 用户交互的基本流程是否清晰；相关的业务规则是否明确 自在 合格
说明：【主要检查点】，一部分是基础的格式正确性和内容完善性检查，已经列入检查点中了，另外，每次评审的申请人，还需把针对本次评审材料的具体细致的检查点，补充到【主要检查点】一列中。【主检人】一列，是对应每个检查点，需要安排相应的主要检查人进行预审，并且反馈预审的结果。
其他需要解决的问题：
序号 问题
说明：这部分【其他需要解决的问题】，由进行预审的评审成员填写。是除了针对检查点反馈的问题外，评审成员还想在评审会上解决的和自己工作内容有关的问题。
合格
不合格
待完成
不适用
项目进度计划
评审材料
反馈人
必选角色 项目组全体
可选角色
序号 主要检查点 主检人 检查结果 反馈问题
1 项目的进度计划中进度时间是否满足所有的时间限制？ 如：项目发布时间、项目结束时间等
2 时间估计是否准确；人员安排是否合理
3 是否明确指定测试环境搭建时间
4 是否安排了“集成测试环境构建”这一任务，并安排了相关的人员
5 是否安排了“系统测试环境构建”这一任务，并安排了相关的人员
7 是否安排了“压力测试环境构建”这一任务
8 是否安排了“合并后测试环境的构建”这一任务
9 是否安排了“回归测试环境构建”这一任务
10 是否识别了项目的风险和问题
11 是否安排了SQA和SCM的工作
12 对于每次评审,是否安排了预审的时间，对评审任务，是否明确了主持人，评审人和记录人?
13 是否安排了日常任务，如周报，周会等
14 项目选定的生命周期模型是否适合？(瀑布型、迭代型等等)
15 是否确定了各里程碑的时间？
16 里程碑的时间是否合理？
17 是否安排了URL审核的时间？
18 是否在发布前安排了数据字典的更新时间？
19 是否安排了支付宝的接口联调时间？是否确定了支付宝的接口人？
说明：【主要检查点】，一部分是基础的格式正确性和内容完善性检查，已经列入检查点中了，另外，每次评审的申请人，还需把针对本次评审材料的具体细致的检查点，补充到【主要检查点】一列中。【主检人】一列，是对应每个检查点，需要安排相应的主要检查人进行预审，并且反馈预审的结果。
其他需要解决的问题：
序号 问题
说明：这部分【其他需要解决的问题】，由进行预审的评审成员填写。是除了针对检查点反馈的问题外，评审成员还想在评审会上解决的和自己工作内容有关的问题。
合格
不合格
待完成
不适用
策划案评审检查点
评审材料
反馈人
必选角色 QA人员
可选角色 程序，美术，策划
序号 主要检查点 主检人 检查结果 反馈问题
1 策划案是否用了最新的文档
2 策划案有没有遗漏、重复或不一致的地方
3 策划案描述是否准确、完整？是否存在二义性？
4 所有图表是否清楚，在不补充说明时能否理解
5 是否每一个需求都可以被设计、被实现、被测试？
6 策划案引用的业务规则描述是否清楚、合理？
7 策划案是否有总体描述
8 是否有名词解析,对相应的专有词语的解析
9 是否有输入输出数据定义,边界条件,默认值,是否为空等说明
10 是否有分支流程说明
11 是否有前置说明和后置说明等
12 是否清晰说明系统的交互过程,描述了为实现需求,系统的内部交互
13 策划案是否可实现；（程序反馈）
说明：【主要检查点】，一部分是基础的格式正确性和内容完善性检查，已经列入检查点中了，另外，每次评审的申请人，还需把针对本次评审材料的具体细致的检查点，补充到【主要检查点】一列中。【主检人】一列，是对应每个检查点，需要安排相应的主要检查人进行预审，并且反馈预审的结果。
其他需要解决的问题：
序号 问题
说明：这部分【其他需要解决的问题】，由进行预审的评审成员填写。是除了针对检查点反馈的问题外，评审成员还想在评审会上解决的和自己工作内容有关的问题。
合格
不合格
待完成
不适用
XXX测试需求设计
XXX项目测试设计
文件编号
XXX-TRD
作 者
吴彬
文档版本
编写日期
2010-2-22
XXX项目
版本号XXX
测试设计
编 写 人： XXX
编写时间： XXX
修订控制页
序号
版本号
修订日期
修订概述
修订人
审批人
备注
1
文档版本与产品版本相一致
填写修订日期
填写修订原因
填写修订人
填写审批人
文档版本与产品版本相一致
2
3
4
5
6
目录
41.
XXX项目测试需求框架图
42.
XXX项目系统交互图
53.
XXX项目测试用例模块流程图及规则说明
A模块
1. XXX项目测试需求框架图
· 此图背景：[在全面覆盖系统UC的基础上，详细分析测试需求的之间业务逻辑关系，可从某个视角出发（一般是玩家），系统地设计本项目的需求目录框架。目录层次的划分原则是叶子目录为一个最基本功能模块，深度要求不超过4层；层级之间的关联原则是能简单表达相互存在影响即可，广度要求在本项目功能范围内，且在叶子目录之间展开。特别说明，如果层级之间的关联非常大，需要使用文字来详细说明]
· 此图说明：[基于UML的用例图形状，通常可用黄色代表系统UC。文字说明按需要添加]
· 此图目的：[用于生成测试需求，便于测试需求管理，指导测试用例编写]
2. XXX项目系统交互图
· 此图背景：[项目中可能涉及多个系统之前的交互包括接口，可以通过多种事件流的抽象描述，叙述性的展现业务逻辑在系统间的顺序。可从实际用户出发（便于理解），确认一个使用场景，在业务流转过程中清晰展现本项目在多个系统的交互以及接口调用关系]
· 此图说明：[基于UML的顺序图形状，虚线表示角色，箭头线表示流转，长方形框表示对象。文字说明按需要添加]
· 此图目的：[用于控制测试范围，清晰地展现系统之间的交互，便于测试需求理解，指导测试用例编写]
3. XXX项目测试用例模块流程图及规则说明
· 此图背景：[按照本项目的业务逻辑细分成多个重要活动，以重要活动为单位模块，在每个模块中详细地描述活动以及活动之间数据流或判断，需要清晰展现主事件流，可选事件流，异常事件流，并且可以结合数据状态的转换]
· 此图说明：[基于UML的状态活动图形状，箭头线表示数据流转，长方形框表示活动，菱形框表示判断。文字说明按需要添加]
· 此图目的：[用于指导和检查测试用例的编写，帮助测试数据准备分析，并且指导测试执行]
A模块
战斗---占领野地
1
2
测试用例评审检查点
评审材料
反馈人
必选角色 测试人员
可选角色 质保部有经验的测试人员，程序，美术，策划
范围 序号 主要检查点 主检人 检查结果 反馈问题
相关性 1.是否需要考虑历史库中的数据问题
安全性 1.是否需要考虑COOKIE记录、COOKIE失效
2.是否考虑特殊模块需要进行加密、校验。如：隐码、校验码
3.对于有接口调用的功能，测试调用、重定向等URL里面，是否包含了不应该明文显示的资料
4.检查网页、通知内容（包括邮件）是否显示了非功能需求外的用户敏感资料，如：密码、密码保护答案、身份证号码、Email地址、真实姓名、电话、手机号码等
5.是否涉及更改充值方式
6.是否需要考虑用户类型，比如:VIP用户
7.是否有容易刷经验刷元宝刷物品的地方存在
性能 1.是否需要做性能测试
兼容性 1.是否考虑到浏览器的兼容性:多种浏览器（IE5、IE6、FF、TT、IE7）的兼容性
2.是否考虑到操作系统兼容性:多种操作系统（XP、2000,win7）兼容性
3.是否考虑到分辨率的兼容性。
4.是否考虑到简繁体的兼容性。
功能模块 结构层次 1.用例层次结构是否清晰:UC需要进行细分时，处于同一级别的模块最好在TC中也能保持在同一等级。
2.用例整体风格是否一致:主要是指用例存在多个测试人员编写的时候，两个人的编写的模式或者是整体框架需要保持一致
功能点细分 准确性 1.用例输入描述动作准确、单一:前置条件和操作清晰界限，有明确输入的动作
2.用例输出可明确判断:输出的结果明确、可判断、可验证、不存在二意性
3.用例是否存在冗余:用例在其他用例中存在就不需要重复编写
4.用例逻辑是否准确:符合程序的逻辑、符合用户的思维逻辑
5.用例功能点覆盖:用例必须完全覆盖UC
6.用例是否具有可读性:用例简单易懂，符合阅读习惯
7.用例是否有正面的和负面的两种用例:用例需要从正、负二方面考虑
规范性 1.用例编号是否符合规范:测试用例的编号一般有一定的规则，定义测试用例编号，便于查找测试用例，便于测试用例的跟踪
2.用例名称是否符合规范:对测试用例的描述，测试用例标题应该清楚表达测试用例的用途
延续性 是否考虑新增字段或新建表对老数据和历史库中数据的产生影响
是否考虑新增或者修改的功能对原有的功能产生影响
说明：【主要检查点】，一部分是基础的格式正确性和内容完善性检查，已经列入检查点中了，另外，每次评审的申请人，还需把针对本次评审材料的具体细致的检查点，补充到【主要检查点】一列中。【主检人】一列，是对应每个检查点，需要安排相应的主要检查人进行预审，并且反馈预审的结果。
其他需要解决的问题：
序号 问题
说明：这部分【其他需要解决的问题】，由进行预审的评审成员填写。是除了针对检查点反馈的问题外，评审成员还想在评审会上解决的和自己工作内容有关的问题。
合格
不合格
待完成
不适用
BUG 状态流程图
Bug的处理
开发人员
分析Bug，最好在注释栏写出问题原因，修改Bug；严重程度为紧急的或影响了测试进程的，该开发人员应该立即停止手上的开发工作，第一时间修改；对否决的BUG在注释栏注释否决原因。
GP\主策
对QA提出的建议性或用户体验问题，给出处理意见，评审确定后列入开发计划
主程
督促程序员修改严重级别较高的BUG
QA人员
负责BUG的提交，跟踪，验证Bug是否已被解决
项目测试负责人
审核测试人员提交的Bug。定期对Bug库进行分析，描绘出曲线图等，报告现状、预测趋势。在测试总结报告中给出意见
Bug状态(Status)：指缺陷通过一个跟踪修复过程的进展情况。包括新建、打开、重新打开、已修复、已关闭及已否决和暂不修改。
新建
为QA人员新问题提交所标志的状态。
打开
开发人员确定为BUG的状态
重新打开
为QA人员对修改问题进行验证后没有通过所标志的状态；或者已经修改正确的问题，又重新出现错误。由QA人员改变。
已修复
为开发人员或策划人员修改问题后所标志的状态，修改后还未验证。（前提：已部署到测试机）
已关闭
为QA人员对修改问题进行验证后通过所标志的状态。由QA人员改变。
已否决
开发人员认为不是Bug、描述不清、重复、不能复现、不采纳所提意见建议、或者QA人员提错，从而拒绝的问题。由开发人员来设置。（注：在注释栏注明原因）
暂不修改
开发人员认为在当前阶段不需要马上处理，或预见到以后代码或功能完善之后会自动修复此问题。由开发人员来设置。
Bug严重级别(Severity，Bug级别)：是指因缺陷引起的故障对软件产品的影响程度。由测试人员指定。
紧急
BUG导致了死机、崩溃、严重影响测试进度；
高
功能未实现、重大漏洞、与策划案不符；
中
错误导致了一个层级最低的功能不能运行，出现程序调试代码；
低
错误是表面化或微小的（提示信息不太准确、错别字、UI布局等），对功能几乎没有影响，仍可使用；
用户体验及建议
建设性的意见或建议（包括用户体验部分）。
Bug优先级(Priority)：指缺陷必须被修复的紧急程度。由项目测试负责人和GP共同评定。
5-Urgent
阻止相关开发人员的进一步开发活动，立即进行修复工作；阻止与此密切相关功能的进一步测试
4-Very High
必须修改，发版前必须修正
3-High
必须修改，不一定马上修改，但需确定在某个特定里程碑结束前须修正
2-Medium
如果时间允许应该修改
1-Low
允许不修改
功能模块(Subject)：QC中需在Test Plan页中定义好Subject，才能在Defects页中使用。
处理意见:开发人员可以在注释栏里添加的说明大概有以下几种（选择使用）：
Fixable
可修改。表示Bug可以被修复或更正
Duplicated
重复。表示该Bug已经被其它测试人员找出来了（‘纯粹’重复），或者开发认为原因是相同的（但从测试来看，认为出现的地方有所不同、表现有所不同等）
Postponed
延后。由于时间、进度、重要程度或者技术/需求等方面的原因，认为不能解决、须延期解决、或者本版不做留待到后续版本解决的Bug。
By Design
因设计结构问题无法修改。测试人员认为是Bug，不符合逻辑，也不符合用户的要求，但开发人员则认为是按照设计做的、只能如此处理，否则修改代价太大
Can’t Reproduce
不可复现。不能重现（如因Bug出现的环境重现不了了），或以前出现的某个Bug自动消失了（可能是在处理其他Bug的时候把这个Bug 一并修复掉了）。
Disagree With Suggestion
不同意所提意见或建议，不采纳
Not Error
不是问题。测试人员提错了
Won’t Fix
这个Bug是一个错误，但还没有重要到非要更正不可的地步，可以忽略不计
项目组各角色在Bug库中的权限
管理员：全部权限
测试组长/经理：全部权限
测试人员：可添加Bug、不能删除Bug、可添加注释评论(R&D Comments)、不可修改他人所提Bug、可调整：Bug概要(题目，Summary)、问题描述、附件附图(Attachments)、Bug状态、Bug级别、测试版本、测试产品、功能模块、测试状态、问题定位、复测状态、注释评论(R&D Comments)、复测人、复测日期、修改人
开发人员/策划人员：不能删除Bug、可添加注释评论(R&D Comments)、可调整：注释评论(R&D Comments)、是否复现、Bug状态（不过无法直接标为closed）、问题描述、处理意见、待测版本、修改人、修改日期。可添加Bug。
GP：除了开发人员的权限，还可调整：优先级别、责任人、Bug概要(题目，Summary) 、附件附图(Attachments)
不属于项目组成员的其他人如研发中心经理组成员等，有必要查看QC库的话，可分配给其帐号及查看的权限。
Bu BUG描述要求
Bug描述的要求为分类准确、叙述简洁、步骤清楚、有实例、易再现、复杂问题有据可查（截图或其它形式的附件）。测试组长/经理把关，以开发人员的角度来审查Bug描述，看其是否描述清楚了Bug，不好描述的把工程文件或截图作为附件提交。具体要求为：
· 问题描述一般格式：问题描述时，建议分几步描述：模块或功能点=>测试步骤=>期望结果=>实际结果=>其它信息，可依实际情况调整；
· 单一：尽量一个报告只针对一个软件缺陷，报告形式应方便阅读。在主报告之后应注明不同的条件；
· 简洁：每个步骤的描述应尽可能简洁明了。只解释事实、演示和描述软件缺陷必要的细节，不要写无关信息；
· 再现：问题必须在自己机器上能复现方可入库（个别严重问题复现不了也可入库，但需标明）；
· 复杂的问题应附截图补充说明或直接通知指定的修改人；考虑到网络数据传输效率，截图的文件格式建议用JPG或GIF，不建议用BMP；抓图可用TestDirector自带的功能，亦可用HyperSnap之类的专用抓图工具。
· 报告中不允许使用抽象词句：比如“有错误”之类；
· 有关操作系统特征问题：应在不同操作系统上进行操作，看是否能重现，并在Bug报告中标识；
注：所有项目采用QC进行Bug管理，该工具能从测试步骤自动生成Bug报告，因此对于Bug描述要求在测试方案用例设计（在Test Plan页中）阶段就可以进行控制。
附：好的Bug报告应满足以下几方面的要求：
· 结构清晰
· 复现故障再写报告
· 隔离Bug：更改条件复测
· 归纳：是否其他模块也有相同的Bug
· 比较：其他测试用例是否使用到此Bug
· 总结：报告的开头有Bug的总结
· 精简：不要有多余的步骤和语言
· 无歧义：语言明确
· 中立：无批评性语言
· 讨论：将要发出的报告送其他测试人员讨论
小 总结
· 通过专业的技术测试出精确的Bug；
· 通过准确的文档报告Bug；
· 通过良好的沟通使Bug尽快解决。
SAS Work Report
乐堂科技 Website Project Management Document
目录
31
测试情况说明
测试进展概要
测试项目内容简介
测试时间及投入人力
32
测试执行与记录
简要描述
暂不修改状态问题记录
BUG趋势图
测试人员提交BUG情况分析：
43
本阶段测试总结：
44
测试总结：（符合测试退出标准）
1 测试情况说明
测试进展概要
[必填:简要明确说明测试进展情况]
测试项目内容简介
[必填:概要介绍项目的具体内容]
本次测试主要内容:
[必填:测试的主要功能点及模块介绍]
测试时间及投入人力
[必填:本次测试时间统计以及投入人力,模块分配情况]
2 测试执行与记录
简要描述
[必填: 对测试执行情况进行简要描述,包括集中BUG出现的地方、测试中出现的重大问题、测试中遇到的难点以及解决办法]
暂不修改状态问题记录
[选填：本次测试未解决的BUG 记录,若没有未解决BUG,可不填写。]
BUG趋势图
[选填：统计单位时间内所有状态的BUG数量趋势，可加文字说明。短期项目可不填写]
测试人员提交BUG情况分析：
各状态分类数量
closed BUG分类数
测试人员
总提交数
已关闭
已否决
暂不修改
紧急
非常高
高
中
低
总计
分析描述：可以根据相关数据等对测试人员进行一些定性分析。态度，责任，能力等。
3 本阶段测试总结：
[二选一: 进度正常啊或者是测试进度不够或者是开发进度不够。。。。需要延期。。。等等。 若所有阶段测试完成则不需要写此项]
4 测试总结：（符合测试退出标准）
[二选一：-阶段性测试报告不用写
根据测试结果，从测试者的角度指出质量缺陷较为集中的模块或者开发环节，分析大量出现的缺陷的产生根源，提出未来消除这些根源的方法或者措施；对需求分析、软件设计、编程实现等测试之前的开发环节如何提高质量、减少缺陷提出具体的意见或者建议。
质量标准：（1）质量缺陷的原因分析深入。（2）改进建议中肯。（3）改进建议具有可操作性。 ]
测 试 报 告
项目名称：
负责部门：
报告人员：
测试日期：
Page 2
Page 5
质量保证部体系
质保部经理：
· 把握部门的发展方向
· 完善工作流程与各项规范、制度 、标准
· 负责本部门的人员的招聘
· 团队核心成员的培养，部门资产的管理及扩增
· 在部门组织内部制定和分配角色。
· 对下属进行绩效考核并监督下属工作情况
· 协调本部门与其他部门的工作
· 服从和执行上级的指令并向CTO汇报工作等
游戏测试组组长：
· 审查测试人员日志，监督并指导下属工作
· 参与工作中发现重大问题的讨论
· 合理制定项目的测试计划及进度
· 根据项目需要安排编写测试相关文档（游戏测试计划、游戏测试报告）并就某些特定文档提请评审。
· 组织各级测试工程师进行测试工作。
· 分配项目具体的测试工作任务
· 进行游戏业务内训工作
· 服从安排部门负责人指示，并向上级汇报工作等
游戏测试设计工程师：
· 对于项目策划案进行分析，搭建功能模块框架
· 设计模块交互流程图
· 根据模块交互流程图编写测试用例、维护测试用例
· 指导游戏测试员执行用例
游戏性能测试工程师：
· 负责产品服务端和客户端性能测试，性能测试场景设计，并向制作部提出可行性需求
· 收集和分析性能测试结果，提交性能测试问题
· 研究性能测试方法和工具
· 提出公司内性能测试工具和方法改进建议
游戏测试员
· 了解游戏项目，执行测试用例
· 上报BUG，验证BUG，提出项目用户体验等改进建议
· 根据测试流程及方法完成测试任务，并及时提供测试结果反馈
平台测试组长：
· 审查测试人员日志，监督并指导下属工作
· 参与工作中发现重大问题的讨论
· 合理制定项目的测试计划及进度
· 根据项目需要安排编写测试相关文档（测试计划、测试报告）并就某些特定文档提请评审。
· 组织各级测试工程师进行测试工作。
· 分配项目具体的测试工作任务
· 进行业务内训工作
· 组织游戏组内总结和分享工作，使部门测试水平不断提高
· 对游戏组内人员进行测试技能培训
· 服从安排部门负责人指示，并向上级汇报工作等
性能测试工程师
· 根据业务需求及项目文档进行性能测试需求分析、编写性能测试方案以满足检测系统各项性能的要求；
· 按照测试方案设置测试场景，录制或开发测试脚本，并根据需要进行修改和参数化工作等；
· 根据需要按一定的策略运行测试脚本，进行性能测试，同时收集系统中相关的性能指标；
· 对测试结果数据进行分析，提供直观的分析结果和性能优化建议，并配合开发工程师进行性能调优；
· 根据业务量增长趋势和测试结果对系统未来进行性能预测，给出性能提升建议
自动化测试工程师
· 搭建自动化测试环境；
· 根据测试用例编写自动化测试工具；
· 执行自动化测试并提交测试报告；
· 提供自动化测试技术支持；
· 自动化脚本的开发和维护、自动化框架的开发
· 自主开发并维护测试工具，进行技术分享和交流，协助提高整个测试团队的工作效率。
平台测试设计工程师：
· 对于项目策划案进行分析，搭建功能模块框架
· 设计模块交互流程图
· 根据模块交互流程图编写测试用例、维护测试用例
· 指导平台测试员执行用例
平台测试员：
· 了解平台项目，执行测试用例
· 上报BUG，验证BUG，提出项目用户体验等改进建议
· 根据测试流程及方法完成测试任务，并及时提供测试结果反馈
质量监督组组长：
· 部门和项目规范、标准的制订和优化
· 执行公司的质量方针，并协调开发部门达到公司的质量目标。
· 负责对项目过程质量进行度量,并对项目过程质量进行评估
· 组织各个阶段的评审工作，以便提早发现问题
· 审查测试项目负责人编写的相关文档
· 测试新技术的研究和培训
· 组织总结和分享工作，使部门测试水平不断提高
GQA：
· 监督游戏组内测试流程和计划的执行情况和开发进度情况
· 负责跟进项目进展,在过程中发现、收集、暴露问题并推动问题解决
· 游戏组内各个阶段的评审工作，以便提早发现问题
· 对游戏组内人员进行测试技能培训
· 负责收集分析项目度量数据
PQA：
· 监督平台组内测试流程和计划的执行情况和开发进度情况
· 负责跟进项目进展,在过程中发现、收集、暴露问题并推动问题解决
· 平台组内各个阶段的评审工作，以便提早发现问题
· 对平台组内人员进行测试技能培训
· 负责收集分析项目度量数据
质保部经理
SQA
GQA
平台测试组组长
质量监督组组长
游戏测试设计工程师
游戏测试员
测试设计工程师
性能测试工程师
自动化测试工程师
游戏性能测试工程师
平台测试员
游戏测试组长
