基于目前的汽車(chē)電氣架構(gòu)主要是分布式的電器架構(gòu)，汽車(chē)的功能分解到了各個(gè)相應(yīng)的功能模塊，因此嵌入式汽車(chē)軟件的復(fù)雜度，相比于IT軟件，并沒(méi)有那么大，但質(zhì)量要求相對(duì)非常高。為了解決軟件開(kāi)發(fā)過(guò)程中的各種問(wèn)題，先后引入了瀑布模型、V模型、敏捷等。

這里以V模型引入汽車(chē)嵌入式軟件開(kāi)發(fā)中的單元測(cè)試、集成測(cè)試和系統(tǒng)測(cè)試。

01  單元測(cè)試

黑盒測(cè)試

黑盒測(cè)試是軟件測(cè)試中的一種測(cè)試方法，它是指在不了解系統(tǒng)內(nèi)部結(jié)構(gòu)或工作原理的情況下，通過(guò)輸入數(shù)據(jù)并觀察輸出結(jié)果來(lái)判斷系統(tǒng)的正確性、完整性和可靠性的測(cè)試方法。

黑盒測(cè)試的重點(diǎn)在于測(cè)試對(duì)象的功能和性能是否符合需求規(guī)格說(shuō)明書(shū)的要求。黑盒測(cè)試適用于所有軟件類(lèi)型，無(wú)論是桌面應(yīng)用程序、服務(wù)器端軟件還是嵌入式控制系統(tǒng)等。

黑盒測(cè)試分為等價(jià)類(lèi)劃分、邊界值分析、決策表測(cè)試、場(chǎng)景測(cè)試等多種方式。

①等價(jià)類(lèi)劃分

等價(jià)類(lèi)劃分是最為常用的一種測(cè)試方法之一，它將所有可能的輸入數(shù)據(jù)劃分成若干個(gè)等價(jià)類(lèi)，每個(gè)等價(jià)類(lèi)的數(shù)據(jù)被認(rèn)為具有相同的影響，從而提高測(cè)試效率和測(cè)試覆蓋率。

例如一個(gè)溫度采集復(fù)雜驅(qū)動(dòng)，不同電壓的輸入表示不同溫度，我們需要在傳感器允許范圍內(nèi)輸入對(duì)應(yīng)的電壓值來(lái)觀察是否輸出了對(duì)應(yīng)的溫度。

②邊界值分析

通過(guò)測(cè)試極限數(shù)據(jù)來(lái)檢測(cè)軟件中可能存在的錯(cuò)誤。

例如一個(gè)溫度采集復(fù)雜驅(qū)動(dòng)，溫敏傳感器測(cè)量溫度范圍為-40℃——150℃，對(duì)應(yīng)電壓為0.2V——4.5V，我們可以在邊界處出入0.19V或者4.6V的情況。

③決策表測(cè)試

適用于復(fù)雜的業(yè)務(wù)邏輯的測(cè)試。決策表是一種規(guī)范化的表格，通過(guò)列出所有可能的輸入組合和輸出結(jié)果來(lái)描述一個(gè)系統(tǒng)的決策邏輯。通過(guò)決策表測(cè)試，可以發(fā)現(xiàn)許多在其他測(cè)試方法中難以發(fā)現(xiàn)的問(wèn)題。

④場(chǎng)景測(cè)試

場(chǎng)景測(cè)試是一種基于用戶(hù)使用場(chǎng)景的測(cè)試方法，它可以發(fā)現(xiàn)軟件在不同場(chǎng)景下的異常行為和錯(cuò)誤。例如LCC（車(chē)道保持輔助）功能在不同路況下的運(yùn)行情況。

白盒測(cè)試

①白盒測(cè)試簡(jiǎn)介

白盒測(cè)試是一種在知道程序內(nèi)部結(jié)構(gòu)的情況下采用的測(cè)試技術(shù)或策略，選取足夠的測(cè)試用例，對(duì)源代碼實(shí)現(xiàn)比較充分的覆蓋，以便盡可能多地發(fā)現(xiàn)程序中的錯(cuò)誤．它包括邏輯覆蓋、路徑測(cè)試、控制流測(cè)試和數(shù)據(jù)流測(cè)試等方法。

在ISO/IEC/IEEE 29119系列軟件測(cè)試標(biāo)準(zhǔn)中，第四部分基于結(jié)構(gòu)的測(cè)試技術(shù)用于白盒測(cè)試中，我們將著重關(guān)注右圖中紅色方框選中的部分

