課件02-嵌入式軟件測試_第1頁
課件02-嵌入式軟件測試_第2頁
課件02-嵌入式軟件測試_第3頁
課件02-嵌入式軟件測試_第4頁
課件02-嵌入式軟件測試_第5頁
已閱讀5頁,還剩84頁未讀 繼續免費閱讀

下載本文檔

版權說明:本文檔由用戶提供并上傳,收益歸屬內容提供方,若內容存在侵權,請進行舉報或認領

文檔簡介

嵌入式軟件測試

第二部分測試類型測試類型—提要代碼類測試類型規格說明類測試類型質量特性類測試類型代碼類測試類型代碼審查(Codeinspections)代碼走查(Codewalkthroughs)靜態分析邏輯覆蓋測試(Logic-CoverageTesting)數據流測試變元測試(mutationtest)代碼審查—內容與方法主要測試內容檢查代碼和設計的一致性檢查代碼執行標準的情況檢查代碼邏輯表達的正確性檢查代碼結構的合理性檢查代碼的可讀性方法審查會依據代碼審查單逐項審查代碼審查—過程計劃介紹準備審查會返工后續跟蹤代碼審查—審查會評審組長產品開發人員記錄人員評審人員SQA人員系統維護人員用戶代表代碼審查—準入條件一組技術上有能力且經過培訓的審查人員一個受過培訓的審查組長正確的計劃和材料的分發良好的專業態度在審查會召開之前的全面準備已完成的設計文檔和源代碼已確認的檢查單或編碼標準代碼審查—需要解決的實際問題審查工作流于形式,缺乏操作性參與審查工作的人員缺乏相應的培訓,審查過程中得不到適當的指導、監督對審查工作的重要性和嚴肅性認識不足,沒有合理的計劃,審查前準備不充分,審查工作變成一種臨時性的即興活動審查人員的審查技能或專業知識不足代碼審查—需要解決的實際問題審查會偏離主題,演變成解決方案研討或技術攻關會,審查效率低下沒有對審查中發現的問題進行跟蹤,使審查工作功虧一簣,前功盡棄沒有建立測量數據收集機制,不分析審查工作的有效性,管理人員和技術人員體會不到審查帶來的效益和效果,不利于全員參與代碼審查—工作指南審查作為項目計劃的一部分考慮,分配資源和時間為每個要審查的工作產品建立一個檢查表限制參與人數,3–5名成員最佳制定議程,并且遵守議程審查會的時間不要超過兩個小時以建設性的方式討論問題,不要針對被審查產品的設計者代碼類—代碼審查工作指南將注意力集中在驗證和確認參與者提出的意見,避免探討解決方案限制爭論和辯駁,對提出的問題有不同意見時,通過記下問題并另行專題討論來結束爭論將討論的意見及其驗證和確認的結果形成文檔建立跟蹤機制,確保返工活動具有滿意的性能代碼走查—內容與方法主要測試內容代碼執行邏輯的正確性代碼數據操作的正確性代碼的健壯性方法人工執行測試用例采用會議形式,關鍵在于用例執行過程中的討論靜態分析—內容與方法主要測試內容控制流分析數據流分析接口分析表達式分析質量度量最差情況分析方法自動測試工具輔助靜態分析—復雜性度量使用McCabe復雜度度量作為指標對循環嵌套進行計算對控制流圖進行直觀檢查對數據流圖進行直觀檢查靜態分析—關注點未定義但被引用的變量必須從代碼中消除全局變量異常(局部覆蓋全局)必須從代碼中消除消除不使用的內容不可達的代碼(包括過程)聲明但未使用的變量定義的變量但未在作用域中使用應在代碼中文檔化說明靜態分析—關注點變量定義后未使用又被重新定義應在代碼中文檔化說明可疑的拋投(信息丟失,不匹配)如果不可避免,使用顯示拋投應在代碼中文檔化說明設計架構問題對控制流圖進行直觀檢查過程參數異常(僅引用,僅定義,未使用)靜態分析—關注點被零除范圍檢查錯棧溢出錯堆溢出錯無效指針操作浮點上溢出浮點下溢出無效浮點運算對象未初始化邏輯覆蓋測試—覆蓋要求語句覆蓋分支覆蓋條件覆蓋條件分支覆蓋修正條件分支覆蓋(MC/DC)條件組合覆蓋基本路徑覆蓋邏輯覆蓋測試—控制流圖一個段是一個或多個無條件連續執行的語句一個段在控制流圖中用一個結點表示,結點可以用任何方便的形式命名一個控制條件轉移是一個分支,一個分支段在控制流圖中用一個輸出邊表示一個程序的入口點用入口結點表示,它是一個沒有輸入邊的結點,一個程序的出口點用出口結點表示,它是一個沒有輸出邊的結點邏輯覆蓋測試—程序實例voidDoWork(intx,inty,intz){intk=0,j=0;if((x>3)&&(z<10)){k=x*y-1;j=sqrt(k);}if((x==4)||(y>5)){j=x*y+10;}j=j%3;}邏輯覆蓋測試—控制流圖例A:1,2,3B:4C:5,6,7,8D:9E:10,11,12F:13,14ABDFEC邏輯覆蓋測試—復雜度度量圈復雜度V(G)計算1V(G)=e–n+2e表示控制流圖中邊的數量,n表示控制流圖中節點的數量計算2V(G)=區域數計算3V(G)=判定節點數+1邏輯覆蓋測試—語句覆蓋程序中每條語句至少被執行一次C1覆蓋、行覆蓋、段覆蓋、基本塊覆蓋語句覆蓋的盲點(循環;條件)語句覆蓋是最起碼的測試要求邏輯覆蓋測試—語句覆蓋用例{x=4、y=5、z=5}執行路徑ABCDEFABDFEC判定1:(x>3)&&(z<10)判定2:(x==4)||(y>5)邏輯覆蓋測試—分支覆蓋程序中的每一個分支至少通過一次C2覆蓋、決策覆蓋、判定覆蓋分支覆蓋的盲點短路估值使分支覆蓋不必考慮所有條件分支覆蓋不能保證所有入口-出口路徑都被執行邏輯覆蓋測試—分支覆蓋用例{x=4、y=6、z=5}{x=2、y=5、z=5}執行路徑ABCDEFABDFABDFEC12判定1:(x>3)&&(z<10)判定2:(x==4)||(y>5)邏輯覆蓋測試—條件覆蓋判定中的每個條件獲得各種可能的結果不要求測試所有可能的分支邏輯覆蓋測試—條件覆蓋用例{x=4、y=6、z=15}{x=2、y=5、z=5}執行路徑ABDEFABDF12ABDFEC判定1:(x>3)&&(z<10)判定2:(x==4)||(y>5)邏輯覆蓋測試—條件分支覆蓋判定中每個條件的所有可能取值至少執行一次同時每個判定的所有可能判定結果至少執行一次邏輯覆蓋測試—條件分支覆蓋用例{x=4、y=6、z=5}{x=2、y=5、z=15}執行路徑ABCDEFABDF判定1:(x>3)&&(z<10)判定2:(x==4)||(y>5)12ABDFEC邏輯覆蓋測試—MC/DC修正條件分支覆蓋(MC/DC)程序里的每一個判定都至少取所有可能的輸出一次程序中判定的每一個條件都取所有可能的輸出至少一次判定中的每一個條件都被證明可以獨立影響判定的輸出邏輯覆蓋測試—MC/DC用例編號條件(與)判定1x>3z<1011TTT12TFF13FTF用例編號條件(或)判定2x==4y>521TFT22FTT23FFF邏輯覆蓋測試—MC/DC用例{x=4、y=5、z=5}11,

