軟件驗證策略是軟件單元驗證過程中所有活動的基礎(chǔ)，因此也是評估的基礎(chǔ)。軟件驗證策略是基礎(chǔ)實踐1所要求的:開發(fā)包括回歸策略在內(nèi)的軟件單元驗證策略。

本文是ASPICE系列文章的第2部分。查看第1部分：ASPICE系列：順利通過ASPICE流程軟件單元驗證(SWE.4)

對于評估人員來說，單元驗證策略必須至少包括以下10個方面:

1. 所有單元的定義。定義可以是通用的，也可以是特定的。確保單元是唯一可識別的。在最簡單的情況下，可以把一列函數(shù)或文件分類為單元。

• 您應(yīng)該能夠回答以下問題：如何確保所有單元都包含在函數(shù)列表中？這可以通過比如定期檢查列表或自動更新列表等方式來實現(xiàn)。

2. 定義如何涵蓋與驗證和測試相關(guān)的特定需求。這包含功能需求、非功能需求和過程需求。

• 您應(yīng)該對整個項目的需求有一個概覽。補充對單元驗證有影響的信息。這些通常也是來自ASPICE、ISO26262或其他安全標(biāo)準(zhǔn)、橫斷面荷載手冊、法律、利益相關(guān)方、MISRA等的要求。如果您明確地在驗證策略中包含各個需求，并簡要地記錄您的解決方案以供實現(xiàn)，這將是很有幫助的。

3.定義測試用例的開發(fā)方法和來自詳細(xì)設(shè)計和非功能需求的測試數(shù)據(jù)。

• 這需要你解釋為此使用的方法，例如為所有接口形成等價類，正面和負(fù)面測試等等。

• 如果您有通用的單元定義，您可能也會為此使用通用的定義。如果你對質(zhì)量管理和功能安全單元有約束或變量（constraints/variants），那么就會期望它們也能顯示質(zhì)量管理和功能安全單元的概述。這一期望同樣適用于所有其他變體。因此，通用的單元定義會增加測試工作量。

• 為了處理這方面的問題，我們建議預(yù)先分析所有的需求，并在此分析的基礎(chǔ)上推導(dǎo)出最合適的方法。

4. 定義用于靜態(tài)驗證和評審的方法和工具的方法。

5. 定義每個測試環(huán)境和使用的每個測試方法論。

• 現(xiàn)成的工具實現(xiàn)方法。參考現(xiàn)有的工具供應(yīng)商文檔以節(jié)省時間。

• 使用掌握盡可能多的方法和技術(shù)的工具。節(jié)省培訓(xùn)和許可證的項目成本。有了一些可以廣泛使用的工具，員工可以更快地重新確定優(yōu)先級，不再需要熟悉工具。

• 使用已有的方法，例如等價類或限制測試來收集測試數(shù)據(jù)。

• 使用能最大限度地減輕重復(fù)活動工作量的工具，例如自動生成報告和可追溯性。

• 盡可能實現(xiàn)自動化

6. 根據(jù)項目和發(fā)布階段定義測試覆蓋范圍。

• 沒有人期望你在第一天就達到100%的覆蓋率。利用項目的持續(xù)時間，并顯示可實現(xiàn)的建設(shè)曲線。

• 從人員或其他資源方面得出你為此需要什么。

• 回顧你的策略，如果有偏差就進行調(diào)整。根據(jù)流程進行變更(SUP.10變更請求管理)。

7.定義動態(tài)單元測試的測試啟動條件和測試結(jié)束標(biāo)準(zhǔn)。

• 哪些條件導(dǎo)致哪些活動的開始。

• 有相關(guān)序列嗎?

• 什么時候終止，什么時候重新開始?他們是怎么得到這個的?

• 他們什么時候停止測試?最好不要使用時間，而是使用技術(shù)或可度量的標(biāo)準(zhǔn)(覆蓋度量，如何測試所有需求)。說明為什么這些指標(biāo)是充分的。

8. 如果測試級別是組合的，那么需要每個測試級別的充分測試覆蓋率的文檔。

• 如果您合并測試級別，您必須證明您如何確定覆蓋級別。覆蓋可以意味著代碼覆蓋、接口覆蓋和需求覆蓋。一個一致的基本原理是，例如，您將測試內(nèi)容移動到更高的級別，因為您可以在這個級別上更有意義地分配測試用例和需求。

• 他們通常從標(biāo)準(zhǔn)和其他指導(dǎo)方針中獲得覆蓋率目標(biāo)。ISO 26262為與安全相關(guān)的代碼部分的代碼覆蓋率設(shè)定了目標(biāo)。ISO 26262含蓄地要求高覆蓋率，并注明:“無正當(dāng)理由的沒有目標(biāo)值或低目標(biāo)值的結(jié)構(gòu)覆蓋率被認(rèn)為是不充分的?！?/span>

• 一般來說，最好是證實所有覆蓋率目標(biāo)值低于100%。這可以通過使用發(fā)布計劃和預(yù)定的需求或特性優(yōu)先級更容易地完成。

• 專業(yè)建議：從源代碼引用或鏈接相關(guān)需求到軟件單元驗證策略的適當(dāng)部分。

9. 處理失敗的測試用例、失敗的靜態(tài)檢查和檢查結(jié)果的過程。

• 本程序應(yīng)與ASPICE問題解決管理策略(SUP.9)過程相關(guān)并保持一致。

• 你應(yīng)該描述誰被告知，以及如何和何時做什么。

• 你還應(yīng)該描述你將在這個過程中分享什么信息/數(shù)據(jù)。

10. 執(zhí)行回歸測試的定義。

• 回歸測試指的是在對單元進行更改后重新執(zhí)行靜態(tài)和動態(tài)測試。目標(biāo)是確定一個單元中未更改的部分是否繼續(xù)工作。

• 在自動化測試中，回歸測試是一鍵完成的。

• 在持續(xù)集成/持續(xù)測試環(huán)境中，表明回歸測試是由“每日構(gòu)建”或其他自動化保證的就足夠了。

關(guān)于評估的說明

如果您沒有覆蓋軟件單元驗證策略中提到的所有10個方面，那么您肯定不會得到BP1“開發(fā)軟件單元驗證策略包括回歸策略”的“完全”評估。直到第4點才完成第2點將導(dǎo)致他們在BP1中被評為部分或更糟。

隱含地，評估人員還期望參與過程的所有人員都了解軟件單元驗證策略的內(nèi)容。如果他們沒有證據(jù)，例如郵件、日志或類似的形式，可能會出現(xiàn)測試人員被召集到評估中，并在面試中確定他們的知識的情況。

在ASPICE中，更詳細(xì)地描述了更高級別的工作產(chǎn)品驗證策略(WP ID 19-10)。它規(guī)定了驗證策略需要安排活動、處理風(fēng)險和限制、驗證的獨立程度和其他方面等能力和要求。