游戏测试策略

司格特

游戏的版本阶段大体如下：

Demo，aplha，open_beta，close_beta，RC，release

测试介入点应该是在alpha阶段进入，在demo阶段也可以对游戏有1个初步的了解，demo的包做一
些简单的防crash准备（后续在兼容性章节看到内容）

在前期和项目组成员一起配合做单元测试或者熟悉功能点具体业务流程。前期的介入可以过度磨合
期用于后期比较频繁的迭代，配合的方式使用W模型，不推荐游戏产业使用瀑布模型（线型），

W模型可以更好的控制时间

测试初期介入其实还是准备测试用例和需求分析，根据当前项目的团队特色来进行测试人员分配
和测试计划的设计，整体还是需要使用1个PDCA的常用。



版本条件（策略） jiazurongyu

随着进度推进，开发完成度达到百分比的进度，取决项目的版本阶段，但根据版本阶段是否满足
进入条件，是根据测试部门制定的一套标准，具体是作为参考还是一定要执行还是根据项目来，
我对文中3.以后环节是比较重视的。

以下可以做一些参考（Aplha会使用到几个重要概念 重要问题指B类至热门问题以上的，阶段完成
度是指alpha版本内规划的内容，开发功能点列表会使用到1个checklist表单）

Aplha版本到open_beta 完成度满足要求以外

参考数据为 1.开发功能点列表完成度高于x% 2.阶段完成度内容100%  3.A类bug低于bug总数的
20~30%  4.重要问题比例低于bug总数的%

Aplha版本还不用使用到缺陷收敛，缺陷收敛的方式来源于统计学和传统软件，经常实践转化为可
用的（缺陷收敛章节）

open_beta开启后->close_beta，随着进度推进，会根据结果是否close_beta，进入准备上线阶段。

参考数据为 1.开发功能点列表完成度高于x% 2.阶段完成度内容100% 3.A类bug低于bug总数的20%

4.重要问题比例低于bug总数的% 5.缺陷密度数值健康 6.高密度模块修复率高于x%

前面2条是硬性保证的，第一条具体数字根据项目实际情况。Beta会使用到几个重要概念缺陷密度
根据问题级别数量和是否100%复现等获取1个数值，确保数值健康，不同阶段根据项目新增问题
和修复问题会存在1个健康的曲线，按天为单位去确保曲线健康，何时需要堆积和补充问题，何时
需要收敛问题，让大家共同参与缺陷收敛保障。高密度模块排出top几的，同上，确保修复率高于
多少百分比。这2条的后者是前者数据缩影，也是关键部分的保障。

close_beta-> RC上线前版本关注点也是一样的，这里需要关注上线前准备的内容，满足一定的
条件下就是完美发布，release正式服到gold_release大家字面上也可以理解。