航天产品的特殊性就在于地面别试验证上天使用，所以务必在产品的天地一致性层面开展有效的工作，首当其冲的就是测试环节，在这个环节往往需要有效模拟上天的使用工况：而实际上，100%的模拟难以实现。

 

同时航天工程作为复杂系统。难以通过一个完整的试验去效证所有环节，需要通过单机测试，系统测试、仿真测试，软件测试和评测，外场验证试验，总装测试等多类型测试去覆益，而在各项测试中往往难以保证所有环节覆盖，尤其是系统间硬件、软件和流程层面的接口。

 

此外，传统的测试仅考虑正向测试，在故障模拟和故障注入层面的工作不够深入，因此在边界测试和压力测试层面存在不足。

 

因此，在实践基础之上，在总结之前项目测试覆盖经验的基础之上，我们提出了基于系统复杂性的五要素测试覆盖性分析方法，以下简单介绍一下：

 

1、五要素方法及内涵

 

五要素是指测试项目中的测试方法、测试状态、测试环境、测试设备、测试指标五个基本要素。

 

 

(1)测试方法包括了正向测试和边界测试（含故障注入、故障模拟），测试手段一般为测试激励注入，根据实际系统的输出判定，能否满足任务要求。正常的激励在系统中一般不会激发出异常，除非系统中存在引入异常的环节，所以故障注入和故障模拟成为重点，这在控制系统仿真试验中一般会做到极致，通过海量的边界模拟给出系统适应性的量化指标，但在其他测试过程中则需要加强对边界，临界工况和最坏情况的测试。

 

从科学的维度来看，正向测试仅仅是测试的一部分而已，从曾经出现的成败型问题来看，无不是一个问题引发下一个问题，一个异常引起下一个异常，如同推倒了多米诺骨牌一样一发不可收拾，固然这取决于故障隔离、重构的设计水平，但如果没有异常工况的测试，也就无从在这两个方面持续取得提升和进步，系统的可靠性和鲁棒性也就无从提高。

 

 

比如我们所熟知的日本卫星的姿态控制，因为控制装置安装错位，在越控姿态愈发发散的前提下，如果没有一种判断和重构机制，则只能是万劫不复的结果。尤其是在复杂巨系统中，是真正可以将蝴媒效应彰显到极致的。

 

(2)测试状态首先是产品（含软件）的技术状态，是否与真正使用工况中的一致。技术状态决定了产品的功能和性能指标达成的水平，研制过程中总会存在枝术状态变化，如果变化本身是否引入异常得不到确认，更无从谈起真正的测试覆盖。

 

我们在日常过程中总是喜欢以守摊儿设备替代，但如果而这技术状态存在差异，也就存在者事实上的不覆盖，直到今日，我们一直还为此付出代价。

 

测试状态其次就是参与工作流程所有设各是否在位的问题，过去我们热衷于研发各种类型的等效器，但实标上更多地仅仅是覆盖了硬件接口，好一点的把软件接口近似覆盖，但数据流、命令/数据响应难以真正模拟，也就造成了实际上应用过程中的极度不匹配。

 

(3)测试环境主要指测试环境和使用环境的一致性，对于天地一致性环境模拟的实际困难，一般是采用分重点模拟不同工况验证，而综合的试验验证模拟手段难以形成，所以分段模拟选取重点就尤为重要。

 

比如我们的桌面联试，就与总装测试存在较大的差别，设备上箭和桌面散布的样式绝对不一样，首先就是电磁的环境就有所不同，电缆的捆扎、固定，设备安装，这些差异带来的变化就对上箭后的电磁兼容摸底提出了具体要求，同样振动、噪声等等环节，需不需要特定的试验，这些都需要深入地分析，如有必要，就不得剪裁一些试验。

 

实际上就测试环境而言，100%模拟上天环境，是一个难度比较大的命题，环境本身就是构成环境本身多个因素相互作用的复合体，所以一定程度上这是一个伪命题，但可以转化为影响成败的环境因素，比如航天器的高低温和空间粒子辐射问题，这是必须要模拟验证到的。

 

使用环境之中也包含了自然环境的因素，虽然我们有验收试验和例行试验，但其覆盖性层面不是一个耦合的结果，因为不同因素只是一个极限工况，并没有太多组合式的应力加入，所以还是应该紧扣成败型的因素去分析和叠加试验应力。

 

