用户登录  |  用户注册
首 页毕业论文毕业设计下载定做交易过程截图支付宝在线支付
当前位置:完美毕业网毕业设计下载计算机毕业设计网络工程

基于交易线/触发线的功能测试案例设计充分性研究 ——以贷记卡项目为例

联系方式:点击这里给我发消息QQ8191040
官方主页:www.biye114.com
图片预览: ;论坛转帖
插件情况:
售后服务:请联系客服QQ:8191040
一键分享拿折扣:
  • 好的评价 如果您觉得此软件好,就请您
      0%(0)
  • 差的评价 如果您觉得此软件差,就请您
      0%(0)

软件简介

 随着“互联网+”时代的到来,国内各大银行纷纷谋求转型。目的是为了适应用户快速变化的需求,为客户提供多元化、个性化的金融产品。建行原有应用架构由后台应用提供分散的,孤立的交易服务,在后台应用中存在着大量的重复功能。为了实现企业级IT架构,从IT切入带动建行全面转型,建行“新一代”目标应用架构提供了集成的综合服务,后台应用组件设计良好,无功能重复。
在建行“新一代”7层12平台的企业级IT架构中,交易线是描述联机业务在请求和应答过程中对各种资源的使用及使用规则,是经过的应用平台和有向路段、交易接口、调用顺序、使用要求等的集合。触发线是在同一交易线下,根据一系列不同的输入,包括不同界面事件触发、不同外部渠道呼入事件触发的或内部系统事件(系统定时或条件触发)引起的不同的业务分支。
在应用组装第一轮次基于技术视角的测试过程中,通过对交易线/触发线的测试分析,可以让测试方充分掌握业务功能的技术实现过程,有利于测试部门和项目组一同保障测试过程质量;通过交易线/触发线的测试案例覆盖,可以保证业务功能实现的全路径、全节点、全规则测试覆盖,以便于在有限的测试资源约束下保证测试充分。
基于交易线/触发线的测试分析设计方法,将业务知识、技术实现、测试理论有效结合,适用于建行“新一代”各项目逻辑复杂,路径较长测试场景。研究基于交易线/触发线的测试案例充分性,可以在积累实践经验的基础上,探索与建行“新一代”企业级IT架构配套的测试工艺。


关键词:交易线,测试分析,测试充分性

目 录
1 绪论 2
1.1 研究背景 2
1.2 研究意义 3
1.3 研究内容 4
1.4 论文结构 4
2 功能测试与测试案例设计理论 6
2.1 我行功能测试介绍 6
2.2 功能测试覆盖的业界评价方法 7
3 基于交易线的功能测试案例充分性研究 8
3.1 评价方法概述及评价流程 8
3.1.1 评价方法概述 8
3.1.2 评价流程 9
3.2 总体类评价指标及逻辑 9
3.2.1 总体类评价指标 9
3.2.2 总体类评价逻辑 10
3.3 界面类评价指标及逻辑 11
3.3.1 界面类评价指标 11
3.3.2 界面类评价逻辑 12
3.4 业务类评价指标及逻辑 13
3.4.1 业务类评价指标 13
3.4.2 业务类评价逻辑 14
3.5 技术类评价指标及逻辑 15
3.5.1 技术类评价指标 15
3.5.2 技术类评价逻辑 16
3.6 充分性整体报告 17
4 贷记卡项目实践 18
4.1 执行信用卡还款业务功能介绍 18
4.1.1 三级活动——执行信用卡还款 18
4.1.2 按卡号还款系统用例 19
4.2 贷记卡项目评价报告实例 19
4.2.1 总体类评价报告 20
4.2.2 界面类评价报告 20
4.2.3 业务类评价报告 21
4.2.4 技术类评价报告 21
5 总结与展望 22
5.1 总结 22
5.2 展望及改进建议 23

