在航空電子領(lǐng)域，安全關(guān)鍵軟件必須通過 DO-178B/C 合規(guī)方式遵守聯(lián)邦航空法規(guī)。航空無線電技術(shù)委員會(huì) （RTCA） 和歐洲民用航空設(shè)備組織 （EUROCAE） 聯(lián)合開發(fā)了DO-178 機(jī)載系統(tǒng)和設(shè)備認(rèn)證中的軟件注意事項(xiàng)。DO-178B/C 是處理機(jī)載系統(tǒng)中使用的安全關(guān)鍵軟件的安全性的指南，旨在滿足適航系統(tǒng)的需求。機(jī)載系統(tǒng)中使用的軟件必須滿足標(biāo)準(zhǔn)和相關(guān)認(rèn)證目標(biāo)。

DO-178B/C 的目標(biāo)之一是“對(duì)軟件產(chǎn)品進(jìn)行符合性審查”。同行評(píng)審的目的是確保完成軟件生命周期，并交付優(yōu)質(zhì)產(chǎn)品進(jìn)行認(rèn)證。在同行評(píng)審過程中，評(píng)審者必須評(píng)審在評(píng)審過程中添加的所有工件，并確保這些工件沒有缺陷。如果發(fā)現(xiàn)任何缺陷，審核者需要將其作為發(fā)現(xiàn)來捕獲。

在下一步中，實(shí)施者必須針對(duì)這些缺陷提供適當(dāng)?shù)慕鉀Q方案。在對(duì)航空電子軟件進(jìn)行驗(yàn)證時(shí)，我們的團(tuán)隊(duì)遇到了許多與拼寫錯(cuò)誤、同一測試（或同一單元）內(nèi)重復(fù)要求、冗余空格（前導(dǎo)、尾隨、單詞之間等）、HLR-to -LLR 可追溯性，以及缺少特定要求的測試用例。

審查者和實(shí)施者都需要花費(fèi)大量時(shí)間來捕捉和解決這些發(fā)現(xiàn)。如果工件數(shù)量增加，識(shí)別和解決此類錯(cuò)誤所需的時(shí)間也會(huì)增加。因此，為了避免此類發(fā)現(xiàn)，我們的團(tuán)隊(duì)提出了“靜態(tài)測試用例和測試過程分析工具”。該工具是用 Python 開發(fā)的，可以捕獲上述錯(cuò)誤。它有助于實(shí)施者在初始階段修復(fù)此類錯(cuò)誤，并有助于減少審查過程的時(shí)間。

概述：

開發(fā)靜態(tài)測試用例和測試過程分析工具的主要目標(biāo)是盡量減少用戶在搜索拼寫錯(cuò)誤的單詞、空格、需求可追溯性問題（在 HLR 和 LLR 之間）和丟失的測試用例（未測試的需求）方面的工作量。

在這里，測試用例在 excel 或文本文件中開發(fā)并添加到工具中。測試用例包含測試用例 ID、低級(jí)和高級(jí)需求的跟蹤、測試用例的目標(biāo)以及包含輸入/輸出的測試步驟以及每個(gè)步驟的目的。

手動(dòng)生成的文檔必然存在容易被忽略的錯(cuò)誤。但是，該工具會(huì)掃描整個(gè)文檔并識(shí)別文本中的拼寫錯(cuò)誤、文本中存在的額外空格以及連續(xù)的重復(fù)單詞。它還檢查測試用例文件名和測試用例 ID 的命名約定，并將其記錄在要顯示的文本文件中。

雖然，excel提供了檢查文本拼寫的功能。它遍歷每個(gè)單詞并需要更多時(shí)間，而該工具可以直接顯示錯(cuò)誤及其位置。

分析需求可追溯性和定位缺失的測試用例是該工具的另一個(gè)特點(diǎn)。在驗(yàn)證中，需求覆蓋率是一個(gè)非常重要的方面，也是 DO-178B/C 標(biāo)準(zhǔn)的核心目標(biāo)之一。DO-178B/C 第 A-7.4 節(jié)和 A-4.6 節(jié)的目標(biāo)分別是“實(shí)現(xiàn)低級(jí)需求的測試覆蓋”和“低級(jí)需求可追溯至高級(jí)需求”。

