再学UML-Bug管理系统UML2.0建模实例
Posted 软件测试培训
tags:
篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了再学UML-Bug管理系统UML2.0建模实例相关的知识,希望对你有一定的参考价值。
https://item.jd.com/34295655089.html
https://item.jd.com/12082665.html
店铺二维码:
来源:http://www.51testing.com
1.项目概述
随着软件项目规模和复杂性的增大,有效跟踪和管理项目中存在的缺陷Bug变得越来越重要。每一个软件企业都需要妥善处理软件中的缺陷,这将直接关系到软件过程质量与软件产品质量,但并非所有的软件组织都知道如何有效地管理自己软件中的缺陷。在软件缺陷管理(Software Defect Management)中,软件缺陷的分类和管理非常重要,因此软件缺陷管理工具的开发和使用将在现代软件开发中发挥重要作用。本系列文章将使用UML2.0对Bug管理系统进行全程建模,该系统名为缺陷管理系统(Bug Management System, BMS),并按照软件工程的标准,提供一套完整的解决方案。
1.1 需求分析
一个完备的bug管理流程通常包括如下几个步骤,如图1-1所示:
图1-1 bug管理流程图
图1-1是bug管理的最基本流程,而实际的bug管理要更加复杂,不同的步骤由不同的角色负责,如提交bug、验证修改后的软件是测试人员的工作,分析和定位bug以及修改相应的软件是分析设计人员以及开发人员的工作,在整个过程中项目经理还需要对bug信息进行统计和监控。在BMS的需求分析过程中,我们发现bug管理流程的某些步骤可以通过一个bug管理系统来完成,一方面可以提高bug的处理速度,另一方面便于对bug信息的跟踪与统计。
通过对bug管理流程和实际使用过程的需求分析,BMS系统基本需求如下:
(1) 系统预设管理员帐号为Admin,初始密码为Admin。BMS系统管理员在登录系统后可修改密码,系统管理员的主要工作包括增加相关人员初始信息,包括帐号、初始密码和项目角色,项目角色包括测试人员、开发组长、开发人员和项目经理;另外,系统管理员还可以删除人员信息。
(3) 测试人员可以利用BMS提交自己发现的bug信息,提交的信息包括bug类型、bug严重程度、bug发生的位置(如所处功能模块、测试界面的URL或名称等)、测试环境描述、使用的测试工具和版本信息、测试用例信息(包括测试数据、期望结果和实际结果等信息)、附加描述信息、附件(屏幕截图或录像等)等。测试人员将尽量填写完整这些信息以便最大程度帮助开发人员重现bug以便调试,在系统数据库中需要记录bug的状态。
(4) 测试人员将bug提交给开发组长,开发组长在查看bug信息之后可将bug分发给相关开发人员,系统可以记录开发组长的bug查看和分发情况。
(5) 开发人员可以登录系统查看bug详情,系统可以记录开发人员是否已查看bug详情。在对bug进行修复后,更新bug修复信息(修复内容、修复时间、修复人等),将更新的bug信息发送给测试人员,系统将修改bug的状态,然后通知测试人员以获取最新版本进行验证。
(6) 测试人员如验证无误,可关闭该bug;否则可重新返回开发人员修复。无论验证是否通过,测试人员需更新bug测试信息(测试结果、测试时间、测试人等)。
(7) 项目经理可以随时查看bug统计报告,对bug信息进行分类汇总与实时跟踪。
1.2 开发技术
本系统采用三层B/S结构进行开发,包括客户端浏览器层、Web服务器层和数据库服务器层,系统整体架构如图1-2所示:
图1-2 BMS整体架构
在实际部署和使用过程中,如果数据量较小,可以将Web服务器和数据库服务器合二为一。B/S结构具备部署和升级简单等优点,系统安装、修改和维护全在服务器端解决,用户在使用系统时,仅仅需要一个浏览器就可运行全部的模块;同时B/S结构还提供了一种异种机、异种网联机、联网解决方案,开发团队与测试团队可以基于不同的操作系统平台和网络环境进行协同工作。
BMS系统开发技术包括:采用Java EE平台,使用MVC架构,运用JSP + Servlet + JavaBean等技术来实现系统功能,数据库采用MySQL,并使用Navicat 8 for mysql对MySQL数据库进行可视化管理,服务器中间件使用Tomcat 6.5,开发工具使用MyEclipse 8.0。
2.系统分析
在BMS的系统分析阶段,我们使用了用例图、顺序图、状态图和活动图等UML图形构造系统的分析模型,对系统进行深入的分析,明确系统的开发目标,更好地回答了“做什么”的问题,各种图形相互补充,从不同的角度对系统进行全面的分析。通过使用UML方法,我们构造了系统的分析模型,具体分析工作如下:
2.1 用例模型
在BMS系统中,我们首先使用用户视图即用例图来将系统功能需求图形化,通过找出执行者与用例来明确和细化系统功能。
UML用例建模流程如图2-1所示:
图2-1 UML用例建模流程图
BMS的执行者包括系统管理员、开发组长、开发人员、测试人员和项目经理,每个执行者对应的功能有所差异。系统提供主要功能包括人员信息的管理和bug信息的管理,因此用例主要包括对人员信息和bug信息的增删改查等操作。
2.2 BMS用例图
通过对系统进行分析,BMS用例图如图2-2所示:
2.3 BMS顺序图(需求模型)
在UML中,我们将顺序图分为两类,一类用于描述系统需求,构造系统的需求模型(分析模型);另一类用于指导设计与实现,构造系统的实现模型(设计模型)。
在系统分析时,可以通过顺序图来对执行者和系统的交互过程进行建模,方便用户更好地理解系统的工作流程。对于需求模型顺序图,一般使用用户熟悉的业务语言来进行系统描述,不涉及到实现细节,一方面方便用户理解,另一方面可以指导后续类图的设计。顺序图可显示不同的业务对象如何交互,对于交流当前业务如何进行很有用,一个业务级的顺序图能被当作一个需求文件使用,为实现一个未来系统传递需求;同时,顺序图能够使用更为清晰形象的表达,将用例带入下一层次,通常一个用例可以被细化为一个或者更多的顺序图。顺序图的主要用途之一,是把用例表达的需求,转化为进一步、更深层次的精细表达。
根据需求我们绘制了每一个用例的顺序图,由于篇幅关系,未将每个用例的顺序图一一列举。图2-3、2-4、2-5、2-6分别是用例“登录”、“提交bug信息”、“查看bug信息”和“更新bug信息”的顺序图。(部分顺序图)
图2-6 用例“更新bug信息”顺序图(需求模型)
在实际开发中,我们可以使用顺序图来描述用例的路径,此时,顺序图可以画得更加简单,最简单的顺序图只有两个交互角色,即“执行者”和“系统”。上述四个顺序图还是有点点偏技术的,微笑,在真正与用户交流时可以用更简单的形式。
2.4 状态图(需求模型)
在需求分析过程中,我们发现BMS系统的核心对象是bug,因此可以使用状态图对其进行建模。UML中的状态图可以用来描述一个特定对象的所有可能状态及其引起状态转移的事件。只有那些具有重要交互行为的类,才会使用状态图来描述,一个状态图包括一系列对象的状态及状态之间的转换。在实际建模中,并不需要给出每个对象的状态图,而需要将注意力集中在整体系统或少数关键的对象上,特别是那些状态比较多的对象。
在BMS系统中,最复杂也最为重要的对象是bug,它在系统中拥有多种不同的状态,不同类型的用户可以对其进行操作,为了更好地描述bug对象状态的转换,我们绘制了bug对象状态图,如图2-7所示:
在图2-7中,我们可以清晰了解bug对象在系统中所具有的状态以及这些状态之间的转换过程,如测试人员提交的bug其状态为“新提交bug”,开发组长查看后该bug的状态将变为“开发组长已查看bug”。
2.5 活动图(需求模型)
在状态图中,我们描述了BMS系统中bug对象的各种状态以及状态之间的转换关系,但是这些状态在转换的过程中无法确定何种状态由哪类执行者负责操作,因此可以通过活动图来进行建模,此时的活动图用于对需求模型进行进一步细化。在系统分析过程中,我们使用活动图取代传统的流程图,在表示系统业务流程的同时通过泳道来确定每一个活动的执行者。在活动图中我们还使用了对象流来表示活动与对象之间的依赖关系,描述在活动中对象的状态。通过活动图建立的模型比状态图建立的模型具有更多信息,在BMS中,我们描述了不同用户对bug的操作活动以及在每一次活动之后bug对象所处于的状态,对操作流程进行图形化建模,如图2-8所示:
图2-8 BMS活动图
3.系统设计
在对系统进行全面分析后,我们开始使用UML对系统进行设计,构造BMS系统的设计模型,包括类图、包图、顺序图(实现模型)、组件图和部署图等的绘制,回答了“怎么做”的问题。具体设计工作如下:
3.1 体系结构设计
BMS采用多层Java EE设计方案,考虑到系统的扩展性,定义了抽象的数据访问层,系统体系结构图如图3-1所示:
图3-1 BMS体系结构图
在图3-1中,BMS系统一共包含五层,其中表示层使用JSP来实现,控制层使用Servlet实现,Servlet将调用业务逻辑层中的方法实现具体业务功能,如果业务功能在实现过程需要访问数据库,则调用数据访问层中的数据库操作方法,为了保证系统的扩展性,我们定义了抽象的数据访问层,业务逻辑层针对抽象数据访问层编程,而将具体数据访问类类名存储在配置文件中,使用XML格式的文件作为配置文件,提高系统的可扩展性。具体实现方案如图3-2所示:
图3-2 数据访问层扩展实现方案
3.2 类图
类图是一个面向对象系统最核心的设计图之一,BMS的主要功能包括bug管理和人员信息管理,针对这两个主要功能模块,我们绘制了两个类图,图3-3对用户信息管理进行建模,图3-4对bug信息管理进行建模。
为了更好地描述各种不同的类,我们使用了彩色UML建模方式,不同类型的类使用不同的颜色来表示,如使用红色表示数据传输类DTO,使用粉红色表示JSP界面类,使用绿色表示Servlet控制类,使用蓝色表示业务逻辑类BO,使用浅蓝色表示数据访问接口IDAO,使用橙色表示数据访问类DAO。
图3-3 用户信息管理部分类图
图3-4 bug信息管理部分类图
欢迎参加众测:
https://wap.ztestin.com/site/register?usercode=FAAAQwMQGAAXAwQBA3QhExcDHAQDPjVaABMIQg%3D%3D
顾翔凡言:比测试技术更重要的是测试思维。
以上是关于再学UML-Bug管理系统UML2.0建模实例的主要内容,如果未能解决你的问题,请参考以下文章