21{x=2、y=5、z=9}13,

23{x=6、y=6、z=15}12,

22執行路徑ABCDEFABDFABDEF12ABDFEC3邏輯覆蓋測試—條件組合覆蓋每個判定中條件的各種組合至少出現一次達到了條件組合覆蓋,所有的語句、分支和條件都將覆蓋,但不保證路徑覆蓋在實際測試中,由于謂詞表達式的短路估值和排它性條件使得達到所有條件組合不可能邏輯覆蓋測試—條件組合覆蓋用例{x=4、y=6、z=5}{x=4、y=5、z=15}{x=2、y=6、z=5}{x=2、y=5、z=15}執行路徑ABCDEFABDEFABDEFABDFABDFEC1423判定1:(x>3)&&(z<10)判定2:(x==4)||(y>5)邏輯覆蓋測試—基本路徑覆蓋基本路徑數=圈復雜度(C)基本路徑覆蓋要求測試C條不同的入口-出口路徑在某些程序中,分支覆蓋可在少于C條路徑的情況下獲得基本路徑覆蓋可能既沒有獲得語句覆蓋也沒有獲得分支覆蓋邏輯覆蓋測試—基本路徑覆蓋圈復雜度C=7-6+2=3用例{x=4、y=6、z=5}{x=4、y=5、z=15}{x=2、y=5、z=15}執行路徑ABCDEFABDEFABDFABDFEC132邏輯覆蓋測試—覆蓋分析器覆蓋分析器是分析測試覆蓋率的工具覆蓋分析器工作原理通過對源代碼的詞法分析,插入可跟蹤代碼,再編譯連接;當裝配過可跟蹤代碼的軟件執行時,就會產生一個跟蹤文件;測試完成后,利用跟蹤文件生成覆蓋報告。邏輯覆蓋測試—覆蓋率的作用發現不可執行的路徑或條件不可能到達或冗余的代碼不充分的測試用例集邏輯覆蓋測試—覆蓋與缺陷查找覆蓋與發現缺陷之間沒有必然聯系達到85%容易,達到100%困難不可到達的代碼(控制流無法到達)復雜序列(很難使控制流到達)數據流覆蓋測試通過一定的覆蓋準則檢查程序中每個數據對象的每次定義、使用和消除數據流模型(DUK)數據流覆蓋策略變元測試測試覆蓋被測實現的指定的變體,如測試探測到變元,則變體“退役”,如測試探測不到變元,則修正測試包變元是指為程序植入小的變化,一般是常出現的錯誤,如將>=改寫成>用于檢查系統的容錯能力和測試套件的充分性規格說明類測試功能測試性能測試接口測試人機交互界面測試功能測試詳盡測試每一個軟件功能功能——產品能夠完成的任務,如:特征/命令/任務標識等組合功能的測試測試基本流(最簡單執行路徑)測試備選流(特定條件下的執行路徑)功能測試—要求檢驗功能的完備性檢驗功能的正確性需要滿足精度等要求測試功能的健壯性功能測試—用例設計方法單項功能邊界值分析等價類劃分組合邏輯分析組合功能場景測試(Scenariotesting)狀態轉換性能測試性能測試是對軟件需求規格說明或設計文檔中的性能需求逐項進行的測試,以驗證其性能是否滿足規定的指標要求性能測試有時可理解為有定量指標要求的一些功能,其基礎是功能滿足要求,所以通常在功能測試的基礎上再做性能測試性能測試—性能系統或組件對于其及時性和資源利用性目標的符合程度良好的性能需求定義有前提條件性能測試—及時性在規定條件下,軟件產品執行其功能時,提供適當的響應和處理時間以及吞吐率的能力響應時間系統對事件產生響應所需要的時間吞吐量特定時間內能夠處理的事件數量性能測試—時間限制類型實時嵌入式系統的時間限制類型最大時間:一個事件和另一個事件發生的時間間隔最大不超過t個單位時間最小時間:兩個事件之間發生的時間間隔最小不小于t個單位時間持續時間:一種狀態必須存在t個單位時間性能測試—資源利用率在規定條件下,軟件產品執行其功能時,使用合適數量和類別的資源的能力主要包括內存使用CPU負載數據庫連接數接口飽和度磁盤利用率性能測試—性能約束需要弄清影響性能指標要求的全部潛在因素的約束條件考慮系統能力(硬件、支撐軟件)網絡負載情況,典型/峰值的并發需訪問的數據庫,類型、數量、結構、布局,數據庫中的數據量網絡的結構,帶寬性能測試—合格判據實時系統往往考慮最差情況強實時系統的一次性能不滿足要求,往往就是功能失效非實時系統通常考慮平均情況性能測試—方法從軟件性能需求中獲得性能測試需求確定需測試的性能指標確定關鍵用例、關鍵場景最重要、最耗時、最頻繁等確定影響被測性能指標的負載規模準備測試環境執行測試用例,記錄測試結果分析、計算結果判定性能測試—性能數據采集方法系統監視器程序監視器系統事件記錄器外部程序事件記錄器內部事件記錄器性能測試—環境時間測量外部觀察,適用于精度要求不高時,如使用秒表計時插樁探測,使用數字示波器,或機器時鐘,關鍵在于測量分辨率測量資源利用率系統自帶測量工具專門設計的方法性能測試—執行考慮盡可能多的情況,反復測試,如實記錄每次測試結果在測試記錄中要記清相應的測試環境,尤其是關鍵影響因素,以便做出正確判斷在得到一系列數據后再作判斷實時系統通常根據最差情況判斷非實時系統通常根據數據分布判斷性能測試—最差運行時間(WCET)獲取最差運行時間(WCET)的常用手段動態測量技術軟件動態運行獲取測試所有情況比較困難需要專門的測量儀器和設備靜態分析技術分析目標代碼結果精確接口測試從系統和子系統設計規格說明、軟件接口需求規格說明中獲得接口測試需求測試所有外部接口,檢查接口信息的格式及內容,考核異常情況的管理測試所有內部接口的功能和性能接口測試—主要接口類型參數接口數據通過參數從一個過程傳遞到另一個過程共享存儲器接口在過程或函數之間共享存儲器API接口一系列的過程被封裝成子系統,供另一個子系統調用消息接口一個子系統向其它子系統請求服務接口測試—主要接口錯誤類型接口誤用一個組件調用另一個組件時,在使用其接口時產生了錯誤接口誤解在調用組件中嵌入了對被調用組件行為的不正確假設同步誤差調用和被調用的組件以不同的速度運行,訪問到過時的信息接口測試—通信協議測試嵌入式系統的通信協議種類很多標準協議私有協議接口驅動程序采用非貨架產品時,需要測試非應用層協議的實現正確性測試健壯性測試需要接口測試設備接口測試—指南設計超出被調用組件參數范圍的測試對于指針參數,一定要測試空指針設計可導致組件失效的測試在消息傳遞系統中,使用強度測試在共享存儲器系統中,改變組件活動的次序人機交互界面測試操作和顯示界面及界面風格與需求規格說明中要求的一致性和符合性(正確性、有效性)以非常規操作、誤操作、快速操作來檢驗人機界面的可靠性對錯誤命令或非法數據輸入的檢測能力與提示情況(健壯性)對錯誤操作流程的檢測與提示對照用戶或操作手冊逐條進行操作和觀察質量特性類測試類型容量測試余量測試強度測試安全性測試信息安全測試可靠性測試容量測試容量測試的目的是檢驗軟件的能力最高能達到什么程度,確定系統的可伸縮性,從容量規劃的角度確定軟件的使用等級限制可伸縮性是系統在對其功能要求增加的情況下,繼續實現響應時間或吞吐量目標的能力有時系統容量作為系統指標,有時系統的實際容量需要測試才能得到容量測試—用例設計確定進行容量測試的性能指標或指標的成分確定影響指標行為的因素,給出這些影響因素在“正常”情況下的典型要求確定性能負載增加的增量值確定到達不正常后,尋找臨界值(容量點)的方法,如二分法容量測試—執行測試前做好分析,確定容量測試不會造成系統損傷測試執行時,通過向系統逐步施加不斷增大的性能負載,確定系統能否可靠地適應性能負載的增加記錄每次性能負載增加的測試結果仔細觀察系統的響應結果,與“正常情況”進行對比根據測試結果,綜合分析,確定系統能可靠處理的最大性能負載,評估系統的可伸縮性余量測試余量測試是對軟件是否達到需求規格說明中要求的余量的測試余量測試時,需要獲得測試量的最大值,剩下的是余量。用什么辦法能說明獲得的測試量是最大值是關鍵例如時間片規定是50ms,規定要求余量是30%,需要說明測試中考慮了消耗時間最長情況,其結果也在35ms以內余量測試—動因嵌入式軟件常常通過裕度設計提高系統的可靠性在實際應用中,由于某些預料不到的情況的發生,系統會在某些時刻以某種方式膨脹,如:處理時間變長,數據從正常區域波動到非正常區域等,設計留有余量將可以容納這些意外波動,維持系統正常運行規格說明中無明確要求時,一般至少留有20%的余量余量測試—目標存儲器使用輸入/輸出通道使用處理時間吞吐量注意:不是所有的性能要求都需要余量測試強度測試強制軟件運行在不正常到發生故障的情況下(設計的極限狀態到超出極限),檢驗軟件可以運行到何種程度需要弄清被測對象什么叫不正常,什么叫發生故障,它們表現形式是什么通常基于單因素假設,選取不同因素反復測試和試驗發現軟件的性能瓶頸,提供優化方案強度測試—相關思考找出臨界點是關鍵測試過程中負載逐步增加,反復測試找到一個最低的導致故障的點也存在達不到故障點的情況關于連續運行時間強度需要連續不中斷的運行,應該構造一個較大的測試用例庫作為支撐,測試用例庫的測試用例重復周期要超過指定的時間長度最好能實現自動測試強度測試—與其它測試的關系正常運行不正常但可運行性能測試故障容量測試強度測試正常運行設計規范余量測試工作極限破壞極限正常工作區設計裕度過應力安全性測試對防止危險狀態措施的有效性和每個危險狀態下的反應的測試對設計中用于提高安全性的結構、算法、容錯、冗余、中斷處理等方案的測試對異常條件下系統/軟件的處理和保護能力的測試,以表明不會導致不安全狀態對雙工切換、多機替換的正確性和連續性的測試安全性測試—要點應明確系統的安全狀態以及對軟件處理的要求安全性測試重點關注安全相關的功能,因此需求的分類管理很重要進行安全性測試時,應對測試的后果預先進行評估,防止測試導致損失,在真實環境下測試前應在仿真環境下預先驗證安全性測試應關注系統各級別上安全機制的協調性和合理性信息安全測試對具有防止非法進入軟件并保護軟件的數據完整性能力的測試對重要數據的抗非法訪問能力的測試防止數據完整性被破壞能力的測試防止系統可用性遭受破壞能力的測試邏輯炸彈等惡意邏輯和功能檢測信息安全測試—焦點嵌入式系統關注的信息安全特征A(可用性)-I(完整性)-C(機密性),控制的可用性和完整性最重要,數據平均信息量較低,機密性要求不高許多控制系統提供0.999999的可用性,安全不能降低可用性!信息安全測試—安全功能驗證身份識別與驗證系統對用戶身份進行鑒別權限管理通過鑒別的用戶的特權和訪問許可完整性避免數據訛誤保密性維持數據

溫馨提示

  • 1. 本站所有資源如無特殊說明,都需要本地電腦安裝OFFICE2007和PDF閱讀器。圖紙軟件為CAD,CAXA,PROE,UG,SolidWorks等.壓縮文件請下載最新的WinRAR軟件解壓。
  • 2. 本站的文檔不包含任何第三方提供的附件圖紙等,如果需要附件,請聯系上傳者。文件的所有權益歸上傳用戶所有。
  • 3. 本站RAR壓縮包中若帶圖紙,網頁內容里面會有圖紙預覽,若沒有圖紙預覽就沒有圖紙。
  • 4. 未經權益所有人同意不得將文件中的內容挪作商業或盈利用途。
  • 5. 人人文庫網僅提供信息存儲空間,僅對用戶上傳內容的表現方式做保護處理,對用戶上傳分享的文檔內容本身不做任何修改或編輯,并不能對任何下載內容負責。
  • 6. 下載文件中如有侵權或不適當內容,請與我們聯系,我們立即糾正。
  • 7. 本站不保證下載資源的準確性、安全性和完整性, 同時也不承擔用戶因使用這些下載資源對自己和他人造成任何形式的傷害或損失。

評論

0/150

提交評論