1绪论
1.1研究背景
软件测试如何达到一定的覆盖度是个非常重要的问题,它是我们测试分析和测试设计工作的基础和出发点。在白盒测试中,我们可以用逻辑覆盖(语句覆盖、分支覆盖、条件覆盖、路径覆盖)等来指导我们的测试分析和设计,并用来评价我们测试工作的充分性。但在黑盒测试中,我们所追求的是需求要达到一定的覆盖度,那么如何衡量需求被覆盖的程度呢?对于测试案例编写人员,怎么知道自己编写的案例可以提交评审了呢?
这是我们对于黑盒测试最想问也是最想解决的问题。对于我行新一代系统这样庞大、复杂、精密的系统,我们不禁也想问这样的问题:功能测试,充分了吗?在新一代系统的功能测试过程中,存在一些亟待解决的问题。这些问题都是研究此课题的背景,在此逐条叙述。
1、没有统一标准要求案例充分性。新一代的项目在编写测试案例时,往往是由业务人员、技术人员、测试人员等三方人员组成测试案例编写小组,按功能点编写测试案例。在编写过程中,并没有明确要求测试案例充分性,均以业务人员的人为主观判断为主。测试案例的充分性,就寄托于案例编写人员的能力水平或者责任心程度上,属于一种不可控的状态。
2、案例评审会缺乏评审材料。在进行新一代项目的测试案例评审时,一般由业务、技术和测试三方人员参加。针对测试案例的充分性、规范性进行评审。但是在评审的过程中,由于缺乏统一的标准和评审材料,会出现评审不充分、流于形式的问题。项目组没有精力关注所有系统用例的测试案例。以贷记卡项目为例,案例总量接近8万条,需要在10个工作日内评审完成。在人力和时间等资源约束下,只能关注重点功能的案例充分性。
3、海量案例无法掌握编写情况。案例编写人员提交案例至案例库,对于万级海量测试案例库,除了案例编写人员自己,项目组很难掌握实际的编写情况。
4、测试过程无法量化。目前关于测试案例是否充分,没法给出量化评价,只能给出主观上的感觉。但是仅凭感觉并不可靠。同时对于不同测试案例编写人员的付出,没法给出量化考核评价。在新一代3.1期贷记卡项目的案例编写过程中,上海卡中心业务部门就举办了一个测试案例编写竞赛,仅从测试案例的数量上评价测试案例编写人员。对于是否覆盖了所有业务规则、是否覆盖了所有基础产品或者可售产品、是否覆盖了所有用户权限……这些问题无法解答。
5、测试案例充分性风险无法统计等。在评审会上记录的一些充分性风险,没有统一的记录和跟踪方式。
1.2研究意义
针对以上研究背景亟需解决的这些问题,如果能提供一种量化评价功能测试案例,也就是黑盒测试的评价方法,可以达到以下效果。
1、测试案例编写人员自检。发布统一的测试案例充分性评估标准,可以方便测试案例编写人员自检。可以对自己编写的案例进行查缺补漏,也可以清楚地知道是否已经达到可以提交评审的程度。
2、测试案例评审会标准化材料。经过量化评审的测试案例,会得出评审报告。将这些材料作为评审会标准化材料,可以方便评估评审时间,控制评审结果,提高评审质量。
3、项目组掌握测试情况。项目组可以根据评价报告及时掌握测试案例的覆盖情况,针对覆盖薄弱环节进行补充和跟踪。
4、测试过程量化考核。不单纯地从测试案例数量评价编写人员的绩效,提供了一种可以评价测试案例质量的可落地有效方法。
5、测试过程改进。
整个评价过程是对测试质量过程管控,最终实现测试质量提高。
1.3研究内容
本文结合“新一代”3.1期贷记卡项目,聚焦到执行信用卡还款这一业务功能,阐述如何通过系统用例的交易线/触发线分析,结合测试案例设计方法,设计测试案例。并针交易路径上各节点业务规则的有效组合,保障测试案例的充分性。
测试充分性评价阶段包括以下三方面内容:
1、充分性评价流程。
给出评价的具体流程,包括评价系统的输入、输出。给出评价流程图。
2、分类评价指标与评价逻辑。
梳理应用的交易线、触发线、触发线中交易节点和规则对应关系以及系统用例的输入要素,是保证测试分析设计落地开展的前提依据。包括总体类、界面类、业务类和技术类。从测试覆盖标准入手,通过检查表技术检查测试案例的充分性。
3、给出实践案例。
以新一代3.1期贷记卡项目组,以“按卡号执行信用卡还款系统用例”为例,给出充分性评价结果。
1.4论文结构
本论文共分为五章。
第一章,绪论(即本章)。介绍论文的研究背景、研究意义、研究内容以及论文的组织结构。
第二章,功能测试与测试案例设计理论。介绍我行北开功能测试与测试案例分析设计编写理论基础。
第三章,介绍了从技术视角检查测试充分性的标准的和评价逻辑。
第四章,将此方法落在贷记卡项目进行实践。给处方法论落地实践方法。
第五章,总结与展望。基于交易线/触发线的测试案例设计充分性量化评价方法,将业务知识、技术实现、测试理论有效结合,从技术视角给出了评价系统用例下的测试案例充分性的评价指标与评价逻辑。适用于建行“新一代”各项目逻辑复杂,交易路径较长的测试场景。
本文研究成果——测试充分性评价报告,可以让项目干系人有效掌握测试覆盖情况,管控测试质量。同时,在积累测试评价实践经验的基础上,探索与建行“新一代”企业级IT架构配套的测试工艺。

