ZDSD零缺陷軟件開發(fā)

上海創(chuàng)景 技術支持經(jīng)理 周國勇

1  　ZDSD零缺陷軟件開發(fā)

　　圖1描述了被提議的針對確認解決方案的層次模型。在嵌入式系統(tǒng)開發(fā)項目中，模型包含了五個基本級別，雖然隨著對過程和項目/團隊的目標、中間產品和整體生產率的關注的不同，這些級別可以進行調整。

1.1級別1

　　級別1應該是對一個將要開發(fā)的系統(tǒng)的確定性的描述和必須要滿足的功能性的標準，這被稱為高級需求。這個級別可以是詳細描述的，也可以不進行詳細的描述，它的精確的定義可以推遲到第二級由設計人員，或者甚至是第三級的系統(tǒng)概要設計階段由實現(xiàn)人員去描述。級別1，高級需求也可以被叫做系統(tǒng)需求、用戶需求、產品需求，或者其他相同含義的稱謂。這些需求可以以數(shù)據(jù)庫方式保存，比如Telelogic DOORS或者以文本方式存在，比如Microsoft Word文檔。

1.2級別2

　　級別2，設計，包含對級別1所描述的系統(tǒng)進行設計的一種表示方法。這一級，在大多情況下被稱為低層需求，低層需求必須首先建立起和級別1的聯(lián)接或者追蹤關系。這個聯(lián)接關系被稱為需求追蹤矩陣(RTM)。圖1的層次模型中的所有級別都直接或者間接的參與到這個RTM中。
　　級別2一般采用典型的三種設計過程中的一種來表示。通常，級別2可以用如下設計模型進行描述，諸如統(tǒng)一建模語言(UML)或者一些專用的建模工具如Mathworks的Simulink和NI的Lab View等?；蛘咦鳛檫x擇，級別2可以用設計規(guī)格說明進行描述，該設計規(guī)格說明既描述了被開發(fā)軟件的自身特性，也包括了軟件系統(tǒng)的詳細接口信息。同樣，在快速原型或者特定情況下，可以采用體系架構概念來達到項目中的關鍵要求，而不用采用一些更加詳細的正式的描述方式。

圖1：ZDSD模型

1.3級別3

　　級別3，實現(xiàn)，包含與級別2的描述保持一致的源代碼或匯編代碼的生成。在采用建模工具的自動代碼生成的情況下，級別2和級別3之間的聯(lián)接可以自動實現(xiàn)，確保兩個級別之間的需求可追蹤性。然而，通常情況，是在嵌入式操作系統(tǒng)供應商，例如Green Hills或者Wind River或者LynxOS，提供的集成開發(fā)環(huán)境(IDE)中進行“手工編碼”。
　　確認行為典型情況下是從級別3開始。防止運行時錯誤的最有效的方法就是提前排除他們。排除運行時錯誤的第一步，也包括其它的實現(xiàn)的缺陷，就是系統(tǒng)的運用代碼規(guī)則檢查。比如MISRA或者High Integrity C++這些由行業(yè)領導者開發(fā)出來的代碼規(guī)則，它們對源代碼實現(xiàn)的的很多方面，比如指針使用，內存管理和語法等進行分析。這些代碼評審的結果，同時也包括苛刻性質量檢查例如代碼復雜度和可維護性、以及包括全面的數(shù)據(jù)流分析，都必須在進行級別4和級別5的驗證進行之前完成。此外，為了對確認行為的第一級進行有效管理，必須要使用一個和整體的RTM集成的缺陷追蹤系統(tǒng)來實現(xiàn)對非一致性（不符合代碼規(guī)則和項目特定的質量模型）的記錄，追蹤和解決。
　　在級別3，一個艱巨的挑戰(zhàn)是實現(xiàn)代碼和高層需求或者低層需求之間的映射。這個聯(lián)接要求理解代碼，至少是到函數(shù)級別，同時也需要文檔來描述和證明相應的聯(lián)接關系。同時，為了有效的進行第4級和第5級的確認任務，需求到源代碼的聯(lián)接必須要集成到RTM中。

