航天器软件参数修改的测试策略研究

侯成杰

（北京控制工程研究所，北京 100190）

1 引言

软件回归测试策略一般包括两类［1-2］，即改动较大时的“全部重测”策略和改动较小时的“选择性”回归测试策略。其中，“选择性”回归测试策略［3-4］又分为3种：安全选择策略，即选择覆盖所有程序中受影响部分的测试用例，如基于代码修改的测试用例选择；最小化选择策略，即选择已有的测试用例的最小子集；随机选择策略。在这些策略中，安全选择策略是一个折中的方案，既有较高的错误检测能力，回归测试用例集也不大，因此适用范围较广。

在航天器软件研制领域，很多软件配置项已经形成了稳定的型谱（指某个软件配置项的基本型）。在研制属于同一系列不同批组的航天器时，不同航天器中具有稳定型谱的某些软件配置项的功能和逻辑可能完全相同，只是由于航天器使用部组件物理特性的差异而导致这些配置项具有少量软件参数上的不同，这种情况在航天器研制上一般被称为“软件参数修改”。很显然，针对软件参数修改的测试应比一般意义的回归测试在规模和工作量上要小得多，如果继续应用前面提到的回归测试策略，可能会导致“事倍功半”的结果。因此，如何进行“最小规模”的回归测试，既保证测试覆盖性，又能最大化地简化测试过程，减少测试人员的工作量，是当前航天器软件研制中面临的一个问题。本文以航天器软件研制中出现的参数修改错误的2个实例为切入点，详细分析了导致错误的原因，并借鉴“选择性”回归测试策略中的安全选择策略，提出了一种专门面向软件参数修改的回归测试策略。

2 航天器软件参数修改错误实例分析

以下通过航天器软件参数修改错误的2 个实例，重点分析导致软件参数修改实施错误而又未被及时发现的主要原因。

2．1 控温回路控温上下限参数颠倒错误

某航天器软件的某版本相对于前一版本有如下参数变更：上电后控温回路2～5的缺省控温范围由10～15 ℃变为15～20℃，其中10 ℃对应的原码为0x69，15℃对应的原码为0x5B，20℃对应的原码为0x51。相应的代码变更如表1所示。

表1 代码变更Table 1 Code change

从表1可以看到，参数修改后的代码中确实存在0x51和0x5B，但是根据软件设计说明，该数组的第2、5、8、11个元素分别对应控温回路2～5的控温上限，即20℃，第3、6、9、12个元素分别对应控温回路2～5的控温下限，即15 ℃；因此，本次参数修改实际上把这些控温回路的上限和下限弄反，从而导致软件加电后控温功能异常。这一问题的实质是参数修改时的位置（顺序）颠倒，导致部分回路控温功能错误。造成该错误的原因是，软件设计人员在参数变更时只注意了参数的数值，忽视了参数的顺序（或位置），特别是在参数个数较多的情况下。这个错误在软件测试阶段未被发现，是由于测试人员在代码审查阶段，对需求变更与代码变更进行确认分析时存在遗漏，没有一一对应。另外，回归测试中的用例选择也存在遗漏，没有执行加电后使用缺省控温范围进行控温的用例。

2．2 加热器回路个数参数修改不完全

航天器B的某管理软件，是在航天器A 管理软件的基础上进行参数修改得到的。修改的参数为加热器回路个数：航天器A 的加热器回路为100路，航天器B 的加热器回路为108 路。软件参数修改过程引入的错误为：该管理软件包括热控管理功能和电源管理功能，其中均有对加热器回路的控制操作；但是在进行参数修改时，只把热控管理功能相关模块中的加热器回路个数改为108，而针对电源管理功能相关模块中使用的加热器回路个数未进行修改（仍为100），致使针对航天器B 的第101路～第108路的电源管理功能错误。这一问题的实质是参数修改不完全，导致部分回路电源管理功能错误。该错误在软件测试阶段未被及时发现，是由于在回归测试中的测试用例集不完整，在回归测试中没有执行针对第101～第108回路的电源管理功能的测试用例。

