几年前，针对某些产品在交付综合试验以及之后的系统级试验中问题不断，暴霹出各种类型的质量问题，于是乎参照电子元器件、原村料的入所(厂)复验、复测的模式，开始论证电子产品的入所(厂)复验方案以及条件建设。

当时做这件事的初衷是好的，也就是通过验收试验后、进入系统试验前的某种特定的复验，针对重点单机的重要接口（软硬件）、指标以及系统匹配性等层面，开展具体的验证，将问题提早暴露。但实际上到最后，囿于成本、投入以及增加工作后本身的意义等诸多因素，最初策划的复验没有走下去，但通过梳理，在前期测试覆盖性、测试数据包的提供等诸多环节也向前走了一步。

最近，针对总装我们又提出了类似的想法，也就是在总装厂，针对各系统提交的设备，能做哪一些较之外观检查、证明性文件检查之外的较为深入的工作。

以下针对这两方面的工作，进行一些分析，以便于更加逼近问题的源头和发力的重点方向：

一、单机验收后交付系统使用之前

1、配套厂的确信和我们的不确信

我们与之交互的主要是靠任务书，问题多发的主要是较为复杂的单机设备，依靠图纸生产的简单单机一般不太会出现一进入系统试验问题不断的情形。而任务书在传递技术要求层面有其先天性的缺点，也就是结果导向性太强，更多的要求也就集中于所谓的功能、性能指标的要求，这些要求来自于经过加入一定偏差、干扰后的数学仿真，以及对于电气产品诸如机械、电气、软件接口及重量等相关的基本要求。

就这部分内容的满足性而言，在经过了单机层面的相关试险后，配套厂是确信的，尤其是就其中某一个有一定难度和高度的指标更是相当确信。但设备在系统中运行起来之后，在与其他单机/系统的开始了频繁的信息流交互之后，容易出现在系统使用工况、临界、边界条件下的不适应。

而这恰恰是系統和总体的不确信。

另外一个我们的不确信正是配套方极其确信的诸如接口环节，因生产过程而引入的一些层次不高的问题。

当在系统测试过程中不断出现问题，尤其是非技术原因导致的问题增多时，系统会越发不确信，包括对配套方的技术实力、任务要求实现的完备性，当一个新研复杂单机进入系统之后，这一点表现得尤为突出。

一个新研产品进入系统，必定会有诸多的技术问题，但在当前一般为非技术问题所掩盖，实际上复杂单机在进入系统级测试之后，也包括系统级的专项测试，必定是会发生和解决诸多的技术问题，这个不容置疑。

其实，这里面始终包含了四个层面的问题：

1)技术本身

总会有认知不到和技术水平未达到的环节，承认与否，这个是现实存在的，所以针对配套方的承诺也好、自信也好，要有一个清醒的应对，那就是针对性的试验验证，怎么快速地通过试验去暴露一些问题，改进一些环节，所说的试验包括单机出厂前的专项试验。

2)技术要求的传递和理解一致

在任务书中，一些冰冷的以数据和图表表征的要求，有时会因理解不一致而凸显其二义性，所以必定要有针对性地做好技术指标的协调一致和确认，最好是在达成一致后在任务书中细致地明确下来。

3)系统测试工况的传递

单机对系统使用工况的不掌握，其只知道输入和输出，而不知道在整个链路上信息流的交互，命令的响应，以及诸多并行、串行工作以及些许偏差而引入的整个系统的不匹配，自然这是系统关注的点，既然存在类似情形，那么系统就有必要在软件协议之外，将系统使用工况对单机进行必要的说明，让其考虑并尝试通过试验去验证一些工况下单机响应、输出的正确性。

4)单机生产过程的质量管控

为了赶工期，这个一定普遍存在，导致我们放松过程的管理闭环，使得一些细致的确认性工作无暇顾及，这些最终显性化为质量管理水平低下，出现许多层次不高的问题，实际上形势也未必像看到的那么严峻，最为关键的就是在当前研制模式下，如何将工作策划好，将一些事情做在前面，避免赶工引入慌乱而导致问题发生。