(4)测试设备是关键的一环，其能否真正模拟各个使用工况，决定了测试的真正覆盖性；

 

测试设备的能力问题，与上面一点具有强关联性，在系统之后的试验，测试设备基本上不会有大的差别，主要差别就在于单元测试和系统测试的差别，也就是系统使用工况的模拟问题，事实上，单机层面是难以模拟系统使用工况的。

 

单元测试设备，系统测试设备，单元覆盖系统，系统测试覆盖出厂测试，出厂测试覆盖飞行试验，其实从上面的测试环境就已经在事实上不覆盖了，那么此处的覆盖重点在哪里？

 

我们认为覆盖的重点就在于下一级测试项目、测试参数、测试流程的覆盖，而在下一级测试中特别是在系统一级覆盖中，最难的也就是流程的覆盖，涉及到硬件电气接口、软件接口、数据流的交互，这也就是为什么单机一进入系统就会频频出现问题的原因，就是在流程上的不覆盖，造成了一些流程性环节设计不满足任务要求。

 

（5）测试指标包含了两个意思，一个就是被测产品的指标可测性，另外一个就是测试设备所能达到的测试指标，能够测到的环节，在上面已经进行了说明。而指标的可测试性取决于设备的测试性设计，此处不展开。

 

此外还有一点就是测试的时间，也就是覆盖性里面隐含着的充分性问题。在这一方面通过简单例子就可以理解，汽车的大量试验（动辄100万公里级)和飞机适航取证的繁杂试验。

 

2、测试覆盖性保证方法

 

针对于此，一般会有以下要求：

 

(1)型号测试覆盖性工作应以飞行任务或其他既定约束为顶层约束，将产品功能性能分解要求对应的测试项目进行自顶向下分解，分解顺序为总体到分系统、再到单机。

 

(2)测试项目应按五要素比对分析，测试项目设置应遵循“单机覆盖分系统，分系统覆盖全箭，出厂覆盖靶场，地面覆盖飞行”的原则。

 

(3)单机根据任务书和技术条件按功能要求、性能要求、接口设计、冗余设计等分类方法逐一设计测试项目，并进行测试覆盖性分析，确认其覆盖任务书和技术条件的程度。以此类推，完成分系统及总体的测试覆盖性分析和确认工作，最终统计技术指标在单机，分系统或者总体的测试性覆盖情况。

 

(4)各级测试项目设置及测试覆盖性分析一般应经过上一级或任务提出方的认可。

 

(5)各级测试覆盖性分析应设定是否覆盖的判别准则和是否接受的放行准则，判别准则和放行准则需经过上一级或任务提出方的认可。

 

(6)测试不覆盖的项目应提出处置措施，不可接受的测试不覆盖项目应明确控制措施，开展风险分析。

 

以上重点加粗了(3)(4)(6)，是因为在日常出现的质量问题中，这是关联度最高的三个环节。

 

整体而言，在单纯的电气接口和软件接口层面，可以通过严格细致的任务书进行约束，关键就在于工况的模拟，这个工况大多时候难以通过任务书进行传递，或者说在进行传递时被忽略了，而在近几年电气层面的问题已经越来越少，取而代之的就是软件接口层面的问题，数据流的交互，响应及时性、竞争与冒险等问题较为多见。

 

这中间还有一个就是单机输出负载的问题，到底是多少，需要系统和总体交代清楚，比如初始化，比如真正的负载电流等。

 

测试项目的上一级确认显得尤为重要，因为上一级熟悉系统工况，知道在什么节点让你以怎样的效率完成任务。

 

我们都在开展不覆盖项目的分析，但是容易忽略一个关键的点，那就是流程性的覆盖，尤其是对于使用流程的覆盖，这是一个涉及到多个系统的覆盖，实践证明，但凡没有见面和调试过的分系统，一般会出问题，自然也是越自负的越容易出问题。要额外关注流程转化的问题，其实就大流程而言，不存在所谓的流程转换，主要因为人为地将大流程分割为多个流程，而在转换时没有充分地考核和验证，包括状态的准备等。

 

3、测试覆盖性保证流程

 

(1)测试项目分解

 

在型号研制的方案阶段，以飞行任务或其他既定约束为顶层约束，结合型号测试性大纲要求，将产品功能性能分解要求对应的测试项目进行自顶向下逐层分解，从总体到分系统，再到单机，确定测试覆盖性分析对象及项目。

 

