JR-T 0130-2016 银行业软件异常分类.pdf
- 文档编号:14661048
- 上传时间:2023-06-25
- 格式:PDF
- 页数:20
- 大小:609.87KB
JR-T 0130-2016 银行业软件异常分类.pdf
《JR-T 0130-2016 银行业软件异常分类.pdf》由会员分享,可在线阅读,更多相关《JR-T 0130-2016 银行业软件异常分类.pdf(20页珍藏版)》请在冰点文库上搜索。
ICS35.240.40A11JR中华人民共和国金融行业标准JR/T01302016银行业软件异常分类Classificationforbankssoftwareanomalies2016-07-01发布2016-07-01实施中国人民银行发布JR/T01302016I目次前言.II引言.III1范围.12规范性引用文件.13术语和定义.14模型.24.1缺陷生命周期.24.2异常实体关系模型.24.3异常相关实体分类过程与本标准的关系.45分类.55.1分类过程.55.2缺陷分类属性.55.3失效分类属性.6附录A(资料性附录)属性示例值.7附录B(资料性附录)分类范例.11B.1意图.11B.2问题场景描述.11B.3分类示例.11参考文献.14JR/T01302016II前言本标准按照国家标准GB/T1.12009给出的规则起草。
本标准由中国农业银行股份有限公司提出。
本标准由全国金融标准化技术委员会(SAC/TC180)归口。
本标准起草单位:
中国农业银行股份有限公司,中国人民银行金融信息中心,中国金融电子化公司,中国工商银行股份有限公司。
本标准主要起草人:
刘国建、于进、叶又升、潘贵平、李宽、吴俊峰、伞亮、侯太利、王子田、李越、何涛、吴金超、夏法鹏、吴晓光、张雯华、时向一、仲海港、魏猛。
JR/T01302016III引言“异常”一词可指任何不正常、不规则、不一致或者对预期的偏离。
异常可以指状态或事件,可以指表现或行为,也可以指形式或功能。
本标准为软件异常的分类提供了一种一致的方法,以分类在项目、产品或系统生命周期的任何阶段产生并在后继的任何阶段发现的软件异常。
异常分类数据可以用于多种用途,包括缺陷原因分析、软件过程改进(如减少缺陷嵌入的可能性或者提高缺陷早期检测的可能性)等。
收集本标准中所描述的数据能为提高IT管理水平和增进软件质量提供宝贵信息。
一是在软件生命周期中越早发现问题,修改成本越低,通常也越容易。
这就推动着使用各种工具、技术和方法来更早地发现问题。
标准的异常数据在评估这些工具、技术和方法的效用时可作为重要参考。
二是通过对异常数据的分析,也能发现项目生命周期中产生问题最多的阶段。
明辨软件中的提高和问题,对软件异常的修正优先级判定和投入资源的分配提供了有价值的参考信息。
三是异常数据能辅助对可靠性和生产率等质量指标的评估。
形成对软件异常的标准分类有着重要的工程意义。
首先,它能使本标准的应用者深刻理解产品开发过程中所产生的异常类型,这些异常信息是项目执行以及过程改进的重要数据来源。
诸如正交缺陷分类和因果分析法之类的分析型技术,能够以异常分类来识别缺陷的根本原因以避免缺陷重现。
过程改进框架(如能力成熟度模型CMMI)则增大了详细理解过程性能和产品质量的需要。
异常分类让对各种开发过程中产生的异常成为评判过程优劣的一个指标。
其次,采用标准的方法对软件异常进行分类,能让开发者和组织之间更好地传达、交流关于异常的信息。
遗憾的是,人们常常赋予同一个词不同的意思或者使用不同的词来表达同一个意思。
同样,如果软件系统之间要有效沟通关于异常的信息,就必须使用共同的逻辑数据模型(如果不要求共同物理数据模型的话)。
如果同样的数据元素在一个系统和其他系统中命名不同,通过一些映射和转译方法仍然能实现数据交换,但是每个系统都必须至少识别并实现同样的概念对象/实体、关系和属性。
本标准的目的是定义一套通用的词汇,以使得银行业相关人员、组织能够就软件异常进行有效的沟通;同时建立一套软件缺陷和失效数据的通用属性集,以便采用工业技术进行分析。
JR/T013020161银行业软件异常分类1范围本标准为银行业软件失效和缺陷的分类规定了一组核心属性。
对特定的应用程序或业务需求来说,还会存在有特定价值的其他失效或缺陷的属性。
本标准未涉及生命周期模型的选择,但选择任何生命周期模型均不影响分类属性。
本标准应用者可基于所选择的生命周期对分类属性值进行裁剪。
问题分类、错误分类、变更请求、检测和移除缺陷、研究和解决失效的方法和过程,以及确定缺陷是否应该移除的过程均不在本标准的范围中。
本标准适用于对任何银行业软件(包括操作系统、数据库管理系统、应用程序、测试软件、固件和嵌入式软件)的失效和缺陷进行分类。
2规范性引用文件下列文件对于本文件的应用是必不可少的。
凡是注日期的引用文件,仅所注日期的版本适用于本文件。
凡是不注日期的引用文件,其最新版本(包括所有的修改单)适用于本文件。
GB/T114572006信息技术软件工程术语ISO/IEC/IEEE24765:
2010系统和软件工程词汇(SystemsandsoftwareengineeringVocabulary)3术语和定义GB/T114572006和ISO/IEC/IEEE24765:
2010中确立的以及下列术语和定义适用于本文件。
3.1缺陷defect在一个项目组件中的瑕疵或缺点,导致该组件不能满足其需求或规格,且需要修复或更换。
ISO/IEC/IEEE24765:
2010,3.764注:
在ISO/IEC/IEEE24765:
2010中,除上述定义外,还有两个定义,分别为:
“一个若不更正则可能引起一个应用失败,或者产生不正确结果的问题。
”引自ISO/IEC20926:
2003SoftwareengineeringIFPUG4.1UnadjustedfunctionalsizemeasurementmethodCountingpracticesmanual;“一个涉及到故障(原因)或失效(结果)的通用术语。
”,引自IEEEStd982.12005DictionaryofMeasuresoftheSoftwareAspectsofDependability。
示例1:
在项目生命周期的早期阶段发现的遗漏和瑕疵。
示例2:
在足以进行测试或操作的软件中存在的故障。
3.2错误error产生不正确结果的人的行为,不正确结果如软件包含一个故障。
ISO/IEC/IEEE24765:
2010,3.1027注:
在ISO/IEC/IEEE24765:
2010中,除上述定义外,还有3个定义,分别为:
“不正确的步骤、过程或数据定义。
”JR/T013020162“不正确的结果。
”“在计算的、观察的或测量的值或情况与准确的、规定的或理论上正确的值或情况之间的差异。
”示例:
在软件规格中对用户需求的遗漏和误解;在设计规格中对需求的遗漏或不正确地翻译。
3.3失效failure系统或系统组件未在规定范围内执行所需功能的事件。
ISO/IEC/IEEE24765:
2010,3.1115注:
故障发生时可能会引起失效。
3.4故障fault软件中错误的一种表现。
ISO/IEC/IEEE24765:
2010,3.1122注1:
ISO/IEC/IEEE24765:
2010中,除上述定义外,还有2个定义,分别为:
“在一个计算机程序中,一个不正确的步骤、过程或数据定义”。
“在一个硬件设备或部件中的缺陷”。
注2:
如果遇到一个故障,则可能引起一个失效。
3.5问题problem一人或多人由于系统使用中的不符合要求而经历的困境或不确定性。
注:
在ISO/IEC/IEEE24765:
2010中,还有2个定义,分别为:
“一个或多个事件的未知的根本原因”。
“需克服的不利状况”,这一定义也描述于IEEEStd10442009中。
4模型4.1缺陷生命周期图1所示为缺陷的生命周期。
由于缺陷在检测出之前无法进行分类,故本标准针对已检测出的缺陷分类,并对表明了存在缺陷的失效分类。
图1用UML状态图描述的缺陷生命周期4.2异常实体关系模型发现问题是对失效进行识别的前提,这些问题是用户识别出的软件在不恰当方式下执行的状况。
同样的,对失效和故障所采取的措施可能会被记录为一个变更请求。
尽管软件变更请求(SCR)和软件版本在本标准内未提出,但它们也出现在图2、图3以及表1中,以帮助阐明范围。
这里展示的是相对简单的情况,一个缺陷有可能和一个修正SCR有关联,且各个SCR有可能关联在一起,但至多只能存在于一个软件发布版本中。
表1采用文字方式描述了对异常相关实体间关系的说明。
JR/T013020163表1对异常相关实体间关系的说明类/实体对关系问题失效一个问题可能由一个或多个失效引起。
一个失效可能会引起一个或多个问题。
失效故障一个失效可能由一个故障引起(失效亦表明了故障的存在)。
一个故障可能引起一个或多个失效。
故障缺陷故障是父类缺陷的子类。
任一个故障都是缺陷,但并不是任一个缺陷都是故障。
若缺陷是在软件执行过程中遇到的(由此导致失效),则该缺陷是故障。
若缺陷是通过审查或者静态分析发现的,且在执行软件之前被移除,则该缺陷不是故障。
缺陷变更请求缺陷可以通过执行更正性变更请求移除。
更正变更请求的目的就是移除缺陷。
(变更请求也可以通过执行自适应或完善式维护的方式启动)图2和图3分别用实体-关系图和UML的类图描述了这些实体间的关系,这两种描述方式表述的内容是一致的。
注1:
圆角矩形代表实体(关注物),连接圆角矩形的线代表实体之间的关系。
线末端的符号表明实体的数目。
线末端附近的圆圈表明实体数目允许为零,即参与是可选的;当没有圆圈时表明至少需要一个实体,即参与是必需的。
三条腿的“鸡爪”符号表明允许多个实体参与;当没有鸡爪符号时表明至多有一个实体可以参与。
一个圆角矩形出现在另一个圆角矩形中表明父子类关系,此处被包含的实体可归为包含实体(父类型)的子类型。
注2:
此图的目的不是制定强制的符号标识方法,也不作为数据库的结构描述。
图2异常相关实体的实体-关系模型JR/T013020164注1:
矩形代表对象类(关注物),连接矩形的线代表对象类之间的关系。
每个矩形内的三个部分(从上到下)包含相应类的名称、属性和方法。
该图的主要焦点是类之间的关系,因此图中仅包含类名。
“方法”在本标准的范围以外,属性的列表及定义在下面的章节中。
线旁边的数字表明关系的多重性,“1”的意思是只有一个,“0.1”的意思是零个或一个,“1.*”的意思是一个或多个,“0.*”的意思是零个、一个或更多。
末端为三角形的线表明父类与子类之间的一般化关系(父类-子类)。
末端为菱形的线表明一个版本中可能会包含的多个更改请求。
注2:
此图的目的不是制定强制的符号标识方法,也不作为数据库的结构描述。
图3异常相关实体的UML类图4.3异常相关实体分类过程与本标准的关系表2给出了关于异常相关实体的分类过程哪些在本标准范围内,哪些在本标准范围外。
表2异常相关实体的分类过程与本标准的关系本标准范围内本标准范围外缺陷分类修正措施分类故障分类错误分类失效分类问题分类定义一组广泛适用于分类的核心属性定义所有可能有用的分类属性定义模板属性值以促进理解裁剪模板属性以满足特定组织的需求JR/T013020165表2(续)本标准范围内本标准范围外在项目或产品生命周期中创建正式的分类过程定义一个过程,规定哪个值应该分配给哪个属性定义一个过程,规定何时何地何人如何记录属性值是否移除缺陷的处理过程5分类5.1分类过程组织应定义其分类过程如下:
a)明确通过分类缺陷和失效要实现的目标;b)明确用于判断出现怎样的系统/软件行为就构成失效的准则(如描述于规格、合同或计划中的);c)明确如何解决分类决策的分歧或冲突;d)明确在项目或产品的生命周期内,分类何时开始与结束;e)明确项目、产品或者组织特有的值,这些值适宜被指派为分类属性(属性值示例参见表A.1和表A.2);f)明确由谁针对每个发现的缺陷和失效向表3和表4中所列的分类属性赋值;g)明确在哪里和怎样维护分类数据。
注:
分类过程可根据企业的管理惯例,采用企业标准、规章制度或非企业标准非规章制度的技术规范方式描述。
5.2缺陷分类属性组织应记录表3中所列所有缺陷属性的值。
属性集并不试图一个不漏。
表A.1为所选属性值的示例,这些值仅是资料性的。
在组织处理缺陷时,属性的值很可能同时被一并记录下来,缺陷的状态可以是嵌入、检测或者移除(如图1);然而,相比跟踪缺陷的状态,跟踪相关缺陷报告的状态更为普遍,因此这些值描述的状态通常是在缺陷解决过程中相关的组织工作流程的状态。
由于存在多种组织特定的缺陷工作流程,故未指定强制的状态值。
表3缺陷分类属性属性定义缺陷ID缺陷的唯一标识符。
描述有关缺失了什么、错误或多余东西的描述。
状态缺陷报告生命周期中的当前状态。
资产包含缺陷的软件资产(产品、组件、模块等)。
工件包含缺陷的特定软件工作产品。
版本检测检测出缺陷时的软件版本标识。
版本修正缺陷被修正时的软件版本标识。
优先级缺陷的处理顺序,该顺序由负责缺陷评估、解决和关闭的组织通过与其他已经报告的缺陷相比而给出。
严重性缺陷可能(或曾经)引起的最严重的失效影响,该影响由负责软件工程的组织(从其视角)确定。
概率该缺陷再次引起失效的可能性。
JR/T013020166表3(续)属性定义影响由缺陷引起的失效而影响到的需求类别。
类型一种分类方式,按照发现缺陷的代码或发现缺陷的工作产品进行划分。
模式一种分类方式,按照缺陷由不正确的实现或表示、需求外的多余添加或遗漏而进行划分。
嵌入活动在缺陷被引入或嵌入期间(例:
在包含缺陷的工件产出过程中)的活动。
检测活动在缺陷被检测到期间的活动(即检查或测试)。
检测日期缺陷被检测到的日期。
修正日期缺陷被修正时的日期。
关联失效由缺陷引起失效的标识符。
关联变更为了修正缺陷所提出的修正变更请求对应的标识符。
处置在关闭时缺陷报告的最终处置。
5.3失效分类属性组织应记录表4中所列全部失效属性的值。
所选属性值的示例见表A.2。
表4失效分类属性属性定义失效ID失效的唯一标识符。
状态在失效报告生命周期中的当前状态。
标题为进行总结报告而对失效的简明描述。
描述对异常行为及其出现条件的全面描述,包括事件顺序和或失效前的用户行为。
环境观察到失效的操作环境的标识。
配置包括相关产品和版本标识符的配置细节。
严重性由负责软件工程的组织(从其视角)来决定。
示例参见表B.1。
分析通过失效调查结论的因果分析的最终结果。
处置失效报告的最终处置。
示例参见表B.1。
观察人观察到失效的人员(可以获得额外的细节的人员)。
开启人开启(提交)失效报告的人员。
负责人负责调查失效原因的人员或组织。
关闭人关闭失效报告的人员。
观察日期观察到失效的时间/日期。
开启日期失效报告开启(提交)的时间/日期。
关闭日期失效报告关闭和分派最终处置的时间/日期。
关联测试当失效发生时进行的特定测试(如存在)的标识。
关联事件若失效报告是从服务台或帮助台的请求/沟通中提炼,相关事件的标识。
关联缺陷声称引起失效的缺陷的标识。
JR/T013020167AA附录A(资料性附录)属性示例值本附录给出了缺陷属性值和失效属性值的一些例子,这些例子可能是常见的,本标准的应用者可以以这些例子作为初始值,归纳适应本组织的典型属性值;也可针对不同性质的软件,给出几套不同的典型取值。
表A.1缺陷属性值示例属性值定义状态打开对一个检测到的缺陷的反应,后继的行动是准备好的。
状态关闭无进一步行动计划(无论是否已将缺陷移除)。
优先级高优先级为该等级的缺陷将优先分析解决。
优先级中优先级为该等级的缺陷将在队列中等候分析解决,且一直排在在高优先级之后。
优先级低具有该等级的缺陷在将在等待队列末分析解决。
严重性阻塞直到改正或适宜的应急方案启用,检测被阻止或暂停。
严重性关键性基础操作不可避免地中断,安全受到损害与威胁。
严重性较大基础操作受到影响,但可继续。
严重性较小非基础性操作中断。
严重性不重要未对操作产生实质性影响。
概率高发生的概率大于70%。
概率中发生的概率介于40%到70%之间。
概率低发生的概率小于40%。
影响功能性实际或潜在原因,由于该原因未能正确执行必须功能(或实现非必需的功能),包括任何影响数据完整性的缺陷。
影响可用性实际或潜在原因,由于该原因未能满足可用性(易用性)需求。
影响安全性实际或潜在原因,由于该原因未能满足安全性需求,诸如鉴别、授权、隐私/机密、可计量性(如审计跟踪或事件日志)等。
影响性能实际或潜在原因,由于该原因未能满足性能需求(如容量、计算精度、响应时间、吞吐量或可用性)。
影响服务能力实际或潜在原因,由于该原因未能满足可靠性、可维护性、可支持性要求(如复杂的设计,无文档代码,有歧义或不完整的错误日志等)。
影响其他将不会导致上述结果的影响。
JR/T013020168表A.1(续)属性值定义类型数值在数据定义、初始化、映射、访问或使用中的缺陷,这些缺陷是在模型、规格或实施中发现的。
例如:
未分配初始值或未设置标志的变量。
不正确的数据类型或列的大小。
使用不正确的变量名。
未定义有效范围。
数据模型中不正确的关系基数,如1.n标记为0.n。
选择列表中值缺失或有不正确的值。
类型接口在接口规格或实现中的缺陷(如用户和机器之间,内部两个软件模块之间,软件模块和数据库之间,内部和外部软件组件之间,软件和硬件之间等)。
例如:
不正确的模块接口设计或实现。
不正确的报表布局(设计或实现)。
不正确或不充分的参数传递。
用户界面中隐藏的或陌生的标签或消息。
发送或显示不完整或错误的消息。
数据输入屏上缺少必须的区域。
类型逻辑决策逻辑、分支、排序或算法中的缺陷,这些缺陷在自然语言规格或实现语言中被发现。
例如:
缺少else语句。
不正确的操作顺序。
表达式中不正确的运算符或操作数。
缺少对返回响应进行状态检测的逻辑(如返回代码、文件结尾,空值等)。
输入值不在有效范围内。
序列图中缺少系统响应。
需求分析或设计规格中业务规则的歧义定义。
类型描述软件描述、使用、安装或操作中的缺陷。
类型语法不符合语言定义的规则。
类型标准不符合定义的标准。
类型其他未定义类型的缺陷。
模式错误不正确、不一致或不明确的东西。
模式丢失应该存在的东西缺失。
模式额外不需要的东西存在。
JR/T013020169表A.1(续)属性值定义嵌入活动需求在需求定义活动中嵌入的缺陷(如需求创意、分析或规格中嵌入的缺陷)。
例如:
需求规格中遗漏满足客户目标所需的功能。
不完整的用例规格。
缺失或不正确的性能需求。
缺失或不正确的安全性需求。
需求规格中未正确规定的功能。
需求规格中满足客户目标并不需要的功能。
嵌入活动设计设计活动期间嵌入的缺陷。
例如:
设计无法支持所提出的需求。
从逻辑数据模型中未正确推导出物理数据模型。
不正确的应用程序接口设计。
嵌入活动编码在“编码”或类似活动中嵌入的缺陷。
例如:
不正确的变量类型。
不正确数据的初始化。
模块接口未按设计编码。
嵌入活动配置在产品构建或封装过程中嵌入的缺陷。
例如:
构建过程中包含的错误源文件。
分发/部署程序包中包含的错误.EXE文件。
在.INI文件中有错误的本地化参数。
嵌入活动文档在安装或操作说明文档中嵌入的缺陷。
例如:
用户手册中列出的不正确的菜单选项。
在线帮助中不正确的任务或导航指示。
产品规格中缺少必要的安装条件。
产品版本注释中错误的版本标识符。
检测活动需求在需求整合、检查、评审过程中检测到的缺陷。
检测活动设计在设计整合、检查、评审过程中检测到的缺陷。
检测活动编码在源代码整合、检查、评审过程中检测到的缺陷。
检测活动供应商测试在任何由供应商进行的测试中检测到的缺陷。
检测活动客户测试在任何由客户进行的测试中检测到的缺陷。
检测活动生产在生产运行和使用中检测到的缺陷。
检测活动审计审计中检测到的缺陷(发行前或发行后)。
检测活动其他在任何其他活动中检测到的缺陷,如用户/操作员的培训或产品演示过程中检测到的缺陷。
处置修正修正/移除缺陷。
处置未找到未找到缺陷。
失效无法复现,或报告的行为实际上是预期的行为。
JR/T0130201610表A.1(续)属性值定义处置参考在另一组织的资产中到的缺陷,且缺陷由该组织修正。
处置重复重复报告的缺陷。
表A.2失效属性值示例属性值定义状态打开未来的行动是可预期的。
状态关闭没有进一步行动的计划。
严重性关键不可避免地中断基本操作和或危及安全。
严重性较大影响基本操作,但能继续。
严重性较小中断非基本操作操作。
严重性无关紧要对操作无显著影响。
处置未知原因未找到失效原因;失效征兆消失了。
处置重复同一失效事件在另一份报告中已经存在。
处置解决发现失效原因并解决。
JR/T0130201611BB附录B(资料性附录)分类范例B.1意图本附录给出了5个银行业应用软件问题场景的范例,意图通过在这些范例中对缺陷和失效指标的确定,为本标准的应用提供参考。
B.2问题场景描述范例问题场景如下所列,其相关的分类数据在表B.1和表B.2中给出。
场景1:
甲银行新开发了一个低柜管理系统,小赵是该银行的客户经理。
在系统上线后,小赵发现在登陆屏上找不到密码输入框,因而无法登陆低柜管理系统,小赵在查询了培训笔记后,也没有发现对这个问题的专门记载,所以焦急地向上级主管部门反映这一问题。
分析:
小赵遇到的不能登录低柜管理系统的问题,是由于因密码输入框未在登陆屏上显示而导致的故障,进一步地是由于在Login.asp工件编码过程中嵌入的缺陷造成的。
场景2:
甲银行低柜管理系统的技术支持团队正在与同一银行另一个网点的小钱沟通,小钱也遇到了类似的问题而无法登陆该低柜管理系统。
分析:
小钱遇到的问题与小赵的相似,足以说明两个不同的故障(事件)可以由一个缺陷(条件)引起。
场景3:
乙银行开发的智慧网点系统组织用户合格性测试,测试人员小孙发现字体的颜色不符合需求文档中4.2.1.3节的要求。
分析:
该范例说明了故障(屏幕上不正确颜色的出现)和引起该故障的缺陷(在代码中将不正确的数据值赋给一个常量)的差异。
场景4:
丙银行组织了新一代财务管理系统的软件需求同行评审,老李发现在需求中的值是以分为单位而不是以元为单位。
分析:
该范例说明在任何故障发生前,应先对直接检测到的失效进行分类。
场景5:
丁银行的一个网点所处的地段平常并不停电,但依旧配备了UPS。
在一个因电路故障导致的突然停电中,丁银行该网点的电池耗尽了电量,并导致了最后一笔业务的状态不能确定,经过电话联系数据运行中心进行查询,才确定了最后一笔业务的状态,并向客户再三解释、致歉,才没有导致客户的投诉。
丁银行该网点的负责人老周十分恼火,在上级行来对IT支持情况进行调研时,向调研人员吴主任反应了这个情况。
吴主任在回来后,对这一问题进行了彻查,发现在提出的需求中指定要在电池电量能够支持10分钟和2分钟时,分别报警,以便疏导客户和执行终端设备下电操作,但在网点没有专门的安全监控系统,故未包括能够满足这一需求的电池电量不足警告。
分析:
该范例中,一直到在生产环境出现失效前,缺陷都没有被检测出来。
B.3分类示例表B.1给出了各场景的失效属性值。
JR/T0130201612表B.1失效分类示例失效属性场景1场景2场景3场景4场景5失效IDF080001F080002FID001不适用DID005标题失效:
缺失密码区域失效:
缺失密码区域-重复显示-错误的字体颜色不适用缺少电池电量不足警报描述登陆屏缺失密码域登陆屏缺失密码域字体颜色不符合系统规格:
黑色而不是蓝色不适用银行网点缺失安全监控系统,导致没有电池电量不足警报环境总行WebServer-2总行WebServer-
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- JR-T 0130-2016 银行业软件异常分类 JR 0130 2016 银行业 软件 异常 分类