ecu測試是什么 汽車ecu測試的共性有哪些

4

測試準(zhǔn)入條件

測試并不是想測就能測的，需要達到一定的條件才能交給測試團隊，這就是測試準(zhǔn)入條件。這些規(guī)則對于大團隊協(xié)作非常重要。

首先要看前面講的必要測試次序及測試結(jié)果是不是滿足進行更高層級測試要求。

硬件設(shè)備已就位，比如，ECU工程樣件、線束、外圍傳感器、對手件等。

測試臺架可用，并已經(jīng)過校準(zhǔn)。

測試信息輸入完成，比如，軟硬件版本、配置參數(shù)、測試計劃、交付信息等。

標(biāo)定已到位。

文檔（需求、測試規(guī)范等）完成review與基線化。

軟件交付按流程完成評審。

5

測試準(zhǔn)出條件

測試不是想來就來，也不是想走就走的，我們還需要準(zhǔn)出條件。

準(zhǔn)出其實是有兩層含義的，第一層是正常結(jié)束，第二層是異常終止。

5.1 正常結(jié)束

一般，我們要同時滿足以下條件，才可進行正常結(jié)束。

所有計劃的測試均已按計劃執(zhí)行。

測試結(jié)果的異常項完成了分析與評審。

發(fā)現(xiàn)的bug錄入相應(yīng)ALM工具。

5.2?異常終止

除了流程強制外，終止的大部分原因是考慮到成本與時間，有些情況下，測試沒必要繼續(xù)進行。

軟件或ECU質(zhì)量太差，不足以支撐測試。

測試開始后，發(fā)現(xiàn)沒有滿足準(zhǔn)入條件。

如果發(fā)現(xiàn)的bug會影響到某些測試的有效性，則這些測試要停下來。

如果修復(fù)某些bug后還需要重測某些case，則這些case在修復(fù)后再進行。

如果新的硬件或軟件很快就可用（很快是多快要具體定義了），所有的測試就可停下來，等待新的軟硬件。

6

測試用例的選擇

開始測試之前，我們多數(shù)會有一個測試用例庫，每版本都全測自然是帶來高成本和長周期，因此，用例是需要被選擇的，也就是我們總說的Delta測試。

產(chǎn)品本身的風(fēng)險高低，對于ASIL等級較高的產(chǎn)品，要強制做一些關(guān)鍵功能測試。

feature的實現(xiàn)情況。

已知的軟硬件變化。

工作量評估。

前序版本、相關(guān)版本的測試狀態(tài)。

變更對未更改部分的影響。

不同項目變體之間的調(diào)度策略。

對于這類主觀及經(jīng)驗屬性較大的決策，每個未執(zhí)行的測試用例最好都有一個的記錄下來的理由。

除了Delta測試，全功能測試的策略也應(yīng)被制定出來，比如，一年至少一次全功能，SOP前完成一次全功能，平臺軟件升級后進行一次全功能，發(fā)版超過5版之后進行一次全功能，硬件有變化時要進行一次全功能......

7

測試管理

測試是一項復(fù)雜冗長的工作，必要的管理是必要的。

7.1 測試管理

測試管理的目標(biāo)是，根據(jù)測試計劃獲取相應(yīng)的測試交付物（例如，測試規(guī)范、測試執(zhí)行、測試報告、測試評審、缺陷提交等)，并且要保證交付能滿足項目進度中定義的里程碑。

7.2?測試資源

交付物能夠及時獲取的一個大前提是測試資源能夠得到滿足，而測試資源包括人員的能力、測試設(shè)備、測試樣件等。

7.3 測試調(diào)度

為了盡早確定可能的退出條件，必須首先執(zhí)行失敗概率更高的測試，比如，依次按照以下次序進行。

bug重新測試

測試新功能

測試修改或優(yōu)化的功能

未改變feature的測試（回歸測試）

7.4 測試計劃和監(jiān)控

基于項目進度要求以及“測試評估”和“測試調(diào)度”的結(jié)果，我們就能夠給出測試階段完成的截止日期，從而得出詳細的計劃。

計劃所需的詳細程度取決于項目的復(fù)雜性和所涉及的測試人員的數(shù)量。

8

雙向追溯性和測試覆蓋率

每一條系統(tǒng)或軟件的可測試需求都需要被至少一個測試用例強制覆蓋。為了檢查測試覆蓋率，測試報告、測試規(guī)范和相應(yīng)需求之間的可追溯性可借助相應(yīng)的需求覆蓋率工具，如Reqtify。

如果測試覆蓋不完整，則需要將信息暴露給項目層面，并完成風(fēng)險評估與偏差許可。

編輯：黃飛

?