银行应用软件开发论文

收稿日期:2010-12-20;修回日期:2011-01-28。基金项目:国家863计划项目（2008AA01Z142）;陕西省教育厅资助项目（2010JK299）。以下是小编精心整理的《银行应用软件开发论文(精选3篇)》，欢迎阅读，希望大家能够喜欢。

银行应用软件开发论文 篇1：

霍耀昌：60天的闪电式收购

2012年11月，电讯盈科企业方案收购了中联集团旗下拥有中国银行应用软件方案业务的中联中国，那么这一收购如今产生了怎样的化学效应？

2012年11月，电讯盈科企业方案与美国安富利公司达成协议，收购中联集团旗下拥有中国银行应用软件方案业务的中联中国。

事隔半年，关于电讯盈科企业方案收购中联中国一事现在仍是业界关注的焦点。大家对于电讯盈科企业方案这一收购是否达到预期，以及未来将会如何带领中联中国向前发展等问题十分关注。基于这些疑问，《软件和信息服务》杂志副总编郭嘉凯与电讯盈科企业方案董事总经理霍燿昌进行了一次深入交流。以下为对话内容：

郭嘉凯：业界对于电讯盈科企业方案收购中联中国一直很感兴趣，您能介绍一下整个的收购过程是怎样的？

霍燿昌：客观来说，其实这次收购有点故事性的色彩。按照公司的规划，在战略上准备发展银行应用软件方案业务，而我们在这一块还没有核心业务系统的技术，所以正准备物色相关的企业进行合并。

恰好在2012年8月份的时候，我们得知在国内银行应用软件方案获得广泛认可的中联中国在和其它企业谈并购的事宜，但是谈了很久也没有结果，我们就抓住这个机会接洽了中联中国。最早我亲自写了一封邮件给安富利总裁，告诉他电讯盈科企业方案有意参与此次收购，并且保证，能够在60天内就完成所有的并购任务。

到最后，事实证明，从去年10月份一开始到11月27号，我们只用了不到60天的时间就完成了整个收购的工作。

郭嘉凯：这次收购确实十分迅速，您为什么这么有信心能在如此短的时间内保证完成收购事项？

霍燿昌：对于这件事情，我之所以有信心，一是基于自己对银行业务的了解。事实上，在来电讯盈科企业方案之前，我在银行和资讯领域有超过30年的经验，从中国香港到英国，再到澳大利亚，我一直都在做和银行相关的工作。另外，对于此次收购，我本身十分感兴趣。在整个收购过程中，几乎所有的任务以及需要面对的问题我都有亲自参与进来。并且，在整个收购过程中，我们只开了两次网络会议就十分顺利地完成了。

可以这么说，这次收购充分说明了我们对银行业务的了解和决心，因此，这次收购对我们来说也是一个非常有历史价值的交易。

郭嘉凯：电讯盈科企业方案收购中联中国是基于怎样的构思？

霍燿昌：其实，前面已经提到，这是基于我们电讯盈科企业方案战略性转折的需求。

公司的董事委员会要把原来的电信公司变成一家TMT（即电信、媒体和科技）的集团，把工作的重心向这三个不同的市场发展。而要想电信、媒体和科技三头齐进，收并购一些相关的企业和公司是势在必行的事情。

对中联中国来说，它的银行应用软件方案涵盖客户管理、资金管理、付款系统、信用卡、结算、规管披露、营运风险管理、商业智能分析、电子银行及各项中介服务，能够为客户提供多功能的关键核心系统软件。

而且，中联中国在北京、上海、武汉、广州等一线城市都设有服务中心。对于我们电讯盈科企业方案来说，想要进军沿海一线城市甚至分散到全国的IT金融行业市场，那么中联中国是一定要收购的。

郭嘉凯：一般来说，企业如果收购不成功的话，很可能面临一些问题，在收购中联之前，您最担心的是什么？

霍燿昌：的确如此，不但是在国内，在国外也是这样。把两家不同文化的公司快速地整合，发挥最大效应并不是一件容易的事。特别的是，国内在软件方面的知识产权保护程度相对不够，所以我们担心出现知识产权得不到保护的问题。当然，另外一个重要的问题就是员工流失的问题。

因为存在这样的一些担忧，在签订收购合同之后，我们立即采取了一系列有效的措施去规避这些问题。

