SWE.5 Software Integration and Integration Test 軟體整合及整合測試

ASPICE 標準解讀 — 軟體工程流程

Published in

ASPICE標準解讀

14 min readApr 14, 2020

目錄: Automotive SPICE(ASPICE)標準解讀 / 軟體工程流程SWE.1 軟體需求分析
SWE.2 軟體架構設計
SWE.3 軟體細部設計與單元開發
SWE.4 軟體單元驗證
SWE.5 軟體整合與整合測試
SWE.6 軟體合格測試

流程目的(Process Purpose)

The purpose of the Software Integration and Integration Test Process is to integrate the software units into larger software items up to a complete integrated software consistent with the software architectural design and to ensure that the software items are tested to provide evidence for compliance of the integrated software items with the software architectural design, including the interfaces between the software units and between the software items.

軟體整合與整合測試流程的目的包含：

整合軟體單元到較大的軟體元件，直至整合的整合軟體，並確保整合軟體與軟體架構設計間的一致性；
確保所有的軟體元件(包含軟體單元間的介面及軟體元件間的介面)都有被測試過，並證明已整合軟體元件與軟體架構設計是一致的

額外說明：本文中提到的元件、組件等名詞，請參照「ASPICE 關鍵觀念3: 元件、組件、單元、項目」

流程結果(Process Outcome)

成功實作軟體合格測試流程，其相應的結果如下：

[Outcome 1]制定一個與專案計畫書和發佈計畫書保持一致性的軟體整合策略，並據此整合軟體元件
[Outcome 2]制定一個軟體整合測試策略(包含回歸測試策略)，並據此測試軟體單元與軟體元件之間的相互影響
[Outcome 3]根據軟體整合測試策略制定測試規格書，該測試規格書適用於提供證據證明已整合軟體元件符合軟體架構設計，包含軟體單元間的介面及軟體元件間的介面
[Outcome 4]根據軟體整合策略，將軟體單元與軟體元件整合成一個完整的整合軟體
[Outcome 5]根據軟體整合測試策略和發佈計畫，從軟體整合測試規格書中挑選測試案例
[Outcome 6]使用所挑選的測試案例去測試已整合的軟體，並記錄測試結果
[Outcome 7]建立軟體元件(軟體架構設計)與測試案例(軟體整合測試規格書)的一致性與雙向可追溯性; 建立測試案例(軟體整合測試規格書)與軟體整合測試結果的雙向追溯性
[Outcome 8]總結軟體整合測試結果並與相關單位溝通

基礎實踐(Base Practices)

SWE.5.BP1: Develop software integration strategy.
SWE.5.BP1: 制定軟體整合策略
[Outcome 1]

Develop a strategy for integrating software items consistent with the project plan and release plan. Identify software items based on the software architectural design and define a sequence for integrating them.

制定一個與專案計劃書和發布計劃書一致的軟體整合策略。根據軟體架構設計識別軟體元件，並定義軟體元件的整合順序。

額外說明 - 「延伸的整合概念:整合層次」關於整合概念，筆者在系統整合與整合測試的文章的BP.1有提到共有三個部分，分別是整合順序、整合層次、整合條件；在本篇，將針對「整合層次」再稍加說明。下圖為一個軟體的拆解圖，整合層次的概念是先將同一層的軟體元件先整合完成後，再往更高層的進行整合，如圖所示，組件1(C1)共有三個模組(M1, M2, M3)，各模組亦有各自的軟體單元，如果要將M1, M2, M3整合成C1，則必須確保M1, M2, M3各自都已經被整合完成，也就是說：在模組階層(Module Level)的整合：
1) 將U1 ~ U4 整合成M1
2) 將U5 ~ U10 整合成M2
3) 將U11 ~ U14 整合成M3在組件階層(Component Level)的整合
1) 將M1 ~ M3 整合成C1
2) 將Mn ~ Mm 整合成C2
3) 將Mn ~ Mm 整合成C3在軟體階層(Software Level)的整合
將C1 ~ C3 整合成一個整合軟體值得一提的是，整合層次與整合順序是相輔相成的兩個概念，整合順序必須考量到不同的階層，在單一階層中，也可以根據專案計畫或是發布計畫的定義，排定整合的順序，舉個例子來說明：在模組階層的整合順序概念
1) 整合M3=> 整合M2=> 整合M1
2) 整合M2=> 整合M1=> 整合M3上述兩個整合順序都是在模組階層下的不同整合順序，兩者都是可行的。

—

SWE.5.BP2: Develop software integration test strategy including regression test strategy.
SWE.5.BP2: 制定軟體整合測試策略包含回歸測試策略
[Outcome 2]

Develop a strategy for testing the integrated software items following the integration strategy. This includes a regression test strategy for re-testing integrated software items if a software item is changed.

根據軟體整合策略制定一個軟體整合測試策略，包含當軟體元件變更時實施重測的回歸測試策略。

—

SWE.5.BP3: Develop specification for software integration test.
SWE.5.BP3: 制定軟體整合測試規格書
[Outcome 3]

Develop the test specification for software integration test including the test cases according to the software integration test strategy for each integrated software item. The test specification shall be suitable to provide evidence for compliance of the integrated software items with the software architectural design.

根據軟體整合測試策略，制定軟體整合測試規格書，該規格書需包括每個已整合軟體元件的測試案例。測試規格書應適用於提供證據證明已整合軟體元件符合軟體架構設計。

