汽車測試領(lǐng)域，在模型測試階段進(jìn)行故障注入，是保障汽車安全性、可靠性的關(guān)鍵手段。如何提高故障注入測試的效率呢？

若需對模型中間層元素注入故障，典型實(shí)施步驟如下：

步驟一，在測試框架（testharness）中選擇需要進(jìn)行故障注入的模型中間元素；

步驟二，在GUI窗口中選擇故障內(nèi)容和故障觸發(fā)方式；

步驟三，將測試用例與故障相關(guān)聯(lián)；

步驟四，運(yùn)行測試，查看結(jié)果。

通過上述步驟才能在用例執(zhí)行期間注入故障。盡管一個(gè)模型元素可以創(chuàng)建多個(gè)故障，但一次仿真只能有一個(gè)故障處于激活狀態(tài)，并且想要自定義故障內(nèi)容還需要手動(dòng)搭建故障模型，這就需要測試人員具有一定模型開發(fā)能力。

如此一來不僅影響效率，并且無法靈活應(yīng)對復(fù)雜多變的測試需求，在一定程度上限制了故障注入的廣度和深度。

難道就沒有更高效、更靈活的方式嗎？當(dāng)然有！TPT新增模型故障注入功能，能夠很好地提高測試效率。那TPT是如何進(jìn)行故障注入的呢？

在測試框架中選定目標(biāo)模型中間元素，以Server Function形式導(dǎo)入至TPT平臺，即可在測試用例中直接調(diào)用。該方法無需額外關(guān)聯(lián)操作或搭建故障模型，且支持單次仿真中對同一元素注入多類故障。

圖1 TPTServer function

下面就以燈控模型為例，介紹TPT是如何進(jìn)行故障注入測試的。

圖2 模型以及信號位置

一、模擬數(shù)據(jù)停滯故障

故障場景：在light_intensity信號在6.99s時(shí)數(shù)值出現(xiàn)卡滯。

用例如下：

圖3 用例內(nèi)容

功能需求要求當(dāng)light_switch為自動(dòng)（2），并且light_intensity>70并持續(xù)3s時(shí)，頭燈關(guān)閉。在運(yùn)行結(jié)果中可以看到，光強(qiáng)數(shù)值在第6.99s時(shí)出現(xiàn)卡滯，未滿足light_intensity>70的條件，因此在3s后headlight沒有關(guān)閉。

圖4 運(yùn)行結(jié)果

二、模擬數(shù)據(jù)突變故障：

故障場景：篩選后的光照強(qiáng)度在故障觸發(fā)信號light_switch_isAuto為true時(shí)出現(xiàn)異常值120。

用例如下：

圖5 用例內(nèi)容

在運(yùn)行結(jié)果中可以看到，檢測到信號light_switch_isAuto為true時(shí)，light_intensity數(shù)值發(fā)生了跳變，導(dǎo)致提前計(jì)時(shí)，并且在3s后headlight關(guān)閉。

圖6 運(yùn)行結(jié)果

三、自定義故障：

故障場景：模擬數(shù)據(jù)噪聲影響。在TPT中添加Script，引入Python庫，自定義函數(shù)加入高斯噪聲。用例如下：

圖7 用例內(nèi)容

在運(yùn)行結(jié)果中可以看到，當(dāng)light_switch數(shù)值發(fā)生變化時(shí)，由于引入了噪聲，light_intensity的數(shù)值>70，headlight關(guān)閉，功能正常。

圖8 運(yùn)行結(jié)果

通常情況下，由于引入噪聲的不確定性，需要多次運(yùn)行驗(yàn)證軟件的一致性。如圖所示，該測試用例運(yùn)行5次僅有一次通過，且多次運(yùn)行通過率并不相同。可在模型中更改閾值或加入滯回結(jié)構(gòu)規(guī)避此類問題。

圖9 多次運(yùn)行結(jié)果

TPT靈活多樣的激勵(lì)方法為故障注入測試提供了新的選擇。對于汽車軟件來說，TPT無疑是一個(gè)強(qiáng)大的“利器”，讓故障注入不再是負(fù)擔(dān)，而是保障安全的有力手段。

故障注入測試前移不僅是測試效率的提升，更是平衡研發(fā)成本與周期的重要保證。北匯信息作為新思科技國內(nèi)合作伙伴，始終以專業(yè)的 TPT 技術(shù)支持經(jīng)驗(yàn)，為國內(nèi)客戶提供貼合行業(yè)需求的測試解決方案。我們將與您攜手，共同推動(dòng)汽車電子測試工作提質(zhì)增效，為行業(yè)發(fā)展注入新的活力。