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