金融科技软件自动化测试用例的冗余评价和削减方法

龚 鑫, 徐立华, 窦 亮, 赵瑞祥

（1. 华东师范大学 计算机科学与技术学院, 上海 200062; 2. 上海纽约大学 工程与计算机科学部, 上海200122; 3. 中汇信息技术(上海)有限公司, 上海 201203）

0 引 言

金融科技指服务于金融领域的计算机技术, 是技术驱动的金融创新, 在金融机构中发挥了重要的作用, 受到来自金融、软件领域学者的广泛关注. 据相关统计, 2019 年全球在金融科技领域的投资金额达到了1 054 亿美元[1]. 金融科技的软件系统通常涉及关键的金融业务, 任何程序缺陷或者错误操作都可能导致巨大的经济损失. 由于金融科技软件往往包含复杂的金融业务逻辑, 测试用例的字段之间具有复杂的约束关系, 因此金融科技软件的测试任务往往需要耗费较高的时间成本和人力成本.

为了确保金融科技软件的质量, 同时降低软件测试的成本, 学者们[2-3]提出了一系列自动化测试用例生成方法 (Test Case Generation, TCG), 这些方法能够在一定的条件下, 快速、自动地生成测试套件. 然而, 自动化测试用例生成方法往往以达到更高的代码覆盖率或者更大的变异分数为目标, 倾向于生成数量更多的测试用例, 未考虑到可能引入的冗余因素, 因此极易造成测试冗余问题. 如果从测试套件中剔除一部分测试用例, 整体的测试质量并不受到影响, 就表明存在测试冗余问题[4]. 测试套件中的冗余因素将提高测试执行环节的成本, 并导致测试用例的管理变得更加困难[5].

本文对实际的金融科技软件 (由中汇信息技术 (上海) 有限公司提供的外汇交易系统下的软件构件) 进行了研究, 发现确实存在测试用例过多的问题, 并且难以使用人工方法高效地判断其冗余程度.这个交易系统为银行间外汇市场、货币市场等提供发行服务、交易服务、交易后处理服务、信息咨询服务以及技术服务, 具有庞大的体量. 系统在测试过程中使用了针对金融科技的两种测试用例生成方法: FACTS (Automated BlaCk-box Testing for FinTech Systems)[2]和FinExpert[3], 这两种方法虽然能够生成覆盖率足够高的测试套件, 但是所生成的测试套件十分庞大, 会引入一定的冗余因素. 在实际的测试环节中, 测试人员更关注业务功能的覆盖情况, 即业务代码能否被测试用例覆盖的情况, 因此, 如果能够通过代码覆盖率对测试冗余进行评估, 这样的评估方法对于金融科技软件来说就具有较理想的实际应用价值.

针对金融科技领域的软件测试环节, 本文提出了最佳覆盖项冗余指标MVI (Most Valuable Item),这是一种基于覆盖率的测试冗余评价指标, 能够对测试套件的冗余因素进行量化. MVI 指标关注程序代码的覆盖项, 并通过覆盖项对测试套件的整体冗余情况进行评估. 为了验证MVI 指标的有效性, 本文进一步提出了一种基于MVI 指标的测试用例削减算法MVIR (Most Valuable Item Reduction). 实验结果显示, MVIR 能够在保证测试性能损失小于9.20%的前提下, 实现大于89.88%的测试用例削减比例, 同时证明了MVI 指标能够有效反映测试套件中的冗余程度. 最后, 使用MVI 指标对FACTS 和FinExpert 这两种测试用例生成方法的冗余程度进行了评估, 结果显示, 这两种方法在生成测试用例的同时会引入较多的冗余因素. 同时, 实验结果发现, MVIR 能够对FACTS 和FinExpert 这两种方法所引入的冗余因素进行有效消解, 将自动化测试用例生成方法与测试用例削减算法相结合, 能够生成质量较高、冗余程度较低的测试套件.