首先，在第一时间安抚中联员工，稳定军心，让他们了解我们的项目管理都是按照国际化、标准化的流程去进行，告诉他们这其实是一个很好的转变。

其次，告诉中联中国的员工我们会保持中联中国这个他们多年辛苦打拼出来的品牌。这个品牌是他们过去与企业一起发展，走过风风雨雨而得到的品牌，我们十分乐意这个品牌一直走下去，保留这样一份品牌的价值。

第三，保证每位员工的薪酬调整，年底奖金的按时发放，而且给他们足够的岗位去自主招聘。

最后，在软件升级方面，我们加大力度让电讯盈科企业方案与中联中国原有的团队一起去发展客户，明确中联中国和电讯盈科企业方案的关系，避免客户产生困惑。

郭嘉凯：现在已经过去了几个月，您觉得公司的磨合达到预期了吗？

霍燿昌：总体来说，我们觉得发展的方向是对的，不过在磨合的步伐上还可以再加快一点。

我当初不希望将很多集团的管理者放在中联的这个队伍里，所以进度就有些慢了。不过从今年3月开始，我们已经把电讯盈科企业方案一部分的管理者放进来，更让集团中有经验的人也参与进来，我自己也花了很多时间去和中联的负责人沟通，希望可以更好地协调好工作，加快整合的进程。

郭嘉凯：您对中联收购之后，在电讯盈科企业方案部门中持有怎样的期望？

霍燿昌：我们的期望主要有三点。第一，在国内，我们希望把金融行业变成主要的服务对象，这项工作目前已在推进当中；第二，把我们从中国开发出来的第一个软件变成一个国际性的全球化软件；第三，中联有100多家银行客户，我们将融合这100多家银行的需求，做出一种能满足广泛需求的软件版本。

郭嘉凯：在接下来的一两年之内，中联中国在发展上有没有什么规划或者目标？

霍燿昌：现阶段有三个很清晰的目标：第一，就是要让我们的客户百分之百的满意；第二，希望中联中国重回国内市场上排名第一的位置，并且还要再找到一些新的客户，让整个市场认识到新的中联已经诞生；第三，从2014年开始，从香港开启打开国际市场的步伐。对此，我们都很有信心。

作者：袁颖

银行应用软件开发论文 篇2：

面向服务软件的蜕变测试方法

收稿日期:2010-12-20;修回日期:2011-01-28。

基金项目:国家863计划项目（2008AA01Z142）;陕西省教育厅资助项目（2010JK299）。

作者简介:路晓丽（1973-），女，陕西西安人，副教授， 博士，主要研究方向：软件测试； 董云卫（1968-），男，陕西西安人，教授，博士，主要研究方向：软件的设计、验证和仿真测试。

（1.西北大学 公共管理学院，西安 710069; 2.西北工业大学 计算机学院，西安 710043）

（luxl73@nwu.edu.cn）

摘 要:在面向服务软件的测试过程中，由于在服务发现之前不可知的交互对象和同一个服务可能会有不同实现，往往出现程序执行结果不能提前预知的Oracle问题。为了有效地解决面向服务软件测试中的Oracle问题，基于面向服务架构（SOA）的特点，提出将蜕变测试方法用于面向服务软件的单元测试和集成测试过程中，依据面向服务软件每个服务的自身性质构造蜕变关系，设计蜕变测试类执行测试用例并验证蜕变关系是否保持，如果蜕变关系被违反了，则发现和报告缺陷，从而有效地支持面向服务软件的测试。

关键词:软件测试；面向服务架构；蜕变测试；蜕变关系

Testing of service-oriented software: a metamorphic testing approach

LU Xiao-li^1,2，DONG Yun-wei²

（1.School of Public Administration，Northwestern University，Xi’an Shaanxi 710069,China;

2.College of Computer Science，Northwestern Polytechnic University，Xi’an Shaanxi 710043,China）

Key words: software testing;Service-Oriented Architecture （SOA）;Metamorphic Testing （MT）;Metamorphic Relation （MR）

0 引言

面向服务架构（Service-Oriented Architecture，SOA）是以服务为基础的松耦合的分布式应用系统的结构，基于服务的形式功能描述为软件系统的灵活性、可扩展性和开放性提供了基础，有效地支持了异构资源共享、动态升级和演化。随着SOA的应用越来越广泛，确保面向服务软件的质量尤为重要，而软件测试是保证面向服务软件质量的主要手段。

