基于模型的测试（二）

2. 规格

前提：被测的软件处于集成或者在开发过程中的系统测试阶段。（图一） 暗含的测试对象是为了保证从外部视角来看系统满足需求。关注的

焦点不在如何执行，而在于用户如何评估它们。测试将根据规格衡量系统的整体的功能的编译，而不是根据代码覆盖率。这些测试有时候被理解为验收测试，这是一种传统的黑盒测试的执行实施。

我们在开发测试中要克服的第一个困难就是确定测试目标。这点听起来似乎不重要，但是它往往是最容易出错的地方。被测产品或程序的描述是最基本的。这些描述常用的格式会根据一组语音邮件系统的呼叫流程图而变化，这个系统是为了计费系统的GUI的用户使用说明。为了定义工作范围（无论是开发还是测试），产品的行为和功能需要被很好的定义和描述。传统的方式是通过令人乏味，平铺直叙的文字描述而成的需求说明，产品规格说明。  规格一旦通过文字描述，那么通常是不完整的，只有典型和理想的功能使用会被描述，而不是所有的可能行为和用户场景。这些不完整的描述使得测试工程师不得不等到产品发布的时候才能了解到功能的详情。那个时候系统完整的上下文才明确，才能开始开发测试用以验证所有余下的可能的场景。另外一个问题是，文字的描述表意模糊（例如：如果非法数字输入，系统会合理地处理，在这里合理没有被定义，如何处理才叫合理）；另外更加过分的是，这将留个用户去理解。 例如，这个问题你认为我们应该允许用户重新尝试并输入，但是我认为我们应该舍弃这个命令。如果你编码，而我来设计测试，那么测试一定会失败，我们还会为了争论这个早该被定义清楚的不是问题的问题而浪费大把时间。在最近的需求工程大会上，通过统计，60%~80%的缺陷的根因是需求没有被正确的描述。

在这个时候在开发过程中使用建模可以戏剧性地减少模糊性——也就是后来减少错误。组织不需要达到SEI等级3或者等级4来实施这些技术；它们能被用在任何地方。实际上，模型并不是一个新的技术。测试工程师经常构建模型。唯一的问题是模型是否应该是固定不变的形式。“模型”大家常常用到，但是形式不一，可能只能存在一小段时间，而且是记录在工程师的餐厅纸或者脑子里。为了写出测试脚本或者测试计划，工程师需要知道系统使用的基本步骤。在操作层面建模和绘制流程图和类似；产品使用中的主要事务以图形的方式被定义。在系统使用中可能会发生的动作顺序被定义。可能发生的动作还意味着在流程的特殊的点可能存在不止一个的动作。大部分建模技术都支持有多重可能的下一步的思路。许多方法论基于状态机的概念，事件在图中根据行为通过箭头来表示，而各类形状的图标表示状态。 一些建模技术支持分层建模，一个状态可以被一个调用其他模型（描述状态内部行为）的“调用”所替代。分层模型使得复杂行为分解为简单的低层次的行为。附加建模能力包括条件的使用、判断的使用，根据变量或者系统上下文来确定事务（箭头）。在研究和工业中被使用的其他文字的格式和符号还包括SDL和 Z [5] both common to the communications sector。非正式但却效果还不错的是符号，Beizer在他的书《Black Box Testing》使用过。这本书审视一些不同的类型的应用并通过简单的文字符号来为每个应用定义合适的模型。

在某种形式的模型下开发出规格，即使是在流程的后期完成，在一下几个方面非常有效：

1）在系统发现缺陷（很多缺陷在建模的时候就能明显发现出来）；

2）可快速定义出系统的用户使用场景的基本操作；

3）可以为下个版本或者其他类似的系统复用；

另外需要强调的是，开发模型会发生在可衡量的小的增量步骤的过程中；