周亞男 朱程輝 劉錦峰

對信號系統(tǒng)長期開發(fā)維護過程中產(chǎn)生的缺陷進行分析，重點研究缺陷發(fā)現(xiàn)階段，缺陷類型等屬性，通過魚骨圖缺陷分析的方法，識別導致缺陷的根本原因，并對產(chǎn)品開發(fā)過程中的不足之處進行跟蹤管理，定制具體的缺陷分析流程，通過一年的實踐，結果表明該分析方法和流程是有效的，對日常缺陷分析工作有著指導意義。

一、引言

隨著微電子技術、計算機技術、通信技術的不斷更新，軌道交通信號系統(tǒng)也在更新?lián)Q代。從模擬軌道電路，到數(shù)字軌道電路，再到現(xiàn)在的無線通信，軌道交通信號系統(tǒng)持續(xù)走向智能高效、安全可靠、方便快捷。同時不同城市的定制化需求，也促使著軌道交通信號系統(tǒng)的不斷升級。

功能的實現(xiàn)與優(yōu)化必定伴隨著軟硬件的變更，產(chǎn)品的迭代，而每一次的開發(fā)過程都是不確定的，受流程，工具以及人的影響，即使嚴格服從ISO9001和EN5012X指導做完整的生命周期開發(fā)和全面的Verification和Validation管理，缺陷依然如影隨形。

缺陷往往給研發(fā)，測試，工程實施團隊帶來人力時間成本的消耗，導致返工，影響系統(tǒng)上線，但凡事都有兩面性，我們在忍受缺陷的同時，缺陷的價值也不可忽視。一個有效的缺陷分析過程可以多維度暴露我們產(chǎn)品迭代過程中的不足，觸發(fā)一次深度的反思與學習，總結經(jīng)驗，將來可以更早的發(fā)現(xiàn)或者消除同類缺陷，降低缺陷成本。

二、缺陷分析的維度

一個成熟的信號系統(tǒng)開發(fā)生命周期都有缺陷管理庫，用來管理產(chǎn)品整個生命周期的缺陷和變更，包括產(chǎn)品維護階段。我們要做的缺陷分析的對象即為CQ庫中的缺陷（本文中提到的缺陷相關字段用Clear Quest舉例，簡稱CQ），當然不是所有缺陷，需要識別哪些缺陷是有價值的，值得投入時間人力成本去分析的。

（一）缺陷發(fā)現(xiàn)的階段

首先，我們引用缺陷屬性中的defect_detection_ phase作為缺陷分析對象的第一步篩選，defect_ detection_phase即缺陷發(fā)現(xiàn)階段，一般情況該字段按照產(chǎn)品的生命周期階段劃分，可以歸納為三大類。

需求設計階段：該階段發(fā)現(xiàn)的缺陷一般都是文檔類的，多數(shù)為評審和驗證過程中發(fā)現(xiàn)的需求設計問題；該階段的缺陷修復成本非常低，可忽略。

產(chǎn)品測試階段：顧名思義，該階段發(fā)現(xiàn)的缺陷多數(shù)為各級產(chǎn)品測試人員提出，對產(chǎn)品的研發(fā)質量有一定的評估價值。缺陷修復需要回滾到Coding甚至Design階段，對研發(fā)和測試人力都不同程度的消耗，對該階段的缺陷進行分析可以識別出問題較多的模塊以及開發(fā)流程中存在的問題，幫助測試人員定位測試側重點，哪些模塊需要重點測試的，提高缺陷發(fā)現(xiàn)率，同時也幫助研發(fā)團隊針對性的總結經(jīng)驗，并且避免將來發(fā)生類似的錯誤。此外，通過分析該組缺陷發(fā)現(xiàn)測試階段的分布情況，可以判斷哪些階段的測試需要加強。例如，系統(tǒng)級測試發(fā)現(xiàn)的缺陷，理論上軟件級測試也能發(fā)現(xiàn)，這種情況則需要做對應的缺陷分析。

維護階段：產(chǎn)品已經(jīng)發(fā)布使用，甚至已經(jīng)部署到現(xiàn)場。該階段發(fā)現(xiàn)的缺陷通常我們定義為逃逸缺陷。在全面智能化的社會，軌道交通信號系統(tǒng)代替了多數(shù)人工操作，功能故障或者降級模式對用戶來說幾乎都是不可接受的。其中，涉及到SIL4的功能缺陷更是可能關系到人身安全，帶來的影響已經(jīng)不僅僅是人力時間成本的估算，該類缺陷產(chǎn)生的成本極高，也是我們需要深度分析的對象。

（二）缺陷的類型

缺陷的類型主要用來識別產(chǎn)品在功能，性能等各方面的表現(xiàn)情況，通過該屬性缺陷分布的統(tǒng)計與分析，識別產(chǎn)品設計的薄弱環(huán)節(jié)，提示研發(fā)團隊在后續(xù)的迭代開發(fā)中，需要著重關注的方向。

在實踐后，我們將缺陷類型分為以下6類：

1.功能（定位到具體模塊）

2.接口（具體的軟/硬件級之間）

3.可用性（人機界面）