SOA的基本元素就是服务，服务就是一个软件模块，这个软件模块能够描述自己,能够被顶级服务发现和定位,能够使用良好的接口和顶级服务进行交互。由于服务是动态发现的，因此没有必要硬编码，服务松散集成在一起，这种结构会极大地增强构建复杂SOA应用的能力。然而，因为服务松散集成，向一个服务提供另一个服务很难提前确定；而且服务通常在异构环境下开发，并且是由不同组织开发的，知道服务实现的所有细节是不现实的，因此，在面向服务软件的测试过程中更多地使用黑盒测试方法。

然而，在对面向服务软件进行黑盒测试时，存在两个问题：首先，一种服务的不同实现的行为表现不一样，一种特定实现的测试结果并不能被看做其他实现的预期结果；其次，一种服务的期望结果很难预测，或者为了预知结果使用人工方法需要花费较大的代价。这两个问题都带来了测试这类应用程序的挑战，这种程序的执行结果不能预知的现象在测试理论中称为“Oracle问题”。本文提出将蜕变测试方法用于面向服务软件的单元测试和集成测试过程中，依据面向服务软件每个服务的自身性质构造蜕变关系，检测几个输出之间的关系来判断服务的功能是否正确，而不仅仅依赖判定单个输出结果是否正确，从而允许在SOA框架下测试结果的交叉验证，能够有效减少SOA应用测试中的Oracle问题的发生。

1 相关研究

目前，国内外在面向服务软件的测试技术领域已有一些研究，提出了一些测试模型和测试方法，它们之间的侧重点各有不同，各有优缺点。文献［1］讨论了面向服务（SOA）的特殊应用Web Service测试，提出了基于XML信息框架产生测试用例的三个规则，并用一个例子进行了说明，表示78%植入的缺陷被发现。文献［2］提出了一种测试Web服务的递增式分组测试方法，并把测试用例应用于服务的一系列实现中。文献［3］提出利用约定中的概念来指导Web Service的测试，建议定义正式的约定来描述Web服务的功能和交互行为，指出测试工作主要用来测试Web服务和约定的一致性。

针对测试过程中出现的程序的执行结果不能预知的现象（即Oracle问题），文献［4］提出了一种蜕变测试（Metamorphic Testing，MT）方法，可以有效地解决测试过程中的Oracle问题。蜕变测试依据被测软件的领域知识和软件的实现方法建立蜕变关系（Metamorphic Relation，MR），利用蜕变关系来生成新的测试用例，通过验证蜕变关系是否被保持来决定测试是否通过^［5］。蜕变关系是指函数的一系列输入及相应输出的关系。假设函数f是待测的函数，{I_1，I2，…，I_n}n>1表示程序f的输入数据，基于输入数据{I_1，I2,…,I_n}n>1给定一个关系r，{I_1，I2，…，I_n}n>1相应的输出{f（I₁）， f（I₂），…， f（I_n）}必須满足属性rf，即：r{I_1，I2，…，I_n}n>1rf{f（I₁）， f（I₂），…， f（I_n）}。蜕变关系MR_f可以表示如下：

MR_f{（I_1，I2，…，I_n， f （I₁）， f （I₂）,…， f （I_n））

|r（I_1，I2，…，I_n）

rf（I_1，I2，…，I_n， f （I₁），f （I₂），…，f （I_n））}

假设程序p实现的是函数f在定义域D上的功能，可以通过任何的测试用例选择策略选择一些测试用例，表示为：T {t_1，t2，…，t_k} D，这些测试用例的执行结果为P（t₁），P（t₂），…，P（t_k）。如果这些测试用例的执行并没有发现缺陷，基于函数f的蜕变关系就可以从这些测试用例生成后续测试用例，表示为：T′ {t_1′，t2′，…，t_m′} D。以正弦（sine）函数为例，根据该函数的重要性质：对于输入变量x_1和x2，如果满足x_{1+ x2}π，那么sin（x₁）sin（x₂），这就是蜕变测试时找到的蜕变关系，若x₁是源测试用例，则依据蜕变关系就可以得到新的后续测试用例x_{2， x2}π- x₁。通常，蜕变测试依据蜕变关系生成更多的后续测试用例，测试时就会多次执行目标程序，使得程序可以进一步被验证。蜕变测试方法可以用于数值计算^［6-7］、无向图遍历^［8］、二叉树查询^［9］和中间件软件测试^［10］等很多领域。

