JRT 0364-2026《金融业应用软件验收测试质量控制框架》_第1页
JRT 0364-2026《金融业应用软件验收测试质量控制框架》_第2页
JRT 0364-2026《金融业应用软件验收测试质量控制框架》_第3页
JRT 0364-2026《金融业应用软件验收测试质量控制框架》_第4页
JRT 0364-2026《金融业应用软件验收测试质量控制框架》_第5页
已阅读5页,还剩10页未读, 继续免费阅读

下载本文档

版权说明:本文档由用户提供并上传,收益归属内容提供方,若内容存在侵权,请进行举报或认领

文档简介

1本文件规定了金融业应用软件验收测试过程的质量控制框架、质量控制过程、质量度量指标、持续改进的要求。本文件适用于金融机构、软件(含算法)提供商、第三方评估机构等开展应用软件验收测试。本文件没有规范性引用文件。下列术语和定义适用于本文件。在质量方面指导和控制组织的协调活动。注:1.一般由用户或用户代表实施测试,也可以委托第三方开展测试。2.采取黑盒测试方式。3.在用户真实使用环境或接近用户真实使用环境的测试环境中开展测试。4.也常称为用户验收测试(useracceptancetesting)。给实体赋予一个数值或类别,以描述其某个属性的过程。注:具体指管控应用软件验收测试进展和产品质量,当应用软件验收测试进展明显偏离计划或产品质量明显偏离预期时,采取梳理过往缺陷问题、剖析成因、落实预防手段等措施,推动应用软件验收测试持续改进。持续改进continualimprovement用以改进组织工作流程成熟度及成果表现水平的一系列循环性活动。基于测试成熟度模型与金融业测试过程改进的最佳实践,并结合金融业已有测试过程体系确立质a)建立质量标准,对金融软件交付全生命周期开展b)推动过程改进,为用户提供符合质量要求的稳定可靠的软件产品,实现市场竞争力和用户满意度的提升。质量控制遵循原则如下。a)风险防控原则:将风险防控理念贯穿到金融软件验收测试各项质量管理活动,围绕风险防控开展验收测试相关工作。b)全生命周期原则:具备覆盖需求编写、需求分析、研发设计、编码、测试、版本投产等软件交付全生命周期的质量管理视角,对验收测试环节进行管控。c)全员参与原则:树立全员质量控制意识,明确各岗位质量管理要求,将质量管理理念融入员工具体工作行为。e)过程结果并重原则:以工作结果为导向,强化金融软件测试全流程质量控制。通过过程控制,确保工作结果符合预期。f)基于事实原则:以客观事实为质量管理工作的依据,用客观事实、客观数据分析评判测试工作。g)持续改进原则:建立穿透式问题溯源机制,以问题为导向,以“溯源一整改一优化”衔接质量改进各环节,持续推动工作质量、效率提升。h)数据安全原则:测试过程中需对敏感数据实施脱敏、加密、访问控制,符合金融行业安全要求。以测试成熟度模型集成为基础,结合软件测试实践,基于软件交付全生命周期视角,构建在验收测试环节验证测试过程质量的质量控制框架。根据质量控制框架相关方要求制定符合实际情况的质量方针和目标,建立以过程为基础的质量控制框架,该框架确定内容如下。a)质量控制所需的过程及相互作用。b)过程目标及相关的绩效指标。c)过程运行的准则和测量方法。e)过程中的风险及应对措施。领域要素流程流程机制制度人员人员工工具数据图质量控制框架33层质量控制领域的管控目标和主要任务如下。a)治理层开展宏观管控,提出质量控制总体目标、方针、战略,提供资源支持和方向性意见。b)管理层贯彻执行治理决策,统筹协调和监督质量控制活动实施,并向治理层反馈执行问题及优化建议。c)操作层具体执行质量检测评估,采集分析数据并构建质量度量指标体系,研发质量检测模型并a)治理层要素包含制度规范、运行机制、标准流程、管理人员。c)操作层要素包含数据体系、效能模型、技术工具、执行人员。5.1治理层质量控制5.1.1制度方面制度方面遵循要求如下。a)应建立覆盖软件交付全生命周期的质量管理体系相关制度。b)宜建设测试质量评估标准,定期修订关键输出的质量检查标准及相关制度。c)宜建立质量风险识别、评估与控制的管理制度。机制方面遵循要求如下。a)应建立问题改进机制。b)应建立测试工作持续改进机制。d)应建立跨团队的质量保证与评价机制。e)宜建立质量控制管理前移机制。f)宜建立过程管控精细化机制。b)应明确定义关键活动的步骤、输入、输出、角色职责、质量要求。流程的关键活动应至少包括:测试需求分析、测试方案制定、测试用例设计、测试用例评审、测试执行、缺陷管理(含提交、跟踪、验证、关闭)、测试报告编制。验收测试关键活动涉及材料见附录A。治理层应配备专业管理人员,相关人员承担风险管理权责并主导制定质量管理制度、明确质量控制运行机制和标准流程、建立质量评价机制。5.2.1方法方面执行方法宜包括以下内容。4a)执行验收标准与过程监控:组织机构落实应用软件验收测试质量评估标准,开展过程数据跟踪、问题分析及改进。b)执行质量自查与整改:组织质量自查工作,明确质量自查分工并按周期分期落实,做到随查随c)开展重点项目评审:建立规范的评审工作机制,对重点项目、高风险项目明确评审要求,并做好评审记录。d)开展质量培训与宣传贯彻:定期开展质量培训与宣传贯彻活动,系统回顾质量控制建设目标和实施成效。e)组建专家智库推进专项评审:组建测试专家智库,制定专家评审工作规程,明确专家智库评审管理层宜面向操作层推广适用范围广和具备基础问题解决能力的测试工具,如有效释放人力投入的通用性工具、保证数据监控时效和频次的时效性工具、采集统计相关数据的自动化工具。5.3.1模型方面质量控制模型宜采用设计方式如下。a)针对不同应用场景构建质量评估、监测分析、风险预警等数据模型,辅助管理层开展效能评价和风险预警,优化资源配置。b)基于大量历史项目的数据积累,构建数据模型(线性、正态分布等)对未来缺陷数据开展预测,指导项目资源的动态调整。5.3.2数据方面b)宜设置操作层维度的效能评价指标,包括工作项、工作时长、过程贡献、结果质量等,分析优势及薄弱环节,促进操作层工作效能持续提升。c)宜结合机构应用软件验收测试职责分工,为人力投入和工作效果的量化结果确定适合的计量方案,辅助管理层优化资源配置。操作层宜结合本机构软件交付一体化工具链、测试工作管理平台、测试相关技术工具的建设进度,分批次分步骤开展用于质量控制过程监控、应用软件验收测试测量、质量控制模型等线上化、自动化、可视化、智能化的工具建设,整体提升数据监测和数据分析效能。注:软件交付一体化工具链指机构内构建的用于促进软件开发团队、软件运营团队、质量保障团队间沟通、协作与工作整合的一系列工具。5.3.4人员方面操作层应确定并配备实施操作人员,相关人员负责实施以过程为导向的验收测试质量管理体系相5示例:操作层人员在验收测试过程中发现机构质量管理体系中可能存在的风险后,按照标准操作流程确认问题缺陷,使用机构熟悉的语言和方式进行清晰表述。6.1指标设计指标设计应遵循治理层宏观管控、管理层协调和监督实施质量控制活动、操作层具体执行质量检测评估的主要原则,构建覆盖战略规划、过程管控、实操落地的立体化指标体系。a)指标应覆盖软件交付全生命周期。指标可根据指标衡量目标分为效率、质量、进度、成本4种类型,各类型的验收测试质量度量指标示例见附录B。治理层指标聚焦战略符合性与风险防控;管理层指标侧重过程质量与资源效能,突出体系管控能力,如测试过程成熟度评级、版本差错率等;操作层指标强调执行精度与交付质量,采用量化数据评价,如测试用例实际通过率、缺陷逃逸率、自动化测试脚本通过率等。一致,如果同一内涵有不同名称,应注明备注名;如果同一名称b)计算公式:优先采用上级部门已确定的计算公式,如果是机构内部指标,计算公式宜征求管理层人员意见并达成一致。指标统计和使用应遵循要求如下。a)重要过程监控指标设置基准值:当实际测量值超出基准值一定范围触发数据预警,如测试覆盖率、测试通过率等。b)多种形式展现指标结果:展现形式包括平台报表统计、监控指标、周报、应用软件验收测试总结会、专项会议等。c)针对不同干系人进行指标结果区分:考虑各干系人岗位职责分工及工作侧重点,广泛征求干系d)充分考虑监控时间要求:通过平台建设逐步提升自动化统计比例,保证数据的时效性与准确性。a)指标应由负责机构度量职能的部门管理,具体指标测量值由指标的测量部门提供。c)指标应围绕“全员质量控制、全流程质量控制”d)应根据治理层对指标的要求以及持续改进需要,由管理层组织操作层完善指标库。e)机构应按照“谁产生,谁负责;谁使用,谁监督”的管理要求,不定期开展数据质量检查工作,确保测量指标的数据信息完整。6a)根据内外部条件变化及阶段性发展需求,建立持续改进机制。b)建立培训和激励方案,鼓励机构全员参与持续改进活动。d)将持续改进的变化纳入机构标准操作流程前,开展试运行以对相关变化开展评估、测量、验证。e)开展改进效果验证,改进措施落地后,通过度量指标、综合评估等方法,对改进成效进行验证。持续改进测试过程包括持续对机构的标准测试过程和项目定义过程进行识别、评估、改进,包括活a)依据治理层规定的责任要求,建立持续改进流程。d)为机构选择并提供最佳实践。e)适应变化,持续评估测试相关新兴工具和技术与本机构的适配性。f)支持技术和知识转化。g)部署高质量、可重复使用的测试资产。h)对疑难问题建立闭环跟踪机制,持续监督整改。7(资料性)验收测试关键活动涉及材料验收测试关键活动涉及材料包括但不限于以下内容。a)需求文档:对金融软件工作产品的功能需求、性能需求、安全需求、其他非功能需求等详细描b)设计文档:对金融软件工作产品的架构设计、模块设计、数据库设计等详细说明。c)测试计划:根据项目范围、任务量大小、时间排期等信息编制的具备可实施性的基本测试方案。d)测试环境:完整描述验收测试所需的软硬件配置,包括服务器配置、网络拓扑、中间件版本、数据库版本等环境要素,具有稳定性、隔离性、一致性,支持监控、模拟、兼容控制。e)测试用例:根据需求文档和设计文档编写的测试案例。f)测试数据:为满足执行一个或多个测试用例的输入需求而创建或选择的数据,该数据可在测试计划、测试用例、测试规程中定义。g)缺陷记录:测试人员发现缺陷后的记录,用于帮助开发人员修复缺陷和辅助测试人员重新开展验证。h)用户文档:用户手册、操作指南等,用于提高测试软件的易用性和用户体验。i)验收报告:测试人员完成验收测试后出具对项目整体质量的评估报告,内容包含项目的测试结果、缺陷统计、缺陷分析说明、风险预警、投产确认等信息。8验收测试质量度量指标示例见下表。时,衡量问题解决效率。间)/问题总数,单位:天。从缺陷提交到修复验证通过的平均周期,聚焦开发团队修复效率。间)/缺陷总数,单位:天。测试提交的缺陷中被确认为有效缺陷的(确认有效缺陷数/总提交测试问自动化测试脚本通过率表示自动化测试脚本通过的比例。(自动化测试通过的脚本数/自动百功能点”或“每百人”发生的生产问[生产问题数/(生产问题数+缺陷例。(已解决问题数/评审发现问题总每千行代码的测试补丁数量。(测试缺陷总数/代码规模)×已关闭的已知风险项占全部识别风险项(已关闭风险数/总识别风险数)测试阶段补丁占所有补丁的比例已执行的测试用例数占计划用例总数的百分比。(已执行用例数/总计划用例数)部需求的比例。用于验证测试范围完整(计划覆盖条目数/总需求条

温馨提示

  • 1. 本站所有资源如无特殊说明,都需要本地电脑安装OFFICE2007和PDF阅读器。图纸软件为CAD,CAXA,PROE,UG,SolidWorks等.压缩文件请下载最新的WinRAR软件解压。
  • 2. 本站的文档不包含任何第三方提供的附件图纸等,如果需要附件,请联系上传者。文件的所有权益归上传用户所有。
  • 3. 本站RAR压缩包中若带图纸,网页内容里面会有图纸预览,若没有图纸预览就没有图纸。
  • 4. 未经权益所有人同意不得将文件中的内容挪作商业或盈利用途。
  • 5. 人人文库网仅提供信息存储空间,仅对用户上传内容的表现方式做保护处理,对用户上传分享的文档内容本身不做任何修改或编辑,并不能对任何下载内容负责。
  • 6. 下载文件中如有侵权或不适当内容,请与我们联系,我们立即纠正。
  • 7. 本站不保证下载资源的准确性、安全性和完整性, 同时也不承担用户因使用这些下载资源对自己和他人造成任何形式的伤害或损失。

评论

0/150

提交评论