正如在代碼管理中所說，代碼管理的分支審查策略建議在代碼合并到正式分支前進行自動化測試。該步驟是為了保證計劃合并到正式分支的代碼本身沒有質(zhì)量問題，這樣不僅能夠減少開發(fā)人員測試工作， 同時還能確保軟件的質(zhì)量。

對于這部分提交前的自動化測試，我們認為它有以下幾方面的要求：

·  測試需要盡可能快地完成。提交前的自動化測試每天可能發(fā)生幾次到幾十次，這取決于開發(fā)人員 提交代碼的頻率，每個開發(fā)人員每次的提交都會觸發(fā)該測試，因此開發(fā)人員需要盡快得到反饋， 了解本次提交的代碼是否有問題，如果有就進行修復(fù)，如果沒有則進行后續(xù)的開發(fā)。因此，盡可 能快的測試，能夠保證開發(fā)的效率。

·  測試的范圍通常是單個模塊，為此提交前的自動化測試的測試方法通常是采用單體測試。對于功能安全件，對測試結(jié)果有一定的要求，需要根據(jù)測試的通過率對代碼的行覆蓋和條件覆蓋有一定的要求。該項測試可以根據(jù)具體的內(nèi)容要求來設(shè)定合適的評判標準。

在持續(xù)集成（CI）中，從檢查策略來看，該環(huán)節(jié)的測試可以包含代碼的靜態(tài)、動態(tài)等環(huán)節(jié)的測試，我們可以理解為保證代碼本身沒有問題。而從觸發(fā)方式來看，一般會采用提交觸發(fā)的方式。

(5) 提交后自動化測試

相比于提交前的自動化測試，提交后的自動化測試強調(diào)的是代碼合并到主干或者生產(chǎn)分支之后進行的測試，該環(huán)節(jié)的測試旨在驗證集成進來的代碼是否會對之前的系統(tǒng)產(chǎn)生影響，以減少集成完整系統(tǒng)后出現(xiàn)的問題。

對于該部分測試，執(zhí)行的頻率相對于提交前的測試頻率會比較低，但同時執(zhí)行時間會比較長，測試的范圍更廣，因為該環(huán)節(jié)會涵蓋完整的系統(tǒng)。而對于測試的類型，該環(huán)節(jié)往往包含了集成測試、系統(tǒng)測試等。對于某些功能安全件，對測試結(jié)果有一定的要求。該項測試可以根據(jù)具體的內(nèi)容要求來設(shè)定合適的評判標準。

在持續(xù)集成（CI）中，該部分的測試由于執(zhí)行時間長、測試范圍廣等特點，一般觸發(fā)策略會選擇定時觸發(fā)，時間點往往設(shè)定在資源長時間空閑的半夜去執(zhí)行。一方面可以保證長時間的測試，另一方面也可以有效地利用資源。

3.  持續(xù)交付

持續(xù)交付（CD）可以理解為是持續(xù)集成（CI）流程上的一個擴展，它是對軟件交付流程的進一步的自動化，以便軟件能夠隨時快速的安裝到生產(chǎn)環(huán)境中。持續(xù)交付（CD）指的是，在完成持續(xù)集成（CI） 的情況下，將軟件進行發(fā)布，使軟件隨時處于一個可部署的狀態(tài)，對于汽車行業(yè)中的持續(xù)發(fā)布，往往指 的是將其發(fā)布到制品庫中進行管理。它強調(diào)的是，不管怎么更新，軟件是隨時隨地可以交付的。

4.5  車載通信技術(shù)

4.5.1  SOME/IP

1.  SOME/IP 協(xié)議概述

SOME/IP（Scalable service-Oriented MiddlewarE over IP）是指基于 IP 的可擴展的面向服務(wù)的中間件。SOME/IP 協(xié)議于 2011 年由 BMW 集團的 Dr. Lars V?lker 設(shè)計，是一種面向服務(wù)的車載以太網(wǎng)通信協(xié)議，位于 TCP/UDP 之上，兼容當前國際共同探討的基礎(chǔ)軟件開發(fā)平臺。

(1) SOME/IP 協(xié)議功能介紹

SOME/IP 協(xié)議采用 C/S（Client/Server）的通信架構(gòu)，其中 Server 是服務(wù)提供者，Client 是服務(wù)消費者。根據(jù)服務(wù)接口類型，使用遠程服務(wù)調(diào)用（Remote Procedure Call）機制，通過數(shù)據(jù)序列化和反序化（Serialization/Deserialization）使得數(shù)據(jù)得以在網(wǎng)絡(luò)中傳輸。通過可用服務(wù)發(fā)現(xiàn) SD（Service Dis- covery）機制來實現(xiàn)服務(wù)的動態(tài)配置。