2 面向服务软件的蜕变测试方法

在面向服务软件的测试过程中，单元测试和集成测试非常重要。在单元测试阶段，软件系统中每一个单个服务都经过测试；在集成测试阶段，对已测试过的服务之间交互进行测试。本章主要介绍面向服务软件的蜕变测试方法，描述蜕变测试类如何帮助测试人员实施单元测试和集成测试。

2.1 单元测试

在对服务进行测试时，主要测试服务是否满足了功能需求。可以对每个被测试的服务构建一个相对应的蜕变测试类，蜕变测试类通过多次执行源测试用例和利用蜕变关系生成的后续测试用例，验证蜕变关系是否保持，如果蜕变关系被违反，则蜕变测试类就会报告发现了缺陷。测试步骤如下所示：

1）为每个要被测试的服务构建相应的蜕变测试类。

2）针对被测服务的功能特性，构建一系列蜕变关系MR，表示为MR_1、MR2，…

3）针对被测服务的特定功能，可以使用特殊值测试法或者随机测试法为每个服务构建源测试用例集合TS，集合中的每个源测试用例表示为TC_i（i0，1,2,…）。

4）对于测试用例集合TS中的每个源测试用例TC_i，基于蜕变关系MR_i 产生对应的后续测试用例，表示为TC_s。

5）蜕变测试类将TS中的每个源测试用例TC_i和相应产生的后续测试用例TC_s传递给被测服务去执行。

6）蜕变测试类使用蜕变关系检测缺陷，验证MR_i（TC_i，TC_s，S（TC_i），S（TC_s）），若蜕变关系MR_i被违反，则报告任何检测到的缺陷；若蜕变关系MR_i没有被违反，则本次测试通过。

2.2 集成测试阶段

在集成测试阶段，当测试某个服务和其他服务之间的交互是否正确时，可以针对每一个服务，找到一个和这个服务有可能进行交互的服务集合；然后对于这个集合中的每一个服务，基于服务之间交互的特点设计一种或多种蜕变关系应用于二者的交互测试中；可以使用单元测试阶段所构建的被测试服务的源测试用例集合，基于新的蜕变关系生成后续测试用例，在交互执行中验证新的蜕变关系是否被保持。如果新的蜕变关系被违反，则蜕变测试类就会报告服务交互过程中的缺陷。测试步骤如下所示：

1）对于每个S，找到和它交互的服务集合ST。

2）对于ST中的每个服务，设计蜕变关系MR_X来测试两者之间的交互。

3）基于被测服务S在单元测试阶段构建的源测试用例集合TS中的TC_i，利用蜕变关系MR_X产生相应的后续测试用例。这时有两种情况：

a）对于TC_i，如果被测服务执行TC_i不会产生输出消息，则蜕变测试类会基于TC_i和蜕变关系MR_X直接计算TC_i的后续测试用例，表示为TC_cc 。

b）对于TC_i，如果被测服务执行TC_i会产生输出消息，则蜕变测试类会根据输出的结果S（TC_i）和蜕变关系MR_X来计算后续测试用例S（TC_i）′。

4）针对a）情况，蜕变测试类传递TC_i給被测试服务执行，并且依据服务注册情况发现ST集合中的服务T₁来处理TC_i对应的后续测试用例TC_cc；针对b）情况，蜕变测试类依据服务注册情况找到ST集合中的服务T₂处理S（TC_i），找到服务T₃处理S（TC_i）′。

5）蜕变测试类从相应服务得到测试结果，针对a）情况，服务S处理TC_i后将返回结果S（TC_i），服务T₁处理后续测试用例TC_cc后将返回结果T_1（TCcc）；针对b）情况，服务T₂处理S（TC_i） 将返回结果T₂（S（TC_i）），服务T₃处理S（TC_i）′将返回结果T₃（S（TC_i）′）。

6）蜕变测试类使用蜕变关系检测缺陷，针对a）情况，验证MR_X （TC_i，TC_cc，S（TC_i），T_1（TCcc）） ；针对b）情况，验证MR_X （S（TC_i），S（TC_i）′，T₂（S（TC_i）），T₃（S（TC_i）′））。若蜕变关系MR_X被违反，则报告任何检测到的缺陷；若蜕变关系MR_X没有被违反，则本次测试通过。