1 相关工作

1.1 测试冗余问题

测试冗余不是一种确切的测试缺陷, 而是一种能够揭示程序潜在缺陷的代码特征. 测试冗余会影响测试套件的可读性与可维护性, 降低测试质量[6]. 产生测试冗余的根本原因, 往往是开发阶段和测试阶段的重复编码, 或者软件代码的变更[4,7-8].

测试冗余问题一直以来受到学者们[7,9-13]的广泛关注, 各类针对测试用例削减技术的研究都对该问题进行了讨论. 测试用例削减技术以减少测试套件中的冗余因素为目标, 主要关注测试用例层面的冗余值, 通常将测试用例区分为“冗余”和“不冗余”两类, 在削减的过程中剔除“冗余”测试用例, 只保留“不冗余”测试用例. 部分文献[4-5]将测试用例的冗余值进行了粒度更细的区分, 并且在削减的过程中,优先删除冗余值较高的测试用例. Koochakzadeh 等[4]基于“语句覆盖”“分支覆盖”“条件覆盖”和“循环覆盖”这4 类代码覆盖率, 提出测试套件冗余指标, 该指标对测试用例之间的相交覆盖项进行分析,并以相交覆盖项数量的百分比作为测试用例的冗余值, 将冗余值为0 的测试用例视为不冗余的, 冗余值大于0 的测试用例视为冗余的. 实验结果显示, 仅仅使用上述4 种覆盖率指标, 对测试用例的冗余判断精确度较低. Koochakzadeh 等[4]建议应该使用更多样化的覆盖率准则进行更细致的冗余指标计算. Marijan 等[5]提出了一种方法, 即在高度可配置软件的持续集成测试环节中, 使用配置选项覆盖率指标和历史的缺陷信息作为冗余指标, 将所有测试用例分为“完全冗余”“部分冗余”和“不冗余”这3 类, 删除“完全冗余”的测试用例, 保留“不冗余”的测试用例, 并根据是否发现新的缺陷, 对“部分冗余”的测试用例进行选择性的保留. 实验结果显示, 该方法能够在不明显降低测试套件的缺陷检测能力的情况下, 有效地缩短回归测试环节的测试执行时间.

Koochakzadeh 等[4]与Marijan 等[5]提到的方法能够在一定程度上对套件的冗余程度进行度量, 但仍具有提升空间. Koochakzadeh 等[4]的方法虽然所使用的覆盖项信息具有较细的粒度, 但是对测试用例进行冗余判断时的粒度较粗; Marijan 等[5]的方法将所有测试用例分为3 种类型, 但是对于同一种类型的测试用例, 缺乏更细粒度的区分, Marijan 等[5]的方法使用到了历史缺陷信息, 这是一种较为难以获取的数据, 限制了该方法的适用性.

1.2 测试用例生成方法: FACTS 和FinExpert

本文研究的金融科技软件在测试过程中使用了FACTS[2]和FinExpert[3]这两种测试用例生成方法.

FACTS 是一种黑盒的测试用例生成方法, 其通过对已有测试套件进行变异操作, 随机删除、修改测试用例的部分字段值, 从而快速生成大量的测试用例. 其优点在于: ①能够在已有测试用例数量较少的情况下, 生成大量新的测试用例; ②所生成的测试套件能够达到较高的代码覆盖率. 其缺点在于:①由于涉及随机变异操作, 所生成的测试用例可能不满足被测程序的约束条件, 进而可能在测试执行时触发异常, 生成无意义的测试用例, 无法保证可用性; ②经过实践检验, FACTS 测试用例生成方法会生成大量无意义的测试用例.