此处就得结合单机测试和单元测试的实际达成的效果，决策系统测试、专项补充测试、出厂和靶场测试的重点，除了自检之外，就是表征系统和单机的重要参数，除了通过BM记录下所有数据备查之外，所选取的测试参数要足以表征系统和单机的好坏。

 

(2)单机测试覆盖性分析和检查确认

 

单机产品的出厂检查、测试应全面覆盖单机任务书和技术条件所规定的项目，以及在单机或分系统设计确定的设计要求中需要测试和检查的项目。单机产品的检查、测试应覆盖上一级分系统测试中对单机的检查项目，未覆盖的项目应加以分析，要有不影响分系统试验的结论，并得到分系统负责人的确认，同时提出分系统测试需求（如果在下一级测试中仍然没有被测试到的可能，则必须回归到单机层面的专项测试或确认，比如雷达设备的探测距离等)。

 

一般而言，单机产品在单元测试及出厂后不能覆盖且无法通过分系统测试覆盖的项目，应在产品图纸下厂前按照“测试不到验收到、验收不到检验到、检验不到工艺保证到、工艺保证不到人员保障到”原则进行分析，并在产品验收、检验、工艺及人员保障各环节采取措施，形成记录，证明产品在各种状态下可以满足设计要求。

 

如前所述，除了单机的本质失效之外，更多的是流程交互、数据流的问题，在没有系统等效器的前提下，如何最大限度地模拟系统工况，成为了单机测试设备研发的重点和难点。

 

同时，有一个关键的点不容忽视，那就是经过了所谓单元测试或工厂测试的新研产品，以及许久未使用的设备，在接入系统后存在不存在对系统的致命性后果，如甫上电之时，系统自然要进行相应的确认工作，如供电和输入、输出接口的复测，最大限度地规避问题。

 

(3)分系统测试覆盖性分析和检查确认

 

分系统测试覆盖性分析和检查确认主要结合分系统的综合试验、专项试验、半实物仿真试验等工作开展。分系统测试应全面覆盖分系统任务书和技术条件所规定的内容，包括任务书、技术文件所规定功能和性能指标的测试情况，分系统级异常情况下的处理功能、冗余设计等。分系统测试应对单机间协调性、匹配性进行检查确认，如对极性正确性。分系统测试应覆盖上级全箭测试中对分系统的检查项目，未覆盖的项目及不影响全箭试验的结论应得到总体确认，同时提出全箭测试需求。

 

整体而言，分系统以上的测试已经难以从性能层面开展更为深入的测试了，比如总装除非单机因设计和生产引入的问题，更多的应该是流程性匹配的问题，也就是全部的系统接入后，流程的匹配性和适应性。

 

此时既然经常容易出现因为个别设备不在位而导致的质量问题，那么索性就进行两种类型的试验，一个是全在位，一个别不在位，看整个流程运行是否符合预期，自然也要考核贮备冗余的切换。

 

(4)全箭测试覆盖性分析和检查确认

 

总体测试覆盖性分析和检查确认主要结合全箭系统间匹配试验、出厂测试等工作开展。全箭的测试应全面覆盖靶场及飞行状态的各项功能要求，分系统间的接口及分系统级冗余设计等。全箭测试应对分系统间协调性、匹配性进行检查确认，如对极性正确性。

 

全箭测试、试验应覆盖靶场测试中对全箭的检查项目，未覆盖的项目及其不影响靶场试验的结论应得到总体确认，同时提出靶场测试需求。对分系统提出的不能覆盖的项目，应给出是否通过全箭测试覆盖的结论。

 

全箭测试未覆盖技术指标要求、不能进行实物对接的接口及靶场测试项目，应通过计算、仿真和过程控制等验证方式进行管控。

 

此处强调一点就是预案，预案的演练，以及相关逆流程的演练，流程走不下去之后，我们如何走向安全和断电，走向撤收，这个不容忽视。

 

(5)靶场测试覆盖性分析和检查确认

 

对全（箭）提出的在全箭测试中不能覆盖的项目，给出是否通过靶场测试覆盖的结论。靶场测试未覆盖且在单机、分系统、全箭也未覆盖飞行状态各项功能要求的项目，应通过计算、仿真和过程控制等验证方式进行确认。

 

