基于过程数据的软件测试工作充分性评价

◎中国人民解放军63921部队 刘文红

◎中国航天系统科学与工程研究院 郭 栋 董冠涛 杨 昕

随着装备向高精度、智能化方向的快速发展，软件在装备中的数量迅速增加，装备中软件的复杂程度也越来越高，作为计算机控制系统核心的软件质量就显得尤为重要。然而，当前在装备软件测试领域，没有建立全面充分的测试数据收集机制，缺少对测试数据的整理分析工作，严重影响了上级机构对软件质量的全面掌握和把控。各级质量管理部门虽然对于软件测试十分重视，但在实际工作开展过程中，缺乏对测试工作的质量评价，没有实际数据支撑，无法科学有效的开展工作。软件研制单位在对软件进行开发方测试时，往往按照各自的理解和经验进行。软件任务下达方、研制单位、使用单位大多仅了解最后测试结果，只能反映软件测试工作中某阶段或者某类特性的质量情况，将测试过程产生的数据与实际工作相结合的非常少。目前度量软件测试工作充分性的方式，除了测试覆盖率指标以外，并没有其他参考。上级机构只能依靠测试大纲和报告评审会上专家的把关，来定性了解软件测评的结果情况，而对测试过程和测试工作的把握极不到位。

如何有效度量软件测试工作的充分性，是摆在各级质量管理部门面前一道亟待解决的难题。研究并给出一套基于测试过程数据对软件测试工作的充分性进行评价的方法，快速衡量每个测试项目的测试工作充分性，量化的分析和总结，可以帮助软件测试机构改进软件测试过程，提高软件测试效率，从而进一步提升软件的质量。

一、基于过程数据的软件测试工作充分性原始度量指标

软件测试工作质量评价体系的构建是软件测试工作质量度量的基础性工作，构建方法通常是对所搜集到的数据进行归纳整理，并根据尺度进行衡量。在选取软件测试工作质量评价指标时，要尽量将软件测试工作质量特性以量化形式表示，使评价结果客观、准确、科学。结合对软件测试工作现状的调研分析和对新形势下测试工作新要求的研究，对软件测试工作质量的主要影响因素进行分析，并结合测试工作实际和特点，软件测试验证过程质量数据收集如下：

（一）工期进度评估

工期进度的评估主要着眼于测试机构按照委托方的时间要求完成工作的能力，包括合同的履约情况和接受紧急工作能力情况两类参数。最简单的方式是按照工作进度是否符合合同要求进行评估。更进一步还可按照回归测试时间要求是否满足等进行度量。测评的时效数据也可作为测试项目的数据统计积累之一，纳入测试工作侧面的评价指标。

（二）测试类型评估

对应于《军用软件测评实验室测评过程和技术能力要求》中列出的22 种常用测试类型，每个测试项目都会选择其中的一些测试类型进行测试。在中国航天科技集团有限公司的企业标准Q/QJA 300-2013 中，分别针对开发方测试和第三方测试所必须选择的测试类型有一定要求。一般地，CD 级软件的配置项测试至少应包括文档审查、功能测试、性能测试、接口测试，具有人机交互界面的软件应进行人机交互界面测试，具有安装卸载功能的软件应进行安装性测试，具有功能边界或数据边界的软件应进行边界测试，此外，AB 级软件的测试在此基础上还必须包括逻辑测试。

当前软件测试项目相对于软件的安全性级别来说，所选择的测试类型数是否充分，也是一个测试工作质量的参考指标。使用更多测试类型对软件进行测试，能关注到更多的软件质量方面，测试工作质量会更好。

（三）测试用例设计充分性

对应每一个选择的测试类型，根据软件的规格说明对其进行用例设计，用例应充分覆盖软件的各项功能、性能、接口要求。测试用例个数的规模应有一定要求。

该部分是结合笔者另一个研究课题的成果《一种基于主成分分析的软件测试用例规模估计方法》[1]，通过对被测项目的代码行数、安全关键级别、软件复杂度、接口复杂度、测试类型个数和编程语言等测试用例规模影响因子信息，在拿到被测软件，使用静态工具扫描圈复杂度，阅读接口文档得到接口复杂度信息之后，即可通过该课题的算法结果给出完成该项测试工作预计应设计的测试用例规模数量。

该算法成果建立在同类项目的测试用例设计具有较大的相似性和关联性的基础上。为了有效利用历史软件测试活动的经验，首先需要构建一个软件测试项目管理数据库，对近年来机构从事的测试活动的数据进行收集、梳理和维护。软件测试项目数据库中包含被测软件的基本数据如下：

（1）测试软件的基本信息：项目名称、项目标识符、软件类型、软件版本、代码大小、程序语言等；

（2）测试过程数据：测试级别、测试类型、测试项、测试用例、测试用例设计方法、测试环境、测试数据、测试用例执行率等；

