第三篇針對系統(tǒng)集成與系統(tǒng)需求測試。
1 系統(tǒng)集成測試
-
測試目標：為集成的軟硬件符合系統(tǒng)架構設計提供證據(jù)，包括軟硬件接口和數(shù)據(jù)流，體現(xiàn)形式常為系統(tǒng)模型中的系統(tǒng)接口。廣義上，也包括一些機械接口，比如，ECU外殼與PCB的連接、接插件與PCB的連接。
-
測試依據(jù)：如前所述，沒有單獨的系統(tǒng)集成測試用例，其或來源于軟件測試或來源于硬件測試，有時還會用到下一小節(jié)提到的系統(tǒng)需求測試。
-
測試對象/測試設計/測試環(huán)境/進入標準/退出標準/負責角色：參考其他測試部分。
2 系統(tǒng)需求測試
-
測試目標：確保集成系統(tǒng)（含配置、標定）經(jīng)過測試，以證明其符合系統(tǒng)需求且已準備好交付。
-
測試依據(jù)：測試用例來源于系統(tǒng)需求，而表現(xiàn)形式可能是一份獨立的系統(tǒng)需求說明書，也可能是在系統(tǒng)級需求或設計里做了系統(tǒng)測試標識的部分。
-
測試對象：帶有硬件、軟件和標定的ECU。
-
測試設計：測試用例的設計可以選擇如下方法，等價類劃分（將輸入數(shù)據(jù)劃分為若干個等價類，從每個等價類中選取代表性的數(shù)據(jù)進行測試，以縮減測試用例）、邊界值分析（重點關注輸入值的邊界條件，因為在這些邊界附近，程序更容易出錯）、決策表（用于描述在不同條件下的系統(tǒng)行為，幫助測試人員理解并測試復雜的邏輯條件）、狀態(tài)轉換測試（關注系統(tǒng)在不同狀態(tài)之間的轉換，確保系統(tǒng)在狀態(tài)轉換時能夠正確工作）、錯誤猜測（基于測試人員的經(jīng)驗和直覺，猜測可能的錯誤并設計相應的測試用例）、負面測試（在某些情況下，測試人員需要考慮負面測試，即測試系統(tǒng)在不滿足正常工作條件時的行為，如故障注入）。
-
測試環(huán)境：不同于軟件測試，該環(huán)節(jié)的測試要盡可能提供更接近實車的真實環(huán)境約束和外部激勵，使用真實的傳感器、真實的對手件、真實的線束、真實的溫度等。總之，盡量模擬實車的實際使用。
-
進入標準：完成必要的前序測試（如系統(tǒng)集成測試）且無重大問題、相關的測試設備（如線束、ECU、傳感器）就位、已review并發(fā)布的軟硬件、已review并發(fā)布的系統(tǒng)需求測試用例與計劃。
-
退出標準：已執(zhí)行對應的測試用例、測試報告已完成、缺陷已錄入工具鏈。除了常規(guī)的退出外，出于成本的考慮，還會有測試中止，比如，基本功能確認失效、發(fā)現(xiàn)的缺陷會影響其他功能測試結果有效性、對于發(fā)現(xiàn)的缺陷被修復后需重新測試的范圍，或者在測試過程中，得知新的軟硬件即將釋放，也應綜合評估后中止。
-
負責角色：系統(tǒng)測試人員。
3 系統(tǒng)需求測試用例選擇
完整的系統(tǒng)需求測試會消耗大量的時間和資源，但發(fā)布前的最后測試又責任重大，所以，我們需要在用例選擇上做一個平衡，不全測，或者不是每次交付全測，而該測的也一個不能少。一般有如下關注點。
-
必測項：為了控制對整車帶來的風險，首先需要設定一些只要打開軟件或動了硬件就得做的必測項。必測項一般是涉及到ECU最基礎的功能或者直接影響產(chǎn)線或其他對手件聯(lián)調(diào)的部分。
-
產(chǎn)品風險大小：對于功能安全等級較高或者涉及到法律法規(guī)認證等高風險軟件，通常，需要投入更多的資源在影響分析與測試量上，這是一個理所當然的決定。
-
不同配置下的功能是否適用：這需要我們有一個清晰的feature list或配置表，不適用的功能自然不需要測試。
-
功能是否實現(xiàn)：即便本配置有該功能，功能的成熟度也得達到可測水平。
-
變更的范圍：結合接口文檔、系統(tǒng)模型、追溯關系等，對功能自身的變更及其對未變更功能的影響進行評估，并進一步確認測試范圍。有時，ECU外部的系統(tǒng)環(huán)境或者車輛的變更都會影響到測試用例的選擇。
-
歷史測試狀態(tài)：舊的版本、相近配置、相近分支或者平臺主線的測試結果可能可以被當前軟件沿用。一般在這里，也是基于變更來評估。
-
全量測試：Delta測試很必要，但全量測試也不應舍棄，我們可以根據(jù)產(chǎn)品和項目特點制定一些執(zhí)行全量測試的規(guī)則，比如，一年至少一次、切換新硬件或新軟件分支基線后至少一次、發(fā)布D樣件之前至少測試一次、ECU上路試車前至少一次、ECU進入車廠產(chǎn)線前至少一次等。
4 雙向可追溯性和一致性
所有系統(tǒng)級別的可測試需求必須至少被一個測試用例覆蓋。
而為了檢查測試覆蓋率，必須能夠通過工具實現(xiàn)測試報告、測試規(guī)范與相應需求之間的可追溯性，比較典型的是建立鏈接。
如果要發(fā)布的軟件版本的測試覆蓋率不完整，測試團隊應向項目經(jīng)理或客戶匯報，并記錄偏差原因和進行風險評估。
一致性呢，一般也只能通過評審來盡量保證。比如，系統(tǒng)測試人員應該參與系統(tǒng)需求的評審，而feature owner則參與系統(tǒng)測試的測試用例評審。
5 全文小結
6 寫在最后
系統(tǒng)測試比較“硬”，即與ECU、整車有更緊密的關系，而它也側面體現(xiàn)了汽車軟件的獨特性。
轉自水輕言
