航天嵌入式软件隐含需求分析与实践

左万娟,王小丽,黄 晨,董 燕

(1.北京轩宇信息技术有限公司 软件测试部,北京 100190; 2.北京控制工程研究所 软件检测站,北京 100190)

随着软件定义卫星设计理念的提出,航天软件的规模日趋壮大,软件在航天器中所承载的作用愈显突出。然而,航天器在轨运行期间的软件问题也不断显现,究其根源,由需求分析缺陷所导致的软件缺陷不容忽视。

根据中国空间技术研究院软件产品保证中心的统计数据,航天器软件第三方评测阶段所发现的软件缺陷中,与需求缺陷紧密相关的缺陷占比达50%以上,其余缺陷也均与需求缺陷存在或多或少的关联。

著名航天软件专家Nancy Leveson总结软件在航天任务事故中的作用时曾言:“几乎与软件相关的航空航天事故都与软件需求缺陷以及对软件需求的错误理解有关。”[1]有40%的软件项目的失败来自于软件需求的模糊[2]。

无论是软件需求缺陷还是对软件需求的错误理解,其根源都在于需求分析。如何把软件需求分析切实做到位,业内开展了很多研究。但是,大多数的研究都基于项目开发的角度,着眼于软件开发需求的分析[2-7],基于测试角度的需求分析研究则较少。

开发需求分析重点解决的是需求从无到有的问题。而基于测试角度的需求分析,则是在已有的显式需求和代码基础上,通过隐含需求分析,实现对显式需求和代码的完善与修正。

本文基于软件测试的角度,聚焦隐含需求分析研究,着重从白盒测试的角度,开展航天嵌入式软件隐含需求分析研究,其研究成果不仅适用于软件测试方,而且对软件项目相关方同样具有参考价值,有利于在软件研制的早期阶段规避因需求缺陷而引入的不良后果。

1 隐含需求分析的重要性

隐含需求,又称隐式需求,指未予以明确说明的软件必须实现的需求。这部分需求一旦未予实现或实现错误,通常都会带来严重的不良后果,导致软件的某些特性不满足用户要求,甚至软件无法正常运行,进而引发客户的强烈不满。隐含需求是培养客户忠诚度的关键内容[8]。无论是软件项目研制相关方还是软件测试方,均应对这些潜在的需求予以分析。工程上,测试方可以对项目研制相关方的需求分析缺陷给予有效的完善与更正,规避因隐含需求未实现或实现错误而引入的不良后果,确保软件质量。

隐含需求分析的目的是将隐含需求显性化。隐含需求显性化可以带来以下好处:

① 接受专家评审,对相关需求合理性做出判定,规避不合理需求。

② 正确指导编码和测试。

③ 有效避免测试遗漏。

2 隐含需求产生原因及常见分析方法

通过工程实践分析与总结,综合已有研究成果,隐含需求产生的原因主要有:

① 用户需求不明确,用户对自身需求比较模糊[9]。

② 分析疏漏,需求分析工作不够完善[10]。

③ 分析能力不足,需求分析人员对系统缺乏全面认识[10],或对新技术缺乏全面了解[11]。

④ 心理默认,心理假设该需求为默认需求,认为无须明确说明。

⑤ 颗粒度不当,需求分解和细化程度不够。

业内针对隐含需求分析方法也进行了大量研究,提出的隐含需求分析方法包括但不限于:用户访谈[5]、情节串联[5]、用户故事[6]、问题驱动的需求诱导[7]、实地观察[12]、情景调查[12]等。从适用性角度而言,这些方法更适用于非嵌入式软件研发过程及其黑盒测试场景。

3 航天嵌入式软件隐含需求分析方法

基于对已有研究成果的理解与思考,结合多年的航天工程实践,从测试角度出发,对航天嵌入式软件的隐含需求分析开展了有针对性的研究与总结,提出了新的分析方法和思路。

3.1 概述

白盒测试是航天嵌入式软件的主要测试技术手段之一,静态测试阶段要对代码进行逐行的人工审查、分析和确认。借助白盒测试过程中对代码设计的充分理解与分析,结合多年工程实践,研究构建了航天嵌入式软件隐含需求分析框图,如图1所示。

图1 航天嵌入式软件隐含需求分析框图

如图1所示,针对航天嵌入式软件,从软件测试方的角度出发,以需求和代码为输入,隐含需求分析着重于3个方面:需求颗粒度分析、代码设计无依据分析和引申推导分析。

通过分析所得到的隐含需求,经过同行专家和项目总体的评审[13]之后,一方面用于完善当前项目的需求、编码及测试,另一方面可将其纳入隐含需求库,用于指导后续项目的相关工作。