（3）被测软件的故障数据：故障位置、故障等级、故障类型、故障编号、发现时间、打开或关闭等。

基于软件测试项目数据库，我们给出软件测试用例设计评价方法的大致思想。在软件测试项目管理中，软件测试项目的测试用例个数评估是一个持续改进优化的过程。可以将用例设计规模评估分为三个阶段：初始阶段，确定当前项目的测试类型和测试范围，在历史数据库中选择同类项目数据，进行评估模型定制，并基于定制的评估模型预测当前测试项目所需的用例规模；测试项目执行过程，得到实际测试用例个数；结项后，对测试用例评估结果的准确性进行评价，并将测试项目的过程数据汇总到历史数据库中，以提高以后估算结果的准确性。

我们选择回归分析方法，利用历史项目数据估计同类测试项目的预估用例数量，并不断更新历史数据库。测试项目实际完成后，检查其实际使用的测试用例与预估用例数量的比值，如果严重低于预估用量，则其测试工作质量是有问题的。

表1 软件测试覆盖率要求

（四）测试覆盖率

对于软件的测试覆盖率，Q/QJA 300-2013《航天型号软件测试规范》针对开发方测试、第三方测试和验收测试，对不同安全关键级别的软件分别进行了要求[2]。

（五）测试文档质量

该部分同样结合《一种基于主成分分析的软件测试用例规模估计方法》[1]，使用类似的方法，软件的相关信息除了能够对软件测试用例个数进行预估，也可以预估提交的测试大纲、测试说明、测试报告的文档页数。

测试项目实际完成后，检查其实际编制的测试文档页数与预估页数的比值，如果严重低于预估用量，则其测试工作质量是有问题的。

（六）测试过程评审意见情况

测试大纲评审、测试用例评审等质量控制关键节点中，对评审所提出的问题易发现程度和问题严重程度的综合评估。每条评审意见的针对问题的严重等级越高，易发现程度越低（问题易发现但自己没有发现），则说明工作质量越糟糕，评价分数越低。

（七）下一验证过程的问题回溯情况

常规考虑的测出问题数和千行代码问题数KLOC，更多表征的是衡量被测软件的质量，而非测试工作的质量。因此在软件的测试工作质量中，我们并未选择该指标，而是选择了另一个指标：下一验证过程问题回溯，来对测试工作质量进行评价。

软件测试工作的目标是尽可能发现问题。在从单元测试、部件测试、配置项测试到系统测试这样一轮轮的测试，乃至后续的定型测试和软件使用过程中，每一个测试过程都可能发现新的软件问题，其中一些问题是在前述测试过程中无法发现的。例如：单元测试更关注软件单元内部的结构和功能，对单元间的调用接口关注不够，软件单元间的调用接口如果出现问题，不容易在单元测试中发现，而更容易在部件测试中去发现。

但若在前一个测试过程检出的问题未检出，而在后一个测试过程被检出，则表明前一测试过程的工作质量有所欠缺。因此需要对每一测试过程测出的问题进行分类计数，统计测出问题中属于前一测试过程应测出未测出的个数，作为本项评价指标。

该项指标的设立，也是对软件测试工作质量问题的一个针对性的措施，通过相应指标的设立来促使软件测试机构提高测试工作质量，尽可能的减少问题遗留到后续验证过程。

表2 软件测试工作质量度量元定量计算

度量指标名子度量指标名方法�■ 0.6 �0.6 �����测试用例设计充分性语 句覆 盖率参考GB/T 38634.4-2021 的计算方式。建议采用测试工具自动统计。测试用例设计充分性所设计的用例个数与预期设计的用例个数间的到的语句行数占代码可执行代码总行数的比率测试项目所设计的用例个数与预期设计的用例个数间的符合程度��X=B/A A—— 代码可执行代码总行数；B——执行测试时所执行到的语句行数���，当���0.6 �0.4 �����，当����2�1，当��2�测试项目的预期用例个数A计算参考1.3中的方法。实际测试用例个数B从测评报告中可直接获得，或从测试说明/记录中计数得到。A——测试项目的预期用例个数B——实际测试用例个数语句覆盖率测 试覆 盖率执行测试时所执行到的语句行数占代码可执行代码总行数的比率分 支覆 盖率X=B/A A—— 代码可执行代码总行数B——执行测试时所执行到的语句行数X=B/A A—— 代码可执行代码总行数；B——执行测试时所执行到的语句行数参考GB/T 38634.4-2021的计算方式。建议采用测试工具自动统计。参考GB/T 38634.4-2021 的计算方式。建议采用测试工具自动统计。测试覆盖率分支覆盖率执行测试时所执行到的代码分支数占代码中所有分支总数的比率执行测试时所执行到的代码分支数占代码中所有分支总数的比率X=B/A A—— 代码可执行代码总行数B——执行测试时所执行到的语句行数参考GB/T 38634.4-2021的计算方式。建议采用测试工具自动统计。MC/DC覆 盖率修正的条件判定覆盖率MC/DC覆盖率修正的条件判定覆盖率X=B/A A——代码中，所有单个布尔条件可以独立影响判定结果的判定条件，其布尔值的可行组合总数B——执行测试时实际执行到的组合数参考GB/T 38634.4-2021 的计算方式。建议采用测试工具自动统计。X=B/A A——代码中，所有单个布尔条件可以独立影响判定结果的判定条件，其布尔值的可行组合总数B——执行测试时实际执行到的组合数参考GB/T 38634.4-2021的计算方式。建议采用测试工具自动统计。���■ 0.6 �0.6 �����，当���0.6 �0.4 �����测试文档质量测试文档质量测试文档页数与预期文档页数间的符合程度测试文档页数与预期文档页数间的符合程度���，当����2�1，当��2�A——测试项目对应文档的预期文档页数B——实际测试文档页数针对测试项目中每一份要求的文档计算出分别的X之后，求均值测试项目的预期文档页数A计算参考1.5中的方法。实际测试文档页B从各测试文档中可直接获得。时所执行

