最近的工作需要經常和測試打交道，但我并非這個細分領域的行家，看著幾千條測試用例和五花八門的測試設備與工具，以及工程師展示的繁復曲線與圖表，著實有些眼花繚亂，沒太看懂，不由得陷入了深深的思索......
1 T型人才與焦利氏稱
陷入思索有兩個原因：一是確實沒跟上節(jié)奏，只能佯裝沉思，以掩飾尷尬，保持風度；二是汽車領域的知識太多了，沒能力是一說，但也實在沒必要事事跟上節(jié)奏，守好自己碗里的飯就不錯了。
可是，我們不是要構建T型知識結構，成為綜合性人才嘛。那怎么辦呢？
寫到這里，想到多年前的大學物理實驗課，絕大多數課意料之內地忘得干干凈凈，但倒是記住了一堂——焦利氏稱，原因是老師說的一句話，“話我照講，實驗你們照做，但你們多年后肯定記不住我們今天做了什么，只要記住一點，焦利氏稱是測微小力的......”老師的反向操作倒也是6，不肖弟子把老師是誰都忘了，還記著這句話。
這堂課的這部分，于我，是最有價值的內容，但凡我遇到測微小力的場景，我就可以快速收集整理焦利氏稱的信息......否則，這么冷門的東西有幾個人曉得呢？
回到我們的T型人才，這涉及一個知識結構搭建的問題，我們得把T這一橫里的那些原則性、策略性、共性的東西提煉出來，完善自己的知識和認知框架，細節(jié)嘛，擇需而取。
下面開始正題，概要講幾個ECU測試的小點。
2 系統(tǒng)與軟件測試的區(qū)別
在ECU開發(fā)測試中，通常會把二者區(qū)分開來，我們從以下幾個角度來看差異點：
- 測試對象：軟件測試是面向集成在芯片上的軟件；系統(tǒng)測試是針對包含軟件、硬件與標定的ECU。
- 測試目的：軟件測試是來尋找軟件中的錯誤，證明軟件本身符合軟件需求；系統(tǒng)測試是尋找軟件、硬件與標定以及結構件共同組成的ECU中的錯誤，證明系統(tǒng)符合系統(tǒng)需求。
- 測試環(huán)境：軟件測試要盡量獨立于硬件，要通過諸如CANoe發(fā)送信號的模擬方式進行，盡量模擬；系統(tǒng)測試要盡量真實，真實的線束，真實的負載等。
3 測試的次序
最好呢，從V模型的最底層按次序逐層測上來，但最好的東西一般不容易得到，我們基本沒有那么多時間來進行這樣的瀑布式開發(fā)。
所以得考慮一些大的原則，然后，適當地并行。
- 單元級測試這種非典型測試，最好首先完成，甚至要通過工具鏈和代碼生成進行綁定，即不達到一定的條件無法生成代碼，早期一些代碼邏輯的覆蓋測試會極大地減少后期痛苦的返工。
- 冒煙或基本功能測試是第二優(yōu)先級的測試，基本可用也是開發(fā)人員基本素養(yǎng)的要求。
- 軟件功能、系統(tǒng)集成、系統(tǒng)測試可以在架構變化、接口歷史問題等現實項目情況的考慮下，進行適當的并行。
4 測試準入條件
測試并不是想測就能測的，需要達到一定的條件才能交給測試團隊，這就是測試準入條件。這些規(guī)則對于大團隊協作非常重要。
- 首先要看前面講的必要測試次序及測試結果是不是滿足進行更高層級測試要求。
- 硬件設備已就位，比如，ECU工程樣件、線束、外圍傳感器、對手件等。
- 測試臺架可用，并已經過校準。
- 測試信息輸入完成，比如，軟硬件版本、配置參數、測試計劃、交付信息等。
- 標定已到位。
- 文檔（需求、測試規(guī)范等）完成review與基線化。
- 軟件交付按流程完成評審。
5 測試準出條件
測試不是想來就來，也不是想走就走的，我們還需要準出條件。
準出其實是有兩層含義的，第一層是正常結束，第二層是異常終止。
5.1 正常結束
一般，我們要同時滿足以下條件，才可進行正常結束。
- 所有計劃的測試均已按計劃執(zhí)行。
- 測試結果的異常項完成了分析與評審。
- 發(fā)現的bug錄入相應ALM工具。
5.2 異常終止
除了流程強制外，終止的大部分原因是考慮到成本與時間，有些情況下，測試沒必要繼續(xù)進行。
- 軟件或ECU質量太差，不足以支撐測試。
- 測試開始后，發(fā)現沒有滿足準入條件。
- 如果發(fā)現的bug會影響到某些測試的有效性，則這些測試要停下來。
- 如果修復某些bug后還需要重測某些case，則這些case在修復后再進行。
- 如果新的硬件或軟件很快就可用（很快是多快要具體定義了），所有的測試就可停下來，等待新的軟硬件。
6 測試用例的選擇
開始測試之前，我們多數會有一個測試用例庫，每版本都全測自然是帶來高成本和長周期，因此，用例是需要被選擇的，也就是我們總說的Delta測試。
- 產品本身的風險高低，對于ASIL等級較高的產品，要強制做一些關鍵功能測試。
- feature的實現情況。
- 已知的軟硬件變化。
- 工作量評估。
- 前序版本、相關版本的測試狀態(tài)。
- 變更對未更改部分的影響。
- 不同項目變體之間的調度策略。
- 對于這類主觀及經驗屬性較大的決策，每個未執(zhí)行的測試用例最好都有一個的記錄下來的理由。
除了Delta測試，全功能測試的策略也應被制定出來，比如，一年至少一次全功能，SOP前完成一次全功能，平臺軟件升級后進行一次全功能，發(fā)版超過5版之后進行一次全功能，硬件有變化時要進行一次全功能......
7 測試管理
測試是一項復雜冗長的工作，必要的管理是必要的。
7.1 測試管理
測試管理的目標是，根據測試計劃獲取相應的測試交付物（例如，測試規(guī)范、測試執(zhí)行、測試報告、測試評審、缺陷提交等)，并且要保證交付能滿足項目進度中定義的里程碑。
7.2 測試資源
交付物能夠及時獲取的一個大前提是測試資源能夠得到滿足，而測試資源包括人員的能力、測試設備、測試樣件等。
7.3 測試調度
為了盡早確定可能的退出條件，必須首先執(zhí)行失敗概率更高的測試，比如，依次按照以下次序進行。
- bug重新測試
- 測試新功能
- 測試修改或優(yōu)化的功能
- 未改變feature的測試（回歸測試）
7.4 測試計劃和監(jiān)控
基于項目進度要求以及“測試評估”和“測試調度”的結果，我們就能夠給出測試階段完成的截止日期，從而得出詳細的計劃。
計劃所需的詳細程度取決于項目的復雜性和所涉及的測試人員的數量。
8 雙向追溯性和測試覆蓋率
每一條系統(tǒng)或軟件的可測試需求都需要被至少一個測試用例強制覆蓋。為了檢查測試覆蓋率，測試報告、測試規(guī)范和相應需求之間的可追溯性可借助相應的需求覆蓋率工具，如Reqtify。
如果測試覆蓋不完整，則需要將信息暴露給項目層面，并完成風險評估與偏差許可。
轉自汽車ECU開發(fā)