为方便后续管理及应用,建议从测试类型[13]角度对纳入隐含需求库的隐含需求进行分类、收集和整理。

3.2 需求颗粒度分析

结合代码设计,对比分析显式需求中的需求描述颗粒度是否过于粗大或是否存在疏漏,疏漏部分即为隐含需求,与项目相关方沟通确认后,应在测试需求中予以明确,并由项目相关方完善需求,必要时应完善代码设计。

以航天软件常见的三取二需求为例,对需求颗粒度分析过程的说明如下。

首先,分析显式需求。发现显式需求中仅规定对某些重要参数做三取二处理,但是未规定具体处理策略。

然后,分析代码设计。确认代码实现策略为:任意两区相等时,取相等两区的数据作为三取二结果;三区均不等时,取一区的数据作为三取二结果。

进一步分析代码实现策略的合理性,发现“三区均不等时取一区数据”的策略不合理,因为三区均不等状态下,无法确认一区数据是否有效。

针对上述分析结果,与项目相关方进行沟通,最终确定处理策略为:任意两区相等时,取相等两区的数据;三区均不等时,进行三区数据按位三取二。

处理策略确认之后,项目相关方负责完善需求、修正代码设计,测试方负责按照既定需求完成相关测试。

3.3 代码设计无依据分析

通过对代码的逐行分析与确认,对比显式需求,识别代码中的无依据设计。首先分析无依据设计的实现结果。然后与项目相关方沟通该部分设计的合理性和必要性,确认无依据设计是属于需求描述遗漏还是属于代码多余设计问题,如属于需求遗漏,则归为隐含需求,在测试需求中予以明确,并由项目相关方修改需求;如属于多余设计,则由项目相关方修改代码、删除多余设计;如经沟通后确认无依据设计必要但存在不合理性,则归为隐含需求,由项目相关方修改需求和代码。代码设计无依据分析示意图如图2所示。

图2 代码设计无依据分析示意图

其中,分析无依据设计的实现结果是非常有必要的,这可以避免测试方在与项目相关方沟通过程中的盲目遵从性,避免单纯依赖于项目相关方获取无依据设计属性(需求描述遗漏、代码多余设计)的判定结果,从而充分发挥白盒测试优势、获得最优的分析结果。

以某指令处理为例,对代码设计无依据分析过程的说明如下。

在代码的逐行分析与确认中,通过与显式需求的对比,发现代码中存在无依据的控制指令输出,即控制指令输出相关的代码没有对应的需求。

与项目相关方沟通上述无依据设计的属性(需求描述遗漏、代码多余设计),由项目相关方确认,由于项目研发过程中的需求更正,这部分代码对应了新增需求,但是新增需求未及时补充至显式需求,导致出现无依据代码。

需求确认后,由项目相关方负责修正需求,测试方负责按照既定需求完成相关测试。

3.4 引申推导分析

以显式需求和代码设计为出发点,通过对代码的逐行分析与确认,理解代码设计,结合软件应用背景,分析需求及代码设计的合理性、全面性,引申推导出可能的隐含需求。这种引申推导出的隐含需求可能是对某一显式需求的更正与完善,也可能是为支持某显式需求而必然存在的需求。引申推导分析示意图如图3所示。

图3 引申推导分析示意图

引申推导分析是在显式需求和代码设计基础上的更进一步的合理性和全面性分析,通过分析现有需求和代码引申得出的隐含需求主要有2类,即完善性隐含需求和支持性隐含需求。

需要注意的是,这种引申出来的需求,可能会与原有的显式需求自相矛盾,因此需要开展需求匹配性分析,并在必要时加以修正。

对于主备单机+冷备份的硬件架构,针对主份故障后断电再加电(即主份断电备份加电、一定时间后再备份断电主份加电)的显式需求,引申出可能存在的主份持续故障状态,需要沟通确认主份持续故障的处理策略,并完善需求。针对此类极端故障,通常要首先确保不会发生持续反复的主份断电再加电,其次要明确永久切备份的时机和条件。由此引申出的需求属于完善性隐含需求。

对于主循环+中断的软件架构,如果主循环或中断的处理时间过长,可能会影响到某些处理的及时性,从而需要结合相关处理的及时性要求,引申推导出对主循环及中断处理时间的限制性隐含需求,并沟通确认相应的性能指标。由此引申出的需求是为支持其他需求而必然存在的需求,属于支持性隐含需求。

下面以航天软件中常见的指令重发机制为例,对引申推导分析过程进行说明。

① 需求规定:指令发出后,未收到正确反馈,则重发指令。

② 代码实现:每发出一条指令,都要查收反馈,未收到正确反馈,则重发指令。

