基于轨道交通信号系统的缺陷分析方法讨论

周亚男 朱程辉 刘锦峰

对信号系统长期开发维护过程中产生的缺陷进行分析，重点研究缺陷发现阶段，缺陷类型等属性，通过鱼骨图缺陷分析的方法，识别导致缺陷的根本原因，并对产品开发过程中的不足之处进行跟踪管理，定制具体的缺陷分析流程，通过一年的实践，结果表明该分析方法和流程是有效的，对日常缺陷分析工作有着指导意义。

一、引言

随着微电子技术、计算机技术、通信技术的不断更新，轨道交通信号系统也在更新换代。从模拟轨道电路，到数字轨道电路，再到现在的无线通信，轨道交通信号系统持续走向智能高效、安全可靠、方便快捷。同时不同城市的定制化需求，也促使着轨道交通信号系统的不断升级。

功能的实现与优化必定伴随着软硬件的变更，产品的迭代，而每一次的开发过程都是不确定的，受流程，工具以及人的影响，即使严格服从ISO9001和EN5012X指导做完整的生命周期开发和全面的Verification和Validation管理，缺陷依然如影随形。

缺陷往往给研发，测试，工程实施团队带来人力时间成本的消耗，导致返工，影响系统上线，但凡事都有两面性，我们在忍受缺陷的同时，缺陷的价值也不可忽视。一个有效的缺陷分析过程可以多维度暴露我们产品迭代过程中的不足，触发一次深度的反思与学习，总结经验，将来可以更早的发现或者消除同类缺陷，降低缺陷成本。

二、缺陷分析的维度

一个成熟的信号系统开发生命周期都有缺陷管理库，用来管理产品整个生命周期的缺陷和变更，包括产品维护阶段。我们要做的缺陷分析的对象即为CQ库中的缺陷（本文中提到的缺陷相关字段用Clear Quest举例，简称CQ），当然不是所有缺陷，需要识别哪些缺陷是有价值的，值得投入时间人力成本去分析的。

（一）缺陷发现的阶段

首先，我们引用缺陷属性中的defect_detection_ phase作为缺陷分析对象的第一步筛选，defect_ detection_phase即缺陷发现阶段，一般情况该字段按照产品的生命周期阶段划分，可以归纳为三大类。

需求设计阶段：该阶段发现的缺陷一般都是文档类的，多数为评审和验证过程中发现的需求设计问题；该阶段的缺陷修复成本非常低，可忽略。

产品测试阶段：顾名思义，该阶段发现的缺陷多数为各级产品测试人员提出，对产品的研发质量有一定的评估价值。缺陷修复需要回滚到Coding甚至Design阶段，对研发和测试人力都不同程度的消耗，对该阶段的缺陷进行分析可以识别出问题较多的模块以及开发流程中存在的问题，帮助测试人员定位测试侧重点，哪些模块需要重点测试的，提高缺陷发现率，同时也帮助研发团队针对性的总结经验，并且避免将来发生类似的错误。此外，通過分析该组缺陷发现测试阶段的分布情况，可以判断哪些阶段的测试需要加强。例如，系统级测试发现的缺陷，理论上软件级测试也能发现，这种情况则需要做对应的缺陷分析。

维护阶段：产品已经发布使用，甚至已经部署到现场。该阶段发现的缺陷通常我们定义为逃逸缺陷。在全面智能化的社会，轨道交通信号系统代替了多数人工操作，功能故障或者降级模式对用户来说几乎都是不可接受的。其中，涉及到SIL4的功能缺陷更是可能关系到人身安全，带来的影响已经不仅仅是人力时间成本的估算，该类缺陷产生的成本极高，也是我们需要深度分析的对象。

（二）缺陷的类型

缺陷的类型主要用来识别产品在功能，性能等各方面的表现情况，通过该属性缺陷分布的统计与分析，识别产品设计的薄弱环节，提示研发团队在后续的迭代开发中，需要着重关注的方向。

在实践后，我们将缺陷类型分为以下6类：

1.功能（定位到具体模块）

2.接口（具体的软/硬件级之间）

3.可用性（人机界面）