白盒測(cè)試相較于軟件單元測(cè)試是一種更為詳細(xì)的測(cè)試方法，測(cè)試人員需要了解被測(cè)試軟件的內(nèi)部結(jié)構(gòu)和邏輯。它測(cè)試軟件中的程序代碼的每一條路徑是否能按預(yù)期執(zhí)行，以檢測(cè)程序中可能存在的邏輯錯(cuò)誤和漏洞，提高軟件的質(zhì)量和安全性。

②白盒測(cè)試優(yōu)點(diǎn)

白盒測(cè)試可測(cè)試出隱藏的錯(cuò)誤，優(yōu)化代碼；

白盒測(cè)試的測(cè)試用例可實(shí)現(xiàn)自動(dòng)化；

白盒測(cè)試比其他測(cè)試方法更全面，因?yàn)樗軠y(cè)試代碼的所有路徑。

③語(yǔ)句覆蓋

若要使語(yǔ)句覆蓋度達(dá)到100%，則要求設(shè)計(jì)足夠多的測(cè)試用例，使得程序中每條語(yǔ)句至少被執(zhí)行一次。語(yǔ)句覆蓋的測(cè)試用例是依據(jù)源代碼中顯性的存在的語(yǔ)句進(jìn)行編寫(xiě)的，所以無(wú)法測(cè)試出隱藏的分支或條件，如懸空的else；再如，在Do-While結(jié)構(gòu)中，語(yǔ)句覆蓋執(zhí)行其中某一個(gè)條件分支。

顯然，語(yǔ)句覆蓋對(duì)于多分支的邏輯運(yùn)算是無(wú)法全面反映的，它只關(guān)注語(yǔ)句是否執(zhí)行一次，而不考慮其他情況。但是，通過(guò)語(yǔ)句覆蓋，可以找到程序中的Dead Code，即未執(zhí)行的代碼(如函數(shù)中return后面的語(yǔ)句)；未執(zhí)行的分支 (如分支判斷條件總是為true或false)。

④分支覆蓋

語(yǔ)句覆蓋測(cè)試程序中每條語(yǔ)句至少執(zhí)行一次的情況，但是它無(wú)法檢測(cè)程序中隱藏的分支或循環(huán)運(yùn)算。分支/決策覆蓋是白盒測(cè)試中測(cè)試執(zhí)行路徑覆蓋度大于語(yǔ)句覆蓋的方法，它們可用來(lái)：

驗(yàn)證代碼中的所有分支；

檢測(cè)由于隱藏分支導(dǎo)致程序操作異常；

消除語(yǔ)句測(cè)試無(wú)法覆蓋的問(wèn)題。

但是，如右圖所示，條件A、B和C構(gòu)造一個(gè)了布爾表達(dá)式，分支覆蓋和決策覆蓋只關(guān)心決策的路徑，會(huì)忽略決策條件中布爾表達(dá)式內(nèi)部的分支。

⑤數(shù)據(jù)流測(cè)試

數(shù)據(jù)流測(cè)試源代碼中定義的變量是否被使用。其中，變量的定義表示為為變量指定了類(lèi)型和名字，如“char variable;”，變量的使用表示為變量參與了判斷(Predicate-use，簡(jiǎn)稱(chēng) p-use)，如“if (variable > 10)”，或計(jì)算(Computation-use，簡(jiǎn)稱(chēng) c-use)，如“variable=3;”。數(shù)據(jù)流測(cè)試的測(cè)試條件為變量的定義-使用對(duì)(Definition-use pair)， 即變量定義的位置到使用的位置，通常，這里的位置表示行號(hào)。

數(shù)據(jù)流測(cè)試的測(cè)試覆蓋項(xiàng)分為兩類(lèi)，一是用于計(jì)算的變量，一個(gè)變量只需要一個(gè)測(cè)試覆蓋項(xiàng)，實(shí)現(xiàn)其中一個(gè)定義-使用對(duì)應(yīng)即可；二是用于判斷的變量，一個(gè)變量需要的測(cè)試覆蓋項(xiàng)等同于定義-使用對(duì)數(shù)量，一個(gè)測(cè)試覆蓋項(xiàng)實(shí)現(xiàn)變量的一個(gè)定義-使用對(duì)應(yīng)。

02  集成測(cè)試

灰盒測(cè)試

