测试建模 ——从需求的角度说建模

关于本文

在上一篇文章的实例中我们了解了基于业务流程测试的建模方法，但在实际工作中针对不同的需求我们还有很多其他建模语言可以使用。今天这篇文章将通过需求的几个不同视角来为大家介绍下还有哪些视图在测试建模中可以被我们拿来使用。

一、需求工程的多个视角

每当我们从产品经理手中接过需求文档时，往往心中的第一个疑问就是怎么“看”，在解答这个问题之前，我们先来了解下《Requirements Engineering Fundamentals》一书中关于“需求三个视角”的描述：

书中将需求分为三个视角解读：数据视角、功能视角和行为视角，并分别列举了类图，活动图和状态图，同时还特别强调了三种视角并非独立存在而是具有一定融合、交叉的关系。

数据视图：描述输入输出数据结构、静态结构及依赖关系（考虑其实际意义，后文称之为：结构视图）

功能视图：描述系统实现的功能，输入输出数据的处理

行为视图：描述系统如何运行和具体功能实现

因此，当接到一个业务需求、产品特性或是整个系统时，我们可以通过这三个视角来解读被测系统。那么，每一种视角究竟有哪些工具可以让我们进行选择使用呢？

如上图，每一种视角下都罗列了一些UML视图，如活动图、状态图、用例图等。测试建模过程中，我们可以依据一些经验从中选取一款或几款使用。

作为一名测试工程师，我们的工作不光单单关注产品本身，更多的时候还要考虑到系统的边界、环境和与之存在的相互依赖关系。(如下图)

将被测系统视作为一个整体，去关注它与外界的交互，这就引出了需求解读的另一个视角——上下文视角(Context perspective）

将以上的内容稍作整理，我们能够很快的归纳出那些将被应用在不同视角下的视图，这些都是SUT建模的表示方法。

（人机交互视角目前还理解的不到位，暂不考虑）

二、不同视图的关联

前文也提到了在需求工程里各个视角下是存在相互关联的，下面以一个例子简单为大家做个介绍。

行为视图：

① 状态机（左）：描绘了系统的几个状态和触发状态改变的事件流

② 流程图（右）：描绘了一系列动作，其中的一些动作对应到了状态机中的事件或是状态内部的某些动作

功能视图：通过数据的流动描绘了系统实现的功能，这里面的一个“功能”就对应到了行为视图中的一个具体的流程。

结构视图：描述了几个对象或是变量具体有哪些属性以及对象之间相互关系，通过这个静态图大体的描述了一个系统（被测对象）由什么组成。功能视图中流动的数据对应过来的就是具体的对象、变量。

从系统整体来看，我们把功能视作黑盒，至于怎么实现用行为视图来描述，那些功能间流动的数据对应的就是结构视图中的对象、变量。同时，状态机中的某一个状态也对应着一个对象的集合。

从SUT建模的角度来看，我们可以通过功能和行为视图来找出测试场景（基础用例）对被测对象的主要业务逻辑进行覆盖，之后通过参考结构视图来向这些测试场景中填补测试数据，从而对测试对象进行一个全面的验证。

三、如何选择视图

4个视角N种视图，在工作中我们能很快的选择出合适的那一款进行建模吗？

当然可以，以下这些经验简要的告诉了我们如何更好的选择、使用。

1. 根据需求特点选择

“名词”较多的优先选择结构视图

“功能、逻辑、算法” 较多的优先选择功能视图

2. 根据项目阶段来判断

需求评审阶段：这个阶段的目标是消除歧义、达成一致，测试建模的主要功能也是促进理解和交流，因此，这个阶段我们使用各类视图建模时不易过度关注细节，大体描述主要流程即可，我们可以随着项目的开展对模型进行迭代更新。

产品实现阶段：产品实现过程中，同时关注各种视图中的细节更有利于理解和评审真实实现逻辑，修正测试模型，生成高质量测试方案。根据产品设计构建的模型还可以用来检验设计的正确性合理性。但是要注意避免通过代码实现来推到测试模型。

提测阶段：提测时主要是对照已有模型（如果前期有建模准备）进行更新补充；或者直接应用探索式测试相关的启发式边建模边测试边反馈修正。

3. 根据个人喜好

“当你无从下手的时候，就从活动图开始”这句话是我在应用测试建模初期常常遵循的一条经验。其实道理很简单，活动图（流程图）似乎与生俱来一直都很熟悉。熟悉的视角肯定能让我们更快的入手，但更重要的一点是一定不能忽视从其他的视角去做一些补充。

“器欲尽其能,必先得其法”，云里雾里的介绍了这么多前因后果、来龙去脉却迟迟没有谈及具体的一种视图该如何使用，这目的就是为了让我们在建模的过程中更加关注对被测对象的分析，更好的了解系统、了解视图以及视图之间的关系，这将有助我们建立更好的测试模型，进而得到质量更高的测试用例，理解了这一点在去看后面关于各类建模语言的介绍将事半功倍~