{{分頁}}

1.4級別4

　　級別4是專注于確認的第一級別。在這一級別，將對嵌入式軟件進行針對功能和針對結構的測試?？梢圆捎茫皂敹?，自底而上，或者兩種策略相結合的測試策略。這一級別可以采用模擬器，軟件仿真技術，測試驅動自動生成器以及測試用例自動生成器。如果要進行實際路徑測試，那么結構測試中需要擴展使用在第三級中應用過分析和斷言方式的形式方法。不采用這些分析技術，缺陷的因果關系是不能被有效的揭示出來。
　　至于功能測試，確認任務是否被成功執(zhí)行的一個關鍵依據(jù)就是在第4級進行的功能測試，能否在第5級（也就是目標環(huán)境）進行成功復現(xiàn)。不考慮主機和目標機的兼容問題，確認追蹤工作也是更加難以進行的。
　　在第4級，RTM得到全面的擴展，將包含比如測試用例標識，測試規(guī)格說明書和測試結果在內的相關確認產品項。如果不一致被更正，那么測試結果中必須包括相應的缺陷報告。第4級別的重點是在進行目標機測試和系統(tǒng)集成測試之前更正缺陷。基于主機的測試是非常典型的一種節(jié)約費用的選擇，因為它很好的提供了早期測試手段，并且它是不依賴于目標平臺實現(xiàn)最低層功能的最佳手段。

1.5級別5

　　對嵌入式軟件的確認，特別是安全苛刻性軟件，最有代表性的是在第5級進行。然而，在這一級，由于功能頻繁的鑒于硬件/軟件之間，使得缺陷的確定比第4級更加的困難。許多基于主機的測試手段，比如運行時庫是不切實的，在多分區(qū)操作系統(tǒng)中是不可行的。另外一個層面的追蹤，從源代碼到目標碼的追蹤也必須被覆蓋。
　　功能測試是第5級中的核心工作。另外，結構覆蓋被用來度量功能需求和實現(xiàn)的最終追蹤關系。(也就是通過功能測試，是否還有未被覆蓋的代碼？如果有，為什么會存在沒有被覆蓋的代碼？)。在第4級中使用的所有測試產品項都會在第5級中涉及到。

2　　ZDSD解決方案

　　LDRA公司提供的ZDSD解決方案完全適合在前面章節(jié)描述的ZDSD模型的要求。在下面圖2的中描述了ZDSD解決方案在V型軟件開發(fā)中的應用。

圖2—軟件開發(fā)的V模型

3　　LDRA產品介紹

　　只有LDRA工具套件主要包括Testbed/TBrun，TBreq以及RTInsight能夠能夠輔助客戶高效的實現(xiàn)ZDSD的軟件開發(fā)流程

3.1 Testbed功能介紹

　　LDRA開發(fā)的工具套件在達到團隊軟件開發(fā)和維護的目標的過程中，對六大活動提供幫助。
 • 代碼評審（使用編碼規(guī)則）
 • 質量評審（分析代碼的復雜度，密度以及可測試性）
 • 設計評審（分析接口，變量使用，控制流等）
 • 單元測試（自動創(chuàng)建測試驅動和測試向量）
 • 測試驗證（追蹤測試執(zhí)行并且分析代碼覆蓋率）
 • 測試管理（測試用例管理，文檔管理）

{{分頁}}

1.  代碼評審

　　通過使用工具提供的強大的包括編碼規(guī)則檢查在內的分析功能以及工具提供的全面的報告，可以實現(xiàn)對傳統(tǒng)代碼評審工作的擴展。用戶可以選擇編程規(guī)則的最大的集合（Set），也可以配置用戶自己的規(guī)則集合，或使用行業(yè)認可的標準，例如：MISRA C/MISRA-C:2004?？焖僮R別出違反規(guī)則的代碼并幫助開發(fā)人員快速的進行修正。

　
　　因此，工具提供的代碼評審功能的一個主要特點是，提供了一個自動化的、有效的、可重復的過程，這個過程既節(jié)省了時間和資源又為開發(fā)者提供了詳細全面的標準，這些是傳統(tǒng)的手工技術不能與之相比的。