FinExpert 基于领域特定知识, 使用领域特定语言 (Domain Specific Language, DSL), 根据预先定义的字段类型、字段取值范围、字段约束条件等信息, 生成大量符合领域特定知识的测试用例. 其优点在于: 由于使用到了领域特定知识, 因此所生成的测试用例能够有效地满足被测程序的约束条件,不容易触发异常, 避免生成无意义的测试用例. 其缺点在于: ①人工成本较高, 只有懂得业务逻辑与程序逻辑的领域专家, 才有能力编写领域特定知识信息; ②所生成的测试套件的质量高低, 取决于领域特定知识信息的准确与否. 在使用FinExpert 时, 为了生成高质量的测试套件, 准确而有效的领域特定知识信息是必要的.

2 方 法

2.1 样 例

软件程序的代码覆盖率, 是软件测试中的一种常用度量指标, 用于描述测试用例被执行的代码数量占源代码总量的比例. 覆盖项是覆盖率准则的单位. 不同的覆盖率准则, 具有不同的覆盖项类型, 例如行覆盖率指标使用代码行作为覆盖项, 分支覆盖率指标使用代码分支作为覆盖项. 代码覆盖率信息,能够作为测试用例冗余程度量化的依据.

为了直观地展示代码覆盖项对于测试冗余的影响, 本节给出一个样例, 该样例取自金融科技软件Bcbip 的代码片段. 图1 给出了样例程序的简化代码, 其中只保留主要的代码逻辑结构, 已对类名、方法名与变量名进行混淆, 并标注出了6 个覆盖项. 图2 给出了样例程序的流程图. 该程序只包含3 条可行的执行路径, 每一条执行路径都具有独特的覆盖项, 而这些独特的覆盖项(覆盖项2、覆盖项4 和覆盖项5)仅被一条路径覆盖, 部分覆盖项(覆盖项1、覆盖项3 和覆盖项6)至少被2 条执行路径覆盖,部分覆盖项(覆盖项1 和覆盖项6)被所有的路径覆盖. 独特覆盖项具有特殊价值, 如果独特覆盖项被覆盖, 所对应的路径必定被执行.

图1 样例程序的简化代码Fig. 1 Simplified source code of the working example

图2 样例程序的流程图Fig. 2 Flow chart of the working example

表1 给出了第一个测试套件, 包含测试用例与覆盖项的覆盖信息. 该测试套件包含3 条不冗余的测试用例, 每条用例分别执行了不同的路径. 根据覆盖到覆盖项的测试用例数量, 能够判断该覆盖项的冗余程度. 对于所有覆盖项来说: ① 独特覆盖项 (不冗余覆盖项), 指仅被1 条测试用例覆盖到的覆盖项, 使用“0”来表示; ② 冗余覆盖项, 指至少被两条测试用例覆盖到的覆盖项, 使用“1”来表示; ③ 未被覆盖到的覆盖项, 指未被任何测试用例覆盖到的覆盖项, 使用“#”来表示.

表1 第一个测试套件的信息Tab. 1 Information about test suite No.1

对于测试用例来说, 当一条测试用例覆盖了独特覆盖项, 那么这条测试用例是不冗余的; 当一条测试用例仅覆盖了冗余覆盖项, 没有覆盖任何独特覆盖项, 那么这条测试用例是冗余的.

分析表1 中数据可知, 3 条测试用例都覆盖到独特覆盖项, 因此所有测试用例都是不冗余的.

表2 给出了第二个测试套件. 该套件在表1 的基础上, 增加了测试用例4. 测试用例4 与测试用例3 是完全相同的, 从直观上来说, 这两条测试用例应该是冗余的. 重新统计所有覆盖项的冗余情况, 可以发现: 覆盖项5 从独特覆盖项变为冗余覆盖项, 进而导致测试用例3 与测试用例4 都没有覆盖任何独特覆盖项, 变为冗余测试用例.

表2 第二个测试套件的信息Tab. 2 Information about test suite No.2

分析表1—2 可知, 覆盖项的冗余信息能够反映测试用例的冗余情况. 受此启发, 本文使用覆盖率指标信息对测试冗余进行分析, 从而提出测试冗余的有效量化方法.