工程師必須檢查需求是否經(jīng)過測試，以及每個(gè)低級(jí)需求 （LLR） 是否都有相應(yīng)的高級(jí)需求 （HLR） 可追溯。靜態(tài)測試用例和測試過程分析工具從測試用例文件中收集數(shù)據(jù)并維護(hù) LLR 和 HLR 列表，以便用戶可以輕松查看并交叉檢查 LLR 到 HLR 的可追溯性。

該工具檢查每個(gè) LLR 是否有與之關(guān)聯(lián)的測試，并記錄同一單元格中 LLR 和 HLR 的重復(fù)項(xiàng)，幫助用戶最大限度地減少檢查整個(gè)測試文件的工作量。

設(shè)計(jì)細(xì)節(jié)：

靜態(tài)測試用例和測試過程分析工具主要分為兩部分：1）需求追溯分析，2）發(fā)現(xiàn)拼寫錯(cuò)誤、空行、多余的空格和錯(cuò)誤的測試用例ID（靜態(tài)分析和清理）。

在需求追溯分析部分，.xlsx 中的測試用例和 .csv 中被測模塊的需求列表作為該工具的輸入提供。它會(huì)生成包含 LLR 和相關(guān)測試 ID 的 CSV 文件、包含測試 ID、HLR、LLR 的解析數(shù)據(jù)的 excel 文件，以及帶有 LLR 和 HLR 的任何重復(fù)項(xiàng)的文本文件。

圖 2.1：工具的需求追溯分析功能

該工具的需求可追溯性分析部分執(zhí)行以下功能：

HLR 和 LLR 之間的可追溯性 —— CSV 格式的測試用例文件和被測模塊的需求列表作為輸入提供給為檢查需求可追溯性而開發(fā)的功能。它根據(jù)測試用例 ID、LLR 和 HLR 解析測試用例文件，并將其放入新創(chuàng)建的 xlsx 文件中。輸入 CSV 文件包含特定模塊的要求列表。

需求測試可追溯性 ——該函數(shù)從 CSV 文件中讀取需求并將它們搜索到已解析的 HLR 和 LLR xlsx 中。如果 LLR 存在于已解析的工作表、LLR 和 HLR 中，它會(huì)捕獲相應(yīng)的測試用例 ID。該工具創(chuàng)建一個(gè)新的 CSV 并在其中寫入 LLR 及其各自的測試用例 ID。如果 LLR 不存在，則會(huì)導(dǎo)致字符串顯示“需求未測試”。

重復(fù)需求識(shí)別 - 該工具識(shí)別解析的 HLR LLR xlsx 文件中的單元格是否包含重復(fù)的 HLR 或 LLR，并在文本文件中記錄這些需求。

在工具的靜態(tài)分析和清理部分，提供一個(gè)或多個(gè)不同格式的測試文件（例如 .xlsx 或 .txt）作為輸入，這些錯(cuò)誤的結(jié)果記錄在一個(gè)文本文件中。

圖 2.2：工具的靜態(tài)分析和清理功能

靜態(tài)分析和清理部分執(zhí)行以下功能：

捕獲靜態(tài)錯(cuò)誤（拼寫錯(cuò)誤、多余的空格、連續(xù)重復(fù)的單詞等）——用戶可以選擇一個(gè)或多個(gè)測試用例文件并將它們作為輸入提供給檢查測試用例文件中的靜態(tài)錯(cuò)誤的函數(shù)。該工具檢查測試用例文件名和測試 ID 名稱是否符合指南，并在文本文件中記錄所有錯(cuò)誤。它還報(bào)告測試用例文件中未使用的行。

結(jié)果：

該工具生成四個(gè)結(jié)果文件：

靜態(tài)錯(cuò)誤報(bào)告 （.txt）

HLR 和 LLR 之間的可追溯性報(bào)告 （.xlsx）

需求和測試之間的可追溯性報(bào)告 （.csv）

重復(fù)要求 （.txt）

以下片段可幫助用戶了解該工具如何工作并產(chǎn)生結(jié)果。

圖 3.1：測試用例中的靜態(tài)錯(cuò)誤報(bào)告

