汽車軟件單元測試、集成測試、系統(tǒng)測試的區(qū)別詳解

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

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

單元測試

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

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

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

①等價(jià)類劃分

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

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

②邊界值分析

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

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

③決策表測試

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

④場景測試

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

①白盒測試簡介

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

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

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

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

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

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

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

③語句覆蓋

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

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

④分支覆蓋

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

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

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

• 消除語句測試無法覆蓋的問題。

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

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

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

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

集成測試

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

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

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

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

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

系統(tǒng)測試

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

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

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

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

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

靜態(tài)測試

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

測試工具

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

用于單元測試和集成測試。

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

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

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

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

用途：

①解決代碼魯棒性問題，提高軟件安全性，可靠性，排查編碼錯(cuò)誤
②檢查編碼規(guī)則一致（MISRA/JSF）。
③靜態(tài)度量（代碼量，調(diào)用次數(shù)等）
④測試覆蓋度
⑤軟件質(zhì)量水平

內(nèi)容來源：

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

-? THE END? -

因文章部分文字及圖片涉及到引用，如有侵權(quán)，請及時(shí)聯(lián)系17316577586，我們將刪除內(nèi)容以保證您的權(quán)益。