购买
下载掌阅APP,畅读海量书库
立即打开
畅读海量书库
扫码下载掌阅APP

4.3 基于UML视图的测试用例设计

如果觉得流程图不能彻底解决问题、不够专业,就应该考虑用UML。写软件就好像建房子一样,系统越复杂,就越需要用专业的手段。如果软件系统复杂,UML就是一种有效的专业工具,可以帮助我们设计测试用例,甚至可以基于UML实现测试用例的自动生成。

UML视图比较多,在最新版本UML 2.4(目前还是Beta版本)中,将建模图形分为两大类,一类是结构图(Structure Diagram),描述软件系统及其组成部分的静态关系;另一类是行为图(Behavior Diagram),描述系统的动态信息,即系统随时间发生的一系列变化。这两部分图构成一个完整的描述体系,能够覆盖测试用例设计所需的各种手段,如图4-8所示。

图4-8 UML 2.4的结构图和行为图总览

UML 2.4 的静态结构图在原来的类图(Class Diagram)、对象图(Object Diagram)、包图(Package Diagram)、综合结构图(Composite Structure Diagram)、组件图(Component Diagram)、部署图(Deployment Diagram)和配置图(Profile Diagram)等的基础上,增加了模型图(Model Diagram)、表明图(Manifestation Diagram)、网络架构图(Network Architecture Diagram),描述能力和灵活性大大增强,可以描述任何复杂系统。

UML 2.4的动态行为图基本没有变化,主要是用例图(UseCase Diagram)、状态机图(State Machine Diagram)、活动图(Activity Diagram)和交互作用图(Interaction Diagram)。交互作用图又分为序列图(Sequence Diagram)、通信图(Commnication Diagram)、时间图(Timing Diagram)和交互概览图(Interaction Overview Diagram)。交互概览图,将活动图联系起来,形成完整的系统活动关系图。

在测试用例设计中,这些图都有帮助,但要看采用什么测试方法。例如,如果采用白盒测试方法,类图、对象图、组件图、配置图、时间图、通信图等对测试用例设计有更大帮助。如果采用黑盒测试方法,用例图、活动图、序列图等有更大帮助。如果介于黑盒测试方法和白盒测试方法之间,则综合结构图、状态机图、交互概览图能提供有效的帮助。

用例图可以帮助我们找到使用系统的各种用户角色,而且了解不同用户角色对系统操作的区别。用例图通常与软件应用场景紧紧联系在一起,从测试用例设计角度看,就是挖掘软件产品的不同应用场景,以便设计足够的测试用例覆盖这些场景。举一个例子,对于一个医院门诊预约系统,它的用户角色包括病人自己、病人家属、医生、医院门诊部、系统管理员等,如图4-9所示。病人自己可以预约看病的时间和医生,也可以取消相关预约,还可以让家属帮他(她)预约。在测试时,我们就要考虑这两种预约有什么不同,以及考虑“能否相互交叉取消”等问题。而对医生、医院门诊部等不同角色的用户,他们看到的信息应该是不一样的,医生希望看到自己在未来一周、一个月有多少病人,占用了哪些时间。而医院门诊部更关心今天各个医生的预约情况,以及如何检查医生门诊的状态等。基于用例图的一个用例,可以产生若干个测试用例,反过来,测试用例要覆盖所有的用例。

序列图不仅可以表示角色活动,理清先干什么事、后干什么事,而且可以帮助我们了解活动期间有哪些信息传递、信息又是如何传递的、返回什么样的信息给用户角色。通过序列图,可以描述对象之间的交互作用,这对白盒测试用例设计会有更大的帮助。对象拥有行为和状态,序列图描述了对象的行为的时间过程,而状态图可以描述对象状态的变化。在传统的方法中,我们常常根据系统状态发生的变化来设计测试用例,即功能图法,它根据状态迁移图来确定系统状态变化的路径,进而设计相应的测试用例来覆盖状态变化的路径。而UML状态图则是以更低层次、更准确的办法来描述对象的状态变化,但从本质上看,两者没有什么区别,只是UML状态图更专业、更系统地描述对象的状态变化,以及事件的触发机制。

图4-9 UML用例图的示例

活动图可以描述两个或者更多类对象之间的过程控制流,而且适合在业务单元的级别上对更高级别的业务过程进行建模,而且也更容易理解,这对测试用例设计很有用。活动图实际上是一种特别的流程图,从这个意义上说,它和4.2节讨论的“基于流程图设计测试用例”是完全相通的。活动图和状态图也有类似的作用,只是状态图把焦点集中在过程中的对象身上,而活动图则集中在一个过程的流程上,并能够揭示各项活动之间的依赖关系。在设计测试用例时,依赖关系也是我们关注的焦点。如果设计人员、编程人员忽视了某种依赖关系,就会引入严重的缺陷。依赖关系的考察,是测试用例的重要组成部分。例如,如图4-10所示的ATM取钱过程的活动图,显示出密码验证、账户余额等依赖关系。

图4-10 ATM取钱过程活动图示例 eQKkfTjVtcCbEbIP7K0MNOMD7EPnbzptsNAZBsFOQdnK9KmOXbpevsaZZYXsJeRS

点击中间区域
呼出菜单
上一章
目录
下一章
×