2.2 最佳覆盖项测试冗余指标

本节提出最佳覆盖项测试冗余指标MVI, 该指标使用覆盖率信息来衡量测试套件冗余程度. 如图3 所示, MVI 指标分为3 个部分: 覆盖项冗余、测试用例冗余和测试套件冗余. 本节详细介绍每个部分的计算公式.

图3 MVI 冗余指标的框架图Fig. 3 Frame diagram of the MVI redundancy metric

2.2.1 覆盖项冗余

MVI 指标基于代码覆盖率进行计算. 根据覆盖项被整个测试套件覆盖的情况, 将覆盖项分为多种类型.① 未覆盖覆盖项: 不被任何测试用例覆盖, 不冗余, 不提升覆盖率; ② 独特覆盖项: 仅被一条测试用例覆盖, 不冗余, 提升覆盖率; ③ 冗余覆盖项: 至少被两条测试用例覆盖, 存在冗余, 提升覆盖率.

在计算覆盖项冗余时, MVI 指标只考虑被测试用例覆盖到的覆盖项, 即只考虑“独特覆盖项”与“冗余覆盖项”, 而忽略“未覆盖覆盖项”.

定义1 覆盖项冗余值:

覆盖项冗余值反映覆盖项的冗余情况, 其计算方式如式(1)所示. 式(1)中:I表示一个覆盖项,NI表示测试套件中覆盖了I的测试用例的数量. 当一个覆盖项的冗余值等于0 时, 表示该覆盖项仅被1 条测试用例覆盖到, 是不冗余的; 当一个覆盖项的冗余值大于0 时, 表示该覆盖项至少被两条测试用例覆盖到, 是冗余的. 覆盖项冗余值虽然不能直观地反映测试冗余情况, 但是该指标能够用于计算测试用例的冗余指标以及测试套件的冗余指标.

2.2.2 测试用例冗余

根据测试用例对覆盖项的覆盖情况, 将测试用例分为多种类型.

独特测试用例: 当一条测试用例覆盖到独特覆盖项时, 它是独特的、不冗余的, 这条测试用例对于覆盖率具有不可替代的贡献; 如果一条独特测试用例被删除, 测试套件的整体覆盖率将下降.

非独特测试用例: 当一条测试用例无法覆盖到独特覆盖项时, 它是冗余的, 这条测试用例能够被替代; 如果一条非独特测试用例被删除, 并不影响测试套件的整体覆盖率.

独特测试用例是不冗余的, 而非独特测试用例是冗余的. 对于一条非独特测试用例, 如果它所覆盖到的覆盖项的冗余程度越小, 那么它的不可替代性越强, 更有可能在其他测试用例被削减时变为独特测试用例. 因此, MVI 指标认为冗余值更小的覆盖项具有更高的价值.

定义2 测试用例冗余值:

式(2)中:C表示一条测试用例,I表示C所覆盖到的覆盖项,RI表示覆盖项I的冗余值. MVI 指标优先统计一条测试用例所覆盖到的所有覆盖项, 并取覆盖项冗余值的最小值作为测试用例冗余值. 测试用例冗余值直接反映了每一条测试用例的冗余情况, 能够指导测试人员对测试用例进行筛选、排序,也能够用于指导科研人员对测试用例削减算法进行研究.

2.2.3 测试套件冗余

定义3 测试套件冗余值:

式(3)中:S表示测试套件,C表示S所包含的测试用例,RC表示测试用例C的冗余值. 测试套件冗余值取测试用例冗余值的均值, 该指标能够直观地显示出整个测试套件的冗余程度. 对于测试人员来说, 如果一个测试套件的冗余值过大, 则需要考虑对测试套件进行削减.

2.3 有效性分析方法