灰盒測(cè)試是界于黑盒測(cè)試和白盒測(cè)試之間的一種測(cè)試。之所以存在灰盒測(cè)試，是因?yàn)榘礈y(cè)試階段來(lái)劃分，整個(gè)測(cè)試的流程包括單元測(cè)試、集成測(cè)試、系統(tǒng)測(cè)試，而白盒測(cè)試對(duì)應(yīng)單元測(cè)試，黑盒測(cè)試對(duì)應(yīng)系統(tǒng)測(cè)試。

在正確的測(cè)試過(guò)程中，應(yīng)該是先測(cè)試單元模塊，單元模塊測(cè)試完成之后，并沒(méi)有立即進(jìn)入系統(tǒng)測(cè)試，而是集成測(cè)試，這個(gè)時(shí)候其使用的方法就是灰盒測(cè)試，即我們測(cè)試完成單個(gè)模塊后，雖然單個(gè)模塊沒(méi)有問(wèn)題，但并不代表這些模塊組合在一塊時(shí)就一定沒(méi)有問(wèn)題。

要驗(yàn)證這些功能模塊組合在一起有沒(méi)有問(wèn)題，就是我們說(shuō)的集成測(cè)試，其使用方法就是灰盒測(cè)試。

集成測(cè)試內(nèi)容

集成測(cè)試是在單元測(cè)試之后進(jìn)行的，以確保所有單元相互協(xié)調(diào)運(yùn)行。通常，一個(gè)單元將被視為具有獨(dú)立功能，但在與其他單元交互時(shí)可能會(huì)引起問(wèn)題。這就是軟件測(cè)試如此重要的原因，尤其是作為一個(gè)整體的測(cè)試單元。

集成測(cè)試主要驗(yàn)證是否滿(mǎn)足軟件架構(gòu)和需求，大多數(shù)情況下采用灰盒測(cè)試。例如各個(gè)單元之間的數(shù)據(jù)接口測(cè)試，軟件性能測(cè)試（cpuload，cycletime，runtime等）

03  系統(tǒng)測(cè)試

系統(tǒng)測(cè)試通常在集成測(cè)試之后，將所有模塊集成到完整的硬件系統(tǒng)上，驗(yàn)證是否滿(mǎn)足系統(tǒng)架構(gòu)需求。通常采用黑盒測(cè)試。系統(tǒng)測(cè)試需要在盡可能遍歷所有工況，考慮盡可能多的、極限的運(yùn)行環(huán)境。

在實(shí)踐中，具體的測(cè)試責(zé)任分配可能因組織和項(xiàng)目而異。然而，一般情況下，可能有以下分配：

單元測(cè)試通常由開(kāi)發(fā)人員自己完成，開(kāi)發(fā)人員編寫(xiě)測(cè)試用例，并在開(kāi)發(fā)過(guò)程中使用自動(dòng)化測(cè)試工具或框架來(lái)執(zhí)行這些測(cè)試；集成測(cè)試通常由測(cè)試團(tuán)隊(duì)或質(zhì)量保證團(tuán)隊(duì)完成，測(cè)試團(tuán)隊(duì)負(fù)責(zé)編寫(xiě)集成測(cè)試用例，測(cè)試組件之間的接口和協(xié)作。開(kāi)發(fā)人員可能參與修復(fù)集成測(cè)試中發(fā)現(xiàn)的問(wèn)題。

系統(tǒng)測(cè)試通常由專(zhuān)門(mén)的測(cè)試團(tuán)隊(duì)或質(zhì)量保證團(tuán)隊(duì)負(fù)責(zé)。他們負(fù)責(zé)編寫(xiě)系統(tǒng)測(cè)試用例，并測(cè)試整個(gè)系統(tǒng)的功能、性能、可靠性和用戶(hù)體驗(yàn)。用戶(hù)代表或業(yè)務(wù)部門(mén)可能參與系統(tǒng)測(cè)試，以驗(yàn)證系統(tǒng)是否滿(mǎn)足用戶(hù)需求。

這些測(cè)試階段之間的責(zé)任分配并不是絕對(duì)的，可能會(huì)根據(jù)組織的規(guī)模、項(xiàng)目的復(fù)雜性和團(tuán)隊(duì)的組織結(jié)構(gòu)而有所不同。在某些情況下，開(kāi)發(fā)人員可能會(huì)參與集成測(cè)試和系統(tǒng)測(cè)試，而測(cè)試團(tuán)隊(duì)可能會(huì)參與單元測(cè)試。關(guān)鍵是確保每個(gè)測(cè)試階段都得到適當(dāng)?shù)年P(guān)注和執(zhí)行，以確保產(chǎn)品的質(zhì)量和穩(wěn)定性。

