作者:阮绍臣,李璐
来源:《中国金融电脑》 2016年第8期
中国农业银行数据中心(北京) 阮绍臣 李璐
银行系统软件的专业性、复杂性和银行业务的特殊性质使得银行软件系统上线后面临种种风险。防范软件风险的重要手段之一是执行有效的软件测试。在软件测试过程中,对软件缺陷的管理是发现软件风险、保障软件测试有效性的关键环节。对于商业银行软件项目来说,软件缺陷管理与软件风险防控是相辅相成的。科学的缺陷管理方法是提高软件测试质量不可或缺的手段,也是减少软件风险的一种可靠途径。
一、银行软件缺陷管理的重要性
作为软件测试活动的最终产出物,软件缺陷反映了软件存在风险的事实。银行系统软件之所以较一般软件的风险更高,其主要原因有以下几方面。
(1)银行软件运行错误可能造成非常高的经济代价,因此对可靠性的要求更高;
(2)银行软件测试除了需要基本的软件领域知识外,还需要具备银行业专业知识;
(3)银行软件特别是核心业务系统通常规模庞大,模块间耦合性强;
(4)银行软件经常面临需求变动、开发周期短等软件工程中较为棘手的非技术性问题。
软件测试的目的是为了提前发现银行系统软件的潜在风险,而缺陷管理实质上就是对风险的管理。从某种意义上说,软件缺陷可以看作是已经发现的风险,因此,缺陷管理对银行软件风险防控具有重要意义。
二、缺陷管理与风险防控的关系
软件缺陷管理的任务主要包括缺陷发现、缺陷提交、缺陷修复、缺陷分析、缺陷验证等。软件缺陷反映了软件存在风险的事实。软件测试的目的就是发现缺陷,发现风险。然而,软件测试的覆盖范围始终是有限的,任何一次测试活动都只能做到“尽可能”地发现缺陷。因此,在缺陷管理的过程中,要特别注意防患于未然,总结历史经验,充分发掘缺陷背后隐藏的风险信息。
根据银行软件测试工作实践经验,笔者认为软件缺陷对风险的反映主要体现在缺陷的业务风险特性、缺陷的影响范围和缺陷的工程等级。
(1)缺陷的业务风险特性
缺陷的业务风险特性是指由于缺陷导致业务失败所可能产生的风险后果。业务风险特性从银行业务角度描述了缺陷发生后可能产生的后果,与软件缺陷本身的严重等级无关。
(2)缺陷的影响范围
对银行软件系统的测试,特别是对核心业务系统的测试,经常需要涉及多个模块甚至多个系统。因此,某一个模块产生缺陷,其真正原因可能并不在模块本身。同样,修复该缺陷后所影响的也不仅仅是模块本身。对缺陷影响范围的合理定位有利于切实理解缺陷的风险所在。
(3)缺陷的工程等级
缺陷的工程等级是软件工程中根据缺陷对系统影响的严重程度划分的评价等级。在评价银行业务软件风险时,区分业务风险与工程风险有利于定位、理解和应对风险。
发现风险和规避已知风险是软件缺陷管理的目标。为了实现这一目标,对软件缺陷进行精细化管理是不可或缺的。一般的软件缺陷管理方法和工具通常注重从流程和缺陷工程等级上实施精细化管理,对于银行业务软件来说,这样做还不够。由于银行业务风险高,又高度依赖于业务系统的运行,因此缺陷管理必须考虑业务层面的影响。在将业务风险纳入后,笔者在传统模型的基础上重新规划了缺陷管理流程,并致力于解决如下问题:
(1)如何设计多系统、多模块的缺陷管理模型,使之更加符合银行软件项目实践活动,并有助于提升风险管控能力;
(2)如何将缺陷与业务特性结合,全面认识缺陷可能带来的风险;
(3)如何利用新的缺陷管理模型挖掘信息、评估风险。
三、软件缺陷管理模型
缺陷的有效处理依赖于相关人员的紧密配合,从软件工程角度看,缺陷处理相关人员包括开发人员、测试人员等。不同角色各司其职,充分发挥每一个角色的能力要靠合理的工作流程来保障。对于银行软件系统而言,因为经常涉及多个业务系统交叉,更加需要一套有效的缺陷管理流程。缺陷管理流程如图1 所示。
基于上述缺陷管理模型,笔者试图完成两项任务:首先,分离系统的技术风险与业务风险,实现风险的精细化评估;其次,找到一种能够评价多系统之间关联风险的方法。
四、软件缺陷的业务风险评估
软件缺陷的业务风险是银行软件测试领域中一类不可忽视的风险,同时,银行软件测试人员还不得不面对软件工程的其他技术风险。区分这两类风险有助于帮助测试人员更好地识别、应对风险。为此,可引入四种缺陷管理角色,分别是测试人员、开发人员、测试经理、开发经理,这些角色的职责如下。
(1)测试人员的职责包括新建缺陷、复核缺陷和验证缺陷。
(2)开发人员的职责包括调查缺陷、修复缺陷。
(3)测试经理的职责包括审核缺陷、评估缺陷。
(4)开发经理的职责包括分配缺陷、进行缺陷流转。
为了实现对风险的精细化评估,需进一步明确四类角色的职责。
对于测试人员来说,应当从“缺陷影响系统运行的程度”这一角度来评估缺陷的技术风险,例如是否会引起系统宕机、是否会损坏数据等;对于开发人员来说,应当给出缺陷的技术解决方案。换句话说,测试人员和开发人员互相配合,以尽量避免被测系统在技术上存在风险。
对于管理人员来说,这里特指测试经理和开发经理,他们应该关注的是缺陷的业务特性。测试经理的主要任务是评估缺陷的业务风险等级,包括缺陷是否存在业务上的风险、风险程度如何;开发经理的主要任务是确认缺陷是否属于自己所负责的业务范围内,如果是则指定相关业务开发人员去解决缺陷,如果不是,则开发经理应该将缺陷转交给其他业务系统的开发经理。测试经理与开发经理互相配合,完成对缺陷业务风险的确认和解决。
在本文提出的风险评估体系中,测试经理是对业务风险进行评估的关键角色,必须具备过硬的业务能力和测试技术。有些缺陷从软件工程角度来讲可能并不严重,然而一旦同银行业务结合起来,这些缺陷就可能潜藏着很大的风险。“安全无小事”,保障客户的财产安全是银行的责任,在涉及客户财产安全的业务系统中,即使仅仅发现了一些极小的缺陷,也必须谨慎处理。根据笔者的经验,软件缺陷所隐含的业务风险与以下几个要素息息相关。
一是业务系统本身的重要性和可靠性要求,比如是否是核心系统、业务连续性要求如何、系统出错后对银行业务的影响覆盖面的广度如何等。
二是缺陷是否涉及其他业务系统,如果一个缺陷是由于其他业务系统的问题所导致,或者这个缺陷与其他业务系统有关联,那么它的风险就会提高。
三是缺陷的产生是不是因为开发人员对业务需求的理解存在偏差。根据经验,如果一个缺陷是因为业务理解不一致产生的,那么很有可能存在更多的类似缺陷。
将业务风险与技术风险分开可以帮助我们更好地寻找风险产生的原因,让测试经理和开发经理专注于解决业务问题,有利于风险管控。
五、多系统关联风险的评估
银行业务系统之间具有较高的关联性。系统之间的关联程度高会增加系统风险。在实际工作中可发现,系统缺陷的统计数据是反映系统间关联程度的重要依据。为此,笔者对系统缺陷数据与系统关联性展开了研究。
软件缺陷在其生命周期中的流转过程提供了有价值的信息。如图1 所示,每一个缺陷从最初的“新建”状态到最终的“关闭”状态,期间要经历若干次状态转换,每次状态转换发生时,缺陷由某个系统/ 角色流转到另一个系统/ 角色。从某个特定角色的角度看,缺陷的流转可能仅仅代表任务的接受或完成。但从风险管理的整体视角看,缺陷的状态转换不单单只是任务的分配,更重要的是可以为系统风险的评估提供信息。在系统间流转的缺陷有着特殊意义:缺陷在系统间的流转路径反映了系统间的耦合程度,在同一测试阶段,如果有大量缺陷都发生了在
某两个系统之间的流转,那么可以认为这两个系统的相关性很高。系统相关性高意味着其中一个系统的变化可能会影响另外一个系统,这样的耦合型系统的业务风险一般也高于一般系统,本文称之为“业务耦合风险”。通过对缺陷流转记录进行分析,可以发现业务耦合风险。
笔者采取如下方法来计算业务耦合风险。首先,筛选缺陷列表中所有的跨系统缺陷。所谓跨系统缺陷,是指缺陷的建立者(测试人员)和缺陷的修改者(开发人员)不隶属于同一个系统的缺陷。其次,筛选完成后,将每一个符合条件的缺陷的建立系统和修改系统归总为一个系统组。再次,合并成员相同的系统组,系统组合并的重复次数即为业务耦合风险指数。
业务耦合风险指数度量了业务耦合风险的大小,换句话说,实现了对多系统关联风险的评估。当某个系统组的业务耦合风险指数较高时,意味着这个组内的系统之间关联性高。在测试过程中,特别是多系统联合测试时,要对业务耦合风险指数较高的系统组给予关注,执行更为细致和全面的测试。
软件缺陷是软件测试工作的产出成果,是反映软件风险的重要实践依据。本文阐述了在银行软件缺陷管理过程中提高风险管控能力的三类措施,包括制定合理有效的缺陷管理角色和流程、分析利用缺陷的业务特性、充分挖掘缺陷流转过程中的有效信息等。总之,在软件缺陷管理流程中引入业务评估要素与关联性度量要素,有助于进一步发挥软件测试对系统风险的防范作用,积累与业务紧密结合的风险防控经验,提升软件测试工作的效率与效果。FCC
因篇幅问题不能全部显示,请点此查看更多更全内容