效率和質(zhì)量在任何領(lǐng)域都很重要，軟件驗(yàn)證也不例外?！办o態(tài)測試用例和測試過程分析工具”提高了驗(yàn)證項(xiàng)目中工件的質(zhì)量，并有助于糾正其中引入的人為錯誤。

介紹：

客觀的：

在航空電子領(lǐng)域，安全關(guān)鍵軟件必須通過 DO-178B/C 合規(guī)方式遵守聯(lián)邦航空法規(guī)。航空無線電技術(shù)委員會 （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)之一是“對軟件產(chǎn)品進(jìn)行符合性審查”。同行評審的目的是確保完成軟件生命周期，并交付優(yōu)質(zhì)產(chǎn)品進(jìn)行認(rèn)證。在同行評審過程中，評審者必須評審在評審過程中添加的所有工件，并確保這些工件沒有缺陷。如果發(fā)現(xiàn)任何缺陷，審核者需要將其作為發(fā)現(xiàn)來捕獲。

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

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

概述：

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

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

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

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

分析需求可追溯性和定位缺失的測試用例是該工具的另一個特點(diǎn)。在驗(yàn)證中，需求覆蓋率是一個非常重要的方面，也是 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īng)過測試，以及每個低級需求 （LLR） 是否都有相應(yīng)的高級需求 （HLR） 可追溯。靜態(tài)測試用例和測試過程分析工具從測試用例文件中收集數(shù)據(jù)并維護(hù) LLR 和 HLR 列表，以便用戶可以輕松查看并交叉檢查 LLR 到 HLR 的可追溯性。

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

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

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

在需求追溯分析部分，.xlsx 中的測試用例和 .csv 中被測模塊的需求列表作為該工具的輸入提供。它會生成包含 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 中，它會捕獲相應(yīng)的測試用例 ID。該工具創(chuàng)建一個新的 CSV 并在其中寫入 LLR 及其各自的測試用例 ID。如果 LLR 不存在，則會導(dǎo)致字符串顯示“需求未測試”。

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

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

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

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

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

結(jié)果：

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

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

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

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

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

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

圖 3.1：測試用例中的靜態(tài)錯誤報(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)測試用例和測試過程分析工具與另一個團(tuán)隊(duì)實(shí)現(xiàn)的 GUI 工具集成在一起。挑戰(zhàn)在于 GUI 工具是用 C# 實(shí)現(xiàn)的，而靜態(tài)測試用例和測試過程分析工具是用 Python 實(shí)現(xiàn)的。

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

以下是此集成的功能：

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

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

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

案例分析：

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

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

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

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

描述大概時間

大約。是時候讓審閱者發(fā)現(xiàn)錯誤并記錄下來了。5分鐘。

大約。是時候讓實(shí)施者進(jìn)行清理了。1分鐘。

大約。實(shí)施者提交更改、重新生成日志和響應(yīng)解決方案的時間。10 分鐘。

總周轉(zhuǎn)時間15 分鐘。

現(xiàn)在，如果在實(shí)施時發(fā)現(xiàn)相同的錯誤，它可以在不到 5 分鐘的時間內(nèi)修復(fù)。

表 5.1：工具的有效性

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

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

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

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

未來范圍：

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

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

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

支持 pdf 標(biāo)記。

結(jié)論：

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

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

審核編輯：郭婷