4.性能（容量、响应时间）

5.可靠性（宕机，失效）

6.其他（例如兼容性等）

（三）缺陷所在模块

缺陷的模块分布可以反映各个模块中缺陷数量的分布状况，它可以被用来评估各模块质量水平和开发难度，该属性为缺陷类型的细化，可根据产品的具体功能模块进行不同粗细颗粒度划分类型。

（四）缺陷根本原因

缺陷根本原因归类可以直接反映产品各阶段活动的质量为持续改进活动提供具体依据，根据实践中各产品的日常缺陷分析结果，将缺陷的根本原因分为以下几类。

1.需求设计不足：例如，先写代码后需求设计的情况，很容易导致需求描述不完整，测试范围不全或者软件与数据接口描述过于简化，导致测试用例设计出现遗漏；

2.测试设计不足：例如，信号系统各子系统之间都有详细的协议定义文件，测试人员对协议的覆盖仅停留在数据包组合分析，未结合实际运行场景，导致测试用例设计不充分；

3.测试数据不足：例如，产品测试数据形式单一，但特定应用项目站型却千差万别，如果产品测试配置组合覆盖不完整，则容易导致特殊站型情况出现缺陷而产品测试过程未发现；

4.测试环境不足：例如，模拟工具仿真接口与真实接口的差异导致缺陷未被发现或者室内不具备测试环境未执行测试，导致到现场该模块出现大量问题；

5.影响分析不足：例如，影响分析的方法过于单一，缺乏系统性分析，仅停留在回归发现缺陷对应的测试用例层面，回归面小，缺乏自动化；

6.流程缺陷：例如，软硬件接口未强制使用真实的设备或者代码走读规范定义不清晰，不全面，测试环境检查不到位等；

7.偶发性：例如，未进行拷机实验，经过一定的运行时间后，产品缺陷暴露或者室内测试生成的数据通信量小，需要大量的现场数据作为前提，才能偶然出现，这种情况一般要求室内测试数据库中导入现场数据；

8.其他。

（五）缺陷分析的方法

好的缺陷分析产生的结果必须是“可行动”的，如果过于抽象和宽泛则很难制定具体有效的改进措施，也就失去了缺陷分析的意义。一般，我们做缺陷分析的方法可以是多种多样的，例如四象限分析法、柏拉图分析法、 ODC正交缺陷分类法等。本文用魚骨图分析法举例，通过产品组各口相关人员以会议形式进行头脑风暴，分析过程以及方法如下：

1.CR写在鱼骨的头上；

2.召集各口同事共同讨论问题出现的具体场景；

3.把分析的角度分组，在鱼骨上标出；

4.根据不同问题大家头脑风暴，总结出根本原因的类型；

5.如果存在多方面的原因，需要逐条分析为什么会产生这样的问题；

6.总结问题的解决或者改进方案，并落实负责人；

鱼骨图形式举例如图1。

通过有效的缺陷分析，我们可以获得如下产出：

产品团队在需求设计、测试、流程等多方面达成共识，不会出现一个部门单方面努力推动的情况；

推动测试工具的开发与完善；

改进既有开发与测试流程；

梳理常见问题以及应对方法；

不同产品可以交流分析结果，避免同类问题发生。

三、缺陷分析的机制建立

缺陷分析的执行需要建立一定的机制，保证分析的及时性以及持续性。如果时间隔太久，会导致缺陷发生场景不清晰甚至不准确，周期性的跟踪总结才能沉淀成产品团队的资产，因此一般建议定义组织级文件，并明确以下内容。

测试缺陷定期进行，分析的周期以及产出物；

逃逸缺陷触发式进行，分析的周期以及产出物；

指定分析活动的组织人、分析结果的汇报人以及汇报的形式。

分析流程如图2所示。

三、结束语

实践表明，通过及时、有效、持续的缺陷分析，并对分析结果进行跟踪落实，建立可实施的分析机制，能积极评估开发和测试活动的质量，更能指导研发和测试在方法以及流程上的持续改进，丰富产品团队资产。

作者单位：卡斯柯信号有限公司（上海）