黑盒測試技術(shù)

白盒測試技術(shù)

基于經(jīng)驗測試方法

測試用例技術(shù)

測試用例和測試數(shù)據(jù)是

從功能性或非功能性規(guī)

范說明(也可從模型) 導(dǎo)

出，而不考慮程序的內(nèi)部

結(jié)構(gòu)。

測試用例和測試數(shù)據(jù)是

從測試對象的結(jié)構(gòu)(如涉

及和代碼)導(dǎo)出，而不考

慮規(guī)范說明

測試員、開發(fā)員或其他測試對測試對象和它的環(huán)境的經(jīng)驗

有與錯誤打交道的經(jīng)驗或估計在哪里可能出現(xiàn)錯誤的經(jīng)驗

4.3.4 黑盒設(shè)計法

根據(jù)黑盒測試方法的特點,將其詳細劃分為以下幾個類別:等價類劃分法、邊界值分析法、決策表法、狀態(tài)轉(zhuǎn)移測試法、測試用例法、因果圖法、判斷表驅(qū)動法、正交試驗設(shè)計法、功能圖法。

4.3.5 白盒設(shè)計法

白盒測試方法是基于結(jié)構(gòu)的測試用例設(shè)計方法。通過觀察測試對象的程序代碼，選擇一個代碼覆蓋的標準，然后根據(jù)這標準生成測試用例。例如，所有的語句至少被執(zhí)行一次，在所選標準的基礎(chǔ)上產(chǎn)生單個的測試用例,基于代碼生成的測試用例的基礎(chǔ)是描述程序結(jié)構(gòu)的控制流圖。控制流圖是一個帶有開始和結(jié)束節(jié)點的有向圖，程序的指令(語句)是通過節(jié)點來表示的,一個沒有分支的語句序列可以用一個節(jié)點表示，語句之間的路徑是通過邊(控制流)來描述，圖內(nèi)的開始和結(jié)束節(jié)點可以省略。

4.3.6 經(jīng)驗設(shè)計法

4.3.6.1錯誤推斷法

基于經(jīng)驗和直覺推測程序中所有可能存在的各種錯誤,從而有針對性的設(shè)計測試用例的方法。錯誤推測方法的基本思想: 列舉出程序中所有可能有的錯誤和容易發(fā)生錯誤的特殊情況，根據(jù)他們選擇測試用例。

例如，在單元測試時曾列出的許多在模塊中常見的錯誤。以前產(chǎn)品測試中曾經(jīng)發(fā)現(xiàn)的錯誤等，這些就是經(jīng)驗的總結(jié)。輸入數(shù)據(jù)和輸出數(shù)據(jù)為零的情況，輸入表格為空格或輸入表格只有一行，這些都是容易發(fā)生錯誤的情況，可選擇這些情況下的例子作為測試用例

在產(chǎn)品測試的實踐中對產(chǎn)品的了解的加深和測試經(jīng)驗的豐富，使用錯誤推測法設(shè)計的測試用例往往非常有效，可以作為測試設(shè)計的一種補充手段，并且積累的經(jīng)驗越豐富，方法使用效率越高。

4.3.6.2 探索測試法

探索式測試(Exploratory Testing)是一種軟件測試方法，也可以說是一種測試思維方法,是一種強調(diào)個人自由與責(zé)任的測試方法,讓獨立測試人員可以借用不斷的學(xué)習(xí)來改善測試的規(guī)劃與測試的執(zhí)行，而在測試的過程中也會同時改善測試案例達到相輔相成的效果。

4.3.7自動化測試用例開發(fā)

測試用例的開發(fā)需嚴格遵循整車控制器功能規(guī)范文檔,測試用例需針對被測控制器功能進行開發(fā)，并形成測試矩陣文檔及測試用例說明文檔。

測試矩陣編寫在嚴格遵守整車控制器開發(fā)功能文檔的基礎(chǔ)上，創(chuàng)建測試用例，文檔中需對每條測試用例的測試功能，測試方法及預(yù)期結(jié)果進行簡單描述，并對每條測試用例進行編碼.以便測試過程中通過測試編號進行查找問題。