2、在哪个阶段如何做到确信

经过上面分析来看，需要聚焦任务源头、输入、生产/试验的过程。

1)在技术转化为工程实现的进程中，总会有一层窗户纸，从原理层面来讲过于简单，但到了具体实现层面，受制于各个环节的偏差，一般会偏离预期，所以技术实现和转化为产品之时，更多的工作在于纠偏，在于重要参数和整体性能的优化，而这个优化只能在方案之初、生产调试、专项验证试验过程中去实现。

2)产品使用方视角来看，一定是参数越优越好，无论是个别参数还是整体指标的满足性，但作为承担方，需要从中找到一个平衡点，技术难度、可靠性、质量水平、成本都要去考虑，因此就需要双方就技术要求的细节和指标达成一致意见，同时要对要求的理解达成一致，补充必要的细化要求纳入任务书。

3)系统测试、使用工况的有效传递，能够很好地在源头进行单机测试的针对性设计，通过单机测试尽量覆盖系统测试和使用工况，在先期测试中尽可能多的暴露问题，消除和补短板，这个工况并非专指测试、使用环境，最为关键的就是在相关测试和使用流程中命令的响应和数据的交互，以及在与不同分系统的命令响应和数据交互的集合之中，按照既定模式运转的顺畅性。

4)而生产过程的质量控制，是规避所有层次不高问题的有效环节，大部分隐藏着的问题，也就是在这一阶段埋下，此处需要强调的依旧是工艺、规程的细化和量化，以此规避掉错误、遗漏、多余物等问题。

总而言之，就是要在前期在设计生产过程中，规避掉非系统匹配性问题(接口不匹配不包含于此)，而其中的难点就在于系统使用工况的模拟，当前90%以上的单机做不到这一层次，所以进入系统后问题不断。

3、接入系统之前究竟要确认什么

1)接口和技术状态的确认

针对首次接入系统的设备，主要指的是新研或借用产品首次接入系统，此时需要关注的就是设备的电气接口、软件接口的确认，通过这些软硬件接口确认，规避平时常说的烧设备情形。之所以聚焦在硬件接口和软件接口，就时因为初始化后硬件、软件接口输出可能存在无序状态，一些随机的输出会造不小的麻烦。

针对成熟产品，需要确认的就是设备的技术状态是否是预期的，是否已经按照要求进行了软硬件的升级。在一个项目研制过程中，产品的技术状态总是在不断地迭代变化过程之中，也就形成了一系列的产品，囿于各类型试验数目较多，容易造成产品技术状态非预期或非最终状态，因此整个产品再介入系统之前需要就此进行细致的确认。

2)关键数据的确认

其实这是我们提出复测的真正起因，也就是源于我们得不到足以表征产品质量水平的过程数据和结果测试数据，而得不到的原因有两个：一是一些关键过程本身就测试不到（其实万物皆可度量，主要看需不需要测，想不想测，在什么时间点测)；二是即使能测试到也未按照数据包要求提供相关数据。

在产品验收过程中，我们接触较多的是过程工艺参数、检验以及最终测试的数据，通过这些数据的分析和确认，可以得出某产品质量是否受控和达标的结论。

既然产品已经验收，那么这些数据是否就不必在产品接入系统前忽略呢？这里面又会有几种情形，一种就是已验收产品是谁验收的，这个是比较关键的，如果不是系统使用方，则其完全有必要对相关数据进行确认；一种是未验收产品，这在当前比较常见，这更需要不同专业针对产品的不同过程、测试相关数据进行确认。比如针对惯性器件，综合需要确认的是电气和软件接口，知道制导姿控专业关注的就是误差模型中各项参数的符合性，偏差的离散度，以及是否按照要求进行了动态指标的测试等。

3)必要的复测/确认

主要是针对一些参数的复测，目标是明晰的，需要测什么必须弄清楚，不做无用功和重复性工作。这个绝对不能扩展为验收试验中所能测试到的所有项目，就会义无反顾地舍弃了单机测试覆盖系统测试的初心。