3 案例分析

下面以一个外汇兑换交易服务的银行应用软件为例，该应用程序共有五个服务，分别为：交易输入服务S1、 外汇兑换服务S2、竞争对手外汇兑换服务S3、中央银行查询汇率服务S4和其他银行查询汇率服务S5。其中，交易输入服务S1负责兑换交易的输入处理；外汇兑换服务S2负责外汇兑换，本例只限于讨论将美元兑换为人民币。通常，银行会提供买入外汇时使用的汇率和卖出外汇时使用的汇率，例如美元和人民币的兑换汇率是一对值8.2796/8.2797，则8.2796为买入汇率，8.2797为卖出汇率。竞争对手外汇兑换服务S3是竞争对手的相同兑换服务，是动态发现的；中央银行查询汇率服务S4负责动态查询中央银行的汇率，例如人民币兑换时查询中国银行关于人民币兑换汇率；其他银行查询汇率服务S5负责查询其他非中央银行的汇率，也是动态发现的。下面以服务S2的测试为例，使用第2章提到的策略和方法，在单元测试阶段和集成测试阶段构建蜕变测试类，基于蜕变关系MR_1、MR2和MR₃发现和报告缺陷。

3.1 单元测试

单元测试阶段主要对各个服务进行测试，下面以外汇兑换服务S2的测试为例进行说明。假设S2有这样的预期行为：对于在一天内的任何一笔交易能够提供相同的汇率；假设该服务的实现中存在这样的缺陷：该服务处理交易单时不定地使用了买入和卖出汇率。针对上述的需求，测试人员构建蜕变关系：MR₁： n S2（x） S2 （nx）。

对外汇兑换服务S2进行测试时，利用第2章提出的策略，可以对外汇兑换服务S2设计一个蜕变测试类，表示为：M_S2。蜕变测试类M_S2负责根据蜕变关系产生后续测试用例，然后传递后续测试用例给服务S2进行处理，接着检查S2（x）和S2（nx）是否保持了蜕变关系MR₁，并根据检查结果报告缺陷。

考虑选择初始测试用例t₀为x100＄的交易，外汇兑换服务S2正确地使用了买入汇率输出了结果，即： S2（100＄）827.968.2796×100。蜕变测试类M_S2依据蜕变关系构建后续测试用例t₁为y200＄2x的交易，并把t₁传递给S2进行处理，这次外汇兑换服务S2错误地使用了卖出汇率输出了结果，即：S2（200＄）1655.94200×8.2797。最后，蜕变测试类M_S2依据蜕变关系MR₁检查S2（100＄）和S2（200＄），2×S2（100＄）1655.92≠1655.94 S2（200＄），这时违背了蜕变关系MR₁，蜕变测试类将会报告缺陷。因此，該服务处理交易单时不定地使用了买入和卖出汇率的缺陷将会通过上边的蜕变测试方法被发现。

3.2 集成测试

假设外汇兑换服务S2有这样的预期行为：能够比竞争对手提供更好的至少相同的汇率。由于该需求涉及到竞争对手的汇率服务，因此需要在集成测试阶段进行验证。假设S3是动态发现的竞争对手汇率服务，针对这样的需求，可以构建蜕变关系为：“MR₂:n S2 （x）≥ S3（n×x）”。 利用第2章提出的策略，可以针对S2和S3的交互特点构建蜕变测试类M_S2S3，蜕变测试类M_S2S3负责根据蜕变关系MR₂产生后续测试用例，然后传递后续测试用例给服务S3进行处理，接着检查S2（x）和S3（nx）是否保持了蜕变关系MR₂，并根据检查结果报告缺陷。

选择初始测试用例t₂为x200＄的交易，依据MR₂，蜕变测试类M_S2S3计算后续测试用例ts为y60＄0.3×200的交易。竞争对手的汇率服务S3被发现后，蜕变测试类M_S2S3传递y给S3进行处理，假设S3使用的汇率为8.2796，则S3（nx）8.2796×0.3×200496.776。蜕变测试类依据蜕变关系MR₂进行验证，有：0.3×S2（200）496.782≥496.776 S3（0.3×200），蜕变关系被保持，因此针对这个用例，蜕变测试类M_S2S3没有报告缺陷。

