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

　?、祵τ谲浖軜?gòu)級別的需求測試覆蓋度，可以用來衡量測試的完整性，以及用于證明沒有設(shè)計之外的功能實現(xiàn)。如果有需要，可以增加新的測試案例，或者提供一個合理的理由說明。

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

　　● 結(jié)構(gòu)覆蓋率可以利用工具計算出來。
　　● 如果是基于模型的開發(fā)，結(jié)構(gòu)覆蓋率可以通過模型級別的模型結(jié)構(gòu)覆蓋率來統(tǒng)一計算。

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

　　⒏軟件集成測試需要盡可能地在真實環(huán)境中運行，如果不行，則需要評估測試環(huán)境與真實環(huán)境的差異性，并針對這些差異，在后續(xù)的階段的真實環(huán)境的測試中設(shè)計專門的案例來執(zhí)行。

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

　　軟件安全需求驗證

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

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

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

　?、硨τ谲浖踩枨髮崿F(xiàn)的測試需要在目標(biāo)硬件平臺上完成。

　　⒋軟件安全需求驗證的結(jié)果需要考慮下面這些因素來評估：

　　● 和預(yù)期結(jié)果一致;
　　● 軟件安全需求的覆蓋率;
　　● 成功或失敗的標(biāo)準(zhǔn)。

　　(未完待續(xù))

　　參考文獻：

　　[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]