2功能测试与测试案例设计理论
2.1我行功能测试介绍
根据我行应用架构的特点,软件测试阶段中属于功能测试类型的有单元测试(Unit Test,简称UT),集成测试中的系统内集成测试(Component Integration Test,简称CIT)、跨系统连接测试(Link Test,简称LT)、跨系统集成测试(System Integration Test),以及用户接受测试(User Acceptance Test,简称UAT)和投产版本功能检验(Verification Test,简称VT)。
1)单元测试是将模块在与系统的其他部分相隔离的情况下进行的测试,侧重于被测代码满足详细设计要求的检验。
2)系统内集成测试是将已分别通过测试的模块,按照概要设计的要求组合起来,在与其他系统相隔离的情况下进行的测试,侧重于系统内对模块间接口功能正确性检验。
3)跨系统连接测试是将已分别通过测试的系统,按照概要设计的要求进行系统间连接的短期测试,侧重于消除跨系统间环境和报文接口的一般性技术缺陷,可以视为下一阶段的绿灯测试,纳入下一测试阶段。
4)跨系统集成测试是将已分别通过测试的系统,按照概要设计的要求组合起来,在与其他系统连通的情况下进行的测试,侧重于对系统间接口功能正确性检验。
5)用户接受测试是相关用户根据测试结果对系统测试和接受,侧重于应用软件对用户需求所规定的正确性检验。根据项目管理办法,用户接受测试由需求提出主管部门组织进行测试。
6)投产版本功能检验是按照类似投产的版本管理要求,将待投产的版本在类似的生产环境中安装,并进行功能回归测试,以检验投产版本质量的过程。也可以将此阶段与用户接受测试阶段的最后一轮合并。
2.2功能测试覆盖的业界评价方法
测试用例的覆盖率最基本的要求是百分之百,即每项功能至少要有一条测试用例。方法就是首先要熟读需求规格说明书(SRS)。功能测试要从最重要,使用频率最高,代码新研发,复杂度高的入手,这些一定不要遗漏。当然也要考虑开发人员的水平,如果文档质量不高,就需要测试评估人员仔细一点。测试覆盖的评价是一个熟能生巧的过程。要经常编写测试列表,然后根据测试范围列表编写测试用例要多方面考虑,功能正常实现的情况和非正常的情况。
测试报告中测试充分性分析,主要体现在一个静态分析,体现的数据指标是 测试活动持续时间,执行用例数,发现缺陷总数,平均每小时用例数,平均每小时发现的缺陷数和千行代码用例数等用来对整个测试覆盖的一个总结。
如果需求定义已经写好,衡量需求覆盖和测试覆盖最直接的方法就是看有多少个需求功能测试点和需求性能测试点。目前业界有专门的测试充分性算法或者是基于充分性测试的准则,可以通过度量来权衡。相对于白盒测试阶段中基本语句覆盖、路径覆盖、条件覆盖、及其组合覆盖,可以通过设计测试数据集合或离散上的谓词原理来分析。
需求覆盖率:(需求覆盖率=测试用例涵盖的需求数/项目所有需求数*100%)。
方式一:如果需求已经定义好,衡量需求覆盖率的最直观的方式是我们有多少功能点,我们有多少性能点要求,这些将作为分母;我们写了多少测试用例,覆盖了多少模块,多少功能点,我们的性能测试用例考虑了待测程序多少性能点,这些作为分子。如:我们系统一共有10个功能和性能点可测试,但我们测试用例只覆盖其中的9个功能点,那么我们的需求覆盖率为90%。方式二:可以通过测试用例评审会议来确定测试用例对需求的覆盖是否完全。测试用例评审通过这个标志,就表示我们的测试在目前能想到的情况下覆盖是100%的。而在实际的测试过程中我们也只能想当然的达到100%,但实际不可能。后续我们在执行过程中可能会发现有测试点的遗漏,会要进行补充,也就是说之前的覆盖是不全的,没有达到100%。如:在某次回归测试报告中我们只对系统中共有的10个需求点中的5个进行回归测试,那么此次执行的需求覆盖率只有50%。
测试覆盖率:还有一种解释为测试用例的执行率(测试用例执行率=当前执行的测试用例总各/该项目所有测试用例总各*100%)。全面的回归测试,测试用例执行率就是100%。我们的真正的测试过程中往往因为时间、人员、精力等原因不能100%的执行所有测试用例;同时小规模的改动,如果大规模的回归测试也很费精力、时间,在这个时候我们就需要有选择性的执行测试用例,如果整个项目有1000条测试用例,本次更新引起的变更需要测试其中的500条测试用例,我们就称此次的测试覆盖率(测试用例执行率)为50%。
3基于交易线的功能测试案例充分性研究
3.1评价方法概述及评价流程
3.1.1评价方法概述
充分性评价主要采用分类评价的方法进行。一共分为四个类别进行充分性统计,最后再进行汇总。
总体类:从技术视角出发对案例充分性进行检查,确保充分性得到最基本保障。
界面类:纯界面要素的测试覆盖检查。提供界面规则库进行比对检查。
业务类:针对需求规则的详细检查,充分性检查的主体。
技术类:针对技术规则的覆盖检查。
在进行充分性评价的过程中,我们有一条前提准则。那就是黑盒测试的覆盖率是不可能达到100%的,只能做到逐步完善。

下载地址

点击此处→注册会员上传设计赚钱
以上是大纲和介绍,如需要完整的资料请在线购买.

软件评论评论内容只代表网友观点,与本站立场无关!

   评论摘要(共 0 条,得分 0 分,平均 0 分) 查看完整评论

下载说明

* 本站所有资料均已审核通过,内容原创保密,标准格式,质量保证
* 无需注册,点击在线购买后即可获取该套毕业设计(论文)完整
* 支付后请联系在线客服QQ:8191040发送资料
  • 官方微信