《解讀汽車軟件測試之“軟件單元與集成測試”》

接上文。

第二篇針對軟件需求測試。軟件需求測試有時也被稱為軟件功能測試或者直接簡稱為軟件測試。

1、概述

軟件需求測試是汽車軟件測試的第四級別。在此階段之后，通�？梢詫④浖�交由驗收團隊或交付團隊進行系統級測試。

測試目標：確保對集成的軟件進行測試，以證明其符合軟件需求。

測試依據：測試用例來源于軟件需求，而表現形式可能是一份獨立的軟件需求說明書，也可能是在系統級需求或設計里做了軟件標識的部分。

測試對象：運行在MCU或SOC上的集成軟件。

測試設計：測試用例的設計可以選擇如下方法，等價類劃分（將輸入數據劃分為若干個等價類，從每個等價類中選取代表性的數據進行測試，以縮減測試用例）、邊界值分析（重點關注輸入值的邊界條件，因為在這些邊界附近，程序更容易出錯）、決策表（用于描述在不同條件下的系統行為，幫助測試人員理解并測試復雜的邏輯條件）、狀態轉換測試（關注系統在不同狀態之間的轉換，確保系統在狀態轉換時能夠正確工作）、錯誤猜測（基于測試人員的經驗和直覺，猜測可能的錯誤并設計相應的測試用例）、負面測試（在某些情況下，測試人員需要考慮負面測試，即測試系統在不滿足正常工作條件時的行為，如故障注入）。

測試環境：汽車軟件開發中，我們常希望得到狀態比較好的硬件，甚至實車環境，但軟件需求測試并不追求于此，而且要盡量保證測試不受硬件的影響，因為要從理論邏輯層面保證軟件需求被落實。比如，Matlab中基于模型的MIL測試環境、基于臺架或虛擬ECU的SIL測試環境。當然，有時PC中無法模擬某些ECU或傳感器，也只能使用真實硬件。

進入標準：完成必要的前序測試（如冒煙）且無重大問題、相關的測試設備（如線束、ECU、CANoe硬件）就位、已review并發布的軟件需求測試用例與計劃。

退出標準：已執行對應的測試用例、測試報告已完成、缺陷已錄入工具鏈。除了常規的退出外，出于成本的考慮，還會有測試中止，比如，基本功能確認失效、發現的缺陷會影響其他功能測試結果有效性、對于發現的缺陷被修復后需重新測試的范圍，或者在測試過程中，得知新的軟硬件即將釋放，也應綜合評估后中止。

負責角色：軟件測試人員。

2、測試用例選擇

完整的軟件需求測試會消耗大量的時間和資源，所以，我們需要在用例選擇上做一個平衡，不全測，或者不是每次交付全測。一般有如下關注點。

產品風險大小：對于功能安全等級較高或者涉及到法律法規認證等高風險軟件，通常，需要投入更多的資源在影響分析與測試量上，這是一個理所當然的決定。

不同配置下的功能是否適用：這需要我們有一個清晰的feature list或配置表，不適用的功能自然不需要測試。

功能是否實現：即便本配置有該功能，功能的成熟度也得達到可測水平。

變更的范圍：結合接口文檔、模型、追溯關系等，對軟件組件自身的變更及其對未變更組件的影響進行評估，并進一步確認測試范圍。有時，軟件外部的系統環境或者車輛的變更都會影響到測試用例的選擇。

歷史測試狀態：舊的版本、相近配置、相近分支或者平臺主線的測試結果可能可以被當前軟件沿用。一般在這里，也是基于變更來評估。

持續集成：為了確保基礎功能沒問題，我們可以設定一些關鍵的必測項，也就是不管什么修改，都至少運行這一套用例。結合自動化測試腳本，可以將其部署在持續集成流水線中。

全量測試：Delta測試很必要，但全量測試也不應舍棄，我們可以根據產品和項目特點制定一些執行全量測試的規則，比如，一年至少一次、切換分支基線后至少一次、發布D樣件之前至少測試一次、軟件上路試車前至少一次、發布10版軟件后至少一次等。

3、雙向可追溯性和一致性

所有軟件級別的可測試需求必須至少被一個測試用例覆蓋。

而為了檢查測試覆蓋率，必須能夠通過工具實現測試報告、測試規范與相應需求之間的可追溯性，比較典型的是建立鏈接。

如果要發布的軟件版本的測試覆蓋率不完整，測試團隊應向項目經理或客戶匯報，并記錄偏差原因和進行風險評估。

一致性呢，一般也只能通過評審來盡量保證。比如，軟件測試人員應該參與軟件需求的評審，而軟件需求開發人員則參與軟件測試的測試用例評審。

4、全文小結

本文首先從目標、對象、環境、進入/退出標準等方面概述了軟件需求測試的基本概念和要求。

由于完整的軟件需求測試會耗費大量的成本，如何選擇測試用例進行Delta測試就是一個重要的課題，所以第二部分對此進行了介紹。

汽車軟件開發中，一般至少應在這個層級及以上關注追溯。這也是本文最后一部分的內容。

5、寫在最后

通常，處于軟件開發末端的軟件需求測試，承擔了不該承擔的攔截問題和保證交付的主要壓力，讓我們向他們致以歉意。

       原文標題 : 解讀汽車軟件測試之“軟件需求測試”