基于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是这样描述敏捷测试的：
Agile testing is a software testing practice that follows the principles of agile software development. Agile testing involves all members of a cross-functional agile team, with special expertise contributed by testers, to ensure delivering the business value desired by the customer at frequent intervals, working at a sustainable pace.
它强调敏捷测试是遵守敏捷开发方法原则之下的软件测试实践，由跨功能敏捷团队的所有人员参与（包括测试人员以其专业特长的特殊贡献）以保证持续的、快速的业务价值交付。所以要理解敏捷测试，我们要仔细看一下“敏捷宣言”：
4-个体与交互重于过程和工具
1可用的软件重于完备的文档
』客户协作重于合同谈判
上相应变化重于遵循计划
制
定洌试计划
设计厕试用例
完成准则
2.L2与传统测试对比
如同功能集成测试处对行内业务交易系统测试，传统测试的流程 大致如下：
第一步：准备产品设计文档，确定测试策略，制定测试计划，主 要完
成分析准备工作。
第二步：根据文档分析结果，设计测试用例，保证测试用例的测 试覆盖率以及其他一系列测试指标。
第三步：执行测试。执行测试主要是搭建测试环境，执行测试用 例。执行测试时要进行进度控制、项目协调等工作。
第四步：提交缺陷。这里要进行缺陷审核和验证等工作。
第五步：消除软件缺陷。通常情况下，开发经理需要审核缺陷， 并进行缺陷分配。程序员修改自己负责的缺陷。在程序员修改完成后, 进入到回归测试阶段。如果满足标准，那么正常结束测试。
第六步：撰写测试报告。对测试进行分析总结。
可见，传统测试具有以下特点：各个流程处理的顺序清晰，各节点耦 合度较小，进程拆分明显，测试过程有严格的规范计划，与开发部门 沟通相对较少，且测试工作开始于开发之后等特点。再通过上文对敏 捷测试概念的总结对比可以看出：
“沟通”非常重要
敏捷测试更强调人的作用，强调测试人员与开发人员之间的沟 通。以
启动准则
回归测试
消除软件缺陷
往我们总要等到产品的一个正式版本发布，才可以开始测试，否则过多的介入会打乱开发计划。而现在，敏捷测试告诉我们，在产品开发过程中就要介入测试。此外，在传统的功能测试中，当一个测试人员发现并提交一个bug时,需要在QC中写大量的文字来描述bug 的环境以及bug的重现步骤，并流转到FLPM平台发送邮件，以通知对应开发人员修复bug,整个流程冗长，且如果文字描述不够清楚，开发人员很可能无法确定bug。而在敏捷测试中，测试人员所需要做的，是与开发人员直接沟通，把问题说清楚，让他能够准确的理解你的意思，甚至包括你对于该bug的分析。接下来一切就十分好办了。到这里，其实我们已经能感受到，测试的角色定位已经变了。因为敏捷开发中，要对质量负责的是整个团队，这一目标就要求测试人员不再是一个独立的质量监督部门，而是要融入到整个团队中，成为开发中不可分割的一部分O
2）调整测试用例的粒度
业界通常认为，测试员最重要的技能就是写用例，通过用例来表达测试思想。我想，即使是到了敏捷时代，这个技能仍然是第一位的。只是，如果你的用例写得过于详细和复杂，那么在团队开始响应变化的时候，你就会措手不及了。至于粒度到什么程度才是合适的呢?那就要看个人的能力，是否强大到能随时调整一份复杂和详细的用例的程度。一般不推崇十分详细的用例，因为有些很细节的地方，也没有文档可以参考。敏捷的最直接的特点就是快速，如果设计的用例粒度太细，那是很难开展敏捷测试的。
3）更多的人参与测试
当测试人员已经不再是一个独立的测试部门时，需要进行测试的也就不只是测试人员了。开发人员也要自测，不同的人可以得到不同的结果，这样才能使我们对产品有全面的把握，才能时刻的知道产品下一步应该怎样“响应变化”。并且开发人员的自测使他亲自体验自
事傩制」数据字典■模型校验■缓存W3 豌
?图形的管理和维护
? UML 2.2模型管理
?流程及对象管理
己开发的系统，甚至可能由此得出进一步的改进优化方案，这些将是 日后开发，更迭版本最有价值的信息。
2.2 VMD 开发工具与当前测试情况
2.2.1 VMD 工具架构
可视化开发工具VMD 是建立在IBM 的RSA 平台的基础上开发 的以流程图生成代码为目的的开发工具。主要开发技术为Eclipse 的 插件开发技术、RSA 模型框架、EMF 、SWT Design. JET 等。其主 要功能模块包括
VMD 视图和其视图下的构建发布、模型构件、数据 结构、联机服务等，以
及一些技术组件，如数据字典、模型校验等。
VMD 逻辑架构图:
RSA ?良好的
Java 及其他语言平台支持
? Clearcase 版本控制支持
?提示/校验等辅助功能
EclipseHStBS
2.2.2 VMD 目标及使用
VMD 目标是以模型驱动开发，在使用VMD 开发时，首先通过界面 导航
配置建立相关模型，再通过此模型经过格式化生成相应代码。模 型以建立构件（即类的方法）为核心，可配合数据结构、数据字典等
集成软件
VMD 功能组件
VMD 技术组件
栩牛设计 新用设计
封装成需求所用构件，封装过程实质为一个方法程序的流程图设计，
可通
过拖拽图元配合图元图解等完成此流程图，而最终将此构件被封装为所需
服务以供其他服务调用。一切以界面图形化开始，以生成正确的需求代码
并通过单元测试结束。
VMD使用流程
VMD使用界面
冒VMD曜富y包妙管理器 m膏▽ o H
■号demoVl-model
＞崩构件矛
」&构件
」俺https://www.doczj.com/doc/0e19097234.html,b.test
T^.7iassA(i!^A)
杉aMethod(a方法)
A杼艰§
＞盆外呼踽
基本曼K
构1牛调月信息
构件方法名：。utboundServiceExeojtor.doOutExe
场入仲竺息：
String outService
TxRequestMsgBodyEntity entity
TxRequestMsgBodyCommon common
2.2.3 VMD角色管理
VMD开发技术支持组人员流动性较高，一般维持在14人左右。需求分析阶段几乎全员参与分析讨论制定开发方案，由于VMD是一个java开发工具，所以每一
Q卧m志/任答仁巴翌Q整怡M:.、
位组内容成员必须具备一定的java开发基础。VMD至今已经发布了三个大的版本，VMD2.0版本之前，测试并不够规范性，且在开发完当前版本功能后才开始展开功能测试与性能测试。2.0版本之后，由于有原版本功能点的依赖，开发任务相对减轻，才逐渐讨论具体的测试方案以及测试计划。组内固定测试员占总人数的三分之一左右，也会根据实际情况进行角色调整。
3 VMD测试实践总结
3.1 VMD1.0版本测试情况介绍
为对比使用敏捷测试方法，首先在此对早期版本VMD的测试情况进行简介，本人于2014年10月份进入VMD开发技术支持小组，此口寸VMD组刚刚开发完VMD1.0版本的基本功能，尚未测试。因此我参与了整个VMD1.0版本的测试过程。
VMD1.0版本总共6人负责全职测试工作，同测试中心一样，测试分为功能测试和性能测试两个方面进行。
根据VMD界面特点，功能测试按两种方式进行切分：模块功能和操作流程功能模块：
件捍用
构麴引
厚- 一J7] NameVo.java S3、
J| 1 package com.(
2 3一 /**
?
* @version
* model 201：
* code 2013-
* hello
*/
10
VMD使用流程：
建立数据结构
建立dao层构件
建立主业务逻辑构件
使用三段论进行服务封装，生成配置文件
生成外呼引用
各测试人员先以功能点进行划分分配测试。比如A负责测试数据结构模块，B负责联机服务，每个测试人员将负责每个模块的整个流程测试，测试模块再以周期性轮换保证测试质量
非功能测试重点放在两个方面：1.VMD启动时间以及各模块执行效率2.各模块执行时内存占有率。
各开发环境打开时间对比:
Tomcat启动时间13秒53秒51秒50秒关闭时间<1秒<1秒<1秒勺秒
连续个构件模型校验内存走势图
3.2 VMD1.0版本测试总结
VMD1.0版本测试由于时间有限以及人员限制并没有严格按照传统的测试流程执行，但也因此暴露了在VMD工具开发中传统测试的不足：
a）在时间有限，人员有限的情况下，虽然编写了一定的测试案例, 但不能充分执行
b）在每天下班前的例会上过缺陷列表，若发现缺陷的测试人员因事早退，旦缺陷描述不够清晰的情况下，开发人员不能定位缺陷，严重影响修正
bug的效率
c）由于测试案例不能有效的被使用，导致模块交换测试人员后无法有效的进行回归测试
d）也是因为测试案例没有有效对测试过程进行记录，导致有时修复的bug 不能及时得到验证
4基于敏捷测试的VMD3.0版本测试分析
4.1 VMD3.0版本的敏捷开发的背景
经过VMD2.0版本的测试探索阶段，VMD3.0基于敏捷测试的测试框架逐渐被完善。敏捷测试的应用离不开敏捷开发，VMD3.0的开发特点满足了对其执行敏捷测试的要求。在之前版本的代码资产以及开发技术资产积累下，VMD3.0版本并不需要从头开始重新开发，而是将原来版本中可复用底层资产以项目为单位移植到新的开发流下进行开发，这无疑大大节省了开发的时间，而各个功能点的开发结束时间也因此梯形化的呈现出来，再加上需求的不断跟新，版本的告诉迭代性，为使用敏捷测试奠定了基础。
更详细的来说，如前文所说，敏捷测试并非传统测试一般将开发与测试前后划分清楚，按先开发后测试的步骤有序的进行。而是在开发过程中开始测试，以测试驱动开发。因此，所开发的项目须满足两点要求：1开发模块能够相互隔离，减少耦合2模块之间有一定的开发时间差，这样测试人员便可以在一个模块开发结束后，立即开始测试，以尽可能早的发现bug问馈给开发人员进行修复。例如数据字典的搜索展示功能被基本上从旧版本“复制"过来，可在短暂开发后立即进行测试，而联机服务模块改动较大，开发周期较长，可置后测试。
4.2依赖VMD开发的敏捷测试设计
针对以上VMD的开发特征，联合敏捷测试的特点，在VMD3.0 版本的测试流程进行如下的设计，以在满足制定的测试标准的前提下，提高测试效率：
1.需求分析阶段：测试人员需参与需求分析与功能设计，以了解用户新需求并对
功能点进行梳理，便于编写测试案例，开发人员进
行旧版本工程迁移
数据结构优化设计.VM D3.0版本测试docx 功能点梳理.x］sx
测试案例设计阶段：制定测试案例设计标准，正反案例比、达到一定案例数量等，根据需求分析与设计文档以及制定的标准，开始编写测试案例，大部分测试案例将在此阶段编写。在写测试案例时，仅要求保证各个功能点被覆盖，不要过于详细（大颗粒度）, 强调时间的利用率。
1
A
3
5
6 T 8 9 1 0 1 1 1 2 1 3
1 4
MW MH26
MCT-KI015I：T-B001-001
■会jnaij企wm
日1
n L?姓击A
剥月
全童inn-E
全里宾入皈3.9咔0於幕
iin-ETO座白讪新雄峪曲厦科州讹DI：b!IO2-0011月
Iin-E303
导入屈功后，2咨9“》?5底丁0〃
＜：匚号的D“逅梁不，政#DiCT-txr?I脚月
：ICT-EXH
导样功后?可破甲栏5亟醐i砌浏DET-C08、DICT-
CC92高明月
岑入芫成后?HMlmegenthoject］理的Log 玉成了
lo.dieejGun 1，戒件，可直
：ICT?EH6 百号入丽BICT-CDT1
MF
更新inn-u
：in-u：oi Hs立住BICT-UBl-001|_
Mf］又件中g遍挪页“，者原劫揖字鼻
没肓，PI
OICT-W-OOi、
IIH-2sm
WAR功后，可成花E巽翻i,砌嫌
：ICT?lD03 吮青?
3I：T-CO6、
DICT-0C92高明月
IICT-WM
争矣成后，g,畋E沁匚月的贝目录=
三成了HteXslLl被单QU
Bici-ar1
m 曜生京
105帼lit
IS-P031也落衬抵丝构危沮?a彖同射困的，K-rcoi-ooi1
IS-TO32Stoll：
K-KCMOl、IS-
M32-(XC?Flf*
IS-P0J3
K-PCCG-001. K-
PW3?CO2
z_Kl俺
is-rox
就0岫*，啪蜘。果心an
□it秫械戋2W）榆抽明-竭类畛
,?浇性，挪赢的稚
K-KXH-001I
IS-M35 修波制*.所有&W曰UFT伶波K-K(S-0011
K-KO-OOl? K-
PO95-OO12Kl俺
时部：*诫输祐帼同饭?输
测试用例审核：开发人员参与到案例的审核中来，以保证案例的质量和可行性，确保测试工作的顺利进行，让开发人员迅速地了解测试的重点并给出相应的意见和建议，测试人员在出案例的同时，要注明案例已覆盖了哪些功能点，具体每个功能点对应的案例编号，这样在测试经理对案例进行审核的时候，能够对案例的覆盖率一目了然，对覆盖率不足的地方能够及时给出意见。
执行测试阶段：初期，开发人员开始进行模块开发的同时，测试人员继续完善
测试案例，当第一个独立模块被开发完毕，立即展开此模块的测试，在测试中测试
到的bug直接与对应模块的开发人员及时沟通，并协助开发人员重现bug,尽快定位缺陷，开发人员需在完成修复后，第一时间与测试人员“沟通”验证缺陷。此
过程中，测试人员须在原有测试案例的基础上继续补充，完善案例库。当有新需求出现时，不断迭代需求分析一设计测试案例一执行测试的过程，丰富测试案例库，达到尽可能高的测试案例覆盖率。除此之外，开发人员在完成开发或bug修复时，应首先自己进行单元测试，帮助测试人员减轻压力。在一定时间内，测试人员须针对修复若干缺陷后的功能模块进行模块级的回归测试，以保证修改的缺陷未干扰其他功能。总结测试的过程：测试执行的一开始是针对部分功能的，以功能点切分，也可按流程划分重点，如着重流程图的图元图解以及代码生成部分的，之后逐步扩展。接着开始采用迭代的过程完成测试任务，即将测试任务划分为多个周期，一开始可以做些关键的功能性测试，可以对代码中的可复用部分（组件，构件）做完整的测试。接着的迭代周期可以做边缘化的功能测试和其他测试，最后的几个迭代应该用于回归测试，和关键的性能和稳定性测试。
版本发布阶段：当前版本稳定后，打包发布，编写使用手册。使客户对发布的版本情况一目了然。写明此版本修复了上个版本中存在的的哪些比较大的bug,以及此版本新增加了哪些功能；如有尚存在的问题，注意注明，有待下个版本改善；或者列出需求不太明确的地方，有待客户给出明确答复意见，在下个版本中完成。
反馈与提高：在产品发布以后，敏捷测试暂时告一段落。但是测试工程师还需要对在VMD测试过程中收集的数据进行缺陷分析。将缺陷进行分类整理，采
用合理的分析方法找出造成缺陷的真实原因，并对其原因进行分类整理。
5总结与展望
5.1展望及改进建议
敏捷测试在VMD上的应用尚且具有一定局限性和问题，以下是问题总结以及改进建议：
L提高用户体验：不同的测试方法是为了保证提供产品的质量，从当前VMD用户反馈来说，VMDT具本身客户体验度不够好，因此作为测试人员，测试的同时不仅要注重功能测试本身的内容，也要注意客户体验层面的感受，尽可能在出版本之前提出自己的意见，便于开发人员及时更改调整。
L使用合适的测试管理工具：测试的良好实施离不开测试管理工具的选择，而测试管理工具的用法也要一句测试方法灵活使用。当前VMD并没有使用合适的管理工具，导致案例以及缺陷不能够较好的保管和记录，但我认为也不能按测试中心方法使用QC,这样很难做到“敏捷”，因此选择好工具和正确的工具使用方法很重要
L自动化测试：其实本文一直避开了往往敏捷测试的一个核心内容：自动化测试，因为项目组目前人员有限，开发进度紧迫，因此一会无法应用自动化测试。在很多其他人的敏捷测试经历中，没有自动化，就没有持续集成，也就没有敏捷。在敏捷测试中自动化测试就更加迫切，这一点比较容易理解，每个迭代都在增加新的功能，而迭代周期的时间相对固定，随着时间的推移，已实现的功能越来越多，这就要求越来越多的回归测试在时间相对固定的周期内完成。如果没有自动化测试，这是难以实施的任务，因此当前VMD的回归测试，并不足够完全。建议利用版本刚刚发布，开发人员手头任务相对轻松的时候，讨论设计自动化测试的跟进
I建立测试案例库：也是因为时间限制，当前VMD并没有使用合适的软件工具建立自己的测试用例库，因此在未来版本开发时很难做到测试用例资产的复用。建议选择合适的工具建立自
己的测试案例库。
5.2总结
从VMD中应用敏捷测试可以看出，针对当前VMD的种种特点: 高速开发、高速迭代，人员有限等，敏捷测试是一个不二的选择。另外，可以总结的是，敏捷测试是一个持续测试、持续反馈的过程，测试人员往往扮演一个“用户代表”的角色，确保产品满足客户的需求。而且，敏捷测试人员和开发人员的区别越来越小，紧密的沟通可以在保证测试标准的情况下，提高测试效率。总而言之，要在测试设计中体现“敏捷宣言”的特点。
综上所述，在敏捷测试可以再VMD项目中继续完善使用。