圖 3.2：HLR 和 LLR 之間的可追溯性報(bào)告

圖 3.3：需求和測試之間的可追溯性報(bào)告

圖 3.4：顯示重復(fù)需求的報(bào)告

靜態(tài)測試用例和測試過程分析工具與 C# 開發(fā)的 GUI 的集成：

我們已經(jīng)成功地將我們團(tuán)隊(duì)創(chuàng)建的靜態(tài)測試用例和測試過程分析工具與另一個(gè)團(tuán)隊(duì)實(shí)現(xiàn)的 GUI 工具集成在一起。挑戰(zhàn)在于 GUI 工具是用 C# 實(shí)現(xiàn)的，而靜態(tài)測試用例和測試過程分析工具是用 Python 實(shí)現(xiàn)的。

集成兩者的想法使用戶能夠保持他們一直在使用的相同 GUI，并具有用于檢查他們正在處理的 TC 中的靜態(tài)錯(cuò)誤的附加功能。集成過程包括啟用 python 腳本以提供與基于 C# 的 GUI 的接口（即，使函數(shù)以測試用例列表作為參數(shù)在命令行上執(zhí)行），從 C# 調(diào)用 python 腳本，以及從 C# 執(zhí)行文件操作生成日志文件。

以下是此集成的功能：

節(jié)省單獨(dú)操作工具的開銷

GUI工具本身提供了選擇TC、執(zhí)行工具、分析報(bào)告等所有界面，節(jié)省了工程師執(zhí)行每個(gè)步驟的時(shí)間

執(zhí)行活動(dòng)與 GUI 工具中的時(shí)間戳（以活動(dòng)日志的形式）一起監(jiān)控，讓用戶知道執(zhí)行是如何工作的

案例分析：

如引言中所述，如果在實(shí)施階段沒有發(fā)現(xiàn)和解決錯(cuò)誤，則在審查過程中糾正錯(cuò)誤的實(shí)施和審查工作會(huì)更大。本案例研究包括同行評(píng)審過程中確定的一項(xiàng)發(fā)現(xiàn)以及解決該問題所需時(shí)間的估計(jì)。下面提供的分析顯示了在此工具的幫助下可以節(jié)省多少實(shí)施和審查時(shí)間。

同行評(píng)審結(jié)果描述：

清除單詞“contrl”的所有拼寫錯(cuò)誤，即測試 1 中的目的陳述 - “Slider contrl”應(yīng)該是“Slider control”。

工件需要重命名。根據(jù)指南重命名它。

表 5.1：工具的有效性

優(yōu)點(diǎn)：

該工具的有效性隨著多個(gè)工件和多個(gè) TC 的審查而增加

將修復(fù)錯(cuò)誤的周轉(zhuǎn)時(shí)間縮短 70%

減少與拼寫、命名約定和 HLR-LLR 可追溯性問題相關(guān)的發(fā)現(xiàn)數(shù)量

未來范圍：

它將 LLR 和相應(yīng)的 HLR 作為需求管理工具的輸入，并檢查測試用例是否包含正確的 LLR 到 HLR 可追溯性。

基于解析的 LLR，它生成一個(gè) TC 模板，該模板將根據(jù)需求準(zhǔn)備好一些基本字段，如目標(biāo)、目的、輸入/輸出。

支持以 .c、.py 或 .xml 格式手動(dòng)創(chuàng)建的測試程序文件。

支持 pdf 標(biāo)記。

結(jié)論：

該工具的目的是通過消除需求可追溯性問題和錯(cuò)誤（例如空格、重復(fù)單詞、拼寫錯(cuò)誤的單詞和命名約定）來生成健壯或高質(zhì)量的工件。它可以節(jié)省大約 10 分鐘。對(duì)于每個(gè)工件。

當(dāng)有多個(gè)工件時(shí)，該工具會(huì)更有效，并節(jié)省大約 70% 的周轉(zhuǎn)時(shí)間。通過持續(xù)使用該工具，我們的團(tuán)隊(duì)消除了與上述所有錯(cuò)誤相關(guān)的發(fā)現(xiàn)，顯著提高了工件質(zhì)量和工作效率。

審核編輯：郭婷