2.  質量評審

　　該功能是使用質量度量可以使你快速確定您的軟件的質量。
LDRA公司努力使質量評審過程自動化：
　　其主要特征包括：
 • 代碼度量提供對軟件質量的度量，可以快速的以可視化的方式了解系統(tǒng)的復雜性。該特征是衡量軟件的清晰性、可維護性和可測試            性的元素；
 • 提供詳細的、彩色的函數(shù)調用關系圖和程序控制流程圖；
 • 自動生成報告，提供軟件質量文檔；

　　工具的質量評審一個主要特點是全面的代碼可視化、系統(tǒng)級的質量度量和代碼的結構化化簡指定，這些可以幫助提高對整個代碼的信心。

3.  設計評審

　　對源代碼（可以被編譯的）與最初的設計需求之間的一致性進行評估是很重要的。
LDRA實現(xiàn)了對這項采用傳統(tǒng)手段需要花費大量時間和資源的工作的自動化。

　　一些主要特征包括：
 　• 接口分析、識別潛藏錯誤程序變量。工具對所有過程的參數(shù)以及函數(shù)的全局變量和返回值進行全面分析；
 　• 工具全面深入理解代碼，代碼解析提供的代碼分析結果沒有“誤報”；

　　工具的設計評審幫助驗證設計規(guī)格說明是否被正確實現(xiàn)。

4.  單元測試

　　在軟件生命周期中隨著軟件開發(fā)的進行，發(fā)現(xiàn)錯誤以及修正錯誤的成本是越來越大的，這個是一個大家公認的事實。經(jīng)驗證明代碼開發(fā)早期的集中測試可以減少相關的成本。

　　單元測試在初始編碼階段提供了識別和改正錯誤的方法，幫助確認和維護軟件單元/模塊的一致性。

LDRA單元測試的主要優(yōu)點有：
 • 自動生成測試驅動，不需添加腳本；
 • 隨著源代碼的改變，對需要修改的測試數(shù)據(jù)進行跟蹤和報告；
 • 測試數(shù)據(jù)和結果很容易被保存，以便回歸測試；
 • 通過直觀的圖形/命令行接口選項可以達到極高的測試效率；
 • 交互式的測試工具可以直接進行測試結果驗證和覆蓋率度量；
 • 自動化的功能使測試人員不必詳細地了解被測試的代碼；

LDRA單元測試工具使測試過程自動化，解決了傳統(tǒng)的單元測試大量消耗時間和資源的問題。

{{分頁}}

5.  測試驗證

　　開發(fā)安全，商業(yè)和任務苛刻性軟件的過程必須堅持最嚴格的標準。在這些標準中一個重要的標準，如DO-178B要求直觀的，管理和檢驗軟件覆蓋率,該標準在航空和防務工程中被廣泛應用。

　　代碼的分析、測試和維護占了軟件開發(fā)生命周期的70%。LDRA的策略和技術可以應用到這些相關工作中。

快速查明被測試軟件中不適當?shù)牟糠?，并且按照一個高的標準來測試并減少回歸測試的成本，這是及其重要的。主要的目的是節(jié)省資源，提高產品質量，縮短上市時間。

工具提供的測試驗證的主要特點是對測試進行度量的可行性，詳細的語句、分支、測試路徑覆蓋率達到測試標準要求。

6.  測試管理

　　因為充分理解一個系統(tǒng)可能需要花費很長的時間和大量的人力、物力。LDRA工具套件幫助開發(fā)者和測試工程師理解、歸檔、維護大的復雜的系統(tǒng)。

　　文檔編制幫助達到質量標準的過程，如ISO 9001:2000。

　　測試管理的一個主要特點是為評審提供整個系統(tǒng)的文檔和版本控制，也幫助減少維護的成本。

3.2 TBreq功能介紹

1.需求測試和驗證

