qileilove

blog已经转移至github,大家请访问 http://qaseven.github.io/

银行业务软件测试评价研究

  摘要:运用系统工程方法,结合银行业务软件的特点,为银行业务软件的测试建立指标体系,用层次分析法确定各指标的权重,并用可能-满意度法计算各指标的满意度,最后通过计算综合满意度对测试作出评价。

  关键词:银行业务软件   软件测试评价

   而众多的软件系统中,银行业务软件以其高复杂性、高安全性、高准确性、高效率性给软件测试带来了一系列难度,尤其是在测试评价方面,仍然停留在比较初级 的阶段,常见的方法有缺陷走势图、缺陷严重程度分布图等等。这些方法可以很清楚看出软件缺陷的走向和分布情况,对于测试评价有一定帮助。但是这些方法存在 指标量化不够,评价指标过于单一的缺点,重复操作性低,在实际使用中对进行测试结果评价的人员要求很高等问题,从而影响评价的效果。

  本文运用系统工程方法为银行业务软件的测试建立指标体系,用层次分析法确定各指标的权重,并用可能-满意度法计算各指标的满意度,最后通过计算综合满意度对测试作出评价。

  一、评价指标体系建立

  要对软件测试结果进行评价,软件的行为特性,如可靠性、正确性、健壮性、可扩展性和性能等,是最基本的指标。但由于银行业务软件的行为特性比较抽象,难以量化,不能直接作为评价指标,必须对之建立量化的子指标。在实际测试中最容易量化的就是测试用例数、程序代码行数、问题修改时间、程序响应时间和测试问题数以及数据量、交易量。

   程序响应时间和数据量、交易量可以对程序性能作出评价,而问题数量及问题的修改时间则可以对程序的可靠性、健壮性、可扩展性、正确性进行很好的评价。不 同严重程度的问题对测试结果的影响是不一样的,比如一般问题可能对程序正确性影响不大,而紧急问题却可能导致程序无法运行从而对程序正确性造成严重影响。 所以对于程序正确性的评价必须区分一般问题、重要问题和紧急问题。

  除了问题的严重程度外,一定测试阶段内程序错误问题的新增数量、关闭数量和总数都是很好的评价指标。总数决定了问题发现是否充分;关闭数量反映了问题修改的速度;新增数量则很容易反映出问题修改的质量。

   每一种数量还要区分绝对数量和相对数量。这是因为在一个100行的程序和一个10000行的程序之间直接比较问题个数是没有意义的。相对数量是指某类问 题数占问题总数的百分比。还有估计相对数量是指某类问题数占估计问题总数的百分比。至于使用绝对数量还是使用相对数量作为评价指标,可视具体情况而定,或 者综合考虑两方面指标。

  除了定出指标外,还需要为这些指标定义满意度范围,从而定义满意度函数。这可以通过历史数据统计和有经验的专家估计来确定。

  根据上述分析结果,结合银行业务软件的特点,将银行业务软件满意度确定为评价的总体目标(O),将其可靠性、健壮性、可扩展性、正确性和性能定为一级指标(即准则层A),然后再进行分解细化,构造出一个评价指标目标树。

  1、正确性

  程序的正确性可以用程序错误问题的数量及问题的处理时间来评价。

  程序错误数量主要考虑测试期内新增数量、关闭数量和总数量。

  问题处理时间是指程序错误类的问题从产生到关闭所花费的人力。由于问题的处理必须考虑到修改对象的复杂度,所以还需要评价平均修改时间,也就是处理时间/修改对象的复杂度(本文中采用代码行数)。问题处理时间可以直接标准化后使用,也可以为其定义满意范围。

  2、健壮性

   健壮性是指在异常情况下,软件能够正常运行的能力。这一能力的评价在实际中难以量化,但可以通过对异常情况下,软件不能正常运行的情况进行评价。所以对 于健壮性可以采用输入错误、操作错误和环境错误的数量来衡量。由于银行业务软件对输入数据的检查在用户需求中有明确的要求,所以输入错误的情况统一归入程 度错误而作为正确性的评价指标。那么评价程序健壮性的就剩下操作错误数量和环境错误数量两个主要的指标。

  3、可扩展性

   程序的可扩展性主要体现在需求变更的处理上。需求变更包括对已有需求的改变和新需求。需求变更的影响范围和需求变更的修改时间可以对程序的可扩展性进行 很好的评量。实际上需求变更的影响范围也可以通过修改时间来衡量。那么对程序可扩展性进行评价的主要就是需求变更的平均修改时间。

  4、可靠性

  凡是测试出现问题(需求变更除外)都认为对程序的可靠性有影响,所以可靠性的评价指标主要就是除了需求变更外的所有问题的数量及问题的平均修改时间。

  5、性能

  对于性能的评价最主要的指标就是程序响应时间。程序响应时间的评价也必须区分绝对时间和相对时间。绝对时间就是指不考虑环境因素影响,而只考虑 程序本身执行的响应时间,比如对于联机测试,程序响应时间控制在5秒以内。相对时间是指考虑环境因素影响,如本底数据量、并发交易量等,对程序响应时间做 相应的平均处理,比如单位本底数据量程序响应时间、单位并发交易量程序响应时间。

  二、指标权重确定

  本文采用层次分析法来确定各指标的权重。

  1、判断矩阵建立

  组建专家团对目标树同层次各项指标,按其在上一层指标中的重要性,进行两两间重要程度比较建立判断矩阵:

  2、相对重要程度的计算

  由于测试评价不需要十分精确的权重计算,所以本文直接采取简单易理解的求和法来计算各指标的相对重要程度。当然也可以直接借助现有的计算软件来进行精确的计算。

  首先将判断矩阵按列归一化:

  然后按行求和:

  最后再进行归一化:

  3、一致性检验

  由于判断矩阵的产生带有很大主观性,往往出现判断的不一致。所以必须对判断矩阵的一致性进行检验。

  首先求取最大特征根:

  计算一致性指标:和一致性比值:

  如果 ,则该判断矩阵的一致性是可以接受的。

  三、满意度计算

  首先根据已经收集的测试数据对最底层指标计算满意度。例如,针对联机测试,评价性能的子指标响应时间的满意范围为[3,30]且满意度递减,那么这个指标的满意度表示如下式:

  经测试联机交易的平均响应时间为5秒,用上式计算可得响应时间的满意度为:

  将同一层的各评价指标的满意度计算加权和,得到上一层评价指标的满意度数值。如果一个评价指标有子层评价指标,那么它的满意度可以直接使用子层 评价指标的加权满意度和,也可以对加权满意度和再按此指标的满意度表达式计算满意度。例如对于指标联机交易性能,其子层评价指标的加权满意度和为0.9, 这个满意度值可以直接反映到更上一层指标的满意度中;如果为它定义满意范围为[0.5,1.0]且满意度递增,那么经计算后可得联机交易性能的满意度为 0.8。

  满意度的计算一直往上直到最终的目标层。

  四、评价分析

  经过满意度计算后,评价指标树中各层评价指标都会有其满意度值。可以直接通过判断目标层的满意度,来判断对本次测试的结果是否满意。如果总体不满意,则可以从上至下逐层检查是哪些指标导致总体满意度偏低。

  五、总结

  本文结合银行业务软件的特点,为银行业务软件测试评价建立评价指标体系,使用层次分析法计算各指标的权重,并用可能-满意度法对测试结果进行评价。

  本文所论述的测试只限于测试阶段,其实按照W模型的思想,测试是贯穿整个软件工程流程的,比如在需求分析阶段就必须为系统测试作准备,在概要设 计阶段就必须为集成测试作准备。而且测试不只是针对软件进行,还包括每一阶段的工作成果,如需求规格、设计规格等等。但由于对这些工作成果测试研究还不够 成熟,在实际运用中可操作性不强。这方面理论和技术的发展将会使银行业务软件的测试更加完善和高效。

posted on 2012-09-17 10:03 顺其自然EVO 阅读(364) 评论(0)  编辑  收藏


只有注册用户登录后才能发表评论。


网站导航:
 
<2012年9月>
2627282930311
2345678
9101112131415
16171819202122
23242526272829
30123456

导航

统计

常用链接

留言簿(55)

随笔分类

随笔档案

文章分类

文章档案

搜索

最新评论

阅读排行榜

评论排行榜