在基礎(chǔ)實踐2中您如何定義驗證標準?有了基礎(chǔ)實踐1中定義的戰(zhàn)略指導方針,您就可以進入下一步了。這個BP(基礎(chǔ)實踐)既適用于靜態(tài)測試也適用于動態(tài)測試。預(yù)期的結(jié)果是單元的特定測試用例和單元級靜態(tài)檢查的定義。在本文中,我們將討論基礎(chǔ)實踐2-7。
本文是ASPICE系列文章的第3篇。

ASPICE基礎(chǔ)實踐
基礎(chǔ)實踐2:制定單元驗證標準
ASPICE過程期望定義標準,以確保單元執(zhí)行軟件詳細設(shè)計和非功能需求中所描述的操作。
所有的工作產(chǎn)品都應(yīng)該按照軟件單元驗證策略中的描述進行生產(chǎn)。
例如,應(yīng)為靜態(tài)測試定義以下標準:
- 靜態(tài)測量的類型(例如,圈復雜度的測量)和成功的評價標準(測量的圈復雜度小于50)。
- 符合編碼標準(如MISRA)
- 符合項目中商定的設(shè)計模式
您可以為所有單元設(shè)置單元驗證標準,或者專門為一類單元或單個單元設(shè)置單元驗證標準。為了不讓工作失去控制,建議對一般定義保持慎重和保守。
專業(yè)提示:覆蓋目標(例如代碼覆蓋)通常不適合作為單元驗證標準。它們最好用作測試結(jié)束標準,從而確定測試何時可以被認為完成。
對于每個測試規(guī)范,基礎(chǔ)實踐6“確保一致性”要求在測試規(guī)范和軟件詳細設(shè)計之間進行內(nèi)容檢查。在大多數(shù)情況下,這是通過審查等質(zhì)量保證措施來完成的。此檢查的目的是證明測試用例正確地測試了鏈接需求的內(nèi)容。明確地期望每個評審都有文檔記錄。
如果在評估過程中發(fā)現(xiàn)缺少或不充分的非功能需求(SWE.1)或缺少或不充分的軟件詳細設(shè)計(SWE.3),BP2評估可能會被降級。
換句話說,如果前面的過程沒有完成,他們也不會得到一個好的評價。
基本實踐3:執(zhí)行軟件單元的靜態(tài)驗證
使用基礎(chǔ)實踐2中定義的標準,軟件單元的靜態(tài)驗證應(yīng)該在基礎(chǔ)實踐3中執(zhí)行。
該驗證可以通過以下方式執(zhí)行:
- 自動靜態(tài)代碼分析工具
- 代碼審查(例如檢查編碼標準和指導方針的符合性或正確使用設(shè)計模式)
成功標準應(yīng)該使用BP2的標準來確定。它們具體說明檢查是成功還是失敗。基礎(chǔ)可以是覆蓋標準或遵從最大值(max.圈復雜度最大為Y)或最小值(min.每行代碼最少x行注釋)。
基礎(chǔ)實踐4:測試軟件單元
使用基礎(chǔ)實踐2中創(chuàng)建的測試規(guī)范,軟件單元測試將在基礎(chǔ)實踐4中執(zhí)行。預(yù)期測試將按照軟件單元驗證策略中所描述的方式執(zhí)行。
對于基礎(chǔ)實踐3和基礎(chǔ)實踐4,明確要求記錄包括結(jié)果在內(nèi)的所有測試。如果出現(xiàn)異常現(xiàn)象和檢驗發(fā)現(xiàn)的情況,應(yīng)將其記錄、評估和報告。
此外,BP4要求以有意義的方式總結(jié)所有數(shù)據(jù)。在軟件單元驗證中,通常需要大量的測試數(shù)據(jù)。測試數(shù)據(jù)應(yīng)該在多個詳細級別上為手動和自動執(zhí)行驗證結(jié)果而準備。對此的解決方案是一個有意義的總結(jié),例如通過餅圖的形式聚集所有測試結(jié)果。
基礎(chǔ)實踐3和基礎(chǔ)實踐4的評估說明
與軟件單元驗證策略(BP1)相比,驗證測試執(zhí)行的偏差導致BP3或BP4的貶值。
對于BP3和BP4,缺乏有意義的總結(jié)會導致降級。如果一個測試只被評為通過/失敗,而沒有關(guān)于測試的附加信息,那么評估人員對受影響的基礎(chǔ)實踐的評價不會比“Partly”更好。自動化軟件單元測試報告中對單元的模擬和計算可以被視為對評估的充分補充信息。
評估人員將希望分別看到BP3和BP4的評估示例。具體地說,他們想要用它來驗證一個發(fā)現(xiàn)是否符合軟件單元驗證策略和SUP.9問題解決管理。
基礎(chǔ)實踐5:建立雙向追溯
在ASPICE中有幾個地方需要雙向追溯。如何實施取決于你自己。在這種情況下,您需要將詳細設(shè)計的需求與測試用例和靜態(tài)測試的結(jié)果聯(lián)系起來。測試用例依次鏈接到詳細設(shè)計的需求。
在最簡單的情況下,這可以通過表格的形式完成(列=測試用例;行=需求)。這種實現(xiàn)需要大量維護,而且很容易出錯。
Pro-Tip:為此使用模型動態(tài)測試工具TPT等工具,盡可能容易地創(chuàng)建鏈接,最好是自動生成報告。您可以將此跟蹤報告為概述用于一致性評審(SWE.4 BP6)作。在更改請求的情況下,您可以更快地分析對測試用例的依賴性。
評估人員明確地希望您將測試用例和需求雙向地鏈接起來(BP5)。
基礎(chǔ)實踐7:總結(jié)和交流結(jié)果
所有單元驗證結(jié)果應(yīng)匯總并通報相關(guān)方。BP7明確地期望有證據(jù)表明已經(jīng)報告了結(jié)果。所有類型的通信媒體,如信件、郵件、視頻、論壇帖子等,都可以作為證據(jù)(只要它們有記錄并可追溯)。
如果SWE.4的BP 3和/或BP 4被評為“None”或“Partly”,那么預(yù)計評估員會對BP7降級。
在BP7的ACQ.13項目要求過程中,需要確定相關(guān)方及其對信息的需求。
ACQ.13項目要求過程不作為ASPICE評估的一部分進行審查。然而,一個項目不應(yīng)該僅僅因為過程沒有被評估就忽略它,這是一個很好的實踐。
總結(jié)
ASPICE要求質(zhì)量保證的許多活動和結(jié)果。許多所需的結(jié)果也應(yīng)該以可驗證的方式進行檢查。
了解并應(yīng)用這些評估規(guī)則可以增加獲得良好評估的可能性。通常,一個項目在2年后達到1級,在2年后達到2級。
經(jīng)驗表明,當團隊愿意學習并不斷工作以滿足需求時,成功是最快實現(xiàn)的。
-
代碼
+關(guān)注
關(guān)注
30文章
4886瀏覽量
70253
發(fā)布評論請先 登錄
?共達電聲通過ASPICE CL2認證
佑駕創(chuàng)新智能座艙DMS項目通過ASPICE CL3評估
硬件輔助驗證(HAV) 對軟件驗證的價值
思必馳語音平臺項目通過ASPICE 1級能力認證
慧榮科技車用級SSD主控芯片獲得ASPICE CL3國際認證
TüV南德助力上海電驅(qū)動獲ASPICE 2級評估認可
TüV南德助力上海電驅(qū)動通過ASPICE 2級能力評估

調(diào)試ADS1278,讀取數(shù)據(jù)過程中在下一次SYNC低脈沖信號前出現(xiàn)反復進入中斷的現(xiàn)象,請問是否正確?
華盛艾思科榮獲DEKRA德凱ASPICE CL2認證證書
華盛艾思科榮獲ASPICE 4.0 CL2級認證
法本信息座艙平臺項目通過ASPICE CL2級評估
汽車軟件開發(fā)中的ASPICE合規(guī)挑戰(zhàn)與Jama Connect解決方案

汽車軟件開發(fā)者的必修課:ASPICE 4.0主要特點、優(yōu)勢及與之前版本的變化之處

評論