基于ISO 26262功能安全標準的測試系統測試方法(上)

　?、?a class="contentlabel" href="http://dyxdggzs.com/news/listbylabel/label/測試">測試案例需要按照表8中的方法進(jìn)行分析設計。

　?、祵τ谲浖軜嫾墑e的需求測試覆蓋度，可以用來(lái)衡量測試的完整性，以及用于證明沒(méi)有設計之外的功能實(shí)現。如果有需要，可以增加新的測試案例，或者提供一個(gè)合理的理由說(shuō)明。

　?、稙榱嗽u估測試案例的完整性，同時(shí)確保沒(méi)有多余的功能，根據表9列出的指標需要衡量出其結構覆蓋率。如果覆蓋率不夠高，要么需要添加額外的測試案例，或者提供一個(gè)合理的理由說(shuō)明。例如，結構覆蓋率的分析可以用于發(fā)現測試案例的不足、無(wú)用代碼、無(wú)效代碼或者多余功能等。

　　● 結構覆蓋率可以利用工具計算出來(lái)。
　　● 如果是基于模型的開(kāi)發(fā)，結構覆蓋率可以通過(guò)模型級別的模型結構覆蓋率來(lái)統一計算。

　?、纷鳛楫a(chǎn)品發(fā)布的一部分，嵌入式軟件需要被驗證其包含設計的所有功能。如果嵌入式軟件包含了設計之外的功能(比如用于調試的代碼)，則這些功能需要被驗證是不影響軟件的安全需求的。如果這些設計之外的功能在真實(shí)產(chǎn)品中保證不會(huì )被激活執行，那也是符合這個(gè)要求的;否則刪除這些功能，也需要按照需求變更流程來(lái)統一處理。

　?、杠浖蓽y試需要盡可能地在真實(shí)環(huán)境中運行，如果不行，則需要評估測試環(huán)境與真實(shí)環(huán)境的差異性，并針對這些差異，在后續的階段的真實(shí)環(huán)境的測試中設計專(zhuān)門(mén)的案例來(lái)執行。

　　● 測試環(huán)境的不同，會(huì )導致源代碼或目標代碼的不一致，比如不同處理器的位數不一樣，會(huì )導致編譯后的目標代碼不一致。
　　● 針對各種測試，需要建立合適的測試環(huán)境。比如目標處理器的測試環(huán)境、仿真處理器的測試環(huán)境、開(kāi)發(fā)測試環(huán)境等。
　　● 軟件集成測試可以利用模型在環(huán)測試(MIL)、軟件在環(huán)測試(SIL)、處理器在環(huán)測試(PIL)、硬件在環(huán)測試(HIL)等測試手段進(jìn)行測試。

　　軟件安全需求驗證

　　本階段的目標是驗證嵌入式軟件符合軟件安全需求，其所規定的要求和建議如下：

　?、避浖踩枨蟮尿炞C需要制定計劃，定義再執行。

　?、矠榱蓑炞C嵌入式軟件實(shí)現了軟件安全需求，表10列了所需的測試環(huán)境。注意：已有的測試案例，例如在軟件集成測試階段使用的可以重用。

　?、硨τ谲浖踩枨髮?shí)現的測試需要在目標硬件平臺上完成。

　?、窜浖踩枨篁炞C的結果需要考慮下面這些因素來(lái)評估：

　　● 和預期結果一致;
　　● 軟件安全需求的覆蓋率;
　　● 成功或失敗的標準。

　　(未完待續)

　　參考文獻：

　　[1]IEC 61508: Functional Safety of Electrical/Electronic/Programmable Electronic Safety-related Systems[S/OL].http://zh.wikipedia.org/wiki/IEC_61508
　　[2] ISO 26262-1:2011, Road vehicles -- Functional safety-Part1: Vocabulary[S]
　　[3]ISO 26262-8:2011, Road vehicles -- Functional safety-Part8: Supporting processes[S]
　　[4]ISO 26262-2:2011, Road vehicles -- Functional safety-Part2: Management of functional safety[S]
　　[5]ISO 26262-9:2011, Road vehicles -- Functional safety-Part9: Automotive Safety Integrity Level (ASIL)-oriented and safety-oriented analyses[S]