04  靜態(tài)測(cè)試

靜態(tài)代碼測(cè)試是一種分析源代碼的過(guò)程，用于查找潛在的編碼錯(cuò)誤、代碼缺陷和安全漏洞。靜態(tài)代碼測(cè)試并不直接運(yùn)行程序，而是檢查代碼的結(jié)構(gòu)、語(yǔ)法、命名規(guī)范、代碼復(fù)雜度等方面的問(wèn)題。靜態(tài)代碼檢測(cè)可以在軟件開(kāi)發(fā)早去提供安全問(wèn)題反饋，幫助開(kāi)發(fā)人員在編譯和運(yùn)行代碼之前發(fā)現(xiàn)潛在的問(wèn)題。

05  測(cè)試工具

Tessy

用于單元測(cè)試和集成測(cè)試。Tessy是一個(gè)針對(duì)嵌入式軟件的C/C++代碼進(jìn)行單元、集成測(cè)試的工具，它可以自動(dòng)化地執(zhí)行測(cè)試、評(píng)估測(cè)試結(jié)果并生成測(cè)試報(bào)告。Tessy的目標(biāo)就是：通過(guò)自動(dòng)化整個(gè)測(cè)試周期，完美支持針對(duì)C語(yǔ)言的單元測(cè)試/集成測(cè)試，同時(shí)，Tessy也同樣關(guān)注測(cè)試組織和測(cè)試管理。

Gtest

用于單元測(cè)試和集成測(cè)試。

Gtest是Google的一個(gè)開(kāi)源框架，它主要用于寫(xiě)單元測(cè)試，檢查真自己的程序是否符合預(yù)期行為。可在多個(gè)平臺(tái)上使用（包括Linux, Mac OS X, Windows, Cygwin和Symbian）。它提供了豐富的斷言、致命和非致命失敗判斷，能進(jìn)行值參數(shù)化測(cè)試、類(lèi)型參數(shù)化測(cè)試、“死亡測(cè)試”。

VectorCAST

VectorCAST是領(lǐng)先的專(zhuān)門(mén)用于高可靠性和高安全性軟件的自動(dòng)化動(dòng)態(tài)測(cè)試工具鏈，覆蓋軟件的單元測(cè)試、模塊測(cè)試、集成測(cè)試、系統(tǒng)功能測(cè)試、回歸測(cè)試和覆蓋率分析等軟件全生命周期SDLC的主要測(cè)試環(huán)節(jié)。VectorCAST支持對(duì)C, C++和Ada語(yǔ)言的測(cè)試，尤其適用于對(duì)嵌入式軟件應(yīng)用的測(cè)試。

QAC

用于靜態(tài)代碼測(cè)試。Helix QAC是權(quán)威的C/C++代碼合規(guī)性靜態(tài)分析工具，適用于對(duì)代碼的規(guī)范性和可靠性有較高要求的軟件系統(tǒng)。Helix QAC提供編碼規(guī)則檢查、數(shù)據(jù)流分析和代碼度量分析等全面的代碼靜態(tài)分析功能，可以自動(dòng)檢測(cè)軟件中不規(guī)范的、不安全的、不明確的、不可移植的有關(guān)編碼風(fēng)格、命名慣例、程序邏輯、語(yǔ)法和結(jié)構(gòu)的代碼。

Helix QAC現(xiàn)已廣泛支持MISRA C/C++, AutoSAR C++14, CERT C/C++, CWE C/C++, HiCPP, JSF等常用編碼規(guī)則集，并完全符合ISO 26262, ISO/SAE 21434, ASPICE, EN 50128, IEC 61508, IEC 60880, IEC 62304, DO-178B/C等研發(fā)標(biāo)準(zhǔn)對(duì)工具鑒定和認(rèn)證的要求。

Polyspace

用于靜態(tài)代碼測(cè)試。Polyspace ：軟件運(yùn)行時(shí)錯(cuò)誤檢測(cè)工具。

用途：

①解決代碼魯棒性問(wèn)題，提高軟件安全性，可靠性，排查編碼錯(cuò)誤

②檢查編碼規(guī)則一致（MISRA/JSF）。

③靜態(tài)度量（代碼量，調(diào)用次數(shù)等）

④測(cè)試覆蓋度⑤軟件質(zhì)量水平

內(nèi)容來(lái)源：

https://blog.csdn.net/weixin_42447823/article/details/133912247