代碼可靠性復習資料

代碼可靠性測試第一章代碼可靠性測試與之前的測試區(qū)別主要加入比較多的靜態(tài)測試一、代碼可靠性設計一般分為4個方面：避免錯誤設計、查找缺陷設計、容錯保護設計和降低復雜度設計避免錯誤設計設計原則:控制和減少程序的復雜性，慎重使用容易引入缺陷的數(shù)據(jù)類型和方法遵循規(guī)則:改進軟件結構，提高模塊獨立性；設計的扇入和扇出適中；保證模塊規(guī)模適中查找缺陷設計是指在設計中增加程序運行時自動查找存在錯誤的一種設計方法。通過在程序重要模塊中或者容易出錯的位置設置檢查點，等待錯誤的出現(xiàn)，其方法包括看門狗定時器、循環(huán)等待次數(shù)控制、軟硬件交互檢查設計、數(shù)據(jù)合法性檢查，也包括對ROM中的代碼進行和校驗、檢測內存、對關鍵函數(shù)功能的檢查以及系統(tǒng)診斷。容錯機制的設計是指在設計中賦予程序某種特殊的功能，使程序在錯誤已被錯誤觸發(fā)的情況下，系統(tǒng)仍然具有正常運行能力的一種設計方法。常出現(xiàn)的容錯性保護是冗余設計技術，冗余設計技術實現(xiàn)的原理是在一套完整的軟件系統(tǒng)以外，設計一種不同路徑、不同實現(xiàn)方案的軟件作為內分，在出現(xiàn)故障時可以用冗余的部分進行替換，從而維護軟件系統(tǒng)的正常運行。4、 降低復雜性設計主旨思想是保證軟件原始需求功能的基礎上，盡可能簡化軟件的結構，縮短模塊內代碼的長度。在軟件復雜程度超過一定的范圍時，出錯率會明顯增加，降低復雜度是保證軟件質量的有效方法之一。二、代碼可靠性編程注意的規(guī)范：形式上的規(guī)范主要有：命名的規(guī)范、代碼風格。包括文件結構、程序版本、命名規(guī)則內容上的規(guī)范主要指高質量的編程、可靠性編程、一致性編程。邏輯和執(zhí)行、函數(shù)設計、接口設計、數(shù)據(jù)操作結構上的規(guī)范主要指分層分塊、封裝隔離的思想第二章軟件代碼可靠性測試：為了測試和評價高可靠性、高安全性的軟件系統(tǒng)而運用一系列測試手段對軟件系統(tǒng)實施測試，發(fā)現(xiàn)軟件的需求分析錯誤、設計錯誤、代碼錯誤、測試隱患和文檔錯誤的過程。需要考慮的方面包括：文檔測試、測試用例的良好設計、測試過程管理、測試環(huán)境搭建、對安全可靠性指標性能指標的測試要采用行之有效的測試手段，并將其作為測試的重點、測試配置管理。軟件測試的目的是做大限度的發(fā)現(xiàn)軟件的錯誤，減少軟件中殘留的錯誤，提高軟件的質量，能夠驗證軟件的功能性和性能性、可用性、可移植性、約束和限制第三章軟件代碼的可靠性測試包含基于模型的需求驗證、軟件質量度量、軟件代碼靜態(tài)分析、軟件代碼動態(tài)分析、黑盒測試、白盒測試、單元測試、集成測試、系統(tǒng)測試、文檔測試等測試手段，其中文檔測試、質量度量、靜態(tài)分析、代碼分析屬于靜態(tài)分析，單元測試、集成測試、系統(tǒng)測試屬于動態(tài)測試。單元測試一般采用白盒測試的技術、集成測試一般采用白盒測試和黑盒測試相結合的方式進行，而系統(tǒng)測試大多采用黑盒測試的思想。文檔測試包括基于模型的需求驗證、測試需求提取，同時將測試過程控制與配置管理作為軟件測試的一部分，對

