靜態(tài)測試技術課件

--靜態(tài)測試技術軟件測試方法和技術由安博測試空間技術中心/提供軟件測試方法和技術董瑞志/~nature_dongEmail:hello_u@MSN:nature_dong@聯(lián)系電話容提要靜態(tài)測試技術桌面檢查代碼審查代碼走查技術評審靜態(tài)測試的內(nèi)容需求定義的靜態(tài)測試設計文檔的靜態(tài)測試源代碼的靜態(tài)測試靜態(tài)測試的定義不執(zhí)行程序代碼而尋找代碼中可能存在的錯誤或評估程序代碼的過程。 靜態(tài)測試可以手工進行，也可以借助軟件工具自動進行。北京測試空間是注冊于北京市海淀區(qū)高新技術園的軟件企業(yè)，目前主要業(yè)務范圍包括軟件測試管理工具研發(fā)、軟件測試項目外包和軟件測試專業(yè)技術人才培養(yǎng)及派遣。北京測試空間地址：北京市海淀區(qū)學院路40號大唐電信測試空間樓聯(lián)系電話：010-623032236230326062303230靜態(tài)測試的特點靜態(tài)測試不必動態(tài)的執(zhí)行程序，也就是不必進行測試用例設計和結果判讀等工作；靜態(tài)測試可以由人手工方式進行，充分發(fā)揮人的優(yōu)勢，行之有效。解鈴還須系鈴人，由于人的思維及交流障礙而造成的邏輯錯誤，有人通過邏輯思維去解決，是一種非常有效的方法；特別是在充分利用人思維互補的情形，檢驗出錯誤的水平非常高。靜態(tài)測試實施不需要特別條件，容易開展靜態(tài)測試的內(nèi)容主要由人工進行代碼審查(CodeInspection)代碼走查(Walkthrough)桌面檢查技術審查主要由軟件工具自動進行的靜態(tài)分析廣義的理解，還包括軟件需求分析和設計階段的技術評審代碼審查與代碼走查的優(yōu)點不僅比桌面檢查優(yōu)越得多，而且與動態(tài)測試的方法相比也有很多優(yōu)點第一，使用這種方法測試，一旦發(fā)現(xiàn)錯誤，就知道錯誤的性質和位置，因而調(diào)試所花費的代價低第二，使用這種方法一次能揭示一批錯誤，而不是一次只揭示一個錯誤又，如果使用動態(tài)測試，通常僅揭示錯誤的征兆。 程序不終止運行，而對錯誤的性質和位置還得逐個查找。代碼審查與代碼走查的效果經(jīng)驗表明，使用這種方法能夠優(yōu)先的發(fā)現(xiàn)30~70％的邏輯設計和編碼錯誤IBM使用代碼審查方法表明，錯誤的檢測效率高達全部查出錯誤的80％Myers的研究發(fā)現(xiàn)代碼審查和代碼走查平均查出全部錯誤的70%代碼審查、代碼走查與動態(tài)測試相互補充研究表明使用代碼審查和代碼走查發(fā)現(xiàn)某類錯誤比用動態(tài)測試更有效，而對另一類錯誤情況正好相反由此可見代碼審查和代碼走查方法與動態(tài)測試結合，測試效果更佳。代碼審查的測試內(nèi)容檢查代碼和設計的一致性檢查代碼對標準的遵循、可讀性檢查代碼的邏輯表達的正確性檢查代碼結構的合理性代碼審查的組成和方式代碼審查由一組程序和錯誤檢查技術組成以代碼審查組方式組織代碼審查組通常由四人組成，其中一人為組長組長是關鍵，最好是一個稱職的程序員，但不是被測試程序的編寫者，也不需要對所檢查的程序很熟悉，但需要較強的組織協(xié)調(diào)和語言能力組長的職責包括分配資料、安排計劃、主持開會、記錄并保存被發(fā)現(xiàn)的錯誤其余成員包括資深程序員、程序編寫者與專職測試人員根據(jù)測試的組織方式（如內(nèi)部測試和獨立測試）不同，代碼審查小組組成可以調(diào)節(jié)，但組長角色不能變動代碼審查的步驟準備程序閱讀審查會議跟蹤及報告準備組長提前把程序目錄表和設計說明書等材料分配給小組成員小組成員熟悉這些材料由被測程序的設計和編碼人員向審查組詳細說明所準備的材料，特別是代碼的主要功能與功能間的關系程序閱讀審查組人員仔細閱讀代碼和相關材料對照代碼審查單標出明顯缺陷及錯誤審查會議審查會由組長主持首先由程序員逐句闡明程序的邏輯，在此過程中可由程序員或其他小組成員提出問題，追蹤錯誤是否存在經(jīng)驗證明在上述闡述過程中，有很多錯誤由講述程序者而不是其他小組成員發(fā)現(xiàn)大聲地朗讀程序給聽眾，這樣簡單的工作是有效的錯誤檢測技術然后利用代碼審查單來分析討論組長負責討論沿著建設性的方向前進，而其他人則集中注意力發(fā)現(xiàn)錯誤，但不去糾正錯誤跟蹤和報告會后把發(fā)現(xiàn)的錯誤登記造表并交給程序開發(fā)人員如果發(fā)現(xiàn)錯誤較多或發(fā)現(xiàn)重大錯誤，那么在改正之后，組長要再次組織審查會議為了改進以后的審查工作，對錯誤登記表也要分析，歸類和精煉以第三方測試的方式進行代碼審查應就發(fā)現(xiàn)的缺陷及錯誤與軟件開發(fā)人員討論避免由于理解不一致產(chǎn)生問題，形成共同認可的審查結果審查會議的時間大約以1.5~2小時為宜審查會需要高度集中注意力，時間太長反而容易使效率降低每次會議可能處理一個或幾個模塊代碼審查單代碼審查單是代碼審查過程所用的主要技術通常是把程序設計及編碼中可能發(fā)生的各種錯誤進行分類，對每一類列舉出盡可能多的典型錯誤，然后制成表格其它測試中發(fā)現(xiàn)的錯誤也要及時歸入代碼審查單，形成某一類型軟件針對性的代碼審查單，以供審查時使用G.J.Myers的代碼審查單（部分）數(shù)據(jù)引用錯誤是否引用了未賦值或者未初始化的變量？所有的數(shù)組引用，其下標值是否都在各自的相應維數(shù)定義界內(nèi)？所有的數(shù)組引用，每一個下表是否是整數(shù)值？所有引用的指針或變量當前是否已經(jīng)分配儲存了？（即是否存在“懸掛引用”的問題）在檢索操作或下標引用數(shù)組時，是否存在“差1”的錯誤？Tobecontinue……G.J.Myers的代碼審查單（部分）數(shù)據(jù)說明錯誤所有變量是否都顯示地說明了？是否每個變量都賦予正常的長度、類型和存儲分類？變量的初始化和它的存儲類型是否有矛盾？Tobecontinue……G.J.Myers的代碼審查單（部分）計算錯誤是否使用過非一致的數(shù)據(jù)類型的變量進行運算？是否存在混合運算？賦值語句的目標變量是否比其右邊的表達式小代碼審查單的其他內(nèi)容還可以包括編程風格、標準、規(guī)范的符合性方面的內(nèi)容在代碼審查單的錯誤登記表中，應寫明所查出的錯誤的類型、錯誤類別、錯誤的嚴重程度、錯誤的位置、錯誤的原因等信息。閱讀的方法要仔細閱讀需求設計等文檔，特別是了解軟件的整體物理意義、應用背景以及在大系統(tǒng)中的地位對大型軟件而言，這些信息會在閱讀程序時有效地幫助讀者從一定的高度審視，而不是停留在逐行掃描代碼有些錯誤要有整體觀才能發(fā)現(xiàn)閱讀結構化代碼的兩種方法追蹤通過每個子程序的主要邏輯行，主要邏輯行全部跟蹤完，然后開始跟蹤第二條路徑相當于深度優(yōu)先遍歷。按排列順序追蹤代碼，從主要行開始，然后檢查較低層的程序段 相當于廣度優(yōu)先遍歷兩種閱讀方法的綜合使用這兩種方式的差別在于何時進入下層模塊，選擇那種方式要視具體程序特點而定廣度優(yōu)先遍歷有助于很快地了解程序的全貌深度優(yōu)先適于詳細查閱功能處理步驟應綜合使用上述兩種方法，在頭一兩遍閱讀時，采用廣度優(yōu)先，然后用深度優(yōu)先程序閱讀的次數(shù)Beizer提出至少要讀程序4次，分別針對印刷錯誤、數(shù)據(jù)結構、控制流和處理4次閱讀要比讀一次能更快、更容易、更可靠的完成任務代碼審查的輔助工具匯編或編譯器生成的交叉引用表（變量、標號、子程序）逆向工程工具（例如從源代碼生成流程圖）帶有快速查找的編輯器代碼走查代碼走查與代碼審查相似，它也是由一組程序和錯誤檢查技術組成，只是程序和錯誤檢查技術不完全相同。代碼走查組代碼走查以小組方式進行代碼走查組包括組長，類似代碼審查組長秘書，負責記錄發(fā)現(xiàn)的錯誤，要有一定水平測試人員，應是具有經(jīng)驗的程序設計人員，或精通程序設計語言的人員，或從未介入被測試程序的設計工作的技術人員（這樣的人沒有被已有的設計框?。?，沒有約束，比較容易發(fā)現(xiàn)問題。代碼走查的過程與代碼審查過程相似先把材料交給每個小組人員，讓他們認真研究程序，然后再召開代碼走查會議。代碼走查會議的內(nèi)容與代碼審查不同，不是讀程序和使用代碼審查單，而是由被指定的作為測試員的小組成員提供若干測試用例（程序的輸入數(shù)據(jù)和期望的輸出結果），讓參加會的成員當計算機，在會議上對每個測試用例用頭腦來執(zhí)行程序，也就是用測試用例沿程序邏輯走一遍，并由測試人員講述程序執(zhí)行過程，在紙上或黑板上監(jiān)視程序狀態(tài)（變量的值）每次開會時間以1－2小時為宜，但不允許中斷如果發(fā)現(xiàn)問題由秘書記下來，中間不討論任何糾錯問題，主要是發(fā)現(xiàn)錯誤測試用例在代碼走查中的作用代碼走查中，測試用例并不是關鍵，也并不是僅想驗證這幾個測試用例運行是否正確，人腦畢竟比計算機慢太多這里測試用例是作為懷疑程序邏輯與計算錯誤的啟發(fā)點，在隨測試實例游歷程序邏輯時，在懷疑程序的過程中發(fā)現(xiàn)錯誤這樣，比幾個測試用例本身直接發(fā)現(xiàn)的錯誤要多得多代碼走查中的缺點代碼走查使用測試用例啟發(fā)檢測錯誤，人們注意力會相對集中在隨測試用例游歷的程序邏輯路徑上，不如代碼審查檢查的范圍廣，錯誤覆蓋面全。技術評審綜合運用走查和審查技術，逐頁、逐節(jié)地檢查軟件開發(fā)前期需求分析和設計的文檔，對軟件的需求，設計結構等方面提出問題評審也被當作一種管理工具，經(jīng)過評審不僅可以提高各階段軟件產(chǎn)品的質量，還可以收集到一些有關該軟件產(chǎn)品質量的數(shù)據(jù)技術評審屬于廣義的測試范疇，也是一種質量保證手段軟件開發(fā)過程中每個階段的評審都必須十分正規(guī)的，嚴格的加以定義，并根據(jù)規(guī)程實施。靜態(tài)測試的內(nèi)容針對不同的軟件中間產(chǎn)品，靜態(tài)測試的內(nèi)容也不盡相同；對不同的文檔進行靜態(tài)測試的內(nèi)容可以體現(xiàn)在對特定文檔的測試對照條例中。下面以軟件開發(fā)過程中的幾個有代表性的主要文檔和代碼，列舉靜態(tài)測試的對照條例，以說明靜態(tài)測試的內(nèi)容：需求定義的靜態(tài)測試對照條例對需求定義的測試著重于測試對用戶需求的描述和解釋是否完整、準確；下面是根據(jù)有關標準整理而成的對需求定義進行靜態(tài)測試的對照條例。我們把這些條例按照所測試的軟件質量因素分成10組：Tobecontinue……需求定義的靜態(tài)測試對照條例兼容性 界面需求是否使軟硬件系統(tǒng)具有兼容性？需求定義的靜態(tài)測試對照條例完備性需求定義是否包含了有關文件（指質量手冊、質量計劃以及其它有關文件）中所規(guī)定的需求定義所應該包含的所有內(nèi)容？需求定義是否包含了有關功能、性能、限制、目標、質量等方面的所有需求？功能性需求是否覆蓋了所有非正常情況的處理？是否對各種操作模式（如正常、非正常、有干擾等等）下的環(huán)境條件都作了規(guī)定？是否對所有功能與時間有關的方面都作了考慮？是否識別出了所有與時間因素有關的功能？它們的時間準則是否都說明了？時間準則的最大、最小執(zhí)行時間是否都定義了？是否識別并定義了在將來可能會變化的需求？需求定義的靜態(tài)測試對照條例完備性（續(xù)）是否定義了系統(tǒng)所有的輸入？是否標識清楚了系統(tǒng)輸入的來源？是否識別出了系統(tǒng)的輸出？是否說明了系統(tǒng)輸入、輸出的類型？是否說明了系統(tǒng)輸入、輸出的值域、單位、格式等等？是否說明了如何進行系統(tǒng)輸入的合法性檢查？是否定義了系統(tǒng)輸入、輸出的精度？是否定義了系統(tǒng)性能的各個方面？在不同負載情況下，系統(tǒng)的生產(chǎn)率如何？在不同的情況下，系統(tǒng)的響應時間如何？系統(tǒng)對軟件、硬件或電源故障必須作什么樣的反應？是否充分地定義了關于人機界面的需求？需求定義的靜態(tài)測試對照條例一致性各個需求之間是否一致？是否有沖突和矛盾？所規(guī)定的模型、算法和數(shù)值方法是否相容？是否使用了標準的術語和定義形式？需求是否與其軟硬件操作環(huán)境相容？是否說明了軟件對其系統(tǒng)和環(huán)境的影響？是否說明了環(huán)境對軟件的影響？需求定義的靜態(tài)測試對照條例正確性需求定義是否滿足標準的要求？算法和規(guī)則是否有科技文獻或其它文獻作為基礎？有哪些證據(jù)說明用戶提供的規(guī)則或規(guī)定是正確的？是否定義了對在錯誤、危險分析中所識別出的各種故障模式和錯誤類型所需的反應？是否參照了有關的標準？是否對每一個需求都給出了理由？理由是否充分？對設計和實現(xiàn)的限制是否都有論證？需求定義的靜態(tài)測試對照條例可行性需求定義是否使軟件的設計、實現(xiàn)、操作和維護都可行？所規(guī)定的模型、數(shù)值方法和算法是否對待解問題合適？是否能夠在相應的限制條件下實現(xiàn)？是否能夠達到關于質量的要求？需求定義的靜態(tài)測試對照條例易修改性對需求定義的描述是否易于修改（例如，是否采用良好的結構和交叉引用表等等）？是否有冗余的信息？是否一個需求被定義多次？需求定義的靜態(tài)測試對照條例健壯性是否有容錯的需求？需求定義的靜態(tài)測試對照條例易追溯性是否可從上一階段的文檔查找到需求定義中的相應內(nèi)容？需求定義是否明確的表明前階段中提出的有關需求和設計限制都已經(jīng)被覆蓋了？（例如，使用覆蓋矩陣或交叉引用表）？需求定義是否便于向后繼續(xù)開發(fā)階段查找信息？需求定義的靜態(tài)測試對照條例易理解性是否每一個需求都只有一種解釋？功能性需求是不是以模塊方式描述的，是否明確的標識出了其功能？是否有術語定義一覽表？是否使用了形式化或半形式化的語言？語言是否有歧義性？需求定義中是否只包含了必要的實現(xiàn)細節(jié)而不包含不必要的實現(xiàn)細節(jié)？是否過分細致了？需求定義是否足夠清楚和明確使其能夠作為開發(fā)設計規(guī)約和功能性測試數(shù)據(jù)的基礎？需求定義的描述是否將對程序的需求和所提供的其它信息分離開來了？需求定義的靜態(tài)測試對照條例易測試性和可驗證性需求是否可以驗證？（即是否可以檢驗軟件是否滿足了需求？）是否對每一個需求都指定了驗證過程？數(shù)學函數(shù)的定義是否使用了精確定義的語法和語義符號？設計文檔的靜態(tài)測試對照條例對設計文檔的靜態(tài)測試著重于分析設計是否與需求定義一致，所采用的數(shù)值方法和算法是否適用于待解問題，程序的設計中對程序的劃分是否與待解問題相適應，需求是否都被滿足了等等。設計文檔的靜態(tài)測試對照條例--完備性軟件設計規(guī)約是否包含了有關文件（指質量手冊、質量計劃及其它有關文件）中所規(guī)定的所有內(nèi)容？是否有充分的數(shù)據(jù)（如邏輯結構圖、算法、存儲分配圖等）來保證設計的完整性？算法、公式等是否充分、準確、完善？是否在設計中明確地說明了產(chǎn)品的開發(fā)中所需要的軟件、硬件和測試所需要的軟硬件？對于每一個程序界面，設計是否都實現(xiàn)了所要求的行為？Tobecontinue……設計文檔的靜態(tài)測試對照條例--完備性是否標識出了程序的每一個輸入、輸出和數(shù)據(jù)庫成分？其描述是否詳細到了可以編碼的程度了？是否說明了程序的操作環(huán)境？是否包含了所有的處理步驟？是否給出了每一個決策點的所有出口轉向？設計是否考慮到了所有可能的情況和條件？設計是否指明了在出現(xiàn)異常情況和不正當輸入的情況下的行為？設計是否參照了有關的設計標準？設計文檔的靜態(tài)測試對照條例—一致性在設計文檔中，是否始終使用標準的術語和定義？文檔的風格和詳細程度是否前后始終一致？界面之間是否相容？設計是否包含內(nèi)在矛盾？模型、算法和數(shù)值方法之間是否在數(shù)學上是相容的？輸入／輸出的格式是否一致？類似的功能和相關的功能的設計是否一致？計算中的輸入、輸出和數(shù)據(jù)庫成分的計量單位和計算精度是否一致？邏輯表達式是否一致？設計文檔的靜態(tài)測試對照條例—正確性設計文檔是否滿足有關標準的要求？設計是否只完成需求定義中要求的功能？若包含額外的功能，則這些功能的必要性是否經(jīng)過論證？測試文檔是否準確？設計邏輯是否正確？即，程序是否會完成所需的功能？設計是否與所描述的操作環(huán)境相一致？界面的設計是否與文檔所描述的界面部分一致？對于設計者不能選擇的輸入輸出和數(shù)據(jù)庫成分的數(shù)據(jù)格式、內(nèi)容和數(shù)據(jù)率，設計是否正確地給予了安排？設計文檔的靜態(tài)測試對照條例—可行性所設計的模型、算法和數(shù)值方法對于應用領域來說是否可以接受？設計能否在所規(guī)定的限制條件下和開發(fā)代價下實現(xiàn)？在可用的資源條件下，所設計的功能能實現(xiàn)嗎？設計文檔的靜態(tài)測試對照條例—易修改性設計是否使用了信息隱藏技術？模塊的組織使對一條需求的改變只影響較少的模塊對于可能改變的數(shù)據(jù)與函數(shù)的結構的設計使它門的界面對于單個函數(shù)的改變不敏感將數(shù)據(jù)結構的取接、數(shù)據(jù)庫的取接和I/O的取接從應用程序中分離開來，并使用專門的程序來完成之，不使用全局可取接的數(shù)據(jù)功能分解成一系列子程序，使每一個子程序都具有最大限度的內(nèi)部緊密聯(lián)系和最低限度的互相依賴高內(nèi)聚、低耦合每一個子程序都只有一個功能嗎？設計文檔的靜態(tài)測試對照條例—模塊性是否采用了模塊化的機制？設計是否使軟件系統(tǒng)由一系列相對來說較小的、以層次結構相互聯(lián)系的子程序組成？是否每一個子程序都只完成一個特定的功能？設計是否使用了特殊的規(guī)則來限制子程序的大??？設計文檔的靜態(tài)測試對照條例—可預測性設計是否包含了子程序來提供在已經(jīng)標識出的出錯情況下所需的反應？所設計的計算機資源調(diào)度方式是否是確定的和可預測的，而不是動態(tài)的？設計是否使用了盡量少的中斷和事件驅動，對使用這樣的功能是否進行了論證？是否設計了在程序的運行過程中進行正確性檢查來發(fā)現(xiàn)運行時刻的錯誤和違反運行許可的情況？設計文檔的靜態(tài)測試對照條例—結構化設計是否使用了層次式的邏輯控制結構？設計文檔的靜態(tài)測試對照條例—易追溯性設計文檔中是否包含設計與需求定義中的需求、設計限制等內(nèi)容的對應關系？設計是否標識出了設計中所包含的需求定義之外的功能？是否對所有函數(shù)都進行了適當?shù)臉俗R使代碼能夠唯一地引用該標識？設計規(guī)約是否包含修改歷史記錄，并使所有的對設計的修改和修改理由都記錄在內(nèi)并賦以編號了？設計規(guī)約是否包含了設計備案文檔并記錄了與設計有關的決策？設計文檔的靜態(tài)測試對照條例—易理解性設計是否避免了不必要的成分和表達形式？設計文檔是否不致造成歧義性解釋？設計文檔的靜態(tài)測試對照條例—可驗證性/易測試性設計中對每一個函數(shù)的描述是否都使用了良好的術語和符號？是否可以驗證它與需求定義相一致？是否定量地說明了使用條件、限制等內(nèi)容？是否可以由此產(chǎn)生測試數(shù)據(jù)？源代碼的靜態(tài)測試對源代碼的靜態(tài)測試著重于分析實現(xiàn)是否正確、完備。源代碼的靜態(tài)測試對照條例—完備性代碼是否完全、準確地實現(xiàn)了設計規(guī)約中所規(guī)定的內(nèi)容？代碼是否滿足設計要求？代碼是否創(chuàng)建了所需的數(shù)據(jù)庫或其它初始化數(shù)據(jù)？是否有未引用的或未定義的變量、常量或數(shù)據(jù)類型？源代碼的靜態(tài)測試對照條例—一致性代碼在邏輯上與設計規(guī)約一致嗎？是否自始至終使用了相同的格式、調(diào)用約定、