SWE.4 Software Unit Verification 軟體單元驗證
ASPICE 標準解讀 — 軟體工程流程
目錄: Automotive SPICE(ASPICE)標準解讀 / 軟體工程流程SWE.1 軟體需求分析
SWE.2 軟體架構設計
SWE.3 軟體細部設計與單元開發
SWE.4 軟體單元驗證
SWE.5 軟體整合與整合測試
SWE.6 軟體合格測試
流程目的(Process Purpose)
The purpose of the Software unit Verification Process is to verify software units to provide evidence for compliance of the software units with the software detailed design and with the non-functional software requirements.
軟體單元驗證流程的目的是驗證軟體單元並提供軟體單元與軟體細部設計及非功能性軟體需求相符合的證據。
額外說明 - 驗證與測試SWE.4軟體單元驗證的名稱與其他測試流程(SWE.5, SWE.6, SYS.4, SYS.5)均屬於V-model右半邊的測試流程，但是在名稱上稍微有差異，讀者可能會注意到在英文的用字也有不同。相較於其他的測試流程，這邊的英文用字是Verfication(驗證)為何單獨SWE.4被稱之為驗證呢？一般來說，「驗證」包含了許多的方法，而「測試」僅只是驗證的其中一種方法。其他的驗證方法還包含審查(Review)、展示(Demonstration), 檢查(Inspection)和分析(Analysis)...等。在ASPICE標準中，針對SWE.4明定了兩種驗證方法：
BP.3 靜態驗證(Static verification)；和
BP.4 測試(Test)為了避免這個流程被單純的以為只有做測試，所以這個流程的名稱才會這麼特別。
流程結果(Process Outcome)
成功實作軟體單元驗證流程，其相應的結果如下：
[Outcome 1]制定一個軟體單元驗證策略(包含回歸測試策略)，並據此驗證軟體單元[Outcome 2]根據軟體單元驗證策略制定軟體單元驗證準則，該準則適用於提供證據證明軟體單元符合軟體細部設計和非功能性需求。[Outcome 3]根據軟體單元驗證策略及已定義的軟體單元驗證準則，驗證軟體單元並記錄驗證結果[Outcome 4]建立軟體單元(軟體架構設計)、驗證準則(軟體單元驗證)與驗證結果(軟體單元驗證)的一致性與雙向可追溯性[Outcome 5]總結軟體單元驗證結果並與相關單位溝通
基礎實踐(Base Practices)
SWE.4.BP1: Develop software unit verification strategy including regression strategy.
SWE.4.BP1: 制定軟體單元驗證策略包含回歸測試策略[Outcome 1]
Develop a strategy for verification of the software units including regression strategy for re-verification if a software unit is changed. The verification strategy shall define how to provide evidence for compliance of the software units with the software detailed design and with the non-functional requirements.
制定一個軟體單元驗證策略，包含當軟體單元被修改後要進行重新驗證的回歸測試策略。軟體單元驗證策略應定義如何提供證據證明軟體單元符合軟體細部設計及非功能性的(軟體)需求。
NOTE 1: Possible techniques for unit verification include static/dynamic analysis, code reviews, unit testing etc.
備註1: 單元驗證的技術包含：靜態/動態分析、程式碼審查、單元測試等...
額外說明 - 軟體單元驗證策略包含的範圍請參考下圖；圖中，當進行軟體單元開發(SWE.3 UC)時，主要參考兩個重要資訊，分別是圖中(1)軟體細部設計和(2)非功能性軟體需求。當軟體需求分析(SWE.1)結束，進入軟體架構設計(SWE.2)時，功能性的軟體需求被用來製作軟體架構設計，另外一部分沒辦法用來製作軟體架構的非功能性的軟體需求(例如:寫code的準則、MISRA C:2012的要求等)，則應該在軟體單元開發(SWE.3 UC)的時候被參照。因此，SWE.4軟體單元驗證所需要證明的便是在SWE.3所開發的軟體單元與(1)及(2)的符合性關，如同在標準的BP1中所描述的，軟體單元驗證策略應該要定義以下：
1) 「軟體單元」與「軟體細部設計」的相符性
2) 「軟體單元」與「非功能性軟體需求」的相符性
—
SWE.4.BP2: Develop criteria for unit verification.
SWE.4.BP2: 制定單元驗證準則[Outcome 2]
Develop criteria for unit verification that are suitable to provide evidence for compliance of the software units, and their interactions within the component, with the software detailed design and with the non-functional requirements according to the verification strategy. For unit testing, criteria shall be defined in a unit test specification.
根據單元驗證策略制定單元驗證準則，該準則適用於提供證據證明軟體單元及其在組件中互動符合軟體細部設計和非功能性需求。針對單元測試，(驗證)準則應被定義在單元測試規格書中。
NOTE 2: Possible criteria for unit verification include unit test cases, unit test data, static verification, coverage goals and coding standards such as the MISRA rules.
NOTE 3: The unit test specification may be implemented e.g. as a script in an automated test bench.備註2: 單元驗證準則包含：單元測試案例、單元測試資料、靜態驗證、覆蓋範圍和程式設計標準(例如: MISRA規則)
備註3: 單元測試規格書可被執行(例如: 用於自動化測試平台中的腳本)
額外說明 - 制定單元準則與工作產出的關係在BP1及BP2所提到的單元驗證策略及單元驗證準則，對應工作產出(WP)的關係請參考下圖。其中單元驗證策略等同於單元驗證計畫書，該計畫書中包含靜態驗證準則及測試準則，其中靜態驗證準則基本上會提到本次單元驗證所需要使用到的查檢表(用於程式碼審查)及靜態分析的覆蓋範圍(例如: MISRA C:2012適用條文，這些內容將用於協助靜態分析工具的設定)；測試準則將被另外定義在一份名為測試規格書的文檔中，在單元驗證計畫書只需要帶到參照這份規格書即可。
—
SWE.4.BP3: Perform static verification of software units.
SWE.4.BP3: 對軟體單元執行靜態驗證[Outcome 3]
Verify software units for correctness using the defined criteria for verification. Record the results of the static verification.
使用定義的驗證準則來驗證軟體單元的正確性。記錄靜態驗證的結果。
NOTE 4: Static verification may include static analysis, code reviews, checks against coding standards and guidelines, and other techniques.
NOTE 5: See SUP.9 for handling of non-conformances.備註4: 靜態驗證可包含靜態分析、程式碼審查、檢查(程式碼)與程式設計標準與準則、其他技術。
備註5: 有關不符合項目的處理，請參見SUP.9。
—
SWE.4.BP4: Test software units.
SWE.4.BP4: 測試軟體單元[Outcome 3]
Test software units using the unit test specification according to the software unit verification strategy. Record the test results and logs.
根據軟體單元驗證策略，使用單元測試規格書對軟體單元進行測試，並記錄測試結果與日誌。
NOTE 6: See SUP.9 for handling of non-conformances.
備註6: 有關不符合項目的處理，請參見SUP.9
—
SWE.4.BP5: Establish bidirectional traceability.
SWE.4.BP5: 建立雙向追溯性[Outcome 4]
Establish bidirectional traceability between software units and static verification results. Establish bidirectional traceability between the software detailed design and the unit test specification. Establish bidirectional traceability between the unit test specification and unit test results.
建立軟體單元與靜態驗證結果的雙向追溯性。建立軟體細部設計與單元測試規格書的雙向追溯性。建立單元測試規格書與單元測試結果的雙向追溯性。
NOTE 7: Bidirectional traceability supports coverage, consistency and impact analysis.
備註7: 雙向追溯性支援覆蓋性、一致性和影響分析。
額外說明 - 建立雙向追溯性的最完整範圍在BP5中，所定義的雙向追溯性大致上包含了三個面向：
1) 靜態驗證準則 <--> 靜態驗證結果
2) 測試準則(單元測試規格書) <--> 單元測試結果
3) 軟體細部設計 <--> 測試準則(單元測試規格書)但是唯獨漏掉了一項，那就是靜態驗證準則與其所參照來源的雙向追溯關係。實務的三種可能在實務中，這一條關係不一定會存在，又或者說這一條關係有很多存在的可能性。因此，筆者針對這一條雙向追溯性關係進一步的說明，請參考下圖中(1)(2)(3)的部分。(1)可能一：非功能需求存在且可以據此開發靜態驗證準則
如果非功能需求確實存在，那麼這一條雙向追溯性的關係描述可以記載在單元驗證計畫書中。通常MISRA C的規則覆蓋率要求會來自客戶端的要求。(2)可能二：非功能性軟體需求不存在，轉而參考內部的開發需求
有一些狀況，客戶並不會直接要求，或者當業界對於MISRA C規則覆蓋率存在一定的默契時，那麼靜態驗證準則可參考內部規範的要求(通常研發單位內部在使用靜態掃描工具時，也有可能默認預設規則，這個做法亦可)；在這種情況下，可以將所參考的規範或設定，紀載在單元驗證計畫書中。※備註：如果所採用的工具預設的模式，也常常是被客戶稽核/評鑑的問題發現點！(3)可能三：全部的軟體需求都被軟體架構設計涵蓋
當所有的軟體需求(包含功能性與非功能性)都被涵蓋在軟體架構設計(SWE.2)時，那麼就不會有非功能性的軟體需求，因此在SWE.4定義靜態驗證準則時，可以直接參照軟體細部設計(細部設計會參照架構設計)；在這種情況下，可以將所參考的文件，紀載在單元驗證計畫書中即可。
—
SWE.4.BP6: Ensure consistency.
SWE.4.BP6: 確保一致性[Outcome 4]
Ensure consistency between the software detailed design and the unit test specification.
確保軟體細部設計與單元測試規格書的一致性。
NOTE 8: Consistency is supported by bidirectional traceability and can be demonstrated by review records.
備註8: 一致性可以透過雙向追溯性來支持，且可以透過審查紀錄來體現。
額外說明 - 確保一致性的最完整範圍同在BP5所說明的追溯性，筆者建議可以確保靜態驗證準則與其所參照來源的一致性。舉個例子：
1) 客戶要求MISRA C的規則覆蓋範圍 <--> 靜態驗證準則(靜態分析工具設定)
2) 自家程式開發的規則 <--> 靜態驗證準則(程式碼審查查檢表)
—
SWE.4.BP7: Summarize and communicate results.
SWE.4.BP7: 總結和溝通測試結果[Outcome 5]
Summarize the unit test results and static verification results and communicate them to all affected parties.
總結單元測試結果及靜態驗證結果並與相關單位溝通。
NOTE 9: Providing all necessary information from the test case execution in a summary enables other parties to judge the consequences.
備註9: 統整並提供測試案例執行的所有必要資訊將能讓其他單位判斷結果。
工作產出(Output Work product)
08–50 測試規格書 [Outcome 2]08-52 測試計劃書 [Outcome 1]13-04 溝通紀錄 [Outcome 5]13-19 審查記錄 [Outcome 3,4]13-22 追溯記錄 [Outcome 4] 13-25 驗證結果 [Outcome 3,5]13-50 測試結果[Outcome 3,5]15–01 分析報告[Outcome 3]
感謝閱讀本文章！
如果你對文章內容有任何問題，請隨時與我聯絡。
if you found any question in the article, please feel free to contact me.
email: linchewing@gmail.com
