实时测控软件研制过程中质量控制方法研究

朱丹，王斌，童艳

（中国人民解放军91550部队，辽宁 大连 116023）

0 引言

实时测控软件在飞行器飞行试验中完成实时数据采集、处理、安全判决和引导计算、落点预示以及试验指挥显示等任务，是测控系统的灵魂和中枢，软件质量的好坏会直接影响承担试验任务的能力及完成试验的水平。

以往测控软件的研制从系统分析、设计、编程和调试到最终定型，大多是研制者的相互检查，经过一定的模拟验证便投入使用。其中存在的隐患和故障积累到一定的程度，当条件满足时就会爆发而产生无法挽回的严重后果。方案修正通常也是各行其道，甚至仅凭记忆，因此，研制的软件从使用到维护都依赖于最初的研制者。随着飞行器试验任务的增多，软件系统不断庞大，研发人员的风险意识日益增强，引入软件质量控制体系势在必行。

1 测控软件质量控制的基本内容及过程

建立有效的软件开发管理模式，明确软件开发各阶段的质量要求和人员的职责，制定软件研制和测试流程；对在研制、测试和使用过程中因软件质量引起的问题，严格按质量问题归零标准要求形成归零报告；建立软件质量信息数据库，详细记载软件开发、测试和使用过程中技术状态变化及发生的质量问题；在试验过程中确需对程序进行更改时，必须严格履行更改手续，经审批签字后，由指定人员执行更改，更改后进行回归测试，经严格评审后方可使用，同时更新相应的文件并重新归档。

1.1 规范软件产品开发文档编制

由于软件开发人员撰写文档的习惯各不相同，因此，我们对软件开发与维护各阶段交付的文档应涵盖的内容和格式都进行了规定，以保持统一的格式与风格[1]。例如，规定各文档在封面标注文档名称、项目名称、项目主管、项目负责人和使用部门、作者、完成日期以及评审负责人、评审日期等；规定通用的图标、术语以及文档各组成部分的字体、大小等。各个阶段评审或评测过的文档都是下一步工作的基础和依据，同时每做一步的修改后，各种文档都要进行向上的追踪设计。因此，即使有个别开发人员离开，交接工作也可以在较短的时间内顺利完成；同时，完整的文档内容和统一的编辑风格既方便使用和维护，又方便日后的扩充和修改。

1.2 规范软件产品编码

a）编码必须以需求分析、概要及详细设计为基础

编码不能跨越设计阶段，必须以评审通过的详细设计说明书为基础进行，然而直接编程又是很多软件开发人员存在的通病。如果详细设计未经评审通过即开始编程，那么只能导致编码修改量的增加，事倍功半。当然在编码阶段回头修改详细设计，或者在详细设计阶段回头修改概要设计都是可能出现的正常现象。

b）针对开发工具制订详细的编码规范

目前常用的可视化开发工具看起来似乎简化了编程工作，实际上为大规模软件的开发管理和集成增加了难度。如果在使用这些开发工具进行正式编码前，未针对特定的环境制订详细的编码规范，也未进行界面设计或设计深度不够，就会给软件集成和使用带来困难。

1）界面设计规范：对包括菜单、屏幕格式、输入和消息、提示信息、表格、曲线输出等进行统一的规范，目的是解决界面的美观问题，人机交互直观、方便、灵活，以及输入、输出的一致性，同时指导编程；

2）程序代码编写规范：包括变量或对象命名规范、数据校验及出错处理、分布式数据的存取方法等，以提高软件的易维护性等。

1.3 软件产品的测试

严格的测试是软件质量控制的重要环节，是提高其可靠性的关键。软件产品的测试流程如图1所示。

图1 测试阶段的信息流程

1.3.1 测控软件系统的测试目标

软件开发的各个阶段并不能发现所有的设计和描述性错误，同时在编码阶段也会产生大量新的错误，虽然这些错误在软件调试中会得到初步的解决，但仍会有遗留。软件测试的目的就是以最少的时间和人力找出软件中潜在的各种错误和缺陷，软件测试的目标可以概括为以下3点：

1）发现软件缺陷和错误程序的执行过程；

2）改正识别出的错误并重新测试之后达到要求；

3）汇总软件出错记录，用于出错预防。

1.3.2 软件测试原则

1）所有的测试都应该追溯到用户需求；

2）制定周密的测试计划，以计划为基础来设计测试用例；3）测试用例由输入数据和预期输出结果组成；4）设计具有通用逻辑覆盖能力的测试用例，并突出临界值和特殊性；