2．3 软件参数修改缺陷分类及影响分析

参数修改中出现的问题一般有2种，即修改错误和修改不全（或修改遗漏）；而修改错误又可分为参数内容错误和参数顺序错误。第1个实例对应的是参数修改错误中的顺序错误，第2个实例属于修改不全。

由于航天器各软件中的参数种类非常繁杂，且一般与软件功能相关，因此，参数修改错误中的参数内容错误的情况比较复杂，也可能导致更严重的错误。例如：卫星的轨道参数是卫星进行初始定位的重要参数，如果修改错误，可能会导致卫星轨道计算出现严重错误，甚至数据溢出并最终导致卫星进入安全模式。此外，参数修改对软件的性能、边界也可能产生影响，这与具体被修改的参数相关，要结合具体情况进行深入分析。

本文所述的测试策略为通用策略，是基于解决参数修改顺序错误和修改遗漏等问题提出的，也适用于参数修改内容错误问题。这是因为：参数修改出现问题的根本原因都是对参数修改的影响域分析不充分，以及回归测试用例集选择不完整。

3 针对软件参数修改的测试策略与实施过程

3．1 测试策略

在应用安全选择回归测试策略的过程中，为进一步简化测试用例集，M．J．Harrold提出了测试用例集约简的概念［5-6］。即在原始用例集中找到一个较小的测试用例子集，并能提供与原始测试用例集一样的测试覆盖率。

在回归测试用例集的约简算法［7］中，需求驱动方法是一种重要的方法。只有进行了需求之间的关系分析，并充分发掘需求之间的约束关系，才能真正实现测试用例集的大幅缩减。该方法是基于构建测试用例-需求覆盖矩阵［8］，反复删除被包含的行（即测试用例）和列（即测试需求），直至矩阵无法再约简。软件参数修改一般都属于需求变更，因此可用这种方法进行回归测试用例集约简。而针对软件参数的修改，在测试时应把重点放在程序实现与软件参数修改的一致性验证上，代码审查无疑是确认参数变更正确性的最直接和有效的方法，即回归测试方案应以代码审查方法为主，动态测试为辅。

借鉴安全选择回归测试策略及测试用例集约简算法中的构建测试用例-需求覆盖矩阵方法，提出以下针对软件参数修改的测试策略，即在针对软件参数修改的代码审查中，采用构建程序-需求覆盖矩阵的方法，在针对软件参数修改的动态测试中，仍然采用基于构建测试用例-需求覆盖矩阵的方法。

3．2 实施过程

测试策略具体的实施过程如下：

（1）针对软件初始版本进行代码审查，构建程序-需求覆盖矩阵，即把所有软件需求均对应到代码行或者代码行集合（函数属于代码行集合的一种）；

（2）在软件初始版本确认测试过程中，针对软件初始版本构建测试用例-需求覆盖矩阵；

（3）在针对参数修改的代码审查阶段，应首先明确参数修改所在的需求变更；

（4）根据测试用例-需求覆盖矩阵及需求约束关系，对用例进行约简，直至得到需要重新运行的测试用例集；

（5）根据程序-需求覆盖矩阵及代码之间的调用（包含）关系，删除被包含的行（即代码行），直至矩阵无法再约简，最终找到该项变更需求所有对应的代码，再审查这些代码是否进行了正确变更；

（6）重新运行这些测试用例来验证变更的正确性，以及对软件功能造成的影响。

在图1所示的测试过程中，构建程序-需求覆盖矩阵和构建测试用例-需求覆盖矩阵是关键节点。只要程序-需求覆盖矩阵是完整的，在针对软件参数修改进行代码审查时就会发现类似第2个实例所示的错误。只要测试用例-需求覆盖矩阵是完整充分的，回归测试用例集也一定是充分的。

