必須實(shí)施所有要求。同樣，反之亦然——所有源代碼（和所有測(cè)試）都應(yīng)該可以追溯到設(shè)計(jì)，并最終追溯到需求（功能性或非功能性）。

當(dāng)需求開始發(fā)生變化時(shí)，挑戰(zhàn)就來(lái)了。若要快速有效地管理更改的影響，需要修改相關(guān)要求或添加新要求，請(qǐng)務(wù)必了解如何在代碼中反映更改以及驗(yàn)證更新所需的測(cè)試中。

圖 2 說(shuō)明了需求和測(cè)試之間的典型關(guān)系[4]。在這里，系統(tǒng)級(jí)需求 （SLR） 應(yīng)該可追溯到高級(jí)需求 （HLR），而高級(jí)需求又可追溯到低級(jí)需求 （LLR）。HLR 可追溯到高級(jí)測(cè)試 （HLT），LLR 可追溯到低級(jí)別測(cè)試 （LLT）。

這種雙向可追溯性使團(tuán)隊(duì)能夠看到從需求規(guī)范到構(gòu)建、測(cè)試、更改和返回的可見性（圖 2）。

[圖2.不同類型需求之間的典型可追溯性結(jié)構(gòu)。（資料來(lái)源：LDRA）]

在不失去可追溯性的情況下管理變更意味著需求和測(cè)試的耦合必須自動(dòng)化 - 這也使得了解測(cè)試和需求變更的上游和下游影響變得簡(jiǎn)單。

驗(yàn)證需求滿足情況

證明系統(tǒng)滿足要求有助于量化“構(gòu)建了正確的系統(tǒng)”。這有兩種風(fēng)格：

使用單元測(cè)試來(lái)證明應(yīng)用程序組件單獨(dú)滿足其各自的目的

使用集成測(cè)試來(lái)顯示應(yīng)用程序的各個(gè)部分作為一個(gè)整體協(xié)同工作

自動(dòng)化和自動(dòng)化工具通過(guò)將單元和集成測(cè)試與其適當(dāng)?shù)囊舐?lián)系起來(lái)并報(bào)告履行情況，而無(wú)需耗時(shí)的手動(dòng)工作，從而提供幫助。圖 3 說(shuō)明了需求管理平臺(tái)中的兩個(gè)場(chǎng)景[5]：

HLR_100 –綠點(diǎn)表示滿足要求，反映了已驗(yàn)證關(guān)聯(lián)的高級(jí)測(cè)試 （TCI_HLT_100） 和低級(jí)別要求（LLR_104 到 LLR_109）的事實(shí)。

HLR_101 –紅點(diǎn)表示需求未滿足，反映低級(jí)別需求LLR_103由于低級(jí)別測(cè)試TCI_LLT_103失敗而未滿足的事實(shí)。

[圖3.使用自動(dòng)化工具報(bào)告需求履行情況。（資料來(lái)源：LDRA）]

在后一種情況下，失敗的測(cè)試具有關(guān)聯(lián)的測(cè)試用例文件，可以使用單元測(cè)試工具和關(guān)聯(lián)的回歸報(bào)告進(jìn)行回歸，以幫助了解測(cè)試失敗的原因。

確定結(jié)構(gòu)覆蓋率

結(jié)構(gòu)覆蓋率是嵌入式軟件中的一個(gè)重要概念，因?yàn)樗ＷC了整個(gè)代碼庫(kù)已得到一致和充分的執(zhí)行。作為 ISO 26262、DO-178B 和 IEC 62304 等標(biāo)準(zhǔn)的關(guān)鍵準(zhǔn)則，結(jié)構(gòu)覆蓋可幫助開發(fā)人員檢測(cè)和刪除死代碼，而質(zhì)量保證 （QA） 則使用它來(lái)確定缺失的測(cè)試用例。在這兩種情況下，將此覆蓋范圍追溯到需求有助于確保每個(gè)已實(shí)現(xiàn)的組件都有一個(gè)原因，并確定尚未實(shí)現(xiàn)的要求。

自動(dòng)化有助于確定結(jié)構(gòu)覆蓋率，顯示隨著基于需求的測(cè)試完成而執(zhí)行代碼的哪些部分[6]。圖 4 展示了一個(gè)測(cè)試驗(yàn)證報(bào)告，其中顯示了不同類型的覆蓋指標(biāo)的結(jié)果：

[圖4.使用自動(dòng)化工具報(bào)告結(jié)構(gòu)覆蓋率（來(lái)源：LDRA）]

陳述–在執(zhí)行應(yīng)用程序時(shí)執(zhí)行的語(yǔ)句數(shù)，占該應(yīng)用程序中語(yǔ)句總數(shù)的百分比。100% 覆蓋率意味著所有語(yǔ)句在測(cè)試期間至少執(zhí)行過(guò)一次。

分支/決策 –在執(zhí)行應(yīng)用程序時(shí)執(zhí)行的分支數(shù)占該應(yīng)用程序中語(yǔ)句總數(shù)的百分比。

單聲道/直流 –修改條件/決策覆蓋率 （MC/DC） 衡量決策陳述中的所有條件是否至少對(duì)所有可能的結(jié)果進(jìn)行一次評(píng)估，以及所有這些條件是否獨(dú)立地影響決策的結(jié)果。

圖 5 顯示了這些測(cè)試與其相關(guān)的低級(jí)需求之間的映射，以形成可追溯性矩陣。在此示例中，所有要求 （LLR_*） 均已使用測(cè)試 （TCI_LLT_*） 進(jìn)行驗(yàn)證。這種類型的報(bào)告只能通過(guò)應(yīng)用此處討論的可追溯性原則來(lái)實(shí)現(xiàn)。

[圖5.一個(gè)可追溯性矩陣，顯示映射到測(cè)試用例的需求驗(yàn)證。（資料來(lái)源：LDRA）]

可追溯性確保制造出“正確”的產(chǎn)品

團(tuán)隊(duì)絕不能將系統(tǒng)和軟件要求降級(jí)到貨架軟件中。隨著產(chǎn)品變得越來(lái)越復(fù)雜，軟件更新的頻率越來(lái)越高，需求可追溯性對(duì)于最大限度地降低風(fēng)險(xiǎn)仍然是相關(guān)性和必要的。

了解需求實(shí)施和測(cè)試的方式和位置可確保軟件適合用途。在軟件更改中保持這種意識(shí)可確保開發(fā)人員了解對(duì)代碼和測(cè)試的影響，而無(wú)需花時(shí)間搜索它們。

自動(dòng)化是動(dòng)態(tài)保持雙向需求可追溯性并確保產(chǎn)品“正確構(gòu)建”的唯一現(xiàn)實(shí)方法。沒有它，團(tuán)隊(duì)將花費(fèi)太多時(shí)間試圖手動(dòng)解決，從而導(dǎo)致成本增加和下游的潛在問題。

審核編輯：郭婷