《解讀汽車軟件測(cè)試之“軟件單元與集成測(cè)試”》

接上文。

第二篇針對(duì)軟件需求測(cè)試。軟件需求測(cè)試有時(shí)也被稱為軟件功能測(cè)試或者直接簡(jiǎn)稱為軟件測(cè)試。

1、概述

軟件需求測(cè)試是汽車軟件測(cè)試的第四級(jí)別。在此階段之后，通�？梢詫④浖�交由驗(yàn)收?qǐng)F(tuán)隊(duì)或交付團(tuán)隊(duì)進(jìn)行系統(tǒng)級(jí)測(cè)試。

測(cè)試目標(biāo)：確保對(duì)集成的軟件進(jìn)行測(cè)試，以證明其符合軟件需求。

測(cè)試依據(jù)：測(cè)試用例來源于軟件需求，而表現(xiàn)形式可能是一份獨(dú)立的軟件需求說明書，也可能是在系統(tǒng)級(jí)需求或設(shè)計(jì)里做了軟件標(biāo)識(shí)的部分。

測(cè)試對(duì)象：運(yùn)行在MCU或SOC上的集成軟件。

測(cè)試設(shè)計(jì)：測(cè)試用例的設(shè)計(jì)可以選擇如下方法，等價(jià)類劃分（將輸入數(shù)據(jù)劃分為若干個(gè)等價(jià)類，從每個(gè)等價(jià)類中選取代表性的數(shù)據(jù)進(jìn)行測(cè)試，以縮減測(cè)試用例）、邊界值分析（重點(diǎn)關(guān)注輸入值的邊界條件，因?yàn)樵谶@些邊界附近，程序更容易出錯(cuò)）、決策表（用于描述在不同條件下的系統(tǒng)行為，幫助測(cè)試人員理解并測(cè)試復(fù)雜的邏輯條件）、狀態(tài)轉(zhuǎn)換測(cè)試（關(guān)注系統(tǒng)在不同狀態(tài)之間的轉(zhuǎn)換，確保系統(tǒng)在狀態(tài)轉(zhuǎn)換時(shí)能夠正確工作）、錯(cuò)誤猜測(cè)（基于測(cè)試人員的經(jīng)驗(yàn)和直覺，猜測(cè)可能的錯(cuò)誤并設(shè)計(jì)相應(yīng)的測(cè)試用例）、負(fù)面測(cè)試（在某些情況下，測(cè)試人員需要考慮負(fù)面測(cè)試，即測(cè)試系統(tǒng)在不滿足正常工作條件時(shí)的行為，如故障注入）。

測(cè)試環(huán)境：汽車軟件開發(fā)中，我們常希望得到狀態(tài)比較好的硬件，甚至實(shí)車環(huán)境，但軟件需求測(cè)試并不追求于此，而且要盡量保證測(cè)試不受硬件的影響，因?yàn)橐獜睦碚撨壿媽用姹ＷC軟件需求被落實(shí)。比如，Matlab中基于模型的MIL測(cè)試環(huán)境、基于臺(tái)架或虛擬ECU的SIL測(cè)試環(huán)境。當(dāng)然，有時(shí)PC中無法模擬某些ECU或傳感器，也只能使用真實(shí)硬件。

進(jìn)入標(biāo)準(zhǔn)：完成必要的前序測(cè)試（如冒煙）且無重大問題、相關(guān)的測(cè)試設(shè)備（如線束、ECU、CANoe硬件）就位、已review并發(fā)布的軟件需求測(cè)試用例與計(jì)劃。

退出標(biāo)準(zhǔn)：已執(zhí)行對(duì)應(yīng)的測(cè)試用例、測(cè)試報(bào)告已完成、缺陷已錄入工具鏈。除了常規(guī)的退出外，出于成本的考慮，還會(huì)有測(cè)試中止，比如，基本功能確認(rèn)失效、發(fā)現(xiàn)的缺陷會(huì)影響其他功能測(cè)試結(jié)果有效性、對(duì)于發(fā)現(xiàn)的缺陷被修復(fù)后需重新測(cè)試的范圍，或者在測(cè)試過程中，得知新的軟硬件即將釋放，也應(yīng)綜合評(píng)估后中止。

負(fù)責(zé)角色：軟件測(cè)試人員。

2、測(cè)試用例選擇