另外，在交易的执行过程中，外汇兑换服务S2需要不断地检测中央银行的相关兑换汇率，外汇兑换服务S2还有这样的预期行为：S2总是动态地从中央银行检测汇率。假设S2的实现中有这样的缺陷：汇率的提供逻辑存在缺陷，从而引起S2有时会使用最小的汇率而不是最大的汇率进行计算。由于该需求涉及到中央银行查询汇率服务和其他银行查询汇率服务，因此仍需要在集成测试阶段进行验证。为了对汇率进行查询，对于每一笔美元和人民币兑换交易，除了交易数额x，还会相应地产生一个查询美元/人民币汇率的输出消息m。针对这样的需求，可以构建蜕变关系为：MR₃:S2 （x，m）＞ S2（x，m′）。这个蜕变关系表示由中央银行通过汇率查询消息m提供的汇率应该好于任何从其他银行通过汇率查询消息m′提供的汇率。利用第2章提出的策略，可以针对这种交互构建蜕变测试类M_S2S，蜕变测试类M_S2S负责根据蜕变关系产生后续测试用例，然后传递后续测试用例给其他银行查询汇率服务进行处理，接着检查结果是否保持了蜕变关系MR₃，并根据检查结果报告缺陷。

针对美元和人民币兑换交易，假设S2动态发现了S4和S5来提供人民币汇率报价，而S4是中央银行查询汇率服务，提供的美元/人民币汇率是8.2796/8.2797，S5是其他银行查询汇率服务，提供的美元/人民币汇率是8.2795/8.2798，这个汇率范围较宽，因此并不好。若S2在处理交易的过程中，错误地使用了S5提供的汇率，则S2将会输出：S2（100＄）827.958.2795×100。蜕变测试类M_S2S依据蜕变关系MR₃产生m的后续测试用例m′， m′依然为“美元/人民币汇率查询”，该消息接着再由M_S2S传递给动态发现的S5来提供相应的汇率，则有S2（100＄，m′）8.2795×100827.95。蜕变测试类M_S2S检查结果后发现S2（100＄，m）827.95≯827.95S2（100＄，m′），违反了蜕变关系MR₃，这时就会报告缺陷，因而S2处理过程中存在的汇率提供逻辑缺陷就会通过上述的蜕变测试方法被发现。

4 结语

随着面向服务架构（SOA）的应用越来越广泛，确保面向服务软件的质量尤为重要。测试面向服务架构的应用时需要处理一些问题，包括：在服务发现之前不可知的交互对象、服务的信息好似一个黑盒并不可知和同一个服务可能会有不同实现。为了有效地解决这些问题， 本文将蜕变测试方法用于面向服务软件的单元测试和集成测试过程中，依据面向服务软件每个服务的自身性质，构造输入与输出之间的蜕变关系，并通过蜕变测试类验证蜕变关系是否保持，从而发现和报告缺陷，有效地支持面向服务软件的测试。未来将重点研究如何为服务构建合适的蜕变关系，并进一步研究当蜕变关系设计好后，如何自动地生成蜕变测试类。

参考文献:

［1］ OFFUTT J，XU W. Generating test cases for Web services using data perturbation［J］. SIGSOFT Software Engineering Notes，2004，29（5）:1-10.

［2］ TSAI W T，CHEN Y，CAO Z,et al. Testing Web services using progressive group testing［C］// Proceedings of Advanced Workshop on Content Computing， LNCS 3309. Berlin: Springer，2004:314-322.

［3］ KECKEL R，LOHMANN M. Towards contract-based testing of Web services［J］. Electronic Notes in Theoretical Computer Science，2005，20（3）:145-156.

［4］ CHEN T Y，CHEUNG S C，YIU S M. Metamorphic testing: A new approach for generating next test cases, HKUST-CS98-01［R］.Hong Kong: Hong Kong University of Science and Technology,Department of Computer Science and Engineering,1998.

［5］ CHEN T Y，TSE T H，ZHOU Z. Fault-based testing in the absence of an oracle［C］// Proceedings of the 25th Annual International Computer Software and Applications Conference. Washington,DC: IEEE Computer Society，2001: 172-178.

［6］ CHAN F T，CHEN T Y，CHEUNG S C，et al. Application of metamorphic testing in numerical analysis［C］// Proceedings of the IASTED International Conference on Software Engineering. Calgary: ACTA,1998:191-197.

