软件测试之文档评审

从事软件测试快两年了，我逐渐感受到设计文档评审的重要性。经常看到课件里的描述--软件在设计阶段引入的问题是最多的，其严重性很高，修改的成本却很低。我们在平时的日常工作中经常会犯错误，那就是太过重视用例的设计与执行。这个也不难理解，我们总是想快速直接的去发现bug来交给程序处理，bug发现的越多我们的价值就越是得到体现。当然这其中也有很多客观的因素，从业人员对游戏业务的了解不足和对项目的不熟悉都导致了这一现象的产生。接下来的结果就是bug很多测试时间紧张，文档反复修改，用例不断维护等等。这对项目的进度和游戏软件的质量有很大的影响。

对设计文档评审的重要性我想不必多说了。那么游戏的设计文档如何来评审呢？下面来谈一下我个人的感受和一些方法。游戏设计文档有很多种类，书写的格式也是因人而异的。但是从整体上设计文档可分成两个层面：一是功能二是逻辑。比如，大部分描述游戏规则的设计文档都是来阐述逻辑的，大部分系统文档都是用来阐述功能的。当然很多情况下都是功能与逻辑的混合，并且功能也是通过逻辑来实现的。这里先加以区分就是为了便于我们在不同的层面上来评审文档。下面阐述一下我的一些方法：

1.询问。问谁，问什么呢？我们在评审文档的过程中应先询问设计人员的设计目的。有些文档的设计目的比较明确不需要问；有些文档的设计目的就比较隐晦了，这个就需要我们向设计人员了解。了解了设计目的，对我们评审文档是有很大帮助的，如果文档的设计目的我们都不清楚谈何评审呢？呵呵，是吧，下面我们就说问的目的。

2.功能评审。我们先了解了设计目的，那么就可以拿设计目的做为一条准绳来评审设计文档中的功能了。评审功能主要是看功能的合理性。如何来评判一个功能是否合理？这个可是很有难度的事情，不过可以先大概的定一个方向：所有与设计目的相悖的功能一般都是不合理的（注意有些功能看似与单个系统的设计目的相悖，但从整体上来考虑却是有其合理性的一面，这个需要我们与策划沟通来了解）。比如，好友系统是用来增加玩家交互方便玩家间沟通的系统，如果设计文档中存在一些不方便玩家交互的功能甚至是阻碍玩家交互的功能，我们就应该及时的通知设计人员。最好都是以建议的形式，并且应该一直保持谦虚诚恳的态度，要尊重设计人员的决定权。

另外，还有一种逆向的推导合理性的方法。我们先把文档的设计目的放到一边。从玩家的角度去感受这些功能带来的感受。如果我们的感受是较好的且感受与设计目的一致，那么说明这个功能设计的很成功是合理的；如果我们的感受一般或是感受不明显并且没有与设计目的相悖的感受，那么说明这个功能设计的一般，也可以认为该功能可以通过；如果我们的感受不好或是与设计目的相悖，那么就说明这个工能设计的不够合理，应该通知设计人员。

3.逻辑推理。人无完人，所有涉及逻辑的地方都有可能出现问题。我在测试过程中就遇到过很多关于防刷和边界的逻辑问题。在这里我要先提及一个概念，就是很多人都把测试思维说成是逆向思维，我总觉得这个说法不太合适，我认为把它描述成正常思维或是发散思维更为合理。废话不多说，那么来说一下我对文档中逻辑推理的一个方法。（其实这些逻辑也可以描述为规则）逻辑是否合理应该从这些逻辑本身出发。首先，所有的逻辑组合起来都是一条条玩家操作的通路，这些通路应该产生正确的结果。所以，当某些玩家操作没有被这些通路所包含时，那就说明有逻辑上的缺失；当玩家的操作没有产生正确的结果时，说明有些逻辑（或是规则）本身不合理（或是错误的）。针对以上情况我们就需要提交bug给设计人员，让他们去补充和完善这些逻辑。

写的差不多了，我也累了。很高兴能拿出一些东西来跟大家分享，欢迎各种鲜花和鸡蛋。最近工作忙，很久没来空间了，自己顶一下！