完整的軟件需求測(cè)試會(huì)消耗大量的時(shí)間和資源，所以，我們需要在用例選擇上做一個(gè)平衡，不全測(cè)，或者不是每次交付全測(cè)。一般有如下關(guān)注點(diǎn)。

產(chǎn)品風(fēng)險(xiǎn)大小：對(duì)于功能安全等級(jí)較高或者涉及到法律法規(guī)認(rèn)證等高風(fēng)險(xiǎn)軟件，通常，需要投入更多的資源在影響分析與測(cè)試量上，這是一個(gè)理所當(dāng)然的決定。

不同配置下的功能是否適用：這需要我們有一個(gè)清晰的feature list或配置表，不適用的功能自然不需要測(cè)試。

功能是否實(shí)現(xiàn)：即便本配置有該功能，功能的成熟度也得達(dá)到可測(cè)水平。

變更的范圍：結(jié)合接口文檔、模型、追溯關(guān)系等，對(duì)軟件組件自身的變更及其對(duì)未變更組件的影響進(jìn)行評(píng)估，并進(jìn)一步確認(rèn)測(cè)試范圍。有時(shí)，軟件外部的系統(tǒng)環(huán)境或者車輛的變更都會(huì)影響到測(cè)試用例的選擇。

歷史測(cè)試狀態(tài)：舊的版本、相近配置、相近分支或者平臺(tái)主線的測(cè)試結(jié)果可能可以被當(dāng)前軟件沿用。一般在這里，也是基于變更來評(píng)估。

持續(xù)集成：為了確�；�礎(chǔ)功能沒問題，我們可以設(shè)定一些關(guān)鍵的必測(cè)項(xiàng)，也就是不管什么修改，都至少運(yùn)行這一套用例。結(jié)合自動(dòng)化測(cè)試腳本，可以將其部署在持續(xù)集成流水線中。

全量測(cè)試：Delta測(cè)試很必要，但全量測(cè)試也不應(yīng)舍棄，我們可以根據(jù)產(chǎn)品和項(xiàng)目特點(diǎn)制定一些執(zhí)行全量測(cè)試的規(guī)則，比如，一年至少一次、切換分支基線后至少一次、發(fā)布D樣件之前至少測(cè)試一次、軟件上路試車前至少一次、發(fā)布10版軟件后至少一次等。

3、雙向可追溯性和一致性

所有軟件級(jí)別的可測(cè)試需求必須至少被一個(gè)測(cè)試用例覆蓋。

而為了檢查測(cè)試覆蓋率，必須能夠通過工具實(shí)現(xiàn)測(cè)試報(bào)告、測(cè)試規(guī)范與相應(yīng)需求之間的可追溯性，比較典型的是建立鏈接。

如果要發(fā)布的軟件版本的測(cè)試覆蓋率不完整，測(cè)試團(tuán)隊(duì)?wèi)?yīng)向項(xiàng)目經(jīng)理或客戶匯報(bào)，并記錄偏差原因和進(jìn)行風(fēng)險(xiǎn)評(píng)估。

一致性呢，一般也只能通過評(píng)審來盡量保證。比如，軟件測(cè)試人員應(yīng)該參與軟件需求的評(píng)審，而軟件需求開發(fā)人員則參與軟件測(cè)試的測(cè)試用例評(píng)審。

4、全文小結(jié)

本文首先從目標(biāo)、對(duì)象、環(huán)境、進(jìn)入/退出標(biāo)準(zhǔn)等方面概述了軟件需求測(cè)試的基本概念和要求。

由于完整的軟件需求測(cè)試會(huì)耗費(fèi)大量的成本，如何選擇測(cè)試用例進(jìn)行Delta測(cè)試就是一個(gè)重要的課題，所以第二部分對(duì)此進(jìn)行了介紹。

汽車軟件開發(fā)中，一般至少應(yīng)在這個(gè)層級(jí)及以上關(guān)注追溯。這也是本文最后一部分的內(nèi)容。

5、寫在最后

通常，處于軟件開發(fā)末端的軟件需求測(cè)試，承擔(dān)了不該承擔(dān)的攔截問題和保證交付的主要壓力，讓我們向他們致以歉意。

       原文標(biāo)題 : 解讀汽車軟件測(cè)試之“軟件需求測(cè)試”