流程的覆盖和信息交互的确认，应该靶场测试覆盖性关注的重点，这个流程是大流程以及构成的小流程，要逐一进行测试的覆盖，一般项目都有合练和演练，要在此项工作之前做足工作，也要充分利用好合练和演练的机会，不要漏掉任何一个看似无关紧要的环节。

 

 

此处补充流程性覆盖的例子：运载的三级覆盖。

 

Ⅰ级覆盖 ：火箭出厂前测试覆盖发射场 测试；

 

Ⅱ级覆盖：地面设备恢复检查工作可以覆盖发射场实际测试、 使用工况；

 

Ⅲ级覆盖：发射场负 3 小时前测试覆盖进入负 3 小时发射流程后测试。

 

《面向运载火箭的测试覆盖性分析方法研究》，张聪，《质量与可靠性》，2017年第1期。

 

除了预案之外，还有一点，就是靶场留守设备的检修，以及备件的准备，以及超期使用设备的更换和问题的交底；通过检修，最大限度地避免问题发生，通过交底，最快地处置质量问题的发生。

 

(6)软件测试覆盖性分析和检查确认

 

软件研制过程中，软件设计人员编写软件测试覆盖性分析汇总表，结合软件验收对软件测试覆盖性进行检查，对不能覆盖的软件应采取措施。全箭出厂前，软件设计人员完善软件测试覆盖性分析汇总表，逐级确认并上报，总体汇总后将软件覆盖性分析有关内容纳入全弹（箭）出厂前测试覆盖性分析专项报告中。

 

此处需要关注A/B级软件评测的环节，100%分支覆盖的要求一定要达成，重点关注单机、系统测试中故障注入后难以模拟的环节，在测试用例的设计层面加大投入。

 

(7)测试数据判据和数据判读、分析

 

既然是测试覆盖性，那么测试数据的分析和判读就尤为重要，这首先是测试判据的制定，在测试数据没有足够的子样积累之前，这主要是取决于设计、仿真的结果，此时数据的上下限和合理偏差的确认极为重要，过宽、过严都不行，需要一个合理的分析，甚至于仿真。

 

当数据积累到一定程度之后，判据可以根据包络分析结构进行适当的修正，但仍然要考虑、器件、系统环境差异带来的偏差。

 

数据判读要有及时性，数据记录考虑全面性，数据表征要有代表性，但全面的数据判读至少要做几次，力争发现一些隐匿的问题。

 

此处需要额外关注超差和部分参数的裕度问题，哪些可以放，需要论证和分析，而对于裕度，则需要根据工况进行深入地仿真验证，裕度必须要留够，避免系统失稳和控制发散。

 

(8)测试覆盖性分析中的问题导向

 

测试覆盖性好坏，带来的是在下一级测试中对上一级测试后遗留问题暴露的多寡，自然我们希望在上一级测试中解决掉大多数问题，但事与愿违，表现出来的永远是层层闯关，分析出来的原因又都是该测试到未测试到，所以我们必须以问题为导向，剖析是测试方法的问题还是管理流程的问题。

 

现在来看，大多数是流程管理的问题，以及好的方法没有得到秉承和延续的问题，所以此处的问题导向就是要通过分析，给管理提个醒儿，序时性要保证，切不可颠三倒四。

 

4、小结

 

(1)先表扬一下：

 

五要素测试覆盖性分析方法，明确了测试覆盖性定义，将地面设备恢复、接口匹配、现场设计、总装等各环节工作纳入测试的范围，扩充了测试覆盖性分析对象及范围，将地面设备恢复、接口匹配、现场设计总装等各环节工作纳入测试的范畴。

 

制定了覆盖性分析确认判据，按运载火箭发射流程的不同阶段制定了三级覆盖性判定准则，具有时间性的判定准则，打破了原有测试覆盖性“一刀切”的判定困局，“化整为零”形成了面向阶段的测试覆盖性分析方法。

 

其细化了测试覆盖性量化分析要素，通过对测试项目内涵要素进行比对分析，包括测试方法、测试状态、测试环境、测试设备和测试指标等要素，可以深入查找火箭全生命周期各个阶段要素差异性，细化了分析方法的颗粒度，加强了分析方法的筛选性。

 