NOTE 1: Compliance to the architectural design means that the specified integration tests are suitable to prove that the interfaces between the software units and between the software items fulfill the specification given by the software architectural design.
NOTE 2: The software integration test cases may focus on
• the correct dataflow between software items
• the timeliness and timing dependencies of dataflow between software items
• the correct interpretation of data by all software items using an interface
• the dynamic interaction between software items
• the compliance to resource consumption objectives of interfaces
備註1: 「符合軟體架構設計」意思是所指定的整合測試能適當的證明軟體單元間與軟體元件間的介面滿足軟體架構設計的規範。(換言之: 軟體整合測試是測試軟體單元間及軟體元件間的介面，該介面定義在軟體架構設計中；測試通過，表示存在軟體元件間及軟體單元間的介面能夠滿足軟體架構設計規範的定義)
備註2: 軟體整合測試案例可針對下述：
•軟體元件間資料流的正確性
•軟體元件間資料流的時效性和時間相依關係
•運用介面來驗證所有軟體元件對資料解讀的正確性
•軟體元件間的動態互動
•介面資源消耗目標的合規性 (備註: SWE.2有針對每個軟體元件定義資源消耗的目標，這是制定測試案例很好的參考依據)

—

SWE.5.BP4: Integrate software units and software items.
SWE.5.BP4: 整合軟體單元與軟體元件
[Outcome 4]

Integrate the software units to software items and software items to integrated software according to the software integration strategy.

根據軟體整合策略將軟體單元整合成軟體元件，並將軟體元件整合成一個整合軟體。

—

SWE.5.BP5: Select test cases.
SWE.5.BP5: 選擇測試案例
[Outcome 5]

Select test cases from the software integration test specification. The selection of test cases shall have sufficient coverage according to the software integration test strategy and the release plan.

從軟體整合測試規格書中選擇測試案例。所選用的測試案例應根據軟體整合測試策略和發佈計畫書，並充分體現其覆蓋率。

—

SWE.5.BP6: Perform software integration test.
SWE.5.BP6: 執行軟體整合測試
[Outcome 6]

Perform the software integration test using the selected test cases. Record the integration test results and logs.

使用選定的測試案例執行軟體整合測試，並記錄整合測試結果與日誌。

NOTE 4: See SUP.9 for handling of non-conformances.
NOTE 5: The software integration test may be supported by using hardware debug interfaces or simulation environments (e.g. Software-in-the-Loop-Simulation).
備註4: 有關不符合項目的處理，請參見SUP.9。
備註5: 軟體整合測試可以透過硬體除錯介面或模擬環境(軟體在線模擬)來協助。

額外說明 - 軟體迴路模擬(Software-in-the-loop Simualtion)「軟體迴路(Software-in-the-loop)」，簡稱為SIL。軟體迴路模擬(Software-in-the-loop Simulation)，它的概念是運用電腦建置的模擬環境，進行程式碼驗證，其目標是確認軟體與預期功能是否符合。除了軟體在線之外，另外一個相對的概念是「硬體迴路(Hardware-in-the-loop)」，簡稱為MIL，其目的是提供動態系統模型類比真實的系統環境，並通過嵌入式系統的輸入輸出將其與仿真系統相連結，可以用於工程開發周期早期的測試與技術支援。

—

SWE.5.BP7: Establish bidirectional traceability.
SWE.5.BP7: 建立雙向追溯性
[Outcome 7]

Establish bidirectional traceability between elements of the software architectural design and test cases included in the software integration test specification. Establish bidirectional traceability between test cases included in the software integration test specification and software integration test results.

建立軟體元件(軟體架構設計)與測試案例(軟體整合測試規格書)的雙向追溯性。建立測試案例(軟體整合測試規格書)與軟體整合測試結果的雙向追溯性。

NOTE 6: Bidirectional traceability supports coverage, consistency and impact analysis.
備註6: 雙向追溯性支援覆蓋性、一致性和影響分析。

—

SWE.5.BP8: Ensure consistency.
SWE.5.BP8: 確保一致性
[Outcome 7]

Ensure consistency between elements of the software architectural design and test cases included in the software integration test specification.

確保軟體元件(軟體架構設計)與測試案例(軟體整合測試規格書)的一致性。

NOTE 7: Consistency is supported by bidirectional traceability and can be demonstrated by review records.
備註7: 一致性可以透過雙向追溯性來支持，且可以透過審查紀錄來體現。

額外說明：請參考下圖藍色框起的部分。軟體整合測試規格書(Software integration test specification)需要與：1)軟體架構設計(Software Architecture Design)保持一致性與雙向追溯性；
2)測試結果(Test result)保持雙向追溯性。

—

SWE.5.BP9: Summarize and communicate results.
SWE.5.BP9: 總結和溝通測試結果
[Outcome 8]

Summarize the software integration test results and communicate them to all affected parties.

總結軟體整合測試結果並與相關單位溝通。

NOTE 8: Providing all necessary information from the test case execution in a summary enables other parties to judge the consequences.
備註8: 統整並提供測試案例執行的所有必要資訊將能讓其他單位判斷結果。

工作產出(Output Work product)

01–03 軟體元件[Outcome 4] 01–50 整合軟體[Outcome 4]
08–50 測試規格書 [Outcome 3,5]
08-52 測試計劃書 [Outcome 1,2]
13-04 溝通紀錄 [Outcome 8]
13-19 審查記錄 [Outcome 7]
13-22 追溯記錄 [Outcome 7]
13-50 測試結果[Outcome 6,8]
17–02 打包清單(Build List)[Outcome 4,7]

* ASPICE網站
* ASPICE 3.1標準

感謝閱讀本文章！

如果你對文章內容有任何問題，請隨時與我聯絡。
if you found any question in the article, please feel free to contact me.

email: linchewing@gmail.com