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