　　TBreq通過和包含了LDRA Testbed和TBrun(單元測試工具)的LDRA工具包的集成， 能夠提供一套完整的解決方案來幫助測試團隊實現(xiàn)測試規(guī)格說明,單元測試場景,測試數(shù)據(jù)以及代碼覆蓋率驗證與您的高層次的設計規(guī)格說明之間的映射。TBreq直接和你的管理工具（DOORS，ReqPro，Word，Excel）接口來保證在整個軟件生命周期中實現(xiàn)需求跟蹤以及保證對于需求覆蓋的完整性。

　　在LDRA工具包里，TBreq根據(jù)需求直接生成測試規(guī)格說明和可執(zhí)行的測試用例。測試結果直接自動的返回到需求管理工具，從而實現(xiàn)“round-trip的需求跟蹤驗證”。

　　TBreq的一個主要的特點是它從任一需求管理工具和數(shù)據(jù)源中獲取需求（高層的需求，派生出來的需求，低層的需求）的能力；同時它提供一個直觀的接口進行跟蹤，產生測試用例和需求驗證。所有的這些特點使得TBreq成為當今市場上最有效的針對需求管理的解決方案。

2.主要優(yōu)點

　　TBreq提供了質量和驗證標準對于實現(xiàn)多層次，雙向需求追蹤和沖突分析所必須的特性：
 • 和大多數(shù)主流的第三方需求管理工具實現(xiàn)集成來增加需求的可見性，并且實現(xiàn)從設計，編碼到測試的追蹤
 • 生成需求測試追蹤矩陣
 • 從源代碼和需求中生成測試規(guī)格說明，同時自動生成測試用例
 • 和LDRA Testbed（實現(xiàn)代碼評審，質量評審，設計評審和覆蓋率分析），TBrun（實現(xiàn)自動單元測試，包括測試驅動生成，測試用例生成，測試報告生成，主機/目標機測試和回歸測試）無縫集成
 • 需求的測試覆蓋分析和沖突分析
 • 自動偵測需求，源代碼和測試數(shù)據(jù)的變更
 • Upstream和Downstream的沖突分析能夠進行回歸風險管理

{{分頁}}

3.接口

　　TBreq是將需求，設計，開發(fā)，測試和驗證工作與您的需求管理工具和設計開發(fā)工具鏈連接起來的最簡單的解決方案：
 • 文本處理工具：Word, Excel, Access, PowerPoint, PDF, . . .
 • 需求管理工具：DOORS, RequisitePro, or any published XML interface
 • 項目管理工具：Microsoft Project
 • UML 工具：Rhapsody, Artisan, Rose, . . .
 • 建模和設計工具：Simulink, Statemate, Scade, Stood, . . .
 • 源代碼文件：C, C++, C#, Ada, . . .
 • 配置管理工具：Clearcase, CVS, PVCS, Dimensions, SYNERGY/CM, . . .

3.3 RTInsightPro嵌入式測試系統(tǒng)

　　隨著嵌入式實時系統(tǒng)的廣泛應用，嵌入式軟件可靠性越來越成為系統(tǒng)能否正常運行的關鍵，由于傳統(tǒng)主機平臺軟件測試工具的局限性，給嵌入式平臺軟件測試帶來很大的困難。
　　RTInsightPro充分考慮到嵌入式軟件實時性特點，結合使用LDRA公司靜態(tài)分析與代碼自動插裝技術，可成功用于實時嵌入式系統(tǒng)集成與系統(tǒng)測試，提供代碼覆蓋率分析、涵數(shù)性能分析、內存泄露分析，任務性能分析，變量監(jiān)控、堆棧監(jiān)控及系統(tǒng)跟蹤功能。

RTInsightPro技術特點

　　通過采用LDRA公司Testbed軟件測試工具靜態(tài)分析與代碼插裝技術，及RTInsightPro硬件可實時地嵌入式系統(tǒng)進行代碼覆蓋率分析與性能分析。由于采用代碼插裝可準確的判斷代碼執(zhí)行情況，同時由于采用RTInsightPro高速虛擬端口技術使得代碼插裝量可控制在每個特征點（即函數(shù)入口、出口，程序分支點）一到兩條指令或語句（代碼增加量可控制在10%之內），大大減少插裝代碼增加對被測系統(tǒng)的影響。