測試用例說明文檔是對測試矩陣的詳細補充，測試矩陣中對測試用例只做簡單描述，測試說明文檔針對每條測試用例測試的功能，測試時的初始條件，完成該測試用例具體需要的詳細執(zhí)行步驟，更改的信號位置及名稱，甚至測試動作后的等待時間，以及預(yù)期結(jié)果需要檢測的信號名稱等進行詳細描述。依據(jù)此文檔可直接編輯自動化測試用例。

說明文檔針對每條測試用例測試的功能，測試時的初始條件，完成該測試用例具體需要的詳細執(zhí)行步驟，更改的信號位置及名稱，甚至測試動作后的等待時間，以及預(yù)期結(jié)果需要檢測的信號名稱等進行詳細描述。依據(jù)此文檔可直接編輯自動化測試用例。

測試管理軟件的功能:1) 寫測試序列:2) 管理試驗軟件:3) 生成測試報告

配置與試驗環(huán)境軟件的功能: 1) 接收測試序列發(fā)來的激勵數(shù)據(jù): 2) 將激勵數(shù)據(jù)發(fā)給實時仿真機，并在線顯示仿真結(jié)果

4.4 測試調(diào)試

4.4.1 冒煙測試

測試工程搭建完成后，連接被測控制器，需要對被測控制器和 HiL 測試設(shè)備做冒煙測試驗證設(shè)備連接與原件是否有基本的問題。冒煙測試有測試人員和開發(fā)人員共同完成，在測試過程中發(fā)現(xiàn)問題，測試人員找到了一個 Bug，然后開發(fā)人員會來修復(fù)這個 Bug，冒煙測試是否通過決定了下一輪系統(tǒng)測試是否可以執(zhí)行。

4.4.2 接口測試

接口測試是只有被測控制器，沒有和整車仿真模型形成閉環(huán)的測試，屬于開環(huán)測試。接口測試通過人為賦值模擬外部控制器與被測控制器之間的數(shù)據(jù)交互,驗證被測控制器數(shù)據(jù)交互是否正常，側(cè)重信號交互驗證。一般接口測試如果有測試程序，可以自動測試，如果沒有測試程序，可手動測試。

4.4.3 首輪測試

被測控制器和整車仿真模型形成閉環(huán)的測試，屬于閉環(huán)測試。閉環(huán)測試通過模擬操作駕駛室變量，使整車模型與被測控制器自動數(shù)據(jù)交互，驗證被測控制器軟件策略，側(cè)重功能和性能驗證。

打開自動化測試用例庫，在 TestStand 測試界面調(diào)入測試用例對象，直接運行即可。

4.4.4問題關(guān)閉

測試過程中發(fā)現(xiàn)的問題使用問題單形式記錄。在問題記錄和問題描述遵循“5C”的要求:

正確(Correct)，不會產(chǎn)生歧義:

清晰( Clear)，容易理解;

簡潔(Concise)，沒有多余的東西;

完整(Complete)，包含重現(xiàn)缺陷的完整數(shù)據(jù)；

致性(Consistent)，缺陷單格式要統(tǒng)

4.4.5 回歸測試

在第一輪測試相關(guān)問題關(guān)閉后，由開發(fā)人員更新軟件，生成新的軟件版本，下載到被測控制器中，在 HiL 設(shè)備上對上個版本中出現(xiàn)并修復(fù)的缺陷進行再次驗證，并以缺陷為核心，對相關(guān)修改的部分進行測試。

4.4.6 測試報告

通過 HiL 測試管理軟件加載測試序列，執(zhí)行測試，輸出測試報告。

4.5測試總結(jié)

被測控制器 HiL 回歸測試完成，在功能方面達到測試通過標準后，需要對 HiL 測試工作進行總結(jié)和整理，并生成及編制 HiL 測試總結(jié)。

HiL 測試總結(jié)主要包括以下內(nèi)容:

1、HilL 測試環(huán)境、測試周期、測試人員及測試內(nèi)容等;

2、測試過程中的問題統(tǒng)計與分析，并對測試遺留問題進行記錄;

3、測試結(jié)束后檢查所做的測試工作及完成情況，提交工作成果，包括: 測試用例說明文檔，測試矩陣文檔，可執(zhí)行文件及生成的測試報告等

來源：新能源汽車電控開發(fā)與測試