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

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

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

1.1級別1

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

1.2級別2

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

圖1：ZDSD模型

1.3級別3

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

{{分頁}}

1.4級別4

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

1.5級別5

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

2　　ZDSD解決方案

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

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

3　　LDRA產(chǎn)品介紹

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

3.1 Testbed功能介紹

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

{{分頁}}

1.  代碼評審

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

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

2.  質(zhì)量評審

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

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

3.  設(shè)計(jì)評審

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

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

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

4.  單元測試

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

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

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

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

{{分頁}}

5.  測試驗(yàn)證

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

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

快速查明被測試軟件中不適當(dāng)?shù)牟糠郑⑶野凑找粋€高的標(biāo)準(zhǔn)來測試并減少回歸測試的成本，這是及其重要的。主要的目的是節(jié)省資源，提高產(chǎn)品質(zhì)量，縮短上市時(shí)間。

工具提供的測試驗(yàn)證的主要特點(diǎn)是對測試進(jìn)行度量的可行性，詳細(xì)的語句、分支、測試路徑覆蓋率達(dá)到測試標(biāo)準(zhǔn)要求。

6.  測試管理

　　因?yàn)槌浞掷斫庖粋€系統(tǒng)可能需要花費(fèi)很長的時(shí)間和大量的人力、物力。LDRA工具套件幫助開發(fā)者和測試工程師理解、歸檔、維護(hù)大的復(fù)雜的系統(tǒng)。

　　文檔編制幫助達(dá)到質(zhì)量標(biāo)準(zhǔn)的過程，如ISO 9001:2000。

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

3.2 TBreq功能介紹

1.需求測試和驗(yàn)證

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

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

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

2.主要優(yōu)點(diǎn)

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

{{分頁}}

3.接口

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

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

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

RTInsightPro技術(shù)特點(diǎn)

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

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

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

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

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

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

{{分頁}}

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

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

　　　　等內(nèi)存使用方面的異常，同時(shí)幫助用戶定位問題；

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

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