（系统工程专业论文）银行业务软件测试研究.pdf

摘要 银行业务软件以其高复杂性、高安全性、高准确性、高效率性给软件i 1 1 4 试 带来了一系列难度。普通的软件测试过程及方法很难全部满足其要求。现有的 软件测试的研究还较缺乏针对银行业务软件的研究。本文针对银行业务软件特 点，结合测试应用现状，对银行业务软件测试进行研究。 银行业务软件测试的实际应用中，单元测试和测试评价是比较欠缺的环节， 本文主要研究适应于银行业务软件特点的单元测试方法和测试评价方法。在单 元测试申，将测试的最小单元细化到比模块更小的单元一次模块，重点研究 次模块测试方法；在测试评价中，应用目前比较成熟的满意度模型，重点研究 评价指标体系的建立和评价结果的分析。 本文首先对银行业务软件测试原理进行剖析。测试原理分银行业务软件特 点、行为特性、缺陷管理、测试分类和测试阶段五个方面进行剖析。从分析银 行业务软件的特点入手，分析银行业务软件与其他软件的不同，以及这些特点 对测试的影响，从而确定银行业务软件测试的侧重点：分析银行业务软件的行 为特性，确定测试需要重点评价的指标；对银行业务软件测试的缺陷管理进行 完善，使之更适应测试的需要；根据银行业务软件测试的分类，分别分析联机 测试、批量测试、压力测试等的测试重点和主要评价指标；分析银行业务软件 测试不同阶段的测试任务和重点测试指标。 然后针对银行业务软件测试比较薄弱的环节单元测试，将单元测试的 最小单元定义为比模块更小的单元次模块。次模块是组成模块的部分，包 含若干行源代码，不能被单独执行或者被其他模块调用次模块的逻辑复杂度 远低于模块。本文提出次模块测试方法，通过实伪说明的方式从程序次模块设 计、次模块测试设计和次模块测试执行三个方面说明次模块测试方法的使用。 再后针对银行业务软件测试十分欠缺的评价环节，提出将目前比较成熟且 简单易用的满意度模型应用于测试评价，结合一个测试实例的分析，重点在评 价指标体系建立和评价结果分析上进行了阐述。 最后对银行业务软件测试的趋势进行了展望，认为在自动化测试、可靠性 评价、可测性评价以及测试驱动开发将会成为银行业务软件测试新的发展方向。 关键字：银行业务软件、软件测试、次模块、满意度法 a b s t r a c t 低t h e s i si sa b o u tt h et e s t i n gr e s e a r c ho fb a n k i n gs y s t e m 。弛er e s e a r c hi s f o c u s e do nt h em e t h o d su s e di nu n i tt e s t i n ga n dt e s t i n ge v a l u a t i o n t e s t i n gm e t h o d b a s e do nh y p o m o d u l ei st h ek e yp o i n to f u n i tt e s t i n gr e s e a r c h s a t i s f a c t i o nm e t h o di s u s e dd u r i n gt e s t i n ge v a l u a t i o n n 圮d e s i g no fe v a l u a t es e r i e sa n dt h ea n a l y s i so f e v a l u a t er e s u l ta r et h ek e yp o i n t so f t e s t i n ge v a l u a t i o nr e s e a r c h f i r s t , t h et e s t i n gp r i n c i p l eo fb a n k i n gs y s t e mi sd i s c u s s e df r o mf i v ea s p e c t s ： c h a r a c t e r i s t i c s ，b e h a v i o rp o i n t s , d e f e c tm a n a g e m e n t ，t e s t i n gc l a s s i f i c a t i o na n dt e s t i n g s t a g e s t h eh i e 曲l o g i cc o m p l e x i t yi so n eo ft h em o s to u t s t a n d i n gc h a t a e t e d s t i c so f b a n k i n gs y s t e m i no r d e rt om a k es u f f i c i e n tt e s t i n g ，t h el o g i cc o m p l e x i t yo ft e s t i n g o b j e c ts h o u l db cr e d u c e d b a n k i n gs y s t e m st e s t i n gc o n 既晡a t e 3o nf o u rm a i n b e h a v i o rp o i n t s ：c o r r e c t n e s s ，p e r f o r m a n c e ，a u g m e n t a b i l i t ya n d r o b u s t n e s s a c c o r d i n g t ot h ec l a s s i f i c a t i o no fb a n k i n gs y s t e m st e s t i n g ，o n l i n et e s t i n g ，b a t c ht e s t i n ga n d p e r f o r m a n c et e s t i n ga l et h em o s ti m p o r t a n to n e s u n i tt e s t i n gi st h em o s ti n s u f f i c i e n t o n ea m o n gt h es t a g e so f b a n k i n gs y s t e m st e s t i n g s e c o n d , t h ec o n c e p to fh y p o m o d u l ei su s e di nt h et e s t i n go fb a n k i n gs y s t e m i n o r d e rt oi m p r o v et h eq u a l i t yo fu n i tt e s t i n go fb a n k i n gs y s t e m , t h es m a l l e s tt e s t i n g u n i ts h o u l db el i m i t e d t oh y p o m o d u l e ah y p o m o d u l ei sap a r to fam o d u l e i t c o n s i s t so fl i n e so fs o u l - e ec o d e s i t s1 0 9 i ec o m p l e x i t yi sm u c hl o w e rt h a nm o d u l e s i tc a nn o tb ee x e c u t e di n d e p e n d e n t l yo rb ec a l l e db yo t h e rm o d u l e s s o f t w a r ed e s i g n s h o u l db ea d j u s t e dt of u l f i l lt h et e s t i n go fh y p o m o d u l e w i t ht h ei l l u m i n a t i o no fa n e x a m p l e , h y p o m o d u l e st e s t i n gi sd i s c u s s e df r o mt h r e es t a g e s ：h y p o m o d u l ed e s i g a , h y p o m o d u l et e s t i n gd e s i g na n dh y p o m o d u l et e s t i n gf u l f i l l m e n t t h i r d ，t h eu s a g eo fs a t i s f a c t i o nm e t h o di nt e s t i n ge v a l u a t i o ni sd i s c u s s e df r o m f i v ea s p e e t s ：t h ed e s i g no f e v a l u a t i o ns e r i e s ，s e r i e s w e i g h t sc o m p u t a t i o n , s a t i s f a c t i o n c o m p u t a t i o na n dt h ea n a l y s i so fe v a l u a t i o nr e s u l t a ne x a m p l ei su s e dt om a k et h e d i s c u s sm o r ei n t u i t i o n i s t i ca n dc l e a r e r l 勰t ，t h et e s t i n gt r e n d so fb a n k i n gs y s t e ma r ed i s c u s s e d a u t o - t e s t i n g r e l i a b i l i t y e v a l u a t i o n t e s t a b i l i t ye v a l u a t i o na n dt e s td r i v e nd e v e l o p m e n tw i l lb et h en e w d i r e c t i o no f t h et e s t i n go f b a n k i n gs y s t e m k e y w o r d s ：b a n k i n gs y s t e m ，s o f t w a r et e s t i n g ，h y p o m o d u l e ，s a t i s f a c t i o n m e t h o d 武汉理工大学硕十学付论文 1 1 选题的目的及意义 第1 章引言 软件工程从1 9 6 8 年提出至今已经有近4 0 年了，可以说已经从“婴儿期” 走向“青年期”。软件工程的理论、方法、技术日新月异，其中软件测试的理论、 方法、技术也是层出不穷但有一些问题始终困扰着每一个进行软件开发和软 件工程研究的人s 那就是这些软件测试方法真的可以有效地保证软件测试顺利 高效地完成吗? 真的能保证被测试软件的品质吗? 软件测试是软件质量保证工程的一个重要组成部分，从软件质量的角度来 说是最关键的质量保证手段。从软件开发的瀑布模型的角度看，测试也是一个 非常重要的工程阶段为了确保设计出的软件产品的可用性和可靠性，就必须 对所开发的软件产品进行系统而全面的测试。基于这一需求，软件测试作为软 件开发过程中的一个重要阶段，受到了软件界的普遍重视并努力探索更为完善 的测试理论、技术和方法 然而，随着软件开发技术的不断发展，以及软件系统的规模和复杂性的不 断增加，传统的软件测试理论和技术已经不能很好地满足开发组织在软件质量、 开发成本以及研制周期等方面的需求。尤其在银行业，全国银行业每年投入大 量人力财力进行新系统的创建和旧系统的改造，这些系统的创建和改造支撑着 很多软件开发商的运营。但由于现在各软件开发商所使用的软件工程方法效率 低、可操作性低、缺乏系统性，缺乏对银行系统的针对性，很难适应银行系统 的复杂性，从而导致系统开发的成本蔼风险高、周期长。这些都严重影响了 其利润率，同时也加大银行企业的投入成本。 在软件的开发过程中，软件测试在开发成本中所占比例较大，通常在4 0 以上。有效解决银行业务软件测试存在的问题，降低软件测试的成本投入，提 高软件测试的品质，对于银行或是对软件开发商都是一件很好的事情。因此针 对银行业务软件的特点，研究具有针对性的软件测试方法就显得十分有必要了。 一则可以降低银行业务软件的开发成本，提高软件丌发商的利涧空间；二则可 以提高银行业务软件系统的可靠性、健壮性、可扩展性、诈确性以及性能，从 而更好地为社会服务。 武汉理t 大学硕士学位论文 1 2 国内外相关研究综述 软件测试相关的理论及方法从产生到现在已近四十年了，国内外对于软件 测试的研究主要分为测试理论、测试技术、测试评价等方面。 测试理论的研究主要分为测试管理、测试模型等方面。测试管理实际上属 于软件工程的一部分。并被纳入软件质量体系中。 ( 1 ) 质量体系 质量体系是软件管理工程的一个部分。软件过程改善是当前软件管理工程 的核心问题，5 0 多年来计算机的发展使人们认识到要高效率、高质量和低成本 地开发软件，必须改善软件生产过程。基于模型的过程改进是指用能力模型来 指导组织的过程改进，使过程能力稳定的进行改善，该组织也能变得更加成熟。 美国卡内基梅隆大学软件工程学院于1 9 8 7 年研究成功的s w - c m m ( c a p a b i l i t y m a t u r i t ym o d e lf o rs o t t w a r e ) 的目的就在于帮助软件组织改善软件生产流程，以 探索一个保证软件质量、缩短开发周期、提高工作效率的软件工程模式与标准 规范。 1 9 9 7 年1 0 月s e i ( s o f l w a r ee n g i n e e r i n gi n s t i t u t e ) 停止对c m m 的研究，改而 致力于c m m i ( c a p a b i l i t ym a t u r i t ym o d e li n t e g r a t i o n ) ，以解决使用多个过程改进 模型的问题。s e i 同时宣布c m m i 将取代c m m ，与2 0 0 0 年8 月1 1 日颁布了 c m m i - s e s w1 0 版本，2 伽1 年1 2 月颁布了1 1 版本，这次发布标志着c m m i 的正式启用。 根据c m m i 的软件生命周期，测试被分为三个阶段：单元测试；集成测试； 系统测试。这三个阶段的测试在软件生命周期盼其他主要阶段分别具有不同的 活动性。而且c m m i 充分考虑这三个阶段的测试的不同之处，分别制定不同的 操作规范。c m m i 主要从以下三个方面扩充传统的软件测试技术： 第一方面，从单纯的对软件的测试活动，扩展为软件的测试和开发过程的 度量。这一方面主要体现在过程度量对软件测试的依赖和应用。对开发过程进 行度量，需要利用软件及中间成果的测试结果，从而建立对软件缺陷和开发过 程的跟踪。从这一点来说，对开发过程的度量，实际上也就是对软件测试活动 的扩展，与传统的软件测试的不同之处就在于关注对软件测试结果数据的分析 和利用，将测试数据有效转换为能够标识过程缺陷的统计数掘。 2 武汉理工大学硕士学位论文 第二方面，软件测试由原来的事后测试行为发展为全过程测试和分析，成 为一种缺陷预防的有效方式传统的软件测试，只针对软件而开展，找到缺陷 之后再加以改正和修补，这是一种“亡羊补牢“的质量管理方式；丽针对开发 全过程所开展的软件测试和过程度量，则注重根据对测试数据的统计分析结果， 来判断软件的未来质量趋势，并提前予以控制和预防，属于一种“防患于未然” 的质量管理方式。与传统的软件测试相比，全过程测试不仅可以有效降低软件 的质量风险，而且还可以提前对软件缺陷进行规避，这不仅缩短了对缺陷的反 ，馈周期和整个项目的开发周期，而且大大降低了软件的维护费用，对于软件的 整个生命周期都有很重大的意义。 第三方面，软件测试与开发过程的其他阶段不再是串行工作方式，而是与 整个开发过程并行进行。与瀑布模型相比，c m m i 模型中所描述的软件测试和 过程度量工作与整个开发过程是并行进行的。软件测试活动存在于软件生命周、 期的各个阶段，其基本特点是以质量保证和客户要求为核心开展对软件和开发 过程的测试和度量，力争将缺陷控制在软件开发过程的每一个阶段，从而有效 缩短开发周期，降低质量风险，并且及时吸取经验教训，提供对过程改进的支 持。 ( 2 ) 测试模型 测试模型除了传统的瀑布模型外，还有v 模型、w 模型、h 模型等。 v 模型最早是由p a u lr o o k 在2 0 世纪8 0 年代后期提出的，旨在改进软件开 发的效率和效果。v 模型反映出了测试活动与分析设计活动的关系。v 模型指 出，单元和集成灏4 试应检溺程序的执行是否满足软件设计的要求；系统测试应 检澳i 系统功能、性能的质量特性是否达至口系统要求的指标；验收测试确定软件 的实现是否满足用户需要或合同的要求。 v 模型把测试作为编码之后的一个阶段，是针对程序进行的寻找错误的活 动，而忽视了测试活动对需求分析、系统设计等活动的验证和确认的功能。 w 模型由e v o l u t i f 公司提出。相对于v 模型，w 模型增加了软件各开发阶 段中应同步进行的验证和确认活动。w 模型强调：测试伴随着整个软件开发周 期，而且测试的对象不仅仅是程序，需求、设计等同样需要测试，测试与开发 是同步进行的。w 模型有利于尽早地全面地发现问题。 在w 模型中，需求、设计、编码等活动被视为串行的，同时，测试和丌发 活动也保持着一种线性的前后关系，上一阶段完全结束，才可j 下式丌始下一个 g 武汉理工大学硕士学位论文 阶段工作。这样就无法支持迭代的开发模型。对于当丽软件开发复杂多变的情 况，w 模型并不能完全解除测试管理所面临的困惑。 v 模型和w 模型均把软件的开发视为需求、设计、编码等一系列串行的活 动，而事实上，这些活动在大部分时间内是可以交叉进行的，所以，相应的测 试之问也不存在严格的次序关系。同时，各层次的测试( 单元测试、集成测试、 系统测试等) 也存在反复触发、迭代的关系为了解决以上问题，产生了h 模 型，它将测试活动完全独立出来，形成了一个完全独立的流程，将测试准备活 动和测试执行活动清晰地体现出来。h 模型揭示了一个原理：软件钡4 试是一个 独立的流程，贯穿产品整个生命周期，与其他流程并发地进行。h 模型指出软 件测试要尽早准备，尽早执行。不同的测试活动可以是按照某个次序先后进行 的，但也可能是反复的，只要某个测试达到准备就绪点，测试执行活动就可以 开展。 。 除上述几种常见模型外，业界还流传着其他几种模型，如x 模型、前置测 试模型等。x 模型提出针对单独的程序片段进行相互分离的编码和测试，此后 通过频繁的交接，通过集成最终合成为可执行的程序。前置测试模型体现了开 发与澳4 试的结合，要求对每一个交付内容进行测试。这些模型都针对其他模型 的缺点提出了一些修正意见，但本身也存在一些不周到的地方。 测试技术的研究除了对于已有的测试方法，如自盒测试、黑盒测试等，进 行改进外，目前比较突出的方向有自动测试、面向对象测试等等。 ( 3 ) 自动测试 软件测试一般分为手工测试和自动测试软件规模的扩大给测试工作带来 很多问题，手工测试的速度慢，效率低。自动测试可以高效的完成一些重复性 测试；降低人为因素对测试过程的干扰；排除测试的随机性和盲目性；降低冗 余，减少遗漏等。软件自动测试就是执行某种程序设计语言编制的自动测试程 序，控制被测软件的执行，模拟手动测试步骤，完成全自动或半自动测试。其 目的在于缩短测试周期，增强对软件性能等方面的测试能力。 自动测试也存在其局限性：第一，自动测试工具本身也是软件，其自身也 需要测试，一旦自身品质存在问题，将对整个测试的有效性和正确性带来严重 影响；第二，对于银行业务软件这种复杂的软件系统，自动测试工具很难满足 要求。所以在银行业务软件开发中，自动测试的使用一直受到很大限；雕，主要 用于压力测试等对于执行结果准确性要求不高的测试中，而对于准确性要求很 高的功能测试，仍然主要依靠人工完成。 4 武汉理- 【大学硕士学位论文 随着软件的规模和复杂度的提高，软件的质量好坏已经不可能简单通过测 试所发现的缺陷多少来判断了，这便把测试评价的研究推上了日程。另外为了 更有效地进行测试，在软件可靠性评价和可测性评价方面也有所发展 测试评价严格意义上来讲。不只是对测试的评价。应该是对软件的品质及 整个测试过程的评价。在实际应用中，软件企业虽然十分重视测试的进行，往 往投入4 0 的成本进行测试，但是在对测试的评价方面却仍然停留在比较初级 的阶段，主要使用的有缺陷走趋图、缺陷严重程度分布图和一些简单的统计数 据分析等方法，而且基本依靠个人经验判断和简单的趋势分析。比如，通过缺 陷走势图和缺陷严重程度分布图可以很清楚看出软件缺陷的走向和分布情况， 对于测试评价有一定帮助。但是存在指标量化不足，评价指标过于单的缺点， 重复操作性低，在实际使用中对进行测试评价的人员要求很高。 ( 4 ) 软件可靠性评价 软件的可靠性是指软件系统在特定的环境下，在给定的时间内，不发生故 障地工作的概率。软件可靠性是评价软件质量的一个重要指标。软件可靠性评 价主要通过建立软件可靠性模型来实现。软件可靠性模型是随机过程的一种表 示，通过这一表示，可以将软件可靠性或与软件可靠性直接有关的量，如平均 无故障时间或故障率等，表示成时何、软件特性以及开发过程的函数。软件可 靠性模型从1 9 5 6 年首次出现至今，已经发展许多不同的模型，比如z j e l i n s k i 和p m o r a n d a 于1 9 7 2 年提出的j m 模型、a l g o e l 和k o k u m o t o 于1 9 7 9 年提 出的g - o 模型、w d b r o o k s 和r w m o t l e y 于1 9 8 0 年提出的i b m 泊松模型等 等。这些模型大多建立在软件失效率服从某种分布的假设条件下，比如j m 模 型假设失效率与软件中的剩余缺陷数成正比；g - o 模型假设失效率呈指数衰减。 由于软件逻辑结构的复杂性、测试行为的复杂性、以及失效模式的复杂性，软 件可靠性模型的基本假设一直存在许多争论，模型在实际应用中也存在预测精 度低、一致性差等问题。而且这些模型的使用十分复杂，这些因素都使得软件 可靠性评价在实际应用中受到限制。 ( 5 ) 软件可测- i 生评价 软件的可测性已逐渐成为软件开发、测试及可靠性评价过程中需要考虑的 一个重要指标。软件可测性是在软件中存在错误的情况下，垓错误引起软件失 效概率的一种估计，它是对软件测试工作难易程度进行衡量的一个标准，对测 试资源的分配、软件测试程度等起着重要的指导作用。已有的软件可测性分析 方法主要有：基于程序运行的动态分析方法，是在软件测试结束时，用测试过 5 武汉理t 大学硕七学位论文 程中使用的测试用例数目表示软件的可测性，这种评价方法的代价较高，且不 能很好地对测试工作的进行起到指导作用ld r r ( d o m a i nr a n g er a t i o ) 方法， 用d o m a i n 表示一个程序的输入值的范目。r a n g e 表示一个应用程序的输出值的 范围，用d o m a i n 与r a n g e 之比表示程序的可测性，它是一种静态度量方法，代 价较小，但没有考虑到程序的控制流、数据流结构，不能很好的刻画软件在包 含错误的情况下，该错误引起程序失效的概率；基于d a - c f g ( c o n t r o lf l o w g r a p h i c ) 的软件缺陷的执行概率估计，从软件失效机理出发，对几种概率进行 分析，包括造成软件失效的软件缺陷执行的概率、软件缺陷导致数据状态发生 变化的概率和改变了的数据状态传播到输出的概率等。 1 3 研究内容和研究方法 现有的软件测试的研究还较缺乏针对性研究。在商务活动中要求做到 o n e 2 0 n e 的个性化服务，而在软件测试却少有针对银行业务软件的测试研究。 在众多的软件系统中，银行业务软件以其高复杂性、商安全性、高准确性、高 效率性给软件测试带来了一系列难度。普通的软件测试过程及方法很难全部满 足其要求。一些专门从事银行业务软件歼发的企业在长期的生产实践中摸索出 一些软件测试过程和方法。但这些方法存在很大局限性：第一，这些方法只针 对本企业的特点，如果用于其他企业，将失去其作用，变得无法操作；第二， 量化不足，在执行过程中难以准确控制；第三，缺乏有效的测试评价模型，结 果的评价基本靠分析者个人魅力，从而造成结果分析的不准确性或者误导性。 银行业务软件测试的实际应用中，单元测试和测试评价是比较欠缺的环节， 本文主要研究适应于银行业务软件特点的单元测试方法和测试评价方法。在单 元测试中，将测试的最小单元细化到比模块更小的单元次模块，重点研究 次模块测试方法；在测试评价中，应用目前比较成熟的满意度模型，重点研究 评价指标体系的建立和评价结果的分析。 本文首先对银行业务软件测试原理进行剖析。测试原理分银行业务软件特 点、行为特性、缺陷管理、测试分类和测试阶段五个方面进行分析。从分析银 行业务软件的特点入手，分析银行业务软件与其他软件的不同，以及这些特点 对测试的影响，从而确定银行业务软件测试的侧重点；分析银行业务软件的行 为特性，确定银行业务软件测试需要重点评价的指标；对银行业务软件测试的 缺陷管理进行完善，使之更适应测试的需要；根据银行业务软件测试的分类， 6 武汉理工大学硕十学位论文 分别分析联机测试、批量测试、压力测试等的测试重点和主要评价指标；分析 银行业务软件测试不同阶段的测试任务和重点测试指标。 然后针对银行业务软件测试比较薄弱的环节一单元测试，提比将单元测 试的最小单元定义为比模块更小的单元次模块以及相应的次模块测试方 法。通过实例说明的方式从程序次模块设计、次模块测试设计和次模块测试执 行三个方面说明次模块测试方法的使用。 再后针对银行业务软件测试十分欠缺的评价环节。提出将目前比较成熟且 简单易用的满意度模型应用于测试评价，结合一个测试实例的分析，重点在评 价指标体系建立和评价结果分析上进行了阐述。 最后对银行业务软件测试的趋势进行了展望，认为自动化测试、可靠性评 价、可测性评价以及测试驱动开发将会成为银行业务软件测试新的发展方向。 7 武汉理工大学硕士学臂论文 第2 章银行业务软件测试原理 软件涣f 试直接关系到软件的质量，软件测试是软件质量保证的关键因素。 这是很多人很容易理解的观点。但很长一段时期以来测试总被人所误解，认为 测试发现衄题则证明开发人员不很擅长他们的工作，是工作品质不高的表现。 其实软件测试的主要目的就是发现错误。一个能够充分发现错误的测试才是成 功的测试。一次测试没有发现任何错误，并不一定能说明测试对象的品质多么 高，相反只能说明这次测试是失败的。所以软件测试人员的目标就是设计测试， 使它能以最少的时间和人力投入系统地发现不同种类的错误。测试额外的收获 才是通过测试结果的分析，可以对测试对象的一些行为特性作出评价，比如其 可靠性、正确性、性能等等，从而在一定程度上表现测试对象的品质。 在银行业务软件的开发过程中，软件测试普遍存在投入高、周期长的现象， 有的项目用户验收测试就长达半年之久。这是因为银行业务软件与普通软件系 统相比，有它自己的特点，这些特点决定了银行业务软件的测试在侧重点、评 量指标与普通软件存在差异性，不能完全照搬普通软件测试方法。为了能够充 分认识银行业务软件测试，就必须先认识银行业务软件的特点。 2 1 银行业务软件特点 银行业本身是一个十分特殊的行业，作为银行业务开展的工具银行业 务软件也具有与普通软件系统不同的特点 ( 1 ) 规模巨大 银行业务软件，尤其是银行核，i i , 业务软件，其程序数量通常在千个以上， 多者上万；平均代码行数上千甚至上万；总代码行数多在十万以上；软件开发 总人力投入多在1 0 0 人年以上。 银行业务软件背后的数据舰模也是十分惊人的。一家银行的分户帐就多在 百万以上，多者可达数千万；银行每天所做的每一笔交易都要求有相应的明细 记录，以规模相对较小的邮政储蓄银行为例，一个地级市的日交易量可达数力 笔，这也就意味着每天至少有几万条明细记录产生。一天几万笔记录，一年就 可达到几百万笔。更何况银行系统的数掘是不允许随便清除的，日积月累，其 数掘量可想而知。 8 武汉理t 大学硕十学位论文 当一个软件的规模达到一定程度，对软件开发的技术和管理都是一个严峻 的考验。 让) 业务复杂 银行业务种类繁多，如基本的储蓄业务、对公业务以及后来的中间业务。 从数量上就有几十上百种之多 各个业务之间关系复杂，比如现在种类繁多的中间业务，大多都要求核心 的储蓄业务支持，因为中间业务本身不能修改储户分户帐。必须通过储蓄业务 的接口来修改，这就意味着一种新的中间业务的上线就会导致储蓄业务的修改。 银行业务软件计算单纯，基本在加减乘除运算范围内，但是逻辑结构复杂。 这一点从银行业务软件最常用的开发工具就可以看出。c o b o l 是银行业务软件 开发最常用的开发语言，它的特点之一就是算数计算量少而逻辑处理量多。逻 辑结构的高复杂度给常规软件测试所使用的白盒测试和黑盒测试等方法带来了 极大障碍。例如，一支程序有十个逻辑判断，那么要对这支程序进行充分测试， 至少需要1 0 2 4 个测试用例。而对银行业务软件来讲，十个逻辑判断并不算多 所以要对银行业务软件进行充分测试，首先要考虑降低测试对象的逻辑复杂度。 ( 3 ) 交易多样 银行业务软件中执行一个完整的功能多称为交易。根据其不同特性，对交 易进行了不同划分 根据交易的响应时间分为联机交易和批量交易联机交易要求响应时间很 短，一般要求控制在5 秒以内，如一般的柜台业务就属于联机交易；而批量交 易则对响应时间没有要求，多用于大数掘量的批次处理，如银行夜晚进行的总 分核对。 根据交易的处理性质分为正常交易、取消交易、冲正交易、调帐交易。正 常交易是指正常进行的交易，这占交易量的绝大多数；取消交易则是在正常交 易执行之后发现有错误，需要取消这笔交易，则启动相应的取消交易，使交易 状态回复到正常交易执行之前的状态，这种交易多要求在正常交易执行的当天 完成；冲正交易的功能与取消类似，但是冲正交易多发生在正常交易执行的次 日以后，此时已经涉及利息计算等问题，所以不能简单地取消此交易，冲正交 易则应运而生；调帐交易则是发现帐务不对，但并不知道是哪笔正常交易造成， 则由调帐交易来对帐务进行调整从而使之下确。 9 武汉理t 大学硕七学位论文 根据交易是否影响帐务分为帐务性交易和非帐务性交易。帐务性交易是银 行业务中十分重要的一部分，它涉及帐务的修改，如存款、取款、转帐等都属 于帐务性交易；非帐务性交易则不对帐务迸行修改，如查询、打印存折等。 根据交易所涉及的单位不同分为本地交易、异地交易，甚至还有跨行交易。 有的银行还会把异地交易进一步区分为同城交易，跨市县所交易、省内异地交 易、省际异地交易。这里异地交易是指交易发生的地点与交易涉及的帐户自辱开 户地不相同。由于异地交易涉及银行的不同清算单位。所以会有这些清算单位 之间的资金清算，此类交易处理会比本地交易要复杂很多。跨行交易还涉及银 行与银行之间的资金清算，这也会增加交易的复杂度。更为复杂的情况是跨行 转帐交易，它所涉及的清算单位有可能涉及三家不同银行，这一类交易的处理 至今都还存在一些争议 交易多样性在增加系统复杂度的同时，也增加了程序韵逻辑复杂度，进而 增加软件测试的困难。 ( 4 ) 应用独立 通常所指的银行业务软件是针对银行业务的需求而开发的应用软件，是区 别于系统软件的银行业务软件的开发只需要关心业务处理，而不必关心数据 存储、网络通讯、安全控制等底层细节处理。这是因为银行业务软件一般都运 行在一种交易平台上。例如c i c s 、t u x e d o ，以及曾经风摩一时的t p e 。这些 交易平台实际属于一种中间件，它们的作用就是隔离应用程序与系统底层处理， 如数据存储、网络通讯、安全控制、进程调度等，使得应用程序的开发变得比 较单纯，只需要关心业务逻辑，同时也增加了银行业务软件的可移植性。 银行业务软件的应用独立性大大减少了测试工作量，在实际中不必专门对 系统底层的处理进行测试。 ( 5 ) 要求严格 银行业务软件的开发要求是非常严格的，尤其是安全性和计算准确性这方 面。比如，利息计算，要求在计算过程中保留小数点后三位，最终计算结果保 留小数点后两位。 银行业务软件对于输入输出部有明确的规定，所以测试中对输入输出的检 查也是十分严格和明确的。 1 0 武汉理r 火学硕士学伊论文 强疆产鑫壤 产品是指在基本功能不改变或者改变不犬的情况下一个产晶的发展。银行 业务软件不是产品。因为不同银行的业务软件之问存在很大差弗，不可能简单 建瑟一豢镟孬熬鳖务软终移接蘩舅一家疆孬。豢至嚣一家锻簿苓嚣建嚣豹分孬 所使用的业务软件都存在很大差异性。所以银 亍此务软件不可能作为产品来开 发，柏殿多采用定制开发，即软件歼发商根据具体的银行需求m 来重新开发。对 手测试髓富，一个锻纷蝗务软件爨使蔫豹测试瘸钢是不可能焱接用于其健锻行 韭务软释的溅试嚣。勉何有效提高灏试用铡的重掰度也是一个德得研究静瀚题。 测试用例重用度的提商将降低对软件测试的成本投入，而且使得软件测试襁 定程度上满足可重复饿，使其可操作性得以提麓。 2 - 2 银行业务软件行为特性 ( 1 ) 爨用性 实稍性是指一个缆确的软件程娩格说明所允许的条件下运行时满足用户需 求的程度由于银行业务软件多采用定制开发，歼发的依据就是特定用户的需 求，正确拜发出来的锭行业务软 孛定是满足髑户需求的所以不必对银褥妲 务软箨豹实孺毪产生酶疑。 ( 2 ) 研靠性 彰嚣性是黠软撵蛾效簿熬簇率张严重栏豹度霪。故障是软终在宠诲懿揉传 条释下聪行对产生的不可接受酌缩莱或行为，敬降通常霆由硒趣带来的。软伟 的可靠性可以通过故障发生的频率和故障所带来影响的破坏程度来度量。戴中 破坏程度可以通过问题修改时间和破坏结果修笈时阊来度量。 银行谴务软箨要求有赛豹可靠瞧，鲡谤绦漩矮可靠往，绒者妇 莓评赞熊可 靠性，都是银行业务软件测试中值得研究的问题。 o ) z e 确性 麴祭一个软释程允许的条件下运行对能潢怒输出规搭说明，劐称这个软件 是j 下确的。换句话说，如果给软件提供了满足输入舰格的输入和软件所需的所 有资源，而最终的输出符合输出舰格说明，则称这个软件是藏确的。 武汉理【大学硕十学付论文 正确性是银行业务软件测试中使用最广的一个度量指标因为银行业务软 件的一个特点就是对每一个功能的输入输出都有明确的要求，这个要求甚至细 致至输入输出数据的类型、长度以及位置。 h ) 健壮性 健壮性是指在异常情况下，软件能够正常运行的能力。正确性描述软件在 需求范围之内的行为，而健壮性描述软件在需求范围之外的行为。健壮性包含 有两层含义：一是容错能力，二是恢复能力。 ( 5 ) 性能 性能是指软件对于响应时间和环境要求的约束条件的满足程度。比如，银 行业务软件中联机交易要求响应时间不超过5 秒。由于银行业务软件运行的环 境相对是固定的，所以度量其性能的指标就集中在响应时间上了r f ( 6 ) 可扩展性 可扩展性反映软件适应“变化”的能力。在软件开发过程中，变化包括需 求的变化、设计的变化、算法的改进、程序的变化等等。由于设计和编码不是 本文讨论内容，所以假设设计和编码都是正确的。这里要讨论的主要是需求的 变化。需求变更是否处理是有一定判断标准的，本文讨论的需求变更都是需要 处理的。可以通过需求变更的影响范围和处理时间来衡量软件的可扩展性。 ( 7 ) 其他特性 软件测试需要衡量的行为特性还包括安全性、易用性、清晰性，兼容性和 可移植性。但对于银行业务软件，安全性是由交易平台来控制；是否易用是眭 用户需求决定的；银行业务软件都是针对特定用户、特定环境进行定制开发， 所以在兼容性和可移植性上不会过多考虑，相反更多的情况是要求软件更好地 适应特定的环境。 以上对银行业务软件的行为特性的分析，将为银行业务软件测试的评价提 供很好的依据。 2 3 银行业务软件缺陷管理 软件测试管理中一个十分重要的环节就足缺陷管理。缺陷就是指软件不满 足测试预期的地方，也常称之为问题，后面部沿用问题这一称呼。由于银行业 1 2 武汉理工大学硕士学位论文 务软件规模大，测试工作量大，测试过程中产生的问题数量较大，这就使得缺 陷管理尤为重要 测试的目的是发现问题，但只发现问题是不够的，还必须解决问题，而且 必须对问题的状态进行跟踪，也就是必须对软件缺陷进行管理。为了有效地对 问题进行跟踪，按照其特性将问题进行分类： ( 1 ) 程序错误( p r o g r a me rr o t ) 此类问题是由程序设计或者编码有误而导致的程序不能正确实现要求的功 能，是必须修正的问题。 ( 2 ) 需求变更( c h a n g er e q u i r e r n e n t ) 此类问题是由于用户改变需求或者提出新的需求而产生的。 、 ( 3 ) 操作错误c u s l u re r r o r ) j 此类问题是由于测试执行者( 或者软件的用户) 操作有误所导致，比如输 入不合乎要求的数据、不按要求顺序操作等等。 ( 4 ) 环境错误( e n vir o n m e n te r r o r ) 此类问题是由于环境配置不正确或者不满足软件运行要求所导致自钆比如 要使用的数据库没有建立、网络不通、要用到的参数没有配置等等。 问题还应区分其严重程度。按问题的严重程度划分为一般( m i n o r ) 、重要 ( m a j o r ) 、紧急( u r g e n 咖不同严重程度的问题的评量权重应该是不同的。 问题的跟踪主要是对其状态进行追踪，所以对于问题的不同状态必须定义 清晰。在银行业务软件测试中将问题按其处理状态戈! 1 分为新增( r e c e i v 就1 ) 、处理 q b ( a s s i g n e d ) 、处理完毕( f i n i s h e d ) 、关闭( c l o s e d ) 、取消( c a n c e l e d ) 。当某次测试 新发现问题则为新增：当该问题被确认并提交修改人进行修改后则为处理中状 态；修改人修改且调试完毕则进入处理完毕状态；经过重测后问题不再存在， 则进入关闭状态；如果问题被分析确认后不予处理或不是问题，则为取消状态。 由于测试一般都是按轮进行，所以每一轮测试的评价必须区分问题的状态，比 如新增问题多少、关闭问题多少等等。对于相同问题重复出现不记录新的问题， 只是标识该问题为重复出现及重复出现的次数。 在测试执行之前，比如在测试规划阶段，必须确定测试对象的范围和规模， 比如测试对象的代码行数、本底数据量、所使用的测试用例数，并且需要对测 试对象可能存在的问题数量进行估计。可能问题数量可以简单地用代码行数每 1 3 武汉理1 ：= 大学硕士学静论文 学筏璐产生阂题戆糕孥寒诤算。鼙予每霉筏羁产生溺题赘穰搴霹戳逶j 童掰雯数 据推算藏者请专家估计。 测试执行中的一项重要工作就是对问题进行跟踪记录问题的跟踪记黎必 须挺袋足够充分戆蕊惑，毙弦羯戆产生簿蘩霹芙溺嚣弱，弱簇豹紧急程霞，阉 题的类迥等等。本文对问题的跟踪记录主要内容定义如表2 - 1 。 痿豫 谥爱 问题编弩为每一个褥蹶分配一个编弩，以便跟踪。 问题来源 问题来自什么地方，是联机交易还是批晕襁序 问题描述对问题现象进行描述。 产生鑫瓣舞蘧发现静瓣期 问题类型。问题的类型，可选范围为： ? c r 需求变更，p 卜程序错误，u 嘣作错误，e 哪墩错误 严垂群发闽题的影响黟垂程痊，可选藏睡为： m 轴o f - 普潺，n 蠲o r - 一重要，u r g e n t - - 紧急 问题状态r e c e i v e 蝴增 a s s i g n e d - - - 简l 题己提交修改 f i n i 盎e 矗一辏浚究残等埒重溅 c l p 扣重测正常，关颟闷题 c 鲫c e l l e d - - - 取消问题 修改入负责对鳃题进行修改的人 穆改嚣期| 霉嚣提交罄菠豹器藕 修改工时修改问题所耗费的人力，用= 【时来计算 修改说明修改方案说明，包括如何解决问题、修改明5 嫂模块等等 螽注替态说明信慧 对于每个测试发现的问题都必须全程跟踪。问题的处理流程可见图2 l ： 1 4 武汉理工大学硕+ 学位论文 图2 1问题跟踪处理流程图 测试执行人员在执行测试过程中一旦发现问题( 测试结果与测试用例预期 不符) 必须马上填写测试问题单，填入测试对象、测试用例、问题现象等信息。 如果问题不影响测试继续进行，则定期将测试问题单汇总给测试管理人员i 如 果此问题影响测试继续进行，则必须马上提交测试问题单给测试管理人员，从 而进入问题处理流程。 测试管理人员在收到测试阎题单后对问题单内容进行登记，此时所有收到 的问题单的状态均为r e c e i v e d ( 新增k 登记完成后测试管理人员将问题单分发 给问题分析人员，由问题分析人员来对问题进行分析以确定问题的分类、严重 程度以及处理方案，并进行问题修改任务的分派。这些信息同时会反馈给测试 管理人员。测试管理人员会根据问题的定性和处理分派相应地更新问题单的状 态。 问题修改人员在接到问题修改的任务后，着手对问题进行修改，包括源代 码、文档的修改以及单元测试。修改工作完成后问题单将回到问题分析人员进 行审核。审核后的问题单再回到测试管理人员统一存档。此时测试管理人员将 问题单状念登记为f i n i s h e d ，并登记修改人、修改所用工时等信息。 处于f i n i s h e d 状态的问题单将会安排重测，或者等待下一轮测试。如果问 题现象不再存在，则此问题单将转入c l o s e d 状态；否则仍然回剑问题处理流程。 1 5 武汉理1 = 大学硕七学位论文 上述流程会花费额外的人力。这些花费是十分有必要的。如果对问题单控 制不严格，或者对问题的修改控制不严格，将会严重影响测试的效果，或者导