4.性能（容量、響應時間）

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

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

（三）缺陷所在模塊

缺陷的模塊分布可以反映各個模塊中缺陷數(shù)量的分布狀況，它可以被用來評估各模塊質量水平和開發(fā)難度，該屬性為缺陷類型的細化，可根據(jù)產(chǎn)品的具體功能模塊進行不同粗細顆粒度劃分類型。

（四）缺陷根本原因

缺陷根本原因歸類可以直接反映產(chǎn)品各階段活動的質量為持續(xù)改進活動提供具體依據(jù)，根據(jù)實踐中各產(chǎn)品的日常缺陷分析結果，將缺陷的根本原因分為以下幾類。

1.需求設計不足：例如，先寫代碼后需求設計的情況，很容易導致需求描述不完整，測試范圍不全或者軟件與數(shù)據(jù)接口描述過于簡化，導致測試用例設計出現(xiàn)遺漏；

2.測試設計不足：例如，信號系統(tǒng)各子系統(tǒng)之間都有詳細的協(xié)議定義文件，測試人員對協(xié)議的覆蓋僅停留在數(shù)據(jù)包組合分析，未結合實際運行場景，導致測試用例設計不充分；

3.測試數(shù)據(jù)不足：例如，產(chǎn)品測試數(shù)據(jù)形式單一，但特定應用項目站型卻千差萬別，如果產(chǎn)品測試配置組合覆蓋不完整，則容易導致特殊站型情況出現(xiàn)缺陷而產(chǎn)品測試過程未發(fā)現(xiàn)；

4.測試環(huán)境不足：例如，模擬工具仿真接口與真實接口的差異導致缺陷未被發(fā)現(xiàn)或者室內(nèi)不具備測試環(huán)境未執(zhí)行測試，導致到現(xiàn)場該模塊出現(xiàn)大量問題；

5.影響分析不足：例如，影響分析的方法過于單一，缺乏系統(tǒng)性分析，僅停留在回歸發(fā)現(xiàn)缺陷對應的測試用例層面，回歸面小，缺乏自動化；

6.流程缺陷：例如，軟硬件接口未強制使用真實的設備或者代碼走讀規(guī)范定義不清晰，不全面，測試環(huán)境檢查不到位等；

7.偶發(fā)性：例如，未進行拷機實驗，經(jīng)過一定的運行時間后，產(chǎn)品缺陷暴露或者室內(nèi)測試生成的數(shù)據(jù)通信量小，需要大量的現(xiàn)場數(shù)據(jù)作為前提，才能偶然出現(xiàn)，這種情況一般要求室內(nèi)測試數(shù)據(jù)庫中導入現(xiàn)場數(shù)據(jù)；

8.其他。

（五）缺陷分析的方法

好的缺陷分析產(chǎn)生的結果必須是“可行動”的，如果過于抽象和寬泛則很難制定具體有效的改進措施，也就失去了缺陷分析的意義。一般，我們做缺陷分析的方法可以是多種多樣的，例如四象限分析法、柏拉圖分析法、 ODC正交缺陷分類法等。本文用魚骨圖分析法舉例，通過產(chǎn)品組各口相關人員以會議形式進行頭腦風暴，分析過程以及方法如下：

1.CR寫在魚骨的頭上；

2.召集各口同事共同討論問題出現(xiàn)的具體場景；

3.把分析的角度分組，在魚骨上標出；

4.根據(jù)不同問題大家頭腦風暴，總結出根本原因的類型；

5.如果存在多方面的原因，需要逐條分析為什么會產(chǎn)生這樣的問題；

6.總結問題的解決或者改進方案，并落實負責人；

魚骨圖形式舉例如圖1。

通過有效的缺陷分析，我們可以獲得如下產(chǎn)出：

產(chǎn)品團隊在需求設計、測試、流程等多方面達成共識，不會出現(xiàn)一個部門單方面努力推動的情況；

推動測試工具的開發(fā)與完善；

改進既有開發(fā)與測試流程；

梳理常見問題以及應對方法；

不同產(chǎn)品可以交流分析結果，避免同類問題發(fā)生。

三、缺陷分析的機制建立

缺陷分析的執(zhí)行需要建立一定的機制，保證分析的及時性以及持續(xù)性。如果時間隔太久，會導致缺陷發(fā)生場景不清晰甚至不準確，周期性的跟蹤總結才能沉淀成產(chǎn)品團隊的資產(chǎn)，因此一般建議定義組織級文件，并明確以下內(nèi)容。

測試缺陷定期進行，分析的周期以及產(chǎn)出物；

逃逸缺陷觸發(fā)式進行，分析的周期以及產(chǎn)出物；

指定分析活動的組織人、分析結果的匯報人以及匯報的形式。

分析流程如圖2所示。

三、結束語

實踐表明，通過及時、有效、持續(xù)的缺陷分析，并對分析結果進行跟蹤落實，建立可實施的分析機制，能積極評估開發(fā)和測試活動的質量，更能指導研發(fā)和測試在方法以及流程上的持續(xù)改進，豐富產(chǎn)品團隊資產(chǎn)。

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