规范了测试覆盖性分析流程，建立基于测试的广义测试覆盖性分析流程，即技术指标要求自顶向下分解，测试覆盖性自底向上和自顶向下相结合开展，形成“正向设计”到“逆向验证”闭环分析回路的流程。

 

(2)重点再突出一下：

 

测试方法、测试状态、测试环境、测试设备、测试指标，这是关键的五个要素，除此之外还有人员的质量意识问题，这个自不必展开

 

这五个要素，都很重要，不可抛却任何一个。测试覆盖性，首先是责任的担当，自上而下和自下而上。系统要考虑单机，对单机测试要提要求，单机也要交底，哪些参数需要专项补充试验测试，因此需要建立这样一种思维，也就是整体性 —— 一体化思维。

 

其次是逻辑的理顺。想要什么，就要测什么，万事万物皆可度量，关键就看在什么节点度量，可前置，可正当时，但不可后置。

 

但能否根据五要素法做好测试覆盖性分析和测试覆盖，主要取决于工作的细致程度。

 

参考资料

 

1、《面向运载火箭的测试覆盖性分析方法研究》，张聪，《质量与可靠性》，2017年第1期

 

后记——再说系统复杂性

 

1、复杂系统的特性

 

一般认为复杂系统具有以下特征：非线性（不可叠加性）与动态性，也可以理解为不确定性和确定性的相互作用和转化。

 

非线性（即不确定性）是产生复杂性的必要条件，没有非线性就没有复杂性。复杂系统都是非线性的动态系统。

 

非线性说明了系统的整体大于各组成部分之和，即每个组成部分不能代替整体，每个层次的局部不能说明整体，低层次的规律不能说明高层次的规律。每个子系统具有相对独立的结构、功能与行为。各组成之间、不同层次的组成之间相互关联、相互制约，并有复杂的非线性相互作用。动态性说明系统随着时间而变化，经过系统内部和系统与环境的相互作用，不断适应、调节，通过自组织作用，经过不同阶段知不同的过程，向更高级的有序化发展，涌现出独特的整体行为与特征。

 

2、航天系统工程和工程系统特点

 

科技成果之大成，即需要综合运用相关专业领城最前沿的研究成果，这使得航天工程成为校术先进性最为突出的复杂工程系统。

 

复杂性是指跨学科集成，跨行业协作，系统庞大，参与人员众多，技术和管理复杂性高。

 

高风险性是指航天产品需要在近乎无雄护支持的情况下，以自主运行模式完成任务航天产品在经过反复综合集成和系统优化之后，其各组成元素之问存在高度的交互关联关系，某个局部的细微问题或异常，均可能导致工程系统整体的功能衰减甚至失效，进而造成严重后果。

 

航天工程系统作为复杂系统即具有复杂性，其复杂性的度量值为其复杂度，系统的复杂度取决于系统复杂度模型，但面临的具体问题就是模型的建立绝非易事。

 

航天工程系统及其各级各类工程产品主要运行在大气层外，其研制和应用需要适应硬件不可维护和外层严酷空问环境等特殊要求，航天工程系统及其产品的研制活动一般具有探索性先进性，复杂性，高风险性的突出特点和高可靠、高质量、小子样研制及一大成功的特殊要求。

 

探索性是指在航天工程实践中，科学、技术和工程何题相耦合，给航天工程实施荐来众多不确定性。

 

先进性是指航天工程系统和产品研制需要集最新科技成果之大成，即需要综合运用相关专业领城最前沿的研究成果，这使得航天工程成为技术先进性最为突出的复杂工程系统。

 

复杂性是指跨学科集成，跨行业协作，系统庞大，参与人员众多，技术和管理复杂性高。

 

高风险性是指航天产品需要在近乎无维护支持的情况下，以自主运行模式完成任务，航天产品在经过反复综合集成和系统优化之后，其各组成元素之问存在高度的交互关联关系，某个局部的细做问测或异常，均可能导致工程系统整体的功能衰减甚至失效，进而造成严重后果。

 

同时系统产品开发过程中有以下具体特点，即多专业融合，多单位参与、多阶段安排、多项目并行，多领域任务，多重大工程，多标准评价、多体系要或等，使得质量控制面临诸多难题，上述八个维度的耦合和交织，从实际研发过程中增加了难度，在一定程度上降低了整个系统研发的可控性，增加了系统研制的风险。