需要谈谈的游戏测试（六）好像不是游戏测试

说明：立志成为可持续改进能手orzhuan家的可以认真看。不是很推荐新人来看。

哪些产业应该使用CMMI，FEMA，哪些产业不需要使用。如何微缩CMMI和FEMA。这些过程带来的是敏捷还是沉重的？什么又是敏捷？

大部分的游戏公司的测试可以通过各种缺陷管理软件来获得一份简单的缺陷管理分析图，甚至额外插件所装的饼图和甘比图等。随着软件的升级变迁，一些可以量化的东西糅和在里面。

那么缺陷管理是如何做的？每个版本的阶段该如何介入？

在拿到一项新的需求任务时，先需要确定该项任务的时间，规模（内容涉及点），人力（和其他项目是否有冲突），工作量（度量项目完整度），范围（优先测试范围）。其中人力部分是一切的关键。P-CMMI

当这部分确定了，我们才开始进行下一步。

首先对规模里的内容进行分析属性，哪些需要交叉，哪些需要重新开始做。代码行数（游戏产业未知），变更复杂度进行度量。

然后制定模块的类型，参与的人员，考量人员的对应的熟悉度。参与人员越少时越需要注意，一次错误的度量将导致本次任务的延期。（除非团队中有多个特性员工，快速工作能力，那就可以弥补），测试负责人需要有一份CMMI里的PIID表（简略）。这部分是个人所带的团队条件许可情况下，必须要有的。团队成员或者自己一个人填满这张表，就可知道，风限是可以控制还是不可控制的了。推荐团队成员一起提升。

分二个工作流程线，一部分在做模块文档和模版时，一部分会做测试套件，在平时测试的过程中，我们累积了一些功能模块的缺陷和易发缺陷的测试点，这个时候会把这些内容单独放在一个表里，添加测试用例进去就完成了套件的功能。用测试套件具备较强的机动性。通常情况下，前期的筹划分为2组即可。

上述内容最终转化为确定一项关键，测试粒度的大还是小。测试时间的周期是否需要顺延。如何照顾团队人员的情绪等。而这部分需要明确的是缺陷管理对于测试的方向定位并不关注。（测试方向定位可看未来的教程里）

执行时，测试案工作（发现问题）和（验收上个版本问题）及（测试套件的回归），收敛缺陷。产生最基本的缺陷图，模块分布图，NOP图，风险杠杆图等，所谓的八表归元法，也就是8张不同作用的表，统计办法根据缺陷管理工具和平时记录，不追求什么美观的话，可以用execl或者PPT快速生成这类的表。统计的过程需要比较长。

可以用多款工具一起来做，但要思考工具之间的关联性。

测试过程中记得定期支援你的队友或者平级或者下属上司，提供一些测试过程中有帮助的截图或者类似Ps，当然如果一直没有组织级的资料库和平时不在意缺陷管理软件的版本正确性，那就只能袖手旁观了。

统计学最怕是混入了大量看起来很对或者一看就很糟的数据。勤用指笔有时候会比电脑好。

团队工作第一次结束后，可以定义交付这次结果的一个模型，是该用线型（瀑布）或者V,W,爆炸，螺旋等？

这个时候如果迷茫的话，可以借助经验数据的得出的指标，对于未来的这次做为管理依据，但用了这种方法，并不会记得在案。无论结果与否，下次依然需要和这次的相匹配。

希望看的明白。