5）测试贯穿于软件开发的各个阶段，从 “小规模”逐步进行 “大规模”测试，发现问题及时解决并进行归零处理，提高开发效率。

1.3.3 软件测试过程

测控软件的测试分为单元测试、集成测试、系统测试[2]。

a）单元测试

在软件分系统设计阶段进行，由各软件模块设计人员在单元编码结束并通过编译程序的语法检查之后对重要的执行路径进行测试，不仅要考虑软件的某些循环边界、非法的逻辑判定和内部数据结构的有效性，也要考虑软件的进程/线程优先级、调度关系、时序关系和时间开销等。

b）集成测试

将所有的程序模块按照软件需求进行组装，对完整的软件系统进行测试，主要目的是发现与接口有关的问题。例如，数据通过接口时可能丢失；子功能组合后未达到预期的性能；个别可以接受的误差可能积累到不能满足需求的程度；全局数据结构可能有问题等。

c）系统测试

在实际的应用环境下运行软件产品，严格依据需求说明来设计测试用例，不仅要考虑合理正常的输入条件，更重要的是设计出特别敏感的、临界的和偶然发生的、能引起问题变异的输入条件。这一阶段的测试主要集中检查系统能否正确地接收输入并正确地输出，发现不正确或遗漏的功能，外部数据库访问错误等问题。

软件测试过程中的关键环节是定义一批能够全面检查被测系统功能与性能的测试数据，建立合理的测试支持系统和严格、科学的测试方法。通过执行测试用例，分析测试结果，不断修改系统原型，最终构造出理想的软件系统原型。

1.4 实时测控软件可靠性评估

软件可靠性是指在规定的环境、规定的时间内，软件系统完成规定功能的能力[2]。

1.4.1 软件可靠性测试

软件可靠性测试更强调测试输入与典型使用环境输入统计特性的一致，强调对功能、输入、数据域及相关概率的先期识别[3]，必须按照实际使用的概率分布来随机地选择输入，并强调测试需求的覆盖面，在测试过程中收集测试数据并使用可靠性模型来计算可靠性指标。这样才能得到比较准确的可靠性估计，找出对软件可靠性影响较大的故障。软件可靠性测试流程如图2所示。

1.4.2 软件可靠性指标

在此仅对实际工程中使用的关键指标进行解释。

a）平均失效间隔时间（MTBF）

两次相邻失效时间间隔的平均值=产品总运行时间/总故障次数。

b）平均失效修复时间（MTTR）

一次故障产生到恢复的时间间隔平均值=总故障时间/总故障次数。

c）可用度（A）

在外部资源得到保证的前提下，软件产品在规定的时间区段内可执行规定功能的能力。

可用度排除了失效产生后可能花费的行政时间和后勤时间，即失效一旦产生，维修人员就在现场。

d）失效率（λ）

产品失效的概率。

e）图3为实际工程中一个简单的计算软件可靠性指标的例子。

产品总运行时间=20+25+50+65+20=180 d=4320 h；

产品发生故障次数=4次；

总的故障恢复时间=2+1+2+2.5=7.5 h；

MTBF=产品总运行时间/总故障次数=4320/4=1080 h；

MTTR=产品总故障时间/总故障次数=7.5/4=1.875 h；

产品可用度A=MTBF/(MTBF+MTTR)=1080/（1080+1.875）=99.827%；

产品失效率λ=1/MTBF=1/1080=0.000925926（1/h）。

对于投入稳定使用并且具有失效后自动恢复能力的实时测控软件系统，我们通常选用可用度或失效率作为衡量软件系统可靠性的指标。在测试过程中，通过执行一系列的软件可靠性估计测试来获取一组统计数据计算可用度及失效率指标，看是否满足该指标的目标值[3]。

2 结束语

软件质量控制是一门涉及多学科、多领域的新兴学科，是保证软件质量、提高其可靠性的重要环节。随着军队现代化建设步伐的加快，新型装备设备的试验鉴定任务日益增多，承担的风险越来越大，同时软件研制领域越来越广，有必要投入更多的人力、物力，针对实际的需求，有目的地对测控软件的研制过程进行质量控制研究，开发相关的支持工具，促进靶场测控软件质量控制及可靠性水平的提高。

[1]张海藩.软件工程导论[M].北京：清华大学出版社，2003.

[2]古乐，史九林.软件测试技术概论[M].北京：清华大学出版社，2004.

[3]GALIN D.软件质量保证[M].王振宇，陈利，王志海，等，译.北京：机械工业出版社，2004.