针对测试冗余指标的有效性, 目前学术界没有较为直观而有效的验证方法. 在以往的研究[4-5]中往往将冗余指标作为一个中间量, 只对测试用例削减算法的有效性进行验证, 而不对冗余指标的有效性进行验证. 对于测试用例削减算法来说, 测试冗余指标的有效性是必要的, 因此本文提出推论: 如果测试用例削减算法是有效的, 则该削减算法所使用的测试冗余指标必然是有效的.

根据以上推论, 本节在MVI 指标的基础上, 提出了MVIR 测试用例削减算法. 通过验证MVIR 的有效性, 能够从侧面验证MVI 指标的有效性.

2.3.1 MVIR 测试用例削减算法

为了评价MVI 指标的有效性, 本文提出一种基于贪心策略的测试用例削减算法MVIR. MVIR 流程见算法1.

算法1 MVIR So输入: 未削减的测试套件 ; 冗余容忍度T输出: 削减后的测试套件Sr 1: S ←So 2: Do:S 3: 计算 中每条测试用例的冗余值4: Rmax ← S 中测试用例冗余值的最大值5: S ←将 S 中冗余值最大的测试用例剔除Rmax 6: While > T 7: Sr ←S 8: ReturnSr

MVIR 具有一个额外的输入参数, 称为冗余容忍度, 记为T. 冗余容忍度的取值必须是非负整数.MVIR 允许削减后的测试套件中保留一定程度的冗余, 并且通过调整冗余容忍度来控制所保留的冗余因素多少, 从而获得更好的测试质量. 当选取冗余容忍度为0 时, MVIR 能够保证削减后不存在冗余的测试用例. 随着冗余容忍度的增大, 所保留的冗余因素将增多.

MVIR 的流程: ①根据测试用例冗余值, 将所有测试用例进行排序. ②删除冗余值最大的测试用例. ③对于剩余的测试用例, 判断是否所有的测试用例冗余值都不大于冗余容忍度. 若不是, 则重复算法1 中的第1 至第3 步; 若是, 则MVIR 执行结束, 使用剩余的测试用例组成新的测试套件.

2.3.2 测试冗余指标有效性验证

根据测试冗余的定义[5], 如果能够从测试套件中删除一部分测试用例, 并且不对测试套件的质量造成影响, 那么测试套件中必然存在一定的冗余因素. 因此, 在保证测试质量不变或者测试质量损耗较低的前提下, 如果能够从测试套件中删除越多的测试用例, 则说明测试用例削减算法的效果越好,并且能够从侧面证实该测试用例削减算法所使用的测试用例冗余指标同样具有较好的效果.

本文使用变异测试方法对测试套件的质量进行评估, 该方法被广泛用于衡量测试套件质量[13]. 变异测试方法通过特定的方式对被测程序的源代码进行修改, 从而注入缺陷, 分析测试套件是否能够有效地检测出所注入的缺陷, 进而对测试套件的质量进行评估. 每一个被注入缺陷的源代码版本被称为变异体, 每个变异体中仅存在一个特定的缺陷. 在对变异体的测试过程中, 如果测试用例的断言失败,则说明测试套件能够“杀死”该变异体. “变异分数”指测试套件能够杀死的变异体数量与所有变异体数量的比值, 变异分数越大, 则说明测试套件的测试质量越高.

对于MVI 指标有效性的具体证明过程如下: ①针对同一个测试套件, 选取不同的冗余容忍度, 使用MVIR 进行不同程度的削减操作, 得到多个削减测试套件; ②对于被MVIR 削减前后的测试套件,使用变异测试方法计算变异分数, 评估“测试质量”; ③对于被MVIR 削减前后的测试套件, 统计测试用例数量变化情况, 评估“削减程度”; ④如果“测试质量”与“削减程度”越高, 则证明MVIR 与MVI 指标越有效.

3 实 验

3.1 实验设置

3.1.1 被测对象

在实验阶段使用金融科技软件下的Bcbip 构件进行, Bcbip 的主要功能是根据发行信息、订单信息以及配售约束信息等输入信息, 计算并输出配售结果. Bcbip 具有3 个测试接口, 每个测试接口都有一个所对应的测试套件, 对于每个测试套件, 由人工方法生成的测试用例数以及分支覆盖率信息如表3 所示.

