需要谈谈的 游戏测试改良流程（二）

互联网的产业里，网络游戏产业也是其中的一部分，改良流程的一部分也介绍一些基础的模型。本章介绍的是瀑布模型的应对办法。

瀑布生命周期模型：（也被称为线性模型）

[需求分析]=>[概要设计]=>[详细设计]=>[编码和单元测试]=>[软件集中]=>[系统集中]=>[验收测试]=>[结束]

这是一个版本简单的交付过程，最后一步测试才介入。这个软件行业刚发展时的流程。现在依然还是不少游戏公司的交付模式。

游戏产业有些许的变化：

前者

[需求分析]由策划部门给予 通常由2个部门执行：程序，美术

[概要设计]通常由3个部门执行：策划，程序，美术。

[详细设计]通常由3个部门执行：策划，程序，美术。

[编码和单元测试]由程序部门执行。

游戏产业测试大部份公司都无法获悉代码，所以这部分就没办法了。

[软件集中]由程序部门执行。

这个应该是程序的代码view，具体对不对我也不清楚。

[系统集中]功能模块的集中，准备交给测试了。

在瀑布生命周期里，这时候还是没有交给测试。

[验收测试]

这个版本的内容终于交到测试手中了。

如果遇到这种情况，我们该怎么办呢？接下来看看这个流程：

后者

[需求分析]由策划部门给予 对口的部门：程序，美术，测试

测试获得策划部门的策划案后，先进行需求分析。添加总表的测试计划，分析关系点和测试粒度。

[概要设计]通常由3个部门执行：策划，程序，美术，测试。

测试也可以加入，但是和其他2个部门无交集。编写第一个版本的测试用例。

[详细设计]通常由3个部门执行：策划，程序，美术。

测试也可以加入，可能和策划沟通较多。考虑到一些接口设计和测试用例补充完整。

[编码和单元测试]由程序部门执行。

当然如果你愿意的话，也可以提供些静态代码测试工具。例如PR公司的PRQA。静态的代码不需要经过调式。

[软件集中]由程序部门执行。这个我不清楚具体内容，不发表评论。可以在这个阶段进行功能单元模块测试。功能的迭代测试。

[系统集中]功能模块的集中。可能在这个阶段进行了多次迭代测试。当缺陷数量满足缺陷密度大概2次左右，实际是根据当前版本内容而定的。

[验收测试]

接下来按策略进行快速回归和冒烟就可以发布，看这个时候就能轻松交版本了。而测试团队的能力也不会因为大量等待的空档期而荒废。

然后前者传统等待的办法，会一时很紧一时过松。而且整个项目的进度也会因为测试周期和延后修复bug占用正常研发团队的沉余时间。

另外注意一些固定规则的无益：

（1）团队比较忌讳有不合理的空档期<wbr> （2）在缺陷密度已经达到后，依然进行量化测试、<wbr> end</wbr></wbr>