12.23模型测试.pptVIP

基于模型的测试 模型是对实际系统的抽象表现，它可以将抽象的事物变得具体，用来帮助认知和理解复杂的系统是如何工作的。目前的软件系统日益复杂，而人类对于复杂事物的理解有限，在这种情况下，采用模型可以将复杂的事物分割成许多清晰、易理解的单元，最终可以帮助更好地理解整个系统。 现实生活中的事物都可以用模型来表示，例如，如果要将计算机连接到Internet，则需要拨号，拨号完成后，网络状态就变为连通；一旦断开，网络状态又变为断开。网络的连接和断开可以用图来表示。 软件测试模型 模型有很多种方法表示，每一种都是从不同的方面描述系统. 控制流、数据流和程序依赖图描述了系统的行为如何根据源代码的结构加以执行. 决策表和状态机则从系统外部来描述的黑盒行为。 根据被测系统的不同特征和不同的测试目的，可以使用不同的模型，这里主要介绍以下模型：有限状态机模型、状态图模型、统一建模语言模型、马尔科夫链模型和语法模型。 有限状态机 有限状态机（FSM，Finite State Machine）是用来描述有限个状态以及在这些状态之间的转移和动作等行为的数学模型，它可以表达状态和中间过程所代表的功能。 有限状态机模型是比较常用的描述软件和软件测试的模型。 基于有限状态机的软件测试假设被测系统在某个时刻总处于某个状态，并决定了当前状态被测系统可能的输入，以及该输入之后被测系统状态的迁移，然后利用图的遍历算法，根据不同的遍历条件，如状态遍历或路径遍历产生测试用例，并将测试数据表达为输入序列。 基于有限状态机模型的测试研究难点在于复杂软件往往要用很复杂的状态机表示，因此建模显得尤为重要。 基于模型的测试技术首先要理解被测系统的功能，是建模的先决条件。测试人员可以通过参考相关文档以及手动测试等方法，对被测系统做一个探索测试的过程，并且从中可以发现建立测试模型的方法。 指导方针： (1)根据测试目标确定需要测试的组件或功能，确定什么要被建模是进行基于模型的测试的第一步； (2)有目的地使用被测系统，了解系统的功能并考虑可能引起的问题； (3)搜集相关有用的文档，如需求说明书、测试用例、规格说明书、设计文档、用户手册等； (4)确定系统的用户，列举用户可能的输入和期望的输出； (5)针对可能的输入了解其适用性和条件，以及相关的业务知识； (6)研究模型的输入序列； (7)理解系统结构、内部数据的交互和计算。 基于有限状态机模型的测试 有限状态机定义 用有限状态机来表示一个软件系统可如下定义： FSM=(I,S,T,F,L),其中： I：系统输入的集合，有限状态机只能从一个状态转换到另一个状态，而这种转换的发生完全取决于输入； S：系统状态的集合； T：用来判定当输入应用到系统的某个特定状态时，状态是否转换； F：最终状态的集合，当达到最终状态，表示系统终止； L：系统启动时的初始状态。 对于这个定义中的最终状态和初始状态存在着不同的意见，有的认为模型严格上讲只能有一个初始状态和一个最终状态，而有的则认为模型可以有多个初始状态和最终状态。 建立有限状态机模型 在理解了系统要实现的功能之后，就要建立被测系统的模型，以了解被测系统在不同状态下的运行情况，因此基于模型的测试技术主要关注的是行为模型，例如状态机和活动图。只有当清楚被测系统中的每种操作之后，才能帮助设计模型和创建测试规则。 以一个简单的例子来说明如何建立一个状态模型，如果有一个窗体如图所示，它有如下的功能： (1)当“Disable”复选框选中时，编辑框变成不可用状态； (2)当“Disable”复选框未选中时，编辑框变成可用状态； (3)当点击“Hello,world”按钮时，编辑框中显示“Hello,world”； (4)当点击“Reset”按钮时，编辑框清空，并且成为可用状态，同时复选框成为未选中状态。 要测试这个窗体，首先是通过操作为这个窗体写出简单的序列化的测试用例，如图所示。 对这个窗体的测试用例可以如表所列 这样的测试有一些缺点 首先，这些测试用例需要手动的维护，如果需要增加一个测试用例，如增加一个测试用例不做任何操作就关闭窗体，那么这些测试脚本就需要更新。 测试用例是静态的。 建立一个状态模型可以加深对软件如何工作和不同测试组合的理解。 基于模型的测试技术的核心就在于使用一种能够被用来生成测试的方法来描述预期的行为，针对每个将要测试的操作，必须要了解以下两个问题： (1)什么时候可以执行这个操作？ (2)这个操作执行后的状态应该是怎么样的？ 从图上可以看出，Sample窗体有五个可能的状态，如表所示。 下图包含了这个窗体的状态模型。五个圆框代表窗体五种可能的状态，连线代表了基于各个状态可以进行的操作。 这样一个有限状态机模型可以定义为： 这个模型也可以用状态表进