［7］ CHEN T Y，FENG J，TSE T H. Metamorphic testing of programs on partial differential equations: A case study［C］// Proceedings of the 26th Annual International Computer Software and Applications Conference. Washington,DC: IEEE Computer Society，2002:34-45.

［8］ CHEN T Y，KUO F C，TSE T H，et al. Metamorphic testing and beyond［C］// Proceedings of the 11th Annual International Workshop on Software Technology and Engineering Practice. Washington,DC: IEEE Computer Society，2004:94-100.

［9］ CHEN T Y，TSE T H，ZHOU ZIQUAN. SemiProving: An integrated method based on global symbolic evaluation and metamorphic testing［C］// Proceedings of the 2002 ACM SIGSOFT International Symposium on Software Testing and Analysis. New York: ACM，2002: 191-195.

［10］ CHEN W K，CHEN T Y. Integration testing of context-sensitive middleware-based applications: A metamorphic approach［J］. International Journal of Software Engineering and Knowledge Engineering，2006，16（5）: 677-703.

作者：路晓丽 董云卫

银行应用软件开发论文 篇3：

呼吸统一开放的空气

开放式应用软件开放平台带给银行更有效的成本控制

值得关注的两个案例：

■ 1996年，位于英国伦敦的巴克莱银行总部（Barclays），为了方便快捷地在其所有设备上实现未来新业务的开发及现有应用软件的升级，第一个提出在多品牌自助设备上实现开放式应用软件开发平台的需求，由此拉开了多厂商解决方案进入应用时代的大幕。

■ 1999年，欧洲著名银行——荷兰银行（ABN-AMRO Bank）对现有资源进行整合改造，其1250台各种品牌的ATM机开始运用统一的开放式应用软件开发平台，最终达到降低自助设备成本，提高应用效率的目的。

Future Trends Survey 2003年对全球ATM市场的调查显示，开放的ATM软件架构将成为未来5年内北美及欧洲ATM行业发展的主要趋势。其对北美市场的调查显示，“开放的ATM软件架构”以14.8%的调查比例居趋势之首；而欧洲市场这一比例为16.7%，仅次于安全标准之后。

为什么开放的ATM软件架构将成为ATM行业发展的主要趋势呢？

成本削减

尽管当代的自助设备业务处理能力越来越强，但是在成本削减和扩大收益方面，依然有很多潜力有待进一步挖掘。德国著名市场研究机构Datamonitor曾指出：“银行需要增加软件方面的投入以更好地利用成熟的硬件设备，并提供增值服务。”

1990年代初期，国际金融业终端设备尚没有统一、标准的接口规范。银行自助设备在应用上各自为政，不同的设备有不同的操作界面；不同的厂商设备，有不同的软件支持系统。随着银行扩大自助服务网络，不同品牌设备所需要各种不同软件、硬件的支持，这给银行造成了相当多的不便。

首先，银行需要购买不同的前置机来管理各个品牌的自助设备。

其次，银行不得不同时组成几套软件开发团队，进行相同需求的应用开发。即便具体开发工作由厂商承担，也使得银行的管理和协调工作变得异常复杂。

再次，多厂商设备还会带来维护的不便、银行客户信息统计的不便、客户对不同的操作界面要有不同的熟悉过程和不同的操作手段。

以上因素都会使硬件投入成本增加，开发成本重复支出，维护成本、员工成本支出过高等一系列问题。当前，开放的自助设备软件架构是解决这些问题的唯一途径。因为国际金融的标准化问题正成为趋势，开放的、标准的软件架构规范也越来越成为银行界的迫切需求。

在今天的西方银行，我们经常会看到，不论是在分行营业厅的自助服务区，还是在独立的自助银行内部，自助设备的品牌往往并不是一种。到过荷兰机场的人一定注意到，其中安置的ATM机品牌非常多，可以堪称是一线国际品牌的荟萃。与之相对应的是，不同品牌的设备带给顾客的不是各自独立的操作模式和混乱而是消费者操作时一致的感受——这就是运行在不同品牌ATM机背后统一平台软件所发挥的功能。当然，运用开放式应用软件开放平台带来的好处不仅如此，更重要的是，它带给银行更有效的成本控制。

第一个采用统一开放式软件开发平台的是巴克莱银行，其授权部负责人Steven Robinson先生说：“每月有成百万客户使用我们的ATM机。运用统一的开放式应用软件开发平台，借助我们合作伙伴的创新、技术和经验所带来的强大动力，巴克莱银行自助服务终端的网络性能得以大大提升。而最终获益者是银行自身：管理和维护成本大大降低，同时，加强了巴克莱银行在同业中的竞争力及在英国的市场地位。”