分析需求的合理性和全面性,引申出针对指令重发后仍然得不到正确反馈的情况,缺乏明确需求。

分析代码设计的合理性和全面性,引申出针对指令重发后仍然未得到正确反馈的情况,代码实现为继续执行指令重发,即针对指令发出后始终得不到正确反馈的情况,代码会不停地执行指令重发。

与项目相关方沟通上述分析结果,最终确认需求为:指令发出后,未收到正确反馈,则重发指令。上述指令重发机制仅执行一次。经确认,上述需求与原需求之间不存在矛盾之处。

需求确认后,由项目相关方负责完善需求并修正代码,测试方负责按照既定需求完成相关测试。

3.5 小结

与非嵌入式软件不同,航天嵌入式软件很少具备人机界面,因此与人机界面相关的隐含需求分析方法未予阐述。

重点关注的3种分析方法中,需求颗粒度分析和代码设计无依据分析的隐含需求来源相对固定,分析难度相对较小;引申推导分析的隐含需求来源庞杂,更依赖于人的逻辑思维能力以及领域知识和经验,分析难度相对较大。但是通过这种方法分析得出的隐含需求对软件质量和客户满意度的提升效能也最大。

在工程实践中,3种分析方法通常并不孤立,需要结合应用。在工程应用中,3种分析方法都需要同时关注需求和代码设计的合理性,这也是航天嵌入式软件静态测试中充分发挥人的主观能动性的一个显著特征。

应充分应用通过分析所获取的隐含需求,具体应用如下:

① 指导完善当前项目的需求和编码。

② 与显式需求一起作为软件测试设计的输入。

③ 充实隐含需求库,用于指导后续项目的需求、编码和隐含需求分析。

4 航天嵌入式软件典型隐含需求

隐含需求来源庞杂,需要具体问题具体分析。在多年的航天器软件第三方评测工程实践活动中,通过开展需求颗粒度分析、代码设计无依据分析、引申推导分析,在隐含需求分析方面已经积累了大量的成果。下面从接口、可靠性安全性、恢复性、性能、功能等不同测试类型[13]角度,给出航天嵌入式软件的若干典型隐含需求及其相应的分析方法。若能在研发过程的初期关注并明确相关隐含需求,不仅有利于软件的全方位协同设计,而且也能为软件测试设计提供指导。

4.1 接口隐含需求

显式需求中,针对接口,通常能够明确接口地址、接口方式、通信格式和内容。但是,一些典型的接口隐含需求容易被忽略,具体说明如表1所示。

4.2 可靠性安全性隐含需求

航天嵌入式软件通常都会适度开展可靠性安全性设计。可靠性安全性典型的隐含需求及其首要分析方法如表2所示。

表2 可靠性安全性典型隐含需求及其首要分析方法

其中,输入合法性校验相关的隐含需求分析重点在于校验的全面性;抗单粒子翻转相关的隐含需求分析重点在于明确保护对象和处理策略;极端故障处理相关的隐含需求,通常是由于项目相关方未考虑到相应的极端故障工况而导致的显式需求的缺失,其分析重点在于明确极端故障工况及其处理策略。

4.3 恢复性隐含需求

考虑到在轨运行环境的复杂性和软件在轨运行的高度自主性,通常会对航天嵌入式软件进行适度的恢复性设计。但是,在此过程中,经常会因显式需求遗漏导致出现隐含需求。恢复性典型隐含需求及其首要分析方法如表3所示。

表3 恢复性典型隐含需求及其首要分析方法

4.4 性能隐含需求

航天嵌入式软件通常采用主循环+中断或者多任务+中断的软件架构。其中,任务处理时间通常在显式需求中会予以明确,但是针对主循环和中断的处理时间鲜有说明。性能典型及其首要分析方法隐含需求如表4所示。

表4 性能典型隐含需求及其首要分析方法

4.5 功能隐含需求

功能隐含需求需要结合具体功能进行具体分析。表5给出2个典型实例的具体说明。

5 结束语

本文从软件测试的视角,借助全代码人工审查的白盒测试实践,重点阐述了航天嵌入式软件隐含需求分析的3种主要方法,这3种方法有助于提高测试过程中隐含需求分析的效能,既能弥补研发过程的不足,又能充分指导测试。

但是,隐含需求是客观存在的,隐含需求分析始终是工程上的难点,目前还没有彻底的解决方法,需要相关科研人员在软件研发、测试等各个环节,通过隐含需求显式化不断地加以完善。从工程角度而言,建立行业性、领域性的隐含需求库是一个值得推荐的方法,后续还可以借助人工智能手段实现包含隐含需求库、共性需求库、共性用例库等在内的知识库系统的智能化管理与应用,从而有效弥补人员的领域知识和经验不足的问题。