表3 Bcbip 基本信息Tab. 3 Basic information about Bcbip

3.1.2 测试套件

本文使用FinExpert 和FACTS 进行实验. 表4 展示了由人工方法、FinExpert 与FACTS 生成的测试套件中的测试用例数, 图4 展示了三者的分支覆盖率信息.

图4 由人工方法、FinExpert 和FACTS 得到的分支覆盖率信息Fig. 4 Branch coverage generated by the manual, FinExpert, and FACTS methods

表4 由人工方法、FinExpert 和FACTS 生成的测试用例数Tab. 4 Number of test cases generated by the manual, FinExpert, and FACTS methods

观察测试用例数. 由人工方法生成的测试用例数量最少, 远少于两种自动化生成方法. 由FinExpert 生成的测试用例数是人为给定的, 为了取得较高的测试质量, 对每个测试接口都生成1 000条测试用例. 由FACTS 生成的测试用例数与测试用例的复杂程度有关, 对越复杂的测试接口,FACTS 所生成的测试用例数越多. FinExpert 和FACTS 所能生成的测试用例数具有相同的数量级.

分析覆盖率信息. 在3 种方法中, FACTS 对于所有接口均能得到最高的分支覆盖率; 对于接口api1 和api3, FinExpert 能得到优于人工方法的分支覆盖率; 对于接口api2, 在3 种方法中, FinExpert所得到的分支覆盖率最低.

FinExpert 对于接口api2 的测试效果不佳, 其根本原因在于: 接口api2 具有较为复杂的约束条件,而当使用FinExpert 对接口api2 编写的领域特定知识信息时, 无法满足一部分约束条件, 进而导致部分的测试用例在执行时触发异常信息, 生成了较多无意义的测试用例. 由于FinExpert 针对接口api2 生成的测试套件存在可用性问题, 因此在实验结果的分析阶段, 不考虑与其相关的数据.

3.2 冗余指标有效性验证实验

冗余指标有效性验证实验分为两个部分: 第一部分, 对削减前后生成的测试套件的质量进行分析;第二部分, 对削减前后生成的测试用例的数量进行分析.

对于实验的第一部分, 本文使用PIT[14]变异测试工具对测试套件的质量进行分析.

本节的实验对MVIR 的冗余容忍度选取了5 个值: 10、5、2、1 和0. 因此, 对于每个给定的接口和测试用例生成方法, 将产生5 个不同的削减测试套件, 以比较不同削减程度下的质量差异.

3.2.1 测试质量评估

图5 列出了削减后测试套件的变异分数. 图例中的“原始”代表未经过MVIR 削减的测试套件,T10、T5、T2、T1和T0分别代表取冗余容忍度为10、5、2、1、0 时的MVIR 削减后所得到的测试套件.

图5 削减后测试套件的变异分数Fig. 5 Mutation score of the reduced suite

为了更直观地展示测试质量在削减前后的差异, 使用式 (4) 对变异分数的相对损失进行计算.

图6 列出了削减后测试套件的变异分数损失, 即性能损失. 从图6 中能够看出, 只有FinExpert(对于接口api2)所得到的性能损失较高, 其余测试套件的性能损失均小于9.20%, 由人工方法生成的测试用例经过削减之后, 性能损失都小于5.26%. MVIR 整体上不对测试套件的性能产生较大的影响.

图6 削减后测试套件的变异分数损失Fig. 6 Mutation score loss of the reduced suite

3.2.2 测试用例数量评估

表5 列出了所有测试套件经过MVIR 削减前后的测试用例数量, 其中“原始”代表未经过MVIR 削减的测试套件,T10、T5、T2、T1和T0分别代表取冗余容忍度为10、5、2、1、0 时MVIR 削减后所得到的测试套件.

