基于VMD开发工具的敏捷测试实施研究doc.docx
- 文档编号:26030825
- 上传时间:2023-06-17
- 格式:DOCX
- 页数:24
- 大小:142.53KB
基于VMD开发工具的敏捷测试实施研究doc.docx
《基于VMD开发工具的敏捷测试实施研究doc.docx》由会员分享,可在线阅读,更多相关《基于VMD开发工具的敏捷测试实施研究doc.docx(24页珍藏版)》请在冰豆网上搜索。
基于VMD开发工具的敏捷测试实施研究doc
基于VMD开发工具的敏捷测试实施研究
摘要
P8_VMD可视化开发工具旨在代替传统的Eclipse,为P8平台应用开发人员提供一个可视化图形配置的操作环境。
经过实践,传统的测试方法很难满足在VMD开发工具开发过程中,需求持续变化,模块功能不断迭代、版本变吏速度快的特点,为了进一步提高测试效率,规范测试流程,充分利用开发工具开发过程特点,VMD测试小组将对比传统测试方法的不足,探索新的测试方法,基于敏捷测试理论进行测试实施,以满足当前开发过程中的测试需求。
本文通过介绍新职员赵筝在VMD小组的参与情况,结合敏捷测试的技术特点,深入探讨在vmd工具的开发过程中如何应用敏捷测试提高测试效率,其与传统测试的过程与结果的对比,以及详细的可行性分析。
关键词:
VMD可视化开发工具、敏捷测试
1绪论2
1.1研究背景2
1.2研究意义2
1.3研究内容与难点3
1.4论文结构3
2敏捷测试技术理论及工作流程4
2.1敏捷测试介绍4
2.1.1敏捷测试的概念4
2.1.2与传统测试对比5
2.2VMD开发工具与当前测试情况7
2.2.1VMD工具架构7
2.2.2VMD目标及使用7
2.2.3VMD角色管理9
3VMD测试实践总结9
3.1VMD1.0版本测试情况介绍9
3.2VMD1.0版本测试总结11
4基于敏捷测试的VMD3.0版本测试分析12
4.1VMD3.0版本的敏捷开发的背景12
4.2依赖VMD开发的敏捷测试设计12
5总结与展望16
5.1展望及改进建议16
1绪论
1.1研究背景
新一代VMD可视化开发工具是一个客户端的开发工具,其建立在IBM的RSA平台的基础上,旨在以流程图生成用户所需的java代码,使用对象为各开发中心项目组的开发人员。
主要开发技术为Eclipse的插件开发技术。
相比于传统的Eclipse开发工具,VMD旨在将P8交易逻辑可视化、结构化、并能够从流程图中反映交易实现业务逻辑,最终做到开发代码的高效性、一致性,并旦增加开发资产的可复用性。
VMD开发技术支持小组负责此工具的完整开发生命周期,从最初的需求分析到开发、测试,再到版本发布、缺陷修复以及产品维护。
其中,测试是一个必不可少的环节,它把控着最终的产品质量,及时发现程序错误,联系开发人员,及时修改缺陷,以满足设计需求。
在VMD快速的开发过程中,VMD测试小组责任重大,为尽可能达到需求标准,须仔细分析VMD的开发特点,有针对性的采用适当的测试方•法,按时按量的完成测试任务。
敏捷测试是其中的选择之一,本文将结合VMD开发的自身特点,着重对敏捷测试应用的可行性进行分析。
1.2研究意义
VMD工具的测试与传统的银行业务系统的测试颇有不同,因此不适用于传统的测试方法进行测试,传统测试中,测试环节在开发环节之后,两者相互独立,不直接沟通,且传统测试不太追逐效率,尽可能保证案例覆盖率等测试标准,流程清晰复杂。
对比来看,VMD测试由于产品性质与开发周期的不同,导致测试流程以及测试的侧重点均和传统测试有较大差距。
结合VMD产品周期较短,且须及时、持续地响应客户频繁的反馈等特点,敏捷测试便成为VMD测试员不得不考虑的途径。
敏捷测试即是不断修正质量指标,正确建立测试策略,确认客户的有效需求能得以圆满实现和确保整个生产的过程安全
的、及时的发布最终产品
1.3研究内容与难点
本文主要以研究敏捷测试在VMD项目中的可行性分析为主。
从VMD的角度出发,结合VMD的开发特点,对比不同版本的VMD测试情况,提出使用敏捷测试的可行性。
例如,由于各个节点功能会因彼此的复杂性不同,开发周期也会有所差别,先开发完成的模块完全可以先进入测试阶段,尽早发现模块质量问题从而反馈至开发人员,持续地进行验证,而不是等到所有代码完成后才开始测试,这也包括参与到单元测试和集成测试中。
除此之外,本文还将从测试流程、测试方法等方面论证敏捷测试的可行性和优势所在。
再经过总结、对比,发掘当前的测试问题以及描述将来的优化方向
1.4论文结构
本论文共分为五章。
第一章,绪论(即本章)。
介绍论文的研究背景、研究意义、研究内容以及论文的组织结构。
第二章,敏捷测试工作流程及技术理论综述。
介绍VMD开发技术支持组的测试工作流程现状及需要的技术理论基础。
第三章,介绍了学员一年中参加的主要实践,以及学员在项目中的思考和总结。
第四章,敏捷测试集成VMD开发的实施。
在了解相关测试理论基础、参与测试实践的基础之上,结合VMD开发的特点阐述如何使用敏捷测试的方•法设计测试案例,安排测试流程,分析测试结果。
第五章,总结与展望。
本章在对敏捷测试理论、方法和流程、系统开发与应用等方面的学习总结基础上,提出了个人对于VMD测试技术和流程等方面的建议。
2敏捷测试技术理论及工作流程
2.1敏捷测试介绍
2.1.1敏捷测试的概念
什么是“敏捷测试”?
敏捷测试既不是一种方法(如黑盒方法、白盒方法等),也不是一种方式(如探索式测试)。
因为在敏捷测试中可以采用已有的各种方法,包括白盒方法、黑盒方法;在敏捷中也可以采用探索式测试,也可以采用基于脚本的测试。
那敏捷测试是什么?
敏捷测试应该是一套解决方案、一•类测试操作与管理的框架、一组实践或由一定顺序的测试活动构成的特定的测试流程。
就像Scrum一样,Scrum可以理解为敏捷方法的具体实现的框架、一组实践或具体的解决方案。
简单地说,敏捷测试就是顺应敏捷开发方法、力求达到质量和效率平衡的一系列的测试实践。
Wikipedia是这样描述敏捷测试的:
Agiletestingisasoftwaretestingpracticethatfollowstheprinciplesofagilesoftwaredevelopment.Agiletestinginvolvesallmembersofacross-functionalagileteam,withspecialexpertisecontributedbytesters,toensuredeliveringthebusinessvaluedesiredbythecustomeratfrequentintervals,workingatasustainablepace.
它强调敏捷测试是遵守敏捷开发方法原则之下的软件测试实践,由跨功能敏捷团队的所有人员参与(包括测试人员以其专业特长的特殊贡献)以保证持续的、快速的业务价值交付。
所以要理解敏捷测试,我们要仔细看一下“敏捷宣言”:
4-个体与交互重于过程和工具
1可用的软件重于完备的文档
』客户协作重于合同谈判
上相应变化重于遵循计划
2.L2与传统测试对比
如同功能集成测试处对行内业务交易系统测试,传统测试的流程大致如下:
启动准则
制定洌试计划
设计厕试用例
回归测试
消除软件缺陷
完成准则
第一步:
准备产品设计文档,确定测试策略,制定测试计划,主要完成分析准备工作。
第二步:
根据文档分析结果,设计测试用例,保证测试用例的测试覆盖率以及其他一系列测试指标。
第三步:
执行测试。
执行测试主要是搭建测试环境,执行测试用例。
执行测试时要进行进度控制、项目协调等工作。
第四步:
提交缺陷。
这里要进行缺陷审核和验证等工作。
第五步:
消除软件缺陷。
通常情况下,开发经理需要审核缺陷,并进行缺陷分配。
程序员修改自己负责的缺陷。
在程序员修改完成后,进入到回归测试阶段。
如果满足标准,那么正常结束测试。
第六步:
撰写测试报告。
对测试进行分析总结。
可见,传统测试具有以下特点:
各个流程处理的顺序清晰,各节点耦合度较小,进程拆分明显,测试过程有严格的规范计划,与开发部门沟通相对较少,且测试工作开始于开发之后等特点。
再通过上文对敏捷测试概念的总结对比可以看出:
“沟通”非常重要
敏捷测试更强调人的作用,强调测试人员与开发人员之间的沟通。
以往我们总要等到产品的一个正式版本发布,才可以开始测试,否则过多的介入会打乱开发计划。
而现在,敏捷测试告诉我们,在产品开发过程中就要介入测试。
此外,在传统的功能测试中,当一个测试人员发现并提交一个bug时,需要在QC中写大量的文字来描述bug的环境以及bug的重现步骤,并流转到FLPM平台发送邮件,以通知对应开发人员修复bug,整个流程冗长,且如果文字描述不够清楚,开发人员很可能无法确定bug。
而在敏捷测试中,测试人员所需要做的,是与开发人员直接沟通,把问题说清楚,让他能够准确的理解你的意思,甚至包括你对于该bug的分析。
接下来一切就十分好办了。
到这里,其实我们已经能感受到,测试的角色定位已经变了。
因为敏捷开发中,要对质量负责的是整个团队,这一目标就要求测试人员不再是一个独立的质量监督部门,而是要融入到整个团队中,成为开发中不可分割的一部分O
2)调整测试用例的粒度
业界通常认为,测试员最重要的技能就是写用例,通过用例来表达测试思想。
我想,即使是到了敏捷时代,这个技能仍然是第一位的。
只是,如果你的用例写得过于详细和复杂,那么在团队开始响应变化的时候,你就会措手不及了。
至于粒度到什么程度才是合适的呢?
那就要看个人的能力,是否强大到能随时调整一份复杂和详细的用例的程度。
一般不推崇十分详细的用例,因为有些很细节的地方,也没有文档可以参考。
敏捷的最直接的特点就是快速,如果设计的用例粒度太细,那是很难开展敏捷测试的。
3)更多的人参与测试
当测试人员已经不再是一个独立的测试部门时,需要进行测试的也就不只是测试人员了。
开发人员也要自测,不同的人可以得到不同的结果,这样才能使我们对产品有全面的把握,才能时刻的知道产品下一步应该怎样“响应变化”。
并且开发人员的自测使他亲自体验自
己开发的系统,甚至可能由此得出进一步的改进优化方案,这些将是日后开发,更迭版本最有价值的信息。
2.2VMD开发工具与当前测试情况
2.2.1VMD工具架构
可视化开发工具VMD是建立在IBM的RSA平台的基础上开发的以流程图生成代码为目的的开发工具。
主要开发技术为Eclipse的插件开发技术、RSA模型框架、EMF、SWTDesign.JET等。
其主要功能模块包括VMD视图和其视图下的构建发布、模型构件、数据结构、联机服务等,以及一些技术组件,如数据字典、模型校验等。
VMD逻辑架构图:
集成软件
VMD功能组件
艮务
VMD技术组件
Maven
事傩制」数据字典■模型校验■缓存W3豌性分析.牒吴金.视图
栩牛设计新用设计
•图形的管理和维护
•UML2.2模型管理
•流程及对象管理
RSA•良好的Java及其他语言平台支持
•Clearcase版本控制支持
•提示/校验等辅助功能
EclipseHStBS
2.2.2VMD目标及使用
VMD目标是以模型驱动开发,在使用VMD开发时,首先通过界面导航配置建立相关模型,再通过此模型经过格式化生成相应代码。
模型以建立构件(即类的方法)为核心,可配合数据结构、数据字典等
封装成需求所用构件,封装过程实质为一个方法程序的流程图设计,可通过拖拽图元配合图元图解等完成此流程图,而最终将此构件被封装为所需服务以供其他服务调用。
一切以界面图形化开始,以生成正确的需求代码并通过单元测试结束。
VMD使用流程
Q卧m志/任答仁巴翌Q整怡m:
.、
VMD使用界面
冒VMD曜富y包妙管理器m膏▽oH
■号demoVl-model
>崩构件矛
」&构件
」俺com.ccb.test
T^.7iassA(i!
^A)
杉aMethod(a方法)
A杼艰§
>盆外呼踽
基本曼K
构1牛调月信息
构件方法名:
。
utboundServiceExeojtor.doOutExe
场入仲竺息:
StringoutService
TxRequestMsgBodyEntityentity
TxRequestMsgBodyCommoncommon
2.2.3VMD角色管理
VMD开发技术支持组人员流动性较高,一般维持在14人左右。
需求分析阶段几乎全员参与分析讨论制定开发方案,由于VMD是一个java开发工具,所以每一位组内容成员必须具备一定的java开发基础。
VMD至今已经发布了三个大的版本,VMD2.0版本之前,测试并不够规范性,且在开发完当前版本功能后才开始展开功能测试与性能测试。
2.0版本之后,由于有原版本功能点的依赖,开发任务相对减轻,才逐渐讨论具体的测试方案以及测试计划。
组内固定测试员占总人数的三分之一左右,也会根据实际情况进行角色调整。
3VMD测试实践总结
3.1VMD1.0版本测试情况介绍
为对比使用敏捷测试方法,首先在此对早期版本VMD的测试情况进行简介,本人于2014年10月份进入VMD开发技术支持小组,此口寸VMD组刚刚开发完VMD1.0版本的基本功能,尚未测试。
因此我参与了整个VMD1.0版本的测试过程。
VMD1.0版本总共6人负责全职测试工作,同测试中心一样,测试分为功能测试和性能测试两个方面进行。
根据VMD界面特点,功能测试按两种方式进行切分:
模块功能和操作流程
功能模块:
J7]NameVo.javaS3、
J|1packagecom.(
23一/**
•
件捍用
构麴引
厚-
一EJ
nJ3
竺
*@version
*model201:
*code2013-
*hello
*/
10
VMD使用流程:
建立数据结构
建立dao层构件
建立主业务逻辑构件
使用三段论进行服务封装,生成配置文件
生成外呼引用
各测试人员先以功能点进行划分分配测试。
比如A负责测试数据结构模块,B负责联机服务,每个测试人员将负责每个模块的整个流程测试,测试模块再以周期性轮换保证测试质量
非功能测试重点放在两个方面:
1.VMD启动时间以及各模块执行效率2.各模块执行时内存占有率。
各开发环境打开时间对比:
测试内容
Eclipse
全量RSA
VMD
精简版RSA
启动时间
初次启动
(-clean)
18秒
5分31秒
43秒
40秒
重新启动
16秒
26秒
24秒
20秒
占用内存
214352k
470228k
306052k
301712k
打开文件
<1秒
<1秒
<1秒
Q秒
编辑保存时间
<1秒
<1秒
<1秒
<1秒
打包
40秒
1分08秒
1分03秒
5]秒
编译时间
单个文件
<1秒
<1秒
<1秒
<1秒
全量
27秒
36秒
27秒
26秒
Tomcat启动时间
13秒
53秒
51秒
50秒
关闭时间
<1秒
<1秒
<1秒
勺秒
连续200个构件模型校验内存走势图
3.2VMD1.0版本测试总结
VMD1.0版本测试由于时间有限以及人员限制并没有严格按照传统的测试流程执行,但也因此暴露了在VMD工具开发中传统测试的不足:
a)在时间有限,人员有限的情况下,虽然编写了一定的测试案例,但不能充分执行
b)在每天下班前的例会上过缺陷列表,若发现缺陷的测试人员因事早退,旦缺陷描述不够清晰的情况下,开发人员不能定位缺陷,严重影响修正bug的效率
c)由于测试案例不能有效的被使用,导致模块交换测试人员后无法有效的进行回归测试
d)也是因为测试案例没有有效对测试过程进行记录,导致有时修复的bug不能及时得到验证
4基于敏捷测试的VMD3.0版本测试分析
4.1VMD3.0版本的敏捷开发的背景
经过VMD2.0版本的测试探索阶段,VMD3.0基于敏捷测试的测试框架逐渐被完善。
敏捷测试的应用离不开敏捷开发,VMD3.0的开发特点满足了对其执行敏捷测试的要求。
在之前版本的代码资产以及开发技术资产积累下,VMD3.0版本并不需要从头开始重新开发,而是将原来版本中可复用底层资产以项目为单位移植到新的开发流下进行开发,这无疑大大节省了开发的时间,而各个功能点的开发结束时间也因此梯形化的呈现出来,再加上需求的不断跟新,版本的告诉迭代性,为使用敏捷测试奠定了基础。
更详细的来说,如前文所说,敏捷测试并非传统测试一般将开发与测试前后划分清楚,按先开发后测试的步骤有序的进行。
而是在开发过程中开始测试,以测试驱动开发。
因此,所开发的项目须满足两点要求:
1开发模块能够相互隔离,减少耦合2模块之间有一定的开发时间差,这样测试人员便可以在一个模块开发结束后,立即开始测试,以尽可能早的发现bug问馈给开发人员进行修复。
例如数据字典的搜索展示功能被基本上从旧版本“复制"过来,可在短暂开发后立即进行测试,而联机服务模块改动较大,开发周期较长,可置后测试。
4.2依赖VMD开发的敏捷测试设计
针对以上VMD的开发特征,联合敏捷测试的特点,在VMD3.0版本的测试流程进行如下的设计,以在满足制定的测试标准的前提下,提高测试效率:
1.需求分析阶段:
测试人员需参与需求分析与功能设计,以了解用户新需求并对功能点进行梳理,便于编写测试案例,开发人员进
行旧版本工程迁移
数据结构优化设计.VMD3.0版本测试docx功能点梳理.x]sx
测试案例设计阶段:
制定测试案例设计标准,正反案例比、达到一定案例数量等,根据需求分析与设计文档以及制定的标准,开始编写测试案例,大部分测试案例将在此阶段编写。
在写测试案例时,仅要求保证各个功能点被覆盖,不要过于详细(大颗粒度),强调时间的利用率。
1
A
3
5
6T
8
9
10
11
12
13
14
15
16
MWMH
26
MCT-KI01
5I:
T-B001-001
■会jnaij企wm日1
nr
L?
姓击A
剥月
全童inn-E
全里宾入皈3.9咔0於幕
iin-ETO
座白讪新雄峪曲厦科州讹
DI:
b!
IO2-001
1
月
Iin-E303
导入屈功后,2咨9“》«5底丁0〃<:
匚号的D“逅梁不,政#
DiCT-txr?
I
脚月
:
ICT-EXH
导样功后•可破甲栏5亟醐i砌浏
DET-C08、DICT-CC9
2
高明月
岑入芫成后»HMlmegenthoject]理的Log玉成了lo.dieejGun1,戒件,可直
:
ICT・EH6百号入丽
BICT-CDT
1
MF
更新inn-u
:
in-u:
oiHs立住
BICT-UBl-001
|_
Mf]又件中g遍挪页“,者原劫揖字鼻没肓,PI
IICT-UXC£加;若3■札m(置盖
OICT-W-OOi、IIH-
2
sm
WAR功后,可成花E巽翻i,砌嫌
:
ICT・lD03吮青・
3I:
T-CO6、DICT-0C9
2
高明月
iict-wm
争矣成后,g,畋E沁匚月的贝目录=三成了HteXslLl被单QU
Bici-ar
1
m
曜生京
105
帼
lit
IS-P031
也落衬抵丝构危沮・a彖同射困的,
K-rcoi-ooi
1
IS-TO32
Stoll:
K-KCMOl、IS-
M32-(XC
?
Flf*
IS-P0J3
K-PCCG-001.K-PW3・CO2
z_
Kl俺
is-rox
就0岫*,啪蜘。
果心an
□it秫械戋2W)榆抽明-竭类畛
•浇性,挪赢的稚
K-KXH-001
I
IS-M35修波制*.所有&W曰UFT伶波
K-K(S-001
1
K-KO-OOl»K-PO95-OO1
2
Kl俺
时部:
*诫输祐帼同饭«输
测试用例审核:
开发人员参与到案例的审核中来,以保证案例的质量和可行性,确保测试工作的顺利进行,让开发人员迅速地了解测试的重点并给出相应的意见和建议,测试人员在出案例的同时,要注明案例已覆盖了哪些功能点,具体每个功能点对应的案例编号,这样在测试经理对案例进行审核的时候,能够对案例的覆盖率一目了然,对覆盖率不足的地方能够及时给出意见。
执行测试阶段:
初期,开发人员开始进行模块开发的同时,测试人员继续完善测试案例,当第一个独立模块被开发完毕,立即展开此模块的测试,在测试中测试到的bug直接与对应模块的开发人员及时沟通,并协助开发人员重现bug,尽快定位缺陷,开发人员需在完成修复后,第一时间与测试人员“沟通”验证缺陷。
此过程中,测试人员须在原有测试案例的基础上继续补充,完善案例库。
当有新需求出现时,不断迭代需求分析一设计测试案例一执行测试的过程,丰富测试案例库,达到尽可能高的测试案例覆盖率。
除此之外,开发人员在完成开发或bug修复时,应首先自己进行单元测试,帮助测试人员减轻压力。
在一定时间内,测试人员须针对修复若干缺陷后的功能模块进行模块级的回归测试,以保证修改的缺陷未干扰其他功能。
总结测试的过程:
测试执行的一开始是针对部分功能的,以功能点切分,也可按流程划分重点,如着重流程图的图元图解以及代码生成部分的,之后逐步扩展。
接着开始采用迭代的过程完成测试任务,即将测试任务划分为多个周期,一开始可以做些关键的功能性测试,可以对代码中的可复用部分(组件,构件)做完整的测试。
接着的迭代周期可以做边缘化的功能测试和其他测试,最后的几个迭代应该用于回归测试,和关键的性能和稳定性测试。
版本发布阶段:
当前版本稳定后,打包发布,编写使用手册。
使客户对发布的版本情况一目了然。
写明此版本修复了上个版本中存在的的哪些比较大的bug,以及此版本新增加了哪些功能;如有尚存在的问题,注意注明,有待下个版本改善;或者列出需求不太明确的地方,有待客户给出明确答复意见,在下个版本中完成。
反馈与提高:
在产品发布以后,敏捷测试暂时告一段落。
但是测试工程师还需要对在VMD测试过程中收集的数据进行缺陷分析。
将缺陷进行分类整理,采用合理的分析方法找出造成缺陷的真实原因,并对其原因进行分类整理。
5总结与展望
5.1展望及改进建议
敏捷测试在VMD上的应用尚且具有一定局限性和问题,以下是问题总结以及改进建议:
L提高用户体验:
不同的测试方法是为了保证提供产品的质量,从当前VMD用户反馈来说,VMDT具本身客户体验度不够好,因此作为测试人员,测试的同时不仅要注重功能测试本身的内容,也要注意客户体验层面的感受,尽可能在出版本之前提出自己的意见,便于开发人员及时更改调整。
L使用合适的测试管理工具:
测试的良好实施离不开测试管理工具的选择,而测试管理工具的用法也要一句测试方法灵活使用。
当前VMD并没有使用合适的管理工具,导致案例以及缺陷不能够较好的保管和记录,但我认为也不能按测试中心方法使用QC,这样很难做到“敏捷”,因此选择好工具和正确的工具使用方法很重要
L自动化测试:
其实本文一直避开了
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- 基于 VMD 开发 工具 敏捷 测试 实施 研究 doc