RTInsightPro功能
　　RTInsighPro提供代碼覆蓋率分析、函數(shù)性能分析、變量監(jiān)控、堆棧使用監(jiān)控、內存泄露分析、任務性能分析及系統(tǒng)跟蹤等功能。

  •　覆蓋率分析
　　　　　　　RTInsightPro結合Testbed針對硬件輔助方式專用的插裝，可以在對系統(tǒng)影響最小的情況下提供下列覆蓋率指標：
　　　　　　　　　　• 語句覆蓋率；
　　　　　　　　　　• 分支覆蓋率；
　　　　　　　　　　• 調用覆蓋率；
　　　　　　　　　　• 外部中斷使用記數(shù)；

  •　函數(shù)性能分析
　　　　　　　采用和覆蓋率分析不同的專門的性能插裝方式，RTInsightPro可以在對系統(tǒng)實時性能幾乎沒有影響的情況下，提供以下時間性能指標：
　　　　　　　　　　• 系統(tǒng)總體執(zhí)行時間；
　　　　　　　　　　• 每個程序最大執(zhí)行時間；
　　　　　　　　　　• 每個程序最小執(zhí)行時間；
　　　　　　　　　　• 每個程序累計執(zhí)行時間；
　　　　　　　　　　• 每個程序執(zhí)行次數(shù)；
　　　　　　　　　　• 中斷服務程序響應時間；

  •任務性能分析
　　　　　　　對于采用實時多任務操作系統(tǒng)的被測試系統(tǒng)，可以提供下列和任務相關的性能指標：
　　　　　　　　　　• 任務執(zhí)行的最大時間；
　　　　　　　　　　• 任務執(zhí)行的最小時間；
　　　　　　　　　　• 任務執(zhí)行的累計時間；

  •　變量監(jiān)控分析
　　　　　　　可以實時對系統(tǒng)中的變量使用情況進行監(jiān)控和記錄，可同時實時監(jiān)控8個系統(tǒng)變量和2個數(shù)組，提供下列功能：
　　　　　　　　　　• 記錄變量的最大值；
　　　　　　　　　　• 記錄變量的最小值；
　　　　　　　　　　• 記錄變量的被寫操作次數(shù)；

{{分頁}}

  •　堆棧監(jiān)控分析
　　　　　　　對于堆棧設置在內存中的系統(tǒng)，可以對堆棧的使用情況進行實時監(jiān)控，提供下列功能：
　　　　　　　　　　• 設置堆棧使用溢出報警上限；
　　　　　　　　　　• 設置堆棧使用溢出報警下限；
　　　　　　　　　　• 給出堆棧當前實時使用情況

　
  •　內存泄露分析
　　　　　　　對于采用了動態(tài)內存分配的系統(tǒng)，RTInsightPro可以實時監(jiān)控動態(tài)內存的使用情況，可以輔助用戶發(fā)現(xiàn)以下問題：
　　　　　　　　　　• 內存分配了未釋放；
　　　　　　　　　　• 內存重復釋放；
　　　　　　　　　　• 釋放未分配的內存；

　　　　等內存使用方面的異常，同時幫助用戶定位問題；

  •　跟蹤分析
　　　　　　RTInsightPro可以對系統(tǒng)的總線狀態(tài)進行實時追蹤，結合對源代碼的分析信息，可以提供源代碼級的追蹤分析，具體功能包括：
　　　　　　　　　　• 提供128K的總線跟蹤分析功能；
　　　　　　　　　　• 提供大概100萬行源代碼級追蹤；
　　　　　　　　　　• 可實時跟蹤記錄系統(tǒng)執(zhí)行狀態(tài)；
　　　　　　　　　　• 可設置靈活的觸發(fā)條件與記錄條件；
　　　　　　　　　　• 可以和外部硬件觸發(fā)進行配合；

參考文獻：
LDRA 公司 Zero Defect Software Development (ZDSD)_Manifesto Version 2.12