二、软件测试工作质量的综合评价方法

根据软件测试工作质量评价模型及采集到的各工作评价指标度量元的原始数据，设计科学的定性与定量结合的评价方法，对数据进行分析、整理与拟合，将每个度量元的原始数据通过计算函数将其转换成值域范围在[0,1]区间内的度量指标值，再将其结合权重指标进行加权计算。

上节中所列出的测试工作质量评价各度量元，定量计算如下。

（一）测试过程评审意见情况的计算

测试过程中常见的控制节点评审包括测试需求评审、测试计划评审、测试说明评审、测试环境就绪评审、测试总结评审等。记录每次评审中专家所提意见共计n 条，并划分每条意见所针对问题的严重等级A 和易发现程度B 两个属性。每个属性均分解为5 级。针对问题的严重等级越高，易发现程度越低（问题易发现但自己没有发现），则说明工作质量越糟糕，评价分数越低。所有评审意见的这两个属性分的均值即为对应子度量指标值。具体如下：

最终测试过程评审意见情况的度量指标计算公式如下：

（二）下一测试过程问题回溯情况的计算

在下一个测试过程中发现上一测试过程中应发现而没发现的问题，每个问题都具有发现问题难度、问题严重等级、发现问题的应发现验证过程三个属性，发现问题难度越小、问题严重等级越高、发现问题的应发现验证过程越靠前（与当前验证过程距离越远），最终的评价分数越低。

设发现问题难度包括1、2、3、4、5 五个等级。其中，等级1 为执行软件基本功能即能发现的问题；等级2 为需要进行一定的用例设计方法，执行到较偏的逻辑分支才能发现的问题；如此递推直至等级5 为极为隐蔽难以发现的问题。发现问题难度每增加一个等级，则权重增加p1，发现的问题难度等级为N1，则发现问题难度对交付后软件问题评价结果权重公式为：

设发现问题严重等级包括1（致命）、2（严重）、3（一般）、4（轻微）、5（建议）五个等级，发现问题严重等级每降低一个等级（对应的值增加），则权重增加p2，发现的问题难度等级为N2，则发现问题难度对交付后软件问题评价结果权重公式为：

设发现问题发生阶段包括单元测试、部件测试、配置项测试、分系统测试、系统测试等，假设划分阶段数为S，按阶段先后顺序对应的标注值为1、2、3、…、S，发现问题发生阶段往后一个阶段，则权重增加p3，发现问题发生阶段对应值为N3，则发现问题难度对交付后软件问题评价结果权重公式为：

设该阶段总分为B，如果在软件交付后共发现k 个问题，第i 问题对应的发现问题难度、问题严重等级、发现问题的发生阶段指标值分别为Ni1、Ni2、Ni3（当未发现问题，即k=0 时，N01=6、N02=6、N03=S+1），对应该阶段的得分值权重为：

同前，p1、p2、p3初始值可以根据专家经验确定，在后期累积历史数据后，可通过对原始数据经过数学处理获取权重来进行调整。

X 归一化后计算公式为：

三、权重的确定

本项目邀请了数十名软件测试领域专家对影响软件测试工作质量的各个指标权重进行评估，采用专家打分法最后给出了软件测试工作质量评价的权重层次化结构如下表所示。

表3 软件测试工作质量评价的权重层次化结构表

四、总结

本研究指出了软件测试工作的现状与不足问题，提出了相应的改进途径，包括采取全面工作质量评价方法来以评为促，帮助软件测试工作质量提高。在此基础上研究提出的软件测试工作质量度量评价模型可用于各软件测评单位的内部质量管理。对于同一组织内部，主要采用度量评价模型中的项目层面数据，通过对各个测试项目的相关数据采集来评价测试项目的工作质量，定量分析软件测试工作绩效数据，形成对软件测试质量的持续正向反馈。