表5 所有测试套件经过MVIR 削减前后的测试用例数Tab. 5 Number of test cases for the MVIR reduced and original test suites

图7 展示了削减后的测试套件的测试用例数量. 分析表5 与图7 的数据可知, 未经削减的FinExpert 测试套件和FACTS 测试套件的测试用例数量范围为 [820,1804] , 而由人工方法生成的测试用例的数量范围为 [10,22] , 数量相差较大; 但是经过削减的FinExpert 的T10、T5、T2、T1和T0的测试用例数量范围都为 [2,19] , FACTS 的T2、T1和T0的测试用例数量范围都为 [11,23] , 这些削减后的测试套件具有与人工方法生成的测试套件相似的测试用例数量, 可以认为这些削减后的结果达到了与人工方法生成的测试用例相同的数量级.

图7 削减后测试套件的测试用例数Fig. 7 Number of test cases for the reduced suite

为了更直观地展示测试用例数量在削减前后的差异, 使用式 (5) 对测试用例数量的削减比例进行计算.

式 (5) 中:Sr表示削减后的测试套件,So表示未削减的测试套件,NSo(NSr) 表示测试套件So(Sr) 的测试用例数量.

图8 列出了所有测试套件经过MVIR 削减后的测试用例削减比例信息. 分析数据可知, 对于FinExpert 和FACTS, 所有测试套件的测试用例削减比例都在89.88%以上; 对于FinExpert 和FACTS 的T0测试套件, 即经过MVIR 削减后不包含冗余因素的测试套件, 测试用例削减比例都在98.66%以上. 结果显示MVIR 能剔除大部分的冗余测试用例, 同时有效消解了测试套件中的冗余因素.

图8 测试套件经过MVIR 削减后的测试用例削减比例Fig. 8 Test case reduction ratios for the MVIR reduced suite

3.2.3 小 结

使用MVIR 进行测试用例削减, 能够在测试性能损失较低 (小于9.20%) 的前提下, 达到较高的测试用例削减比例 (大于89.88%). 该实验结果证明MVIR 能够有效地消解冗余因素, 同时从侧面证明MVI 指标能够有效地反映测试冗余的程度.

3.3 测试用例生成方法的冗余分析

本节使用MVI 指标探究测试用例生成方法的冗余情况. 表6 展示了由人工方法、FinExpert 和FACTS 这3 种方法所生成的原始测试套件的冗余值. 由人工方法、FinExpert 和FACTS 所生成的测试套件的平均冗余值分别为5.32、636.94 和336.15, FinExpert 和FACTS 所产生的冗余程度均远高于由人工方法所产生的冗余程度. 实验数据表明, FinExpert 和FACTS 这两种方法在自动化生成测试用例的同时, 引入了较多的冗余因素. 在使用此类自动化测试用例生成方法时, 应该对测试冗余问题予以重视.

表6 人工方法、FinExpert 和FACTS 的原始测试套件的测试套件冗余Tab. 6 Suite redundancy for the original test suites of manual, FinExpert and FACTS

表7 展示了所有测试套件经过MVIR 削减前后的冗余值. 分析数据可知, 当冗余容忍度小于等于10 时, FinExpert 和FACTS 所生成的测试套件经过MVIR 削减后都能够获得与未经过削减的由人工方法生成的测试套件相当的冗余值. 由此可见, 将测试用例生成方法和测试用例削减算法相结合, 能够自动化地生成高质量、低冗余的测试套件.

表7 所有测试套件经过MVIR 削减前后的测试套件冗余Tab. 7 Suite redundancy for the original and reduced test suites

3.4 冗余容忍度的选取

在实际应用中, 冗余容忍度的选择直接影响MVIR 的实际效果: 减小冗余容忍度, 能够提高测试套件的削减比例, 但是将会降低测试质量; 合适的冗余容忍度能够对削减比例与测试质量进行有效的权衡.

