TA的每日心情 | 擦汗 3 小时前 |
---|
签到天数: 1046 天 连续签到: 4 天 [LV.10]测试总司令
|
一、项目背景及研究目标
项目测试过程中经常会发现,被测系统期望实现的功能往往超出需求书中所列内容,这些功能一般不会在需求中写明,却能一定程度上影响用户体验,我们称之为软件默认功能。课题组于前期启动了“软件默认功能测试案例库研究及构建”创新课题的研究工作,建立理论模型,提出了一套系统的识别软件默认功能的方法;构建了软件默认功能库和案例库,开发配套的自动化工具生成软件默认功能案例,有效减少了需求原因导致的测试遗漏,并大大缩短了案例编写时间,提升工作质量和工作效率。
本推广项目基于此项创新课题的研究成果,通过在不同领域项目(目前以移动支付和信用卡领域为主)的实践,推动该研究成果及配套工具的应用,提升案例编写质量和编写效率,全面覆盖测试需求,减少测试遗漏,支持测试工作的科学开展。
二、项目研究成果及推广应用
1.研究成果一:构建理论模型
图1:理论模型
针对默认功能进行分析研究,提出一整套理论模型以解决问题。模型整体包括:
1)基础模型层:对此类功能的定义和分类;通过分析该类功能,提出一个重要的概念——圈子,并对其进行了定义和性质分析,提出共识有范围、共识有变化和共识需标准化;
2)解决方案层:基于定义和性质,提出了识别该类功能的方法,并建立了软件默认功能库的基本架构;
3)应用服务层:为实现整个解决方案模型,设计了配套的实现模型,包括软件默认功能库、测试案例库和配套的自动化工具。
2.研究成果二:提出一套系统的识别软件默认功能的方法
1)挖掘旧有用例中的软件默认功能
在项目测试过程中,测试人员会不断分析系统功能,思考系统的潜在风险和缺失的必要功
能,实际上已经识别了大部分系统的软件默认功能并形成相应的测试用例。因此现有的测试用例有很大一部分都是针对软件默认功能的,之前并没有很好地利用这些资源,每个项目测试人员又会进行重复分析,浪费大量人力。所以挖掘旧有用例中的软件默认功能是一个简单高效的识别软件默认功能的方法。 2)专家法识别
针对之前没有测试资源的系统圈子,就需要进行重新识别,其识别过程与接到新的测试项目类似。主要分成如下几个步骤:
(1)需求分析,形成交易功能列表和交易性质列表; (2)根据交易性质列表分析每一个交易性质应具有的软件默认功能,形成交易性质决定的软件默认功能;根据交易功能列表分析每一个功能应具有的软件默认功能,形成交易功能扩展类软件默认功能;
(3)进行专家评审,以保证识别出的软件默认功能质量。
3)统计法识别
根据软件默认功能前两个性质:共识有圈子、共识会生长,会发现一个圈子里的多个类似的交易或功能具有相同的软件默认功能,而且通过分析这些交易或功能可以看到共识生长的趋势。例如:
图2:统计法识别案例 根据上边的统计结果,选择相册图片和照明功能应是扫码功能的软件默认功能;查询历史信息和扫银行卡功能目前是业务需求,但有变为软件默认功能的趋势。
3.研究成果三:构建软件默认功能库和案例库
根据对圈子的相关分析和功能的分类,搭建出软件默认功能库的基础架构。由于共识有圈子,则不同圈子的软件默认功能是有差别的,所以每一个圈子都会有一些特殊的软件默认功能。当然也会存在圈子共有的软件默认功能,叫做公用软件默认功能。
因为软件默认功能有两类,即交易性质决定的软件默认功能和交易功能扩展类软件默认功能,我们把每个圈子的软件默认功能都分成这两类,架构如下:
图3:软件默认功能架构图 系统圈子需要根据之后的软件默认功能的相同程度进行调整,比如手机app里有两个系统明显不同,软件默认功能很多不相同,就需要把这个圈子分成两个,变成A手机app系统圈和B手机app系统圈;反之如果出现管理平台类系统的软件默认功能和手机app类系统特殊软件默认功能基本都一样,两个圈子就需要合并成一个圈子。
4.研究成果四:开发配套的自动化案例生成工具
开发配套的自动化案例生成工具,根据已有的软件默认功能生成测试用例,以提高工作效率。整个应用过程如下图:
图4:自动化生成案例应用过程图 1、软件默认功能识别入库(前期录入)
2、测试用例入库(前期录入)
3、利用自动化工具生成被测交易的测试用例(每次项目操作使用)
图5:自动化案例生成工具界面
5.推广应用情况
本推广项目目前已在优惠促销系统升级项目、二维码应用平台、信用卡合作伙伴项目和商户收单风险管理项目中进行推广,推广情况总结如下:
图5:推广应用情况
三、对组织级资产贡献程度
1.该项目的实施会对已有的测试用例进行分析形成用例库,是对已有测试资产的有效利用;
2.测试用例作为一种测试资产,功能库和案例库是不断扩充的过程,通过应用项目的不断增加,案例库将不断完善,应用的过程也是体现资产价值的过程;
3.自动化生成工具能极大地提高案例编写效率;
4.不仅测试人员,项目推广之后,需求编写人员、开发人员都可将其作为编写需求和开发系统的依据;
5.形成了一套测试部门自己的方法论,能够在即便输入条件(需求书、设计说明书等文档)不完善的情况下,也能设计出更完备的测试方案。从而提升组织级的测试能力。
|
|