为了发现类似第1个实例所描述的错误，在对参数修改实施代码审查时还要遵循一项重要准则，就是“一一对应”，即要把需求中的参数对应到程序中的数据，并确认其数值的一致性。此时，经常需要进行一些数据转换工作（如32bit浮点数与十进制小数之间的转换）；而针对较多参数同时更改的情况，除了确定数值的正确性外，还要特别注意参数的顺序（位置），这正是第1个实例所对应的情况，即要注意程序中数据是否出现在对应的位置上，而不能仅注意是否出现该数据。

图1 针对软件参数修改的测试实施过程Fig．1 Software testing process for parameter change

这里还要强调一下软件的可维护性设计。针对第2个实例，如果把程序中多次引用的参数都定义成宏，而不是使用立即数的话，对参数进行修改时只要修改该宏定义即可。这样不仅提高了软件的可维护性，还可以避免同时修改多处参数导致修改不完全带来的风险。

4 结束语

本文以回归测试用例集的需求驱动方法为基础，结合对航天器软件参数修改错误实例的分析，提出了构建程序-需求覆盖矩阵和测试用例-需求覆盖矩阵的测试策略。目前，这两个矩阵是由测试人员构建的，回归测试时的代码审查和测试用例集的选择，也均由测试人员手工进行，工作量较大，且存在出错的可能性。如果把上述两个覆盖矩阵工具化，并加入自动分析功能，则在回归测试时可由工具自动分析软件代码变更的正确性和影响域，从而大大提高测试效率和分析准确性。目前还没有构建上述两个矩阵的工具软件。软件测试工具LDRA Testbed的最新版本（v9．1．x）［9］中，新增了软件需求与代码的覆盖分析功能，可用来构建程序-需求覆盖矩阵。

本文提出的软件参数修改测试策略，可以解决目前存在的回归测试中的代码审查覆盖不全、回归测试用例集不完备等问题。如果有上述软件工具的支持，针对航天器软件参数修改的测试工作效率将会得到进一步提高。

（References）

［1］Rothermel G，Harrold M．Analyzing regression test selection techniques［J］．IEEE Transactions on Software Engineering，1996，22（8）：529-551

［2］朱婷婷．基于需求矩阵的软件回归测试方法研究及应用［J］．软件产业与工程，2010（2）：45-48

Zhu Tingting．Research and application for regression testing method based on requirement matrix［J］．Software Industry and Engineering，2012（2）：45-48（in Chinese）

［3］Harrold M，Gupta R，Soffa M L．A methodology for controlling the size of a test suite［J］．IEEE Transactions on Software Engineering and Methodology，1993，2（3）：270-285

［4］彭园园．回归测试方法及测试用例优化研究［D］．武汉：武汉理工大学，2009

Peng Yuanyuan．Regression test method and research on test suite optimization［D］．Wuhan：Wuhan Institute of Technology，2009（in Chinese）

［5］Untch R G，Harrold M J．Prioritizing test cases for regression test［J］．IEEE Transactions on Software Engineering，2001，27（10）：929-948

［6］顾庆，唐宝，陈道蓄．一种面向测试需求部分覆盖的测试用例集约简技术［J］．计算机学报，2011，34（5）：879-887

Gu Qing，Tang Bao，Chen Daoxu．A test suite reduction technique for partial coverage of test requirements［J］．Chinese Journal of Computers，2011，34（5）：879-887（in Chinese）

［7］Elbaum S，MalisheVsky A G，Rothermel G．Incorporating varying test costs and fault severities into test case prioritization［C］／／Proceedings of the International Conference on Software Engineering． New York：IEEE：200l：329-338

［8］Chen T Y，Lau M F．A new heuristic for test suite reduction［J］．Information and Software Technology，1998，40（56）：347-354

［9］Liverpool Development and Research Association（LDRA）．LDRA Testbed v9．1．x User’s Manual［Z］．Liverpool，England：LDRA，2012