在选取冗余容忍度时, 本文建议遵守以下原则.

(1) 如果测试环境允许进行变异测试, 并且能够接受变异测试的时间成本, 则建议使用变异测试方法来指导冗余容忍度的取值. 在保证测试质量的前提下, 应选取尽可能小的冗余容忍度. 使用测试套件中测试用例的数量作为冗余容忍度的初始值, 并且不断减小冗余容忍度, 使用MVIR 对测试套件进行削减, 同时使用变异测试方法计算削减后测试套件的变异分数. 在理想情况下, 当冗余容忍度从初始值不断减小时, 冗余程度较高的测试用例被优先剔除, 不会降低测试质量, 因此变异分数不发生改变; 当冗余容忍度减小到一定程度时, 所保留的测试用例已经具备足够的测试质量, 如果继续减小冗余容忍度将会导致测试质量下降, 这种情况下的冗余容忍度是最佳的.

(2) 如果原则 (1) 并不适用, 被测程序本身具有由人工方法生成的测试套件, 并且该测试套件具备一定的参考价值, 则建议使用该测试套件来指导冗余容忍度的取值, 保证削减后的测试套件与人工测试套件具有较为接近的冗余程度. 首先使用MVI 指标计算人工测试套件的冗余值, 将该冗余值作为冗余容忍度的初始值, 并且不断增大冗余容忍度, 同时使用MVIR 对测试套件进行削减. 当削减后的测试套件的冗余值与人工测试套件冗余值大致相等时, 则所对应的冗余容忍度的取值是较为合适的.

(3) 如果原则(1) 与 (2) 均不适用, 则建议使用经验值来确定冗余容忍度. 在实际的软件项目中,往往难以使用变异测试方法, 并且不能保证被测程序已具有合适的人工测试套件. 在这种情况下, 只能依据其他软件项目的经验来指导冗余容忍度的取值. 针对相关项目或者开源项目, 使用原则 (1) 或者原则(2) 计算冗余容忍度, 计算所得到的冗余容忍度也是具有参考意义的. 本文根据实验部分的数据, 给出冗余容忍度的经验值: FinExpert 的冗余容忍度建议设置为10, FACTS 的冗余容忍度建议设置为5.

4 有效性威胁

外部有效性. 实验部分所使用到的被测程序只有1 个, 数量较少, 可能缺乏代表性. 本文的工作主要关注金融科技领域的软件测试, 希望通过选取实际的工业软件进行实验, 从而提高外部有效性. 然而, 由于金融科技领域的软件对于软件开发流程的安全性具有较高要求, 导致实验中能够获取到的样本程序数量非常有限. 期望在后期的工作中能够从合作机构获取更多的工业软件, 进一步检验本文所提出方法的实际效果, 获取更加丰富的实验数据.

内部有效性. 第一, 测试冗余的概念较为抽象, 本文对抽象的测试冗余指标进行量化, 可能与业界的已有认知之间存在一定的偏差. 第二, 本文推断MVIR 的有效性能够充分说明MVI 指标的有效性,但是无法保证不存在例外情况.

5 结 论

本文针对金融科技领域的软件测试, 提出了一种基于最佳覆盖项的冗余评价指标MVI, 用于对测试套件的冗余因素进行量化分析. 为了验证MVI 指标的有效性, 本文在MVI 指标的基础上提出了MVIR 测试用例削减方法. 实验部分使用了金融科技领域的软件进行探究, 结果显示MVIR 能够在测试性能损失较低的前提下, 达到较好的削减效果. 实验结果从侧面证明了MVI 指标能够有效反映测试套件中的冗余因素. 最后, 使用MVI 指标分析金融科技领域的自动化测试用例生成方法:FinExpert 和FACTS, 发现这两种方法均会引入较多的冗余因素, 但是如果使用MVI 指标来优化这两种方法, 能够有效地缓解冗余情况, 生成高质量的测试套件.