SWE是Software engineering process group的縮寫，也就是說(shuō)它本質(zhì)上是個(gè)功能組。SWE下轄6個(gè)過(guò)程。在過(guò)程評(píng)估模型中，過(guò)程實(shí)施指標(biāo)包含兩個(gè)，一個(gè)是BP，一個(gè)是WP。
BP（Basic Practice）面向活動(dòng)，講的是你需要做的事，即這個(gè)活動(dòng)在開(kāi)發(fā)過(guò)程中有沒(méi)有做這幾件必要的事？比如你說(shuō)你去打掃廁所，那你需要擦馬桶、擦水龍頭、擦花灑、拖地面......總之是個(gè)事兒。這個(gè)在Automotive SPICE官方文檔中對(duì)應(yīng)的是綠區(qū)，講的是How。
WP（Work Product）面向結(jié)果，即最終呈現(xiàn)給評(píng)審員的材料。你說(shuō)你把廁所打掃干凈了，那你自己記錄的Checklist呢？照片呢？總之是可被審查的成果。這個(gè)在Automotive SPICE官方文檔中屬于藍(lán)區(qū)的范疇，講的是What。
我們今兒這篇文章只討論BP，因?yàn)锽P的活如果都干了，大多數(shù)的WP你手里也就有了。SWE中包含多少個(gè)BP呢？一共是4+(5+6+5+3+4+3)+3*6=48個(gè)BP。這個(gè)計(jì)算式子是怎么來(lái)的呢？
之前@東曉一家介紹過(guò)PDCA管理法（見(jiàn)先決知識(shí)點(diǎn)），定策略肯定屬于Plan的范疇，建立雙向可追溯性和確保一致性則屬于Check，溝通與總結(jié)測(cè)試結(jié)果屬于Act/Adjust的范疇。剩下的這些BP比如畫架構(gòu)、定接口、寫測(cè)試用例肯定就算是Do的范疇了。
對(duì)于Check和Adjust，我們需要做三件事，即建立雙向可追溯性、確保一致性、溝通和總結(jié)測(cè)試結(jié)果。我們發(fā)現(xiàn)SWE中的六個(gè)過(guò)程（Process），每個(gè)過(guò)程都有這三件事需要做。算下來(lái)一共是3*6=18個(gè)BP。
對(duì)于Plan，我們需要做策略，SWE中有4個(gè)策略需要制訂，即軟件單元驗(yàn)證策略、軟件集成策略、軟件集成測(cè)試策略和軟件合格性測(cè)試策略。
剩下的26個(gè)BP就都是Do了。我們可以采用東曉一家的三字法。這里我有小部分用的不是東曉老師的說(shuō)法，關(guān)于用詞每個(gè)人都有自己的喜好吧。
現(xiàn)在我們知道了，以前不畫架構(gòu)，不寫每個(gè)函數(shù)具體的流程圖，不寫開(kāi)機(jī)序列的順序圖，一心想寫好代碼，直接發(fā)給黑盒測(cè)試組測(cè)試的流程是不正規(guī)的，是不符合功能安全的。那遵循軟件開(kāi)發(fā)的6個(gè)過(guò)程，48個(gè)基本實(shí)踐，怎么這么繁瑣？第一次執(zhí)行時(shí)有沒(méi)有重點(diǎn)可尋？是否滿足二八原則呢？即能否只把20%的BP做好就能達(dá)到80%的效果呢？庫(kù)樂(lè)瑪公司（KUGLER MAAG CIE）提供了的Automotive SPICE的免費(fèi)視頻教程，我們看看能否快速地理解Automotive SPICE軟件開(kāi)發(fā)6大過(guò)程的核心要點(diǎn)。
這個(gè)過(guò)程可幫助您的組織將系統(tǒng)需求中與軟件相關(guān)的部分轉(zhuǎn)化為一組軟件需求。
為什么我們要用文檔來(lái)記錄軟件需求？
通常來(lái)說(shuō)，您已經(jīng)有了系統(tǒng)需求或客戶需求，那為什么還要投入時(shí)間和精力來(lái)記錄其他軟件需求呢？在一個(gè)項(xiàng)目中，你希望按時(shí)、在預(yù)算內(nèi)、以客戶要求的質(zhì)量交付商定過(guò)的結(jié)果。如果不記錄軟件需求，可能會(huì)忽略掉功能或完全誤解客戶的期望。這會(huì)導(dǎo)致額外的工作、成本和延遲。您還可以忽略對(duì)軟件的功能或非功能方面至關(guān)重要的軟件方面。這可能導(dǎo)致錯(cuò)誤的開(kāi)始，甚至是額外的開(kāi)發(fā)周期。
這一過(guò)程與SYS的上下游都有緊密的聯(lián)系，上游即系統(tǒng)需求分析（SYS.2），系統(tǒng)架構(gòu)設(shè)計(jì)（SYS.3），下游即軟件架構(gòu)設(shè)計(jì)（SWE.2）和軟件合格性測(cè)試（SWE.6）。其他依賴性強(qiáng)的流程是項(xiàng)目管理（MAN.3）和配置管理（SUP.8），例如，因?yàn)榘l(fā)布管理和缺陷管理（SUP.9）和變更請(qǐng)求管理（SUP.10）。這里的聯(lián)系是，測(cè)試中發(fā)現(xiàn)的缺陷必須得到解決，錯(cuò)誤修復(fù)和更改請(qǐng)求必須在回歸測(cè)試中得到解決。
以下是Automotive SPICE?軟件需求分析中最重要的三個(gè)關(guān)鍵點(diǎn)。
1-1 你需要考慮的不僅僅是客戶的要求
文本化記錄軟件需求的一個(gè)重要原因是，你需要考慮的不僅僅是客戶的期望。軟件必須符合標(biāo)準(zhǔn)、規(guī)范和其他增加需求數(shù)量的規(guī)定。出于文檔目的，將系統(tǒng)需求或僅在軟件開(kāi)發(fā)的情況下、客戶和其他利益相關(guān)者的需求映射到反映軟件內(nèi)部視圖的軟件需求中。軟件需求反過(guò)來(lái)構(gòu)成了軟件合格性測(cè)試（SWE.6）和所有下游流程的基礎(chǔ)，例如軟件架構(gòu)設(shè)計(jì)（SWE.2）。
1-2 確保你分析并理解需求的含義
顧名思義，這個(gè)過(guò)程的另一個(gè)面是需求分析。您應(yīng)分析需求的可行性或風(fēng)險(xiǎn)。這兩者緊密相連。如果您不確定某個(gè)需求的可行性，則存在固有的風(fēng)險(xiǎn)，因?yàn)榭赡苄枰獣r(shí)間才能找到解決方案，或者根本沒(méi)有解決方案。顯然，這與我們?cè)陧?xiàng)目管理（MAN.3）中必須執(zhí)行的評(píng)估有著密切的聯(lián)系，尤其是MAN.3 BP5。另一個(gè)需要分析的主題是可測(cè)試性(testability)。當(dāng)然，測(cè)試人員的支持可以用來(lái)確保這一點(diǎn)。通常，測(cè)試人員還被要求評(píng)審(review)需求。此外，分析應(yīng)涵蓋技術(shù)影響。這包括評(píng)估需求之間的依賴關(guān)系。
我在關(guān)于系統(tǒng)需求分析（SYS.2）的視頻中加入了一個(gè)例子。
最后，分析還應(yīng)涵蓋需求的業(yè)務(wù)方面。因此，應(yīng)確定各種要求的實(shí)施如何影響成本和時(shí)間。現(xiàn)在，你可以說(shuō)你不能在需求數(shù)據(jù)庫(kù)中記錄所有這些。請(qǐng)記住，Automotive SPICE?沒(méi)有說(shuō)明您應(yīng)在何處文本記錄這些信息。
例如，您可以在需求數(shù)據(jù)庫(kù)中介紹分析的第一部分（可行性和風(fēng)險(xiǎn)）、相應(yīng)和相關(guān)變更請(qǐng)求中的技術(shù)含義，以及項(xiàng)目管理工具中對(duì)成本和進(jìn)度的影響。
1-3 建立可追溯性和一致性
該過(guò)程還要求您確保軟件需求、系統(tǒng)需求和系統(tǒng)架構(gòu)之間的可追溯性。
然而，Automotive SPICE?明確表示不需要冗余。您可以決定是希望跟蹤系統(tǒng)需求、系統(tǒng)架構(gòu)還是兩者的組合。這取決于哪種方法以最佳方式支持您的開(kāi)發(fā)，而不是哪種方法對(duì)您更容易。
可追溯性可通過(guò)DOORS等超鏈接、Rectify等特定的可追溯性工具、可追溯性矩陣或你們公司工具環(huán)境支持的其他可管理方式來(lái)建立。
可追溯性的目的是支持以下3項(xiàng)：
——一致性檢查，即驗(yàn)證軟件需求的完整性和準(zhǔn)確性。
——變更請(qǐng)求或缺陷情況下的影響評(píng)估。
——報(bào)告的執(zhí)行情況。
這個(gè)點(diǎn)的另一部分是確保一致性。
一致性意味著您可以根據(jù)系統(tǒng)需求和系統(tǒng)架構(gòu)分別證明軟件需求的完整性和正確性。
這只能通過(guò)評(píng)審（review）來(lái)確定。
如果您跳過(guò)此評(píng)審，您可能有不完整或錯(cuò)誤的軟件需求。最糟糕的是，您甚至可能沒(méi)有注意到軟件合格性測(cè)試（SWE.6）中的缺陷，因?yàn)樵摐y(cè)試是根據(jù)您的軟件需求執(zhí)行的。如果這些都是錯(cuò)誤的，你的測(cè)試可能不會(huì)顯示任何錯(cuò)誤的行為。所以，請(qǐng)不要跳過(guò)評(píng)審這個(gè)環(huán)節(jié)！
這個(gè)過(guò)程有助于組織搭建和記錄軟件產(chǎn)品的內(nèi)部邏輯。
軟件架構(gòu)的目標(biāo)是什么？期望是既然您已經(jīng)有了軟件需求（SWE.1），這些需求描述了軟件應(yīng)該做什么。軟件架構(gòu)設(shè)計(jì)的目的是定義如何實(shí)現(xiàn)軟件需求中記錄的功能。簡(jiǎn)而言之，需求描述了“什么what”，架構(gòu)則描述了“如何how”。
許多組織和項(xiàng)目在理解如何記錄體系結(jié)構(gòu)以及需要哪些元素方面存在問(wèn)題。
軟件架構(gòu)的三個(gè)關(guān)鍵點(diǎn)
——恰當(dāng)?shù)囊晥D
——接口
——可追溯性
2-1 架構(gòu)視圖
通常，軟件架構(gòu)只包括軟件的物理視圖、框圖等。在如今大多數(shù)復(fù)雜的項(xiàng)目中，這顯然是不夠的。當(dāng)然，您希望對(duì)軟件進(jìn)行分層分解，以演示和解釋如何在不同組件和子組件中實(shí)現(xiàn)功能性和非功能性需求。
其他的視圖包括：
——?jiǎng)討B(tài)視圖，
——顯示特定功能分解的特定功能視圖，
——狀態(tài)流程圖，
——接口等等。
通常，系統(tǒng)越復(fù)雜，需要的視圖就越多。
由于不同的視圖必須保持一致，因此應(yīng)該使用適當(dāng)?shù)腢ML或SysML工具。該工具需要支持一致性檢查。
2-2 接口
評(píng)估中經(jīng)常遇到的一個(gè)陷阱就是缺乏對(duì)接口的詳細(xì)描述。
評(píng)審員希望看到的接口文檔的內(nèi)容包括：
——名稱
——類型
——單位
——Resolution
——范圍
——默認(rèn)值
等等。
如果沒(méi)有這些信息，就不可能在集成測(cè)試中對(duì)接口進(jìn)行適當(dāng)?shù)臏y(cè)試。同樣，在適當(dāng)?shù)腢ML或SysML工具中描述這些接口才能夠支持不同視圖之間的一致性。
作為對(duì)SYS.2中定義的補(bǔ)充，當(dāng)前章節(jié)從進(jìn)程間通信機(jī)制和總線通信機(jī)制的角度考慮了軟件組件之間的特定軟件接口。
2-3 可追溯性
這個(gè)過(guò)程還要求您確保軟件架構(gòu)和軟件需求之間的可追溯性。
通常情況下，需求和架構(gòu)之間存在工具造成的不連續(xù)，這會(huì)使證明可追溯性變得困難。
可追溯性的目的是：
——支持一致性檢查，即檢查軟件需求覆蓋范圍的完整性和準(zhǔn)確性。
——支持變更請(qǐng)求或有缺陷情況下的影響評(píng)估。
——支持利益相關(guān)者的期望報(bào)告，并確定需求是否已在架構(gòu)中實(shí)現(xiàn)。
Automotive SPICE中的軟件詳細(xì)設(shè)計(jì)和單元構(gòu)造過(guò)程（也稱為SWE.3）幫助您的組織為軟件組件（SWC）提供經(jīng)過(guò)評(píng)估的詳細(xì)設(shè)計(jì)，并指定和生產(chǎn)軟件單元。
軟件詳細(xì)設(shè)計(jì)的目標(biāo)是什么？許多組織和項(xiàng)目在理解如何記錄詳細(xì)設(shè)計(jì)方面存在問(wèn)題。那么，在這個(gè)過(guò)程中你應(yīng)該管理的三個(gè)方面是什么呢？
以下是Automotive SPICE?中軟件詳細(xì)設(shè)計(jì)的最重要方面。
3-1 細(xì)節(jié)的層次
通常，組織很難確定詳細(xì)設(shè)計(jì)應(yīng)該有多么具體。一個(gè)很好的辦法是記住詳細(xì)設(shè)計(jì)的目的是什么。它是實(shí)現(xiàn)代碼和單元測(cè)試的基礎(chǔ)。尤其是單元驗(yàn)證需要詳細(xì)描述。在這方面，必須要考慮覆蓋范圍。
在安全方面，ISO26262中的關(guān)鍵軟件可提供指導(dǎo)。在非安全軟件中，通常至少需要C0-或聲明（statement）覆蓋，一些客戶要求C1-或分支覆蓋。覆蓋率目標(biāo)越高，詳細(xì)設(shè)計(jì)所需的細(xì)節(jié)就越多。如果您有ASIL-B的分類模塊，則需要C1覆蓋。這意味著您的詳細(xì)設(shè)計(jì)應(yīng)該識(shí)別軟件的不同分支。
3-2 接口
我在評(píng)估中經(jīng)常遇到的一個(gè)陷阱是缺乏對(duì)外部和內(nèi)部接口的詳細(xì)描述。
接口文檔的預(yù)期內(nèi)容包括：
1.名字
2.類型
3.單位
4.resolutions
5.取值范圍
6.默認(rèn)值
如果沒(méi)有這些信息，就不可能在單元測(cè)試中對(duì)接口進(jìn)行適當(dāng)?shù)臏y(cè)試。
如果外部接口是在架構(gòu)級(jí)別中描述的（SWE.2），并在軟件集成測(cè)試（SWE.5）中進(jìn)行測(cè)試，那這當(dāng)然是可以的。
3-3 文檔的時(shí)間安排
在實(shí)現(xiàn)代碼之前描述詳細(xì)設(shè)計(jì)。通常情況下，詳細(xì)設(shè)計(jì)是在事后描述的，也就是在編寫代碼之后。
為什么這樣做是一個(gè)問(wèn)題？單元測(cè)試應(yīng)該檢查代碼是否滿足詳細(xì)設(shè)計(jì)。如果在寫代碼之后再寫詳細(xì)設(shè)計(jì)，那么單元測(cè)試的關(guān)鍵點(diǎn)就丟失了。
現(xiàn)在，你可以說(shuō)你可能不需要單元測(cè)試。關(guān)鍵是，您應(yīng)該從軟件架構(gòu)而不是代碼中派生出軟件詳細(xì)設(shè)計(jì)。如果這個(gè)鏈條斷了，那么文檔的內(nèi)容和所有的測(cè)試就會(huì)突然變得毫無(wú)意義。因此，在開(kāi)始編寫代碼之前，必須先編寫軟件詳細(xì)設(shè)計(jì)。
循序漸進(jìn)地迭代開(kāi)發(fā)軟件詳細(xì)設(shè)計(jì)和代碼并沒(méi)有什么錯(cuò)。
Automotive SPICE?中軟件單元級(jí)別的驗(yàn)證過(guò)程（簡(jiǎn)稱SWE.4）有助于貴公司證明所實(shí)施的軟件單元不僅有效，而且滿足要求。這些是之前在SWE.3中規(guī)定的。
Automotive SPICE?中的軟件單元驗(yàn)證過(guò)程可幫助貴公司驗(yàn)證軟件單元是否以所需的質(zhì)量實(shí)施了詳細(xì)設(shè)計(jì)以及相關(guān)的功能性和非功能性需求。最終，這一過(guò)程為您作為供應(yīng)商提供了保證。
單元驗(yàn)證，這是一系列后續(xù)測(cè)試中的第一組測(cè)試。
如果不進(jìn)行單元驗(yàn)證，將產(chǎn)生兩個(gè)負(fù)面后果：
——并不是所有的問(wèn)題都能保證在之后被發(fā)現(xiàn)，因?yàn)楹罄m(xù)的測(cè)試有不同的重點(diǎn)，比如集成測(cè)試和需求測(cè)試。
——然而，如果您在更高的測(cè)試級(jí)別上發(fā)現(xiàn)這樣的問(wèn)題，您將不得不重新運(yùn)行夾在兩個(gè)測(cè)試之間的大多數(shù)測(cè)試。
這是因?yàn)閱卧?jí)別的錯(cuò)誤行為可能會(huì)掩蓋更高測(cè)試級(jí)別的問(wèn)題。正如你所見(jiàn)，這個(gè)過(guò)程可以幫助你發(fā)現(xiàn)更多的問(wèn)題，同時(shí)減少你的努力和成本。
以下活動(dòng)是Automotive SPICE?軟件單元驗(yàn)證中最重要的三項(xiàng)活動(dòng)。
4-1 定義軟件單元驗(yàn)證的策略
正如你可能從我們的一些視頻中了解到的，策略是一種易于理解的教學(xué)描述。這對(duì)于更大的分布式項(xiàng)目尤其重要，這樣所有人都會(huì)知道如何做。
該策略的主要目的是描述您打算如何證明軟件單元符合詳細(xì)設(shè)計(jì)。
需要三種類型的驗(yàn)證，您應(yīng)該解釋它們應(yīng)該如何工作：
——靜態(tài)和動(dòng)態(tài)分析，
也就是說(shuō)，使用分析工具檢查代碼。
——代碼審查，
同事閱讀并審閱同事提供的代碼。
——單元測(cè)試，
使用書面測(cè)試規(guī)范證明符合詳細(xì)設(shè)計(jì)。
此外，Automotive SPICE?需要回歸測(cè)試策略。回歸測(cè)試僅僅意味著，如果你改變了一個(gè)單元中的某些東西，你就可以確保所有沒(méi)有改變的東西仍然運(yùn)行良好。
一個(gè)實(shí)際的例子：如果使用持續(xù)集成（CI），通常會(huì)在夜間測(cè)試期間再次運(yùn)行所有單元測(cè)試。所以，策略就是我剛才說(shuō)的這些。
4-2 提供詳細(xì)設(shè)計(jì)的雙向可追溯性和一致性
這里需要三種類型的可追溯性，即用于：
——詳細(xì)設(shè)計(jì)中的每個(gè)單元您都知道對(duì)應(yīng)到哪個(gè)測(cè)試規(guī)范。如果每個(gè)測(cè)試規(guī)范都能對(duì)應(yīng)到某個(gè)單元，那么可追溯性是雙向的。
——每個(gè)單元你都知道代碼審查和靜態(tài)分析的結(jié)果。
——每個(gè)單元測(cè)試規(guī)范你都知道單元測(cè)試結(jié)果。
那么一致性意味著什么？例如，對(duì)于詳細(xì)設(shè)計(jì)中的單元與相應(yīng)測(cè)試規(guī)范之間的關(guān)系，一致性要求：
——該單元鏈接到了正確的測(cè)試（而不是另一個(gè)單元的測(cè)試）
——本測(cè)試適用于對(duì)這個(gè)單元進(jìn)行完整的測(cè)試。
如果情況并非如此，則必須鏈接其他測(cè)試。
一致性還要求測(cè)試能夠真實(shí)的正確的測(cè)試軟件單元。換句話說(shuō)：沒(méi)有差錯(cuò)的測(cè)試。
4-3 總結(jié)和交流測(cè)試結(jié)果。
這通常被稱為測(cè)試總結(jié)報(bào)告。這份總結(jié)報(bào)告應(yīng)該發(fā)送給需要這些信息的人，比如開(kāi)發(fā)團(tuán)隊(duì)、項(xiàng)目經(jīng)理、質(zhì)量工程師等等。
讓我們仔細(xì)看看這份報(bào)告應(yīng)該長(zhǎng)成什么樣子：顧名思義，它應(yīng)該總結(jié)結(jié)果，隱藏不必要的細(xì)節(jié)。摘要報(bào)告應(yīng)該傳達(dá)的主要信息是什么？它應(yīng)符合軟件詳細(xì)設(shè)計(jì)。
我將給你一個(gè)我在評(píng)估中經(jīng)常看到的反例：報(bào)告包含餅圖，顯示了1520項(xiàng)本應(yīng)執(zhí)行的測(cè)試，但其中112項(xiàng)無(wú)法執(zhí)行，89項(xiàng)測(cè)試失敗。就這樣。目前還沒(méi)有關(guān)于112項(xiàng)測(cè)試無(wú)法進(jìn)行的原因和風(fēng)險(xiǎn)的信息。也沒(méi)有關(guān)于89次失敗測(cè)試的問(wèn)題會(huì)產(chǎn)生多大問(wèn)題的信息。報(bào)告也沒(méi)有顯示是否與詳細(xì)設(shè)計(jì)相符。事實(shí)上，詳細(xì)設(shè)計(jì)一丁點(diǎn)也沒(méi)有提到。他們必須將餅圖與956個(gè)軟件單元相關(guān)聯(lián)，而不僅僅是與1520個(gè)測(cè)試相關(guān)聯(lián)。我想你已經(jīng)明白了這一點(diǎn)。當(dāng)然，這會(huì)是評(píng)估中的減分項(xiàng)。
Automotive SPICE?中的軟件集成和集成測(cè)試過(guò)程（也稱為SWE.5）幫助您的組織確保軟件體系結(jié)構(gòu)的各個(gè)元素被集成，然后進(jìn)行測(cè)試，以證明它們按照計(jì)劃一起工作，并按照軟件架構(gòu)中的描述進(jìn)行交互。
在我的課堂和評(píng)估中，我遇到了很多問(wèn)題，比如“嘿，我們做了大量的需求測(cè)試，為集成測(cè)試付出的額外努力真的值得嗎？”
那么，你的看法是什么？想過(guò)嗎？
為了回答這個(gè)問(wèn)題，我們必須首先闡明集成測(cè)試的含義。
集成測(cè)試的目的是檢查代碼是否符合軟件架構(gòu)設(shè)計(jì)。這包括根據(jù)SWE.2檢查接口、動(dòng)態(tài)行為和資源消耗。
那么，讓我們把最初的問(wèn)題修改為：“需求測(cè)試能證明符合軟件架構(gòu)嗎”？答案是：當(dāng)然不能，因?yàn)檫@些測(cè)試針對(duì)的是需求，而不是架構(gòu)。到目前為止，一切順利。但你們中的一些人可能會(huì)說(shuō)：“好吧，明白了。但是，針對(duì)軟件架構(gòu)進(jìn)行測(cè)試的附加值是什么？如果代碼功能運(yùn)行良好，這還不夠好嗎？”
讓我們仔細(xì)看看：在需求測(cè)試中是否可以檢測(cè)到代碼與軟件架構(gòu)不一致的情況？是的，可以，但不能保證。你可以將需求測(cè)試的數(shù)量乘以一千、一萬(wàn)、十萬(wàn)，但這仍然不能保證。成本會(huì)激增，但軟件仍然會(huì)有錯(cuò)誤，這些錯(cuò)誤本可以通過(guò)對(duì)架構(gòu)進(jìn)行測(cè)試來(lái)避免！現(xiàn)在，底線是：與詳盡的需求測(cè)試相比，執(zhí)行集成測(cè)試可以以更低的成本為您提供更健壯的軟件。祝賀你現(xiàn)在理解了這一過(guò)程的價(jià)值，你是“高端俱樂(lè)部”中的一員了！
以下是Automotive SPICE?中軟件集成和集成測(cè)試的最重要的三個(gè)方面。
5-1 定義軟件集成和集成測(cè)試的策略
正如你可能從我們的一些視頻中了解到的，策略是一種易于理解的教學(xué)描述。這對(duì)于更大的分布式項(xiàng)目尤其重要，這樣所有人都會(huì)知道如何做。
該策略首先從一個(gè)開(kāi)發(fā)人員的角度描述了軟件團(tuán)隊(duì)的工作流程，他們可以在將軟件交付到團(tuán)隊(duì)工作流之前，執(zhí)行一些簡(jiǎn)單的集成測(cè)試。然后團(tuán)隊(duì)可以進(jìn)行一些集成測(cè)試，作為夜間測(cè)試運(yùn)行的一部分。當(dāng)這些完成后，他們會(huì)在將工作交付到項(xiàng)目工作流之前執(zhí)行一些最終的集成測(cè)試。然后可能會(huì)有一些額外的集成測(cè)試。此外，Automotive SPICE需要“回歸測(cè)試策略”。回歸測(cè)試僅僅意味著，如果你改變了軟件中的某些東西，你就可以確保所有沒(méi)有改變的東西都能正常工作。
一個(gè)實(shí)際例子是：如果使用持續(xù)集成，通常會(huì)在夜間測(cè)試期間再次運(yùn)行所有集成測(cè)試。所以，策略就是我剛才說(shuō)的這些。
5-2 為軟件架構(gòu)提供雙向可追溯性和一致性
可追溯性意味著，對(duì)于每個(gè)相關(guān)的架構(gòu)元素，例如接口，您可以對(duì)應(yīng)到相應(yīng)的測(cè)試。如果反過(guò)來(lái)你也能做到這一點(diǎn)（即每個(gè)接口測(cè)試都能對(duì)應(yīng)到架構(gòu)中的接口），反之亦然，那么可追溯性是雙向的。
那么一致性意味著什么？在我們前面的示例中，一致性要求接口鏈接到正確的測(cè)試（而不是其他測(cè)試）。這個(gè)測(cè)試應(yīng)該對(duì)接口進(jìn)行完整的測(cè)試。如果情況并非如此，則必須鏈接其他測(cè)試。一致性還要求測(cè)試能夠真正的正確的測(cè)試接口。換句話說(shuō)，沒(méi)有差錯(cuò)的測(cè)試。
5-3 總結(jié)并交流測(cè)試結(jié)果
這通常被稱為測(cè)試總結(jié)報(bào)告。這份總結(jié)報(bào)告應(yīng)該發(fā)送給需要這些信息的人，比如開(kāi)發(fā)團(tuán)隊(duì)、項(xiàng)目經(jīng)理、質(zhì)量工程師等等。讓我們仔細(xì)看看這份報(bào)告應(yīng)該是什么樣子。顧名思義，它應(yīng)該總結(jié)結(jié)果，隱藏不必要的細(xì)節(jié)。摘要報(bào)告應(yīng)該傳達(dá)的主要信息是什么？你怎么認(rèn)為？當(dāng)然，它應(yīng)當(dāng)符合軟件架構(gòu)。
Automotive SPICE中的軟件合格性測(cè)試過(guò)程（也稱為SWE.6）有助于您的組織保證集成軟件滿足軟件需求。
什么是軟件合格性測(cè)試？我們期望您已經(jīng)有了軟件需求，所以我們的目標(biāo)是對(duì)照這些需求進(jìn)行檢查，并確定它們是否完全滿足并正確實(shí)現(xiàn)。
由于該過(guò)程是在軟件交付前不久執(zhí)行的，可以直接交付給客戶，也可以作為系統(tǒng)的基礎(chǔ)，因此與項(xiàng)目管理（MAN.3）、配置管理（SUP.8）、產(chǎn)品發(fā)布（SPL.2）等過(guò)程有著密切的關(guān)系，當(dāng)然還有軟件需求分析（SWE.1）。
如果軟件合格性測(cè)試不能很好地被執(zhí)行，錯(cuò)誤可能無(wú)法被發(fā)現(xiàn)，客戶滿意度也會(huì)下降。測(cè)試環(huán)境取決于產(chǎn)品。例如SIL、PIL或HIL。
以下是Automotive SPICE?軟件合格性測(cè)試三個(gè)的最重要方面。
6-1 你需要一個(gè)明確的測(cè)試策略
與所有測(cè)試和支持過(guò)程一樣，軟件合格性測(cè)試需要開(kāi)發(fā)和定義測(cè)試策略。對(duì)于每個(gè)測(cè)試級(jí)別，您可能需要一個(gè)單獨(dú)的測(cè)試策略，但是最好在所有測(cè)試級(jí)別上開(kāi)發(fā)和協(xié)調(diào)測(cè)試策略。這可以確保涵蓋所有需求，并避免冗余。
測(cè)試策略應(yīng)涵蓋以下主題：
——有問(wèn)題的測(cè)試對(duì)象
——開(kāi)發(fā)測(cè)試用例和測(cè)試數(shù)據(jù)的方法（例如，開(kāi)發(fā)正/負(fù)測(cè)試、等價(jià)性劃分）
——回歸測(cè)試策略，在Automotive SPICE術(shù)語(yǔ)中，這意味著您定義了在錯(cuò)誤修復(fù)或更改請(qǐng)求后要如何重新測(cè)試
——測(cè)試環(huán)境
——與項(xiàng)目計(jì)劃和發(fā)布計(jì)劃相關(guān)的測(cè)試覆蓋率
——進(jìn)入和退出標(biāo)準(zhǔn)以及測(cè)試中斷標(biāo)準(zhǔn)
當(dāng)然，這個(gè)過(guò)程與問(wèn)題解決管理（SUP.9）有很強(qiáng)的聯(lián)系，所以您可以使用測(cè)試策略或缺陷管理策略來(lái)文檔化如何處理失敗的測(cè)試。
6-2 選擇正確的測(cè)試用例
這個(gè)期望聽(tīng)起來(lái)可能微不足道，但并不是這樣…
該過(guò)程希望根據(jù)測(cè)試目標(biāo)和覆蓋率，為各種測(cè)試選擇測(cè)試用例。其目的和期望是，對(duì)于不同的交付，根據(jù)上述測(cè)試策略對(duì)軟件進(jìn)行適當(dāng)?shù)臏y(cè)試。
這個(gè)想法是，你可以有不同期望的交付。策略的一個(gè)例子是，您可以完全覆蓋重要交付所有已實(shí)現(xiàn)的軟件需求。
對(duì)于較小的交付，僅測(cè)試自上次交付以來(lái)實(shí)施的需求增量。
當(dāng)然，對(duì)于這種方法，必須選擇正確的測(cè)試用例。選擇測(cè)試用例的另一種可能情況是回歸測(cè)試，它包括更改請(qǐng)求和/或錯(cuò)誤修復(fù)。這里選擇的測(cè)試用例涵蓋了變更請(qǐng)求或bug，以及它們可能產(chǎn)生的影響。后者意味著對(duì)可能受變更請(qǐng)求或錯(cuò)誤修復(fù)影響的需求的依賴性也會(huì)被測(cè)試。
6-3 建立可追溯性和一致性
這個(gè)過(guò)程還要求您確保軟件測(cè)試用例和軟件需求之間的可追溯性。
可追溯性可以通過(guò)超鏈接來(lái)建立，比如在DOORS中，通過(guò)特定的可追溯性工具（比如Rectify），通過(guò)可追溯性矩陣，或者通過(guò)工具環(huán)境支持的其他可管理方式。
可追溯性的目的是：
——支持一致性檢查，即檢查軟件需求覆蓋范圍的完整性和準(zhǔn)確性。
——支持變更請(qǐng)求或缺陷情況下的影響評(píng)估。
——支持報(bào)告利益相關(guān)者的期望，并確定哪些需求已經(jīng)通過(guò)測(cè)試，通常稱之為覆蓋率報(bào)告。
這個(gè)要點(diǎn)的第二部分是一致性，在這種情況下，軟件需求和軟件測(cè)試用例之間是一致的。如果覆蓋范圍完整且正確，通常會(huì)檢查一致性。這只能通過(guò)審查（Review）來(lái)執(zhí)行。
如果您無(wú)法證明您的軟件已完全正確覆蓋，您可能會(huì)發(fā)布一個(gè)未經(jīng)充分測(cè)試的軟件，因此確保一致性符合您的最佳利益！因此，請(qǐng)確保正確執(zhí)行此審查（Review）！
[1]Video tutorials and expert talks on Automotive SPICE, functional safety and cybersecurity
[2]kuglermaag.com/automoti
[3]kuglermaag.com/automoti
[4]SWE.3 - System Architectural Design - Kugler Maag Cie
[5]kuglermaag.com/automoti
[6]Get familar with the Automotive SPICE?-Process SWE.5
[7]kuglermaag.com/automoti
聲明：本翻譯稿僅用于學(xué)習(xí)交流，不得用于商業(yè)行為。如有侵權(quán)請(qǐng)聯(lián)系本文作者進(jìn)行刪除。
