效率和質量在任何領域都很重要，軟件驗證也不例外。“靜態測試用例和測試過程分析工具”提高了驗證項目中工件的質量，并有助于糾正其中引入的人為錯誤。

介紹：

客觀的：

在航空電子領域，安全關鍵軟件必須通過 DO-178B/C 合規方式遵守聯邦航空法規。航空無線電技術委員會 （RTCA） 和歐洲民用航空設備組織 （EUROCAE） 聯合開發了DO-178 機載系統和設備認證中的軟件注意事項。DO-178B/C 是處理機載系統中使用的安全關鍵軟件的安全性的指南，旨在滿足適航系統的需求。機載系統中使用的軟件必須滿足標準和相關認證目標。

DO-178B/C 的目標之一是“對軟件產品進行符合性審查”。同行評審的目的是確保完成軟件生命周期，并交付優質產品進行認證。在同行評審過程中，評審者必須評審在評審過程中添加的所有工件，并確保這些工件沒有缺陷。如果發現任何缺陷，審核者需要將其作為發現來捕獲。

在下一步中，實施者必須針對這些缺陷提供適當的解決方案。在進行航空電子軟件驗證時，我們的團隊遇到了許多與拼寫錯誤、同一測試（或同一單元）內重復要求、冗余空格（前導、尾隨、單詞之間等）、HLR-to -LLR 可追溯性，以及缺少特定要求的測試用例。

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

概述：

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

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

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

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

分析需求可追溯性和定位缺失的測試用例是該工具的另一個特點。在驗證中，需求覆蓋率是一個非常重要的方面，也是 DO-178B/C 標準的核心目標之一。DO-178B/C 第 A-7.4 節和 A-4.6 節的目標分別是“實現低級需求的測試覆蓋”和“低級需求可追溯至高級需求”。

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

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

設計細節：

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

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

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

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

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

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

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

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

圖 2.2：工具的靜態分析和清理功能

靜態分析和清理部分執行以下功能：

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

結果：

該工具生成四個結果文件：

靜態錯誤報告 （.txt）

HLR 和 LLR 之間的可追溯性報告 （.xlsx）

需求和測試之間的可追溯性報告 （.csv）

重復要求 （.txt）

以下片段可幫助用戶了解該工具如何工作并產生結果。

圖 3.1：測試用例中的靜態錯誤報告

圖 3.2：HLR 和 LLR 之間的可追溯性報告

圖 3.3：需求和測試之間的可追溯性報告

圖 3.4：顯示重復需求的報告

靜態測試用例和測試過程分析工具與 C# 開發的 GUI 的集成：

我們已經成功地將我們團隊創建的靜態測試用例和測試過程分析工具與另一個團隊實現的 GUI 工具集成在一起。挑戰在于 GUI 工具是用 C# 實現的，而靜態測試用例和測試過程分析工具是用 Python 實現的。

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

以下是此集成的功能：

節省單獨操作工具的開銷

GUI工具本身提供了選擇TC、執行工具、分析報告等所有界面，節省了工程師執行每個步驟的時間

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

案例分析：

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

同行評審結果描述：

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

工件需要重命名。根據指南重命名它。

描述大概時間

大約。是時候讓審閱者發現錯誤并記錄下來了。5分鐘。

大約。是時候讓實施者進行清理了。1分鐘。

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

總周轉時間15 分鐘。

現在，如果在實施時發現相同的錯誤，它可以在不到 5 分鐘的時間內修復。

表 5.1：工具的有效性

優點：

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

將修復錯誤的周轉時間縮短 70%

減少與拼寫、命名約定和 HLR-LLR 可追溯性問題相關的發現數量

未來范圍：

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

基于解析的 LLR，它生成一個 TC 模板，該模板將根據需求準備好一些基本字段，如目標、目的、輸入/輸出。

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

支持 pdf 標記。

結論：

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

當有多個工件時，該工具會更有效，并節省大約 70% 的周轉時間。通過持續使用該工具，我們的團隊消除了與上述所有錯誤相關的發現，顯著提高了工件質量和工作效率。

審核編輯：郭婷