2001年，荷兰银行全年交易量为1.3亿欧元，其中30%是用户通过自助设备完成的。这样大的交易量，统一的开放式应用软件开发平台所起到的作用显而易见。荷兰银行副总裁Kees Guijt先生访华时谈到：“首先对于用户来讲，所有的界面感受都是一样的；其次，我们在未来要实现新品种ATM机的时候，能够做得很快；最重要的是，在这些自助软件的开发、测试维护、问题解决方面都能够成本降低。”，Kees Guijt先生强调说，银行不能只是单从业务采购这方面去看待ATM，还应看到一整套的银行服务解决方案。

后浪推前浪

过去的10年中，在客户需求的推动下，自助设备的统一开放式应用软件平台在国际银行业被逐步接受。然而，任何一项技术都不是停滞不前的。

统一开放式软件开发平台经历了从WOSA/XFS (BSVC)到CEN/ISSS (CEN/XFS)，再到现在基于JASS技术的 J/XFS的过程。

1992年5月，由微软牵头、全球主要设备厂商参与的金融终端应用编程接口标准—WOSA/XFS（Windows Open Service Architecture / eXtensions for Financial Services——Windows开放式系统构架/金融服务扩展功能）项目开发正式启动，并于次年CeBIT展会上由西门子利多富公司做了第一个原型演示。

1996年，全球银行方案厂商委员会根据世界各地供应商提供的数据，重新规范WOSA/XFS2.0，此后直至2001年12月，完成了CEN/XFS 规范 3.0 版本——现在全球多数银行所应用的金融外设驱动的国际标准接口——并成为今天这一应用领域的一面旗帜，它将众多的国际厂商招至旗下，在此规范下开发出一系列的应用解决方案。

在随后的1997年，西门子利多富为巴克莱银行提供了全球第一套基于WOSA/XFS标准的统一开放式软件开发平台——ProTopas。

随后的几年内，由于越来越多的银行对统一开放标准的强烈需求，有更多的厂商先后开发出类似的基于WOSA标准的软件平台。

支持多供应商硬件的解决方案还仅仅是第一步；适应客户行为的变化还会带来银行自身更多的变革。

近几年，包括自动取款机、票据打印机、便利终端以及自助服务互联网终端在内的自助服务系统是目前银行使用频率最高的渠道，超过40%的客户与银行接触都是通过自动取款机进行的，正是自助设备的高使用率，推动了这一银行重要渠道的不断变革。

在世界各地，自助系统与最新的Web Services结合后，银行的客户不仅可以通过自助设备完成各种现金类交易，还可以使用现在形形色色的互联网服务，申请银行新的产品、购买银行保险保单、购买彩票等。在欧洲和美国，银行已经开始利用自助服务设备和互联网技术的结合，来处理一些可以赚取佣金的中间业务，比如在自助服务终端上播放广告以获得广告收入。

而在德国，大部分德国银行都只是把已经安装的自动存取款机和票据打印机作为单独的设备来使用，采用与互联网技术实行网络链接的银行还是市场中的“少数派”而不是市场的主流。实际上，德国目前70%的自助服务设备都可以支持接入互联网，而实际的结合比例依然不到1%。

一个可喜的现象是，现在德国许多银行都已经在转变观念，这是行动的先兆。那些因界面不兼容和标准混乱所造成的高昂成本，银行也越来越不堪重负。而那些已接入互联网的银行则看到，自助服务系统正在成为独立的销售力量，而且它们正在不遗余力地提高现有自助服务系统的价值。

在中国台湾，银行的客户也从这种技术结合中得到更多的实惠，7-Eleven便利连锁店通过金融网络化，为客户提供一系列的诸如自助缴费、信用卡借贷等增值服务。

今天，银行界已经实现了由硬件到跨操作系统的统一平台的跨越——由Sun牵头，IBM、德利多富、DeLaRue和NCR基于Java环境下开发了J/XFS——跨操作系统的新的软件平台，它为银行数据的无缝集成提供了基础性平台，适应银行应用环境的多样性，将为银行带来整合的效益。（本文作者赵锐博士 为德利多富公司大中华区软件中心总经理）

作者：赵　锐