需求模型下的航天軟件測試用例方法探討

摘 要 為了解決隨著軟件規模和空間系統復雜性的增長，“空間模型在軟件開發周期中的縮短”導致軟件開發效率不足的問題，例如通過引入新的空間軟件開發方法，模型驅動軟件開發方法，模型驅動的軟件開發方法采用“開發人員構建圖形模型，由模型代碼自動生成”模型，以提高軟件開發效率，并具有正式的驗證功能，以確保代碼與模型的一致性。然而，模型驅動的軟件開發方法不僅提高了航天模型軟件的開發效率，而且還挑戰了傳統的軟件測試方法。盡管目前在航空航天領域有相對完善的測試方法系統，并且部分測試工作可以自動執行，但是這些傳統的測試方法基于需求文檔的測試，因此無法應用于模型驅動的開發軟件。如何有效地測試模型驅動的航空軟件已經成為迫在眉睫的問題。

關鍵詞 需求模型下;航天軟件測試;用例方法

引言

隨著各種航空技術的發展，航空軟件的規模和復雜性也在增加。另外，航天模型的開發周期呈現出逐漸縮短的趨勢，這導致傳統軟件開發模式無法滿足航天模型軟件開發的效率和可靠性要求。作為提高軟件開發效率的解決方案，模型驅動的軟件開發方法受到了越來越多的關注。目前，模型驅動軟件開發方法已廣泛應用于航空，軌道交通等高安全性實時嵌入式領域，航空航天領域已經嘗試了模型驅動軟件開發方法，并取得了一定的成果，驗證了軟件開發方法在航空航天領域的可行性。然而，新的軟件開發模式不僅為“開發效率低下”的問題帶來了解決方案，而且還帶來了新的問題：如何有效地測試由新模式開發的軟件。

1 基于數據流圖的測試用例自動生成方法

在以前的基于數據流圖的用例生成研究中，通常采用路徑遍歷的方法來規劃測試用例中的每條路徑。這種方法的缺點是無法建立輸入和輸出之間的關系，并且某些路徑不可達，從而導致冗余的測試用例。因此，本文通過將輸入輸出映射表添加到數據流程圖來設計用例生成方法。根據需求分析的完整性，使用數據流程圖的測試用例設計分為兩種情況：

①當前測試項目的數據處理節點中有一個輸入輸出映射表，或者雖然沒有輸入輸出映射表，但是在其子圖中的所有處理節點中都有一個輸入輸出映射表，因此父節點的輸入-輸出映射表可以自動從子圖導出。在這種情況下，根據從節點本身或子圖自動導出的輸入輸出映射表，如果表中有空格，則表示該行中空格對應的輸入變量的值不會影響輸出，并且變量定義中的值范圍將添加到表中。然后，將表中的每一行計劃為一個測試用例，用于檢查輸入表中指定范圍內的數據時是否可以獲得預期的輸出。②當前測試項目的數據處理節點不存在輸入輸出映射表，也不能通過子圖自動導出。在這種情況下，由于無法確認輸入和輸出之間的關系，因此可用于生成輔助測試用例。輔助測試用例僅包含輸入變量的值范圍。如果子圖中輸入變量的輸入節點處有輸入輸出映射表，則通過映射表確定輸入變量的值范圍;否則，通過定義變量獲得值范圍[1]。

2 基于狀態遷移圖的測試用例自動生成方法

狀態遷移圖生成的用例應涵蓋模型中的所有狀態和狀態遷移。像數據流程圖一樣，狀態遷移圖也可以抽象為有向圖，狀態抽象為有向圖的節點，狀態遷移也抽象為圖的有向邊。通過遍歷有向圖，可以獲得所有狀態遷移路徑，并且將每個遷移路徑計劃為測試用例。用例應將路徑中的所有狀態遷移條件作為輸入，并將路徑中的狀態遷移序列作為預期輸出。通常，狀態測試序列越長，錯誤暴露的可能性就越高，因此，設計的測試用例的錯誤糾正能力也就越強。基于此原理，深度優先算法更適合于路徑遍歷。通過分析狀態遷移圖的組成結構，主要有三種形式：①時間狀態遷移圖的特征在于，從一個狀態向另一個狀態進行正向遷移之后，沒有反向遷移到先前狀態的情況，即狀態遷移是單向的。這種類型的狀態遷移圖可以抽象為有向圖，并表示為樹圖。傳統的深度優先算法可用于完成所有路徑的遍歷。②緊密連接的狀態遷移圖，即狀態遷移圖中的任何兩個不同狀態都具有可相互訪問的遷移路徑。從這種狀態遷移圖抽象出來的有向圖將包含大量循環，因此很難直接遍歷有向圖。因此，可以考慮在遍歷狀態遷移圖之前對其進行預處理。③將以上兩種類型的狀態遷移圖組合在一起，即狀態遷移圖具有幾個緊密連接的組件，但本身不是一個緊密連接的圖。從這種狀態遷移圖抽象出來的有向圖也是帶循環的有向圖，不能直接遍歷。首先，可以減少圖中的強連接分量，并且可以將強連接的分量抽象為圖的節點，以獲得無環的有向圖。然后，可以基于深度優先的路徑遍歷圖。最后，可以計算每個牢固連接的組件的路徑以補充深度優先遍歷的路徑[2]。

3 基于控制表的測試用例自動生成方法

在傳統的手動測試方法中，決策表是重要且常用的需求分析和描述工具。判斷表通常由條件堆，動作堆，條件元素和動作元素組成。其中，條件元素和動作元素分別代表輸入條件和輸出動作。條件堆是一組條件元素，枚舉所有輸入條件，動作堆是一組操作元素，枚舉所有輸出動作。測試人員通過覆蓋決策表中所有可能的條件元素組合和相應的動作元素組合來設計測試用例。控制表可以視為傳統決策表的變體。控制表的控制輸入對應于決策表的條件堆，控制輸出和處理激活對應于動作堆。因此，可以根據傳統決策表測試用例的設計思路和方法生成基于控制表的測試用例，即完成控制表中控件輸入，控件輸出和處理激活的覆蓋。顯然，可以通過將控制表的每一行都計劃為測試用例來滿足測試元素的完全覆蓋的要求。

4 結束語

本章主要介紹以下內容：解釋了使用需求模型自動生成測試用例的整個思想;分析了模型存儲格式，并通過XML解析技術提取了生成測試用例所需的模型信息;建立了自動劃分測試項目的規則。分析了數據流圖，狀態遷移圖，控制表和順序圖，并開發了基于不同類型模型的測試用例生成策略，然后設計了相應的測試用例生成算法。

參考文獻

[1] 左萬娟，虞礪琨，王小麗，等.基于共性需求的軟件通用自動化測試設計研究[J].計算機技術與發展，2020，30（6）：49-54.

[2] 劉夢飛.航天軟件測試用例設計質量的評估及提升[J].質量與可靠性，2020（2）：39-41，45.

作者簡介

陳海燕（1983-），女，廣西玉林人;學歷：本科，研究方向：軟件工程/軟件測試。