①理想的情况：

系统使用过程中各项参数均可测试，单机测试也可以覆盖，那么此时不需要针对这些参数的复测，可以直接通过交付数据进行必要的确认。

实际上这一理想情况不经过充分的工作是难以实现的。

②现实的骨感：

单机测试不到，系统可以测试到，也就是现实中的常态，主要是系统使用工况下的一些参数，以及这些参数深入分析后所反映出的产品在系统工况下的性能指标的满足性。

既然单机测试不覆盖，也就失去了入所（厂）复测的基础，因为这些指标只能在系统测试中去确认，也就是想方设法的非系统测试如果行得通，为什么不让单机测试去覆盖？！

而接入系统的先期测试，如综合试验的调整期，是叫作单机的验收阶段，还是产品的入所复测阶段，叫什么已经没有意义，唯一的真相就是单机未覆盖系统测试，产品和数据即便一起送达，也表征不了产品真实的质量水平。那我们究竞要解决什么问题？

很简单，就是如何规避单机出厂前应该暴露问题在系统测试中再次发生，或者说没有征兆地发生。

③选择什么，放弃什么

对于不覆盖的，要么想办法在单机阶段覆盖，实在覆盖不了的我们认命，那就在“单机的系统验收阶段”或者“调整性试验阶段”解决诸多问题。

对于能覆盖的，我们就去确认数据。

对于能覆盖且关乎接入安全的环节，那就聚焦电气、机械、软件接口，一个比较常见的例子就是针对首次接入系统的设备、电缆去确认接插件的点号，相关点号的导通和绝缘（注意不该绝缘的点和有电气连接的点），通过再次确认，规避一些严重的问题。

4、所有问题的内在就是测试覆盖性

在最初的复测论证中，我们引入了与单机测试一致甚至于更为细化的测试要求和资源，以期获得更为细化、翔实的测试数据，整体而言投入较大，关键是增加了系统单机验证的流程，增加了测试的时间和成本，而此项工作如果在前期的单机测试中得以覆盖，无论是在效率和效益层面，都会做到更好。

至此，所有的问题都指向了产品研制/生产过程中的测试覆盖，也就是谁的责任谁来负，为下一道工序提供合格的产品，而合格产品由下一道工序来进行定义。

这个定义就要求系统和单机，上下工序之间的交互，将系统的使用工况测试环境、测试要求完美地传递给单机，并与其一起搭建适宜的测试环境，然后获取关键的测试数据。

二、单机/子系统交付总装上装之前

在以往的交付过程中，我们强调了产品的外观检查、质量证明文件的齐全和完备，这在前期发挥了积极有效的作用，至少回馈并保证了产品相关质量活动的完备性。

但此种模式自然难以规避、找出已交付产品的问题/隐患，产品上装之后，在测试过程中依旧会不断地发生本应该在上一阶段测试中应该暴露的问题，这就是我们常说的问题层层闯关到最后的环节。

因此产品上装之前需要首先确认的就是之前工作的完备性，单机测试、单元测试、系统测试、匹配测试、专项测试的完备性，是否已经完成了验收，这些都可以纳入到产品的电子履历中，设定必须完成项，一旦不能按照节点完成必要的工作，则不予以接收，这是一种类型的数据。

另外一种类型的数据就是已有数据中的关键参数，重量、技术状态、测试数据的包络特性，是否存在超差等，通过关键数据的快判，优先选取性能较好地产品用于重要的试验。

其实，需要达成一个共识，那就是针对产品数据的眼见为实，对关键指标关键参数、关键工序、关键过程的数据进行必要的自动确认。

三、结论

对于单机设备面言，类似于元器件复测/复验的工作，在研制过程中不太现实、不经济、不适宜，更多的应该聚焦产品实现过程的测试数据和质量数据，通过数据的确认辅以简单的确认、测量、测试，将质量水平高低不一致的产品甄别区分开来。

最终，系统使用前的测试和确认，也就是将产品出厂之前的测试覆盖性、完备性做到极致，针对性进行大幅度地提升，并规避安全性问题发生。