軟件代碼可靠性進行了充分地闡述。靜態(tài)測試：代碼可靠性測試的過程（其階段分為）：測試需求分析、制定測試計劃、設計分析、測試工具選擇和測試數(shù)據(jù)準備、測試執(zhí)行、回歸測試、測試結束后及時的總結，對測試結果分析右側是負責人提交測試報告。代碼可靠性測試過程如下圖：靜態(tài)測試X單元測試集成測試-質度以代碼分折*=口盒測試}■■：：動態(tài)測試代碼可靠性測試過程如下圖：靜態(tài)測試X單元測試集成測試-質度以代碼分折*=口盒測試}■■：：動態(tài)測試：葉'黑盒測試」i:靜態(tài)分析;;；：系統(tǒng)測試=汽文檔測試］測試需求提恥軟件代碼可靠性測試技術：黑盒測試技術（P206）、白盒測試技術（P241）、單元測試技術、集成測試技術、系統(tǒng)測試技術單元測試涉及的測試方面：模塊接口測試、局部數(shù)據(jù)、邊界值、出錯處理、獨立路徑集成測試測試的方面:檢查模塊接口的數(shù)據(jù)、各個子模塊組合起來檢查父模塊是否達到預期的功能、檢查一個模塊的功能是否對另一個模塊的功能產(chǎn)生影響、全局數(shù)據(jù)是否有問題、單個模塊的誤差積累起來是否會放大。從而達到不可預料的后果。第六章軟件靜態(tài)分析又稱為用源代碼分析，與動態(tài)測試相對應，靜態(tài)測試不必設計測試用例，不運行被測試代碼，只對源程序代碼本身進行分析。通過人工方式進行代碼靜態(tài)分析具有很大的局限性，原因是比較耗時、易犯錯、可靠性低，對內缺乏可持續(xù)性對外不具有權威性。新一代代碼測試技術是基于規(guī)則的代碼檢查，意義重編程規(guī)范為依據(jù)分析源代碼，發(fā)現(xiàn)其不合規(guī)則和違反的地方，并給出違規(guī)的具體信息。注意：在單元測試中判定和路徑的區(qū)別是判定是路徑的組成部分，并且判定數(shù)＞=路徑數(shù)對于語句數(shù)量，如果這個語句是一個函數(shù)調用的話也算在語句數(shù)中。掌握6.3.1數(shù)據(jù)類型及數(shù)據(jù)類型轉換規(guī)范（1.數(shù)據(jù)類型相關的編碼風格）P135理解軟件代碼靜態(tài)分析的概念P132第七章掌握7.3典型錯誤類型分析（緩沖區(qū)溢出，內存泄露，引用未申明或初始化的變量，編譯錯誤等）P173理解7.1軟件代碼動態(tài)分析的概念P169：是指在代碼無錯誤地通過編譯的前提下，通過檢查源程序的語法、結構、過程、接口等來檢查程序的正確性，找出代碼中隱藏含的運行時錯誤和缺陷，如數(shù)學異常、緩沖區(qū)溢出、指針地址的有效性或數(shù)組越界錯誤等軟件運行時錯誤。軟件代碼動態(tài)分析的原理P1701數(shù)據(jù)流分析通常用數(shù)據(jù)流來分析數(shù)據(jù)處理異?，F(xiàn)象，包括初始化、賦值、引用數(shù)據(jù)異常第八章理解8.1軟件黑盒測試概念也稱基于軟件需求的測試，在完全不考慮程序內部結構和內部特性的情況下，對軟件的功能、接口以及其他質量特性進行測試，主要驗證系統(tǒng)是否滿足軟件需求。8.3軟件黑盒測試技術和方法（1）功能分解法（2）等價類劃分法（3）邊界值分析法（4）因果圖分析法（5）場景測試法（6）猜錯法理解第九章軟件白盒測試軟件白盒測試概念又稱基于結構的測試或基于代碼的測試，是按照程序內部的結構來進行測試，通過測試來檢測產(chǎn)品內部動作是否按照設計規(guī)格說明書的規(guī)定正常進行，檢驗程序中的每條通路是否都能按預定要求正確工作。軟件白盒測試技術和方法（1）靜態(tài)白盒測試：代碼質量度量，編程準則檢查，程序代碼動態(tài)分析（2）對判定的測試（3）對路徑的測試（4）對循環(huán)的測試（5）對變量的測試十章掌握10.1.3單元測試的主要目的P2771、驗證代碼實現(xiàn)與設計文檔的一致性2、發(fā)現(xiàn)設計文檔中存在的錯誤3、發(fā)現(xiàn)代碼本身發(fā)現(xiàn)的錯誤。單元測試方法和技術（程序流程圖，常用的邏輯覆蓋測試方法及測試數(shù)據(jù)設計，以及各種覆蓋方法的目的）P279P2801、 單元測試方法：典型值、邊界值、錯誤推測法、異常處理法（輸入異常值作為測試用例）2、 語句覆蓋率，判定/分支覆蓋率（被測軟件實際執(zhí)行判定分支與總分支數(shù)之比）重點課本例子！理解10.1單元測試的概念及重要性P276單元測試是指某一個具體的函數(shù)、類或者類的方法，對于C語言來說是一個函數(shù)，對于C++、Java來說單元測試的對象通常是類或者類的方法,對于圖形效果的軟件來說測試對象時一個窗口或者一個菜單。10.3單元測試策略和過程P285P2871、 自頂向下的集成策略：首先歲最頂層的單元進行測試，把頂層單元所調用的單元作為樁模塊；其次，對第二次單元進行測試，使用最頂層的單元作為驅動模塊，把該層的單元所調用的作為樁模塊；依此類推直到測試完所有的單元（周期長）2、 自底向上的測試策略：首先對最底層的單元展開測試，將調用該單元的單元作為驅動模塊；然后再逐層對被測單元進行測試，以下層被測試過的單元作為樁模塊，依此類推直到測試完所有的單元（復雜、時間周期長、側重于功能測試而不是面向整個程序結構的測試）3、 獨立測試：忽略各個單元之間的關系，為每個單元單獨設計樁模塊和驅動模塊，單獨測試各個單元。（目前最好的方法，可以縮短軟件開發(fā)周期，劣勢：無法早起得到開展集成測試策略，不方便建樁模塊和驅動模塊）4、 過程：計劃階段、設計實現(xiàn)階段、執(zhí)行階段、總結階段287頁圖十一章：掌握11.3.1集成測試策略P3361、非增量式集成策略（大爆炸式集成策略）定義：大爆炸集成也稱為一次性組裝或整體拼裝，就是把所有通過單元測試的模塊一次性集成到一起進行測試，不考慮組件之間的相互依賴性及可能存在的風險。目的：盡可能縮短測試時間，使用最少的測試用例驗證系統(tǒng)優(yōu)點：可以并行調試所有模塊工作效率高；需要的驅動、樁模塊、測試用例少；方法簡單易行。缺點：不能充分對各模塊之間的接口進行測試；不能良好的對全局數(shù)據(jù)結構進行測試；一次集成模塊多時，會出現(xiàn)大量錯誤一次性運行成功概率小；修復一處錯誤困難；一次性集成完成若出現(xiàn)軟件問題，軟件龐大不易查找定位問題所在2、 自頂向下集成策略：就是按照系統(tǒng)層次結構圖，以主程序模塊為中心，自上而下逐步測試處于低層的模塊，按照深度優(yōu)先或者廣度優(yōu)先策略，對各個模塊一邊組裝一邊進行測試。目的：從頂層控制開始，沿著與軟件開發(fā)設計順序同樣的路線對被測系統(tǒng)進行測試，來驗證功能和接口的正確性。3、自底向上集成：是從系統(tǒng)層次結構圖最低層模塊開始進行組裝和集成測試的方式，該策略由于從底層開始逐步向上集成，因此對于一個給定層次模塊而言，其子模塊已經(jīng)全部被集成驗證過，不需要創(chuàng)建樁模塊，直接運行子模塊即可。目的：從依賴最小的底層模塊開始，按照層次結構圖，逐層向上集成，驗證系統(tǒng)穩(wěn)定性4、三明治集成策略：集成了自頂向下和自底向上兩種集成方法的優(yōu)點，因此也屬于基于功能分解集成。通常三明治集成是將被測系統(tǒng)劃分為三個層次，中間層為目標，對頂層測試采用自頂向下的方式，對底層采用自底向上的方式，最后測試在目標層會和。目的：綜合利用自頂向下和自底向上兩種集成測試策略的優(yōu)點5、 改進的三明治集成策略：與三明治集成策略相同，集自頂向下和自底向上集成策略的優(yōu)點于一身，但本策略通過更改集成策略方式和方法以彌補三明治集成策略的不足。理解11.1集成測試基本概念及其主要任務P331集成測試又被稱為組裝測試、部件測試、子系統(tǒng)測試：是在單元測試的基礎上，將所有已通過單元測試的單元按照軟件概要設計文檔的要求組裝成為部件、子系統(tǒng)或系統(tǒng)，并進行測試的過程，一般是指對程序模塊按照特定的集成測試策略進行組裝，對模塊之間的接口以及集成后模塊的功能等進行正確性的檢驗。任務：主要任務是驗證集成后模塊之間的接口以及集成模塊的功能。11.3集成測試過程P3431、計劃階段（軟件概要設計文檔通過評審之后進行詳細的集成測試計劃主要的參考文檔：軟件需求規(guī)格說明文檔、軟件概要設計文檔制定）2、設計階段：依據(jù)軟件需求規(guī)格說明文檔，軟件概要設計文檔和軟件集成測試計劃文檔，分析被測系統(tǒng)結構、接口、模塊、測試策略、測試環(huán)境、時間進度安排等因素、3、實施階段：主要工作依據(jù)設計階段的分析編寫集成測試用例、開發(fā)集成測試所需腳本、集成測試所需測試工具的配置等內容。4、執(zhí)行階段：執(zhí)行集成測試用例并記錄相應結果和存在的缺陷，更改后回歸測試5、評估階段：分析集成測試結果，并進行匯總分析形成集成測試報告，然后將集成測試結果與研制方進行討論和驗證確定集成測試結果是否有效，測試環(huán)境、測試過程是否受控，以及被測系統(tǒng)是否通過集成測試。十六章掌握16.1測試文檔分類（測試計劃，測試用例，測試總結報告）1、測試計劃：是描述預測活動的范圍、方法、資源和進度的一種文檔。它確定測試項、測試特征、測試任務、執(zhí)行每一項任務的人員以及需要應急對策的任何風險。2、測試用例：是針對一項特定的軟件產(chǎn)品進行測試任務的描述，體現(xiàn)測試方案、方法、技術和策略；內容包括測試目標，測試環(huán)境、輸入數(shù)據(jù)、測試步驟、預期結果等，并形成文檔。3、測試報