軟件測試技術基礎(第二章程序結構靜態(tài)分析)

軟件測試技術基礎

（FoundationofSoftwareTestingTechnology）

第二章程序結構靜態(tài)分析

主講教師：實踐輔導教師：主要內容代碼審查代碼走查桌面檢查同行評審控制流分析數(shù)據(jù)流分析信息流分析2今天，不是每一個測試人員都閱讀代碼，但是研究代碼確是一種測試方法，被廣泛接受。以下因素影響是否采用閱讀代碼作為測試工作的一部分程序的大小和復雜性開發(fā)團隊的大小開發(fā)期限團隊文化和背景3人工測試人工測試可以在程序代碼編寫完，基于計算機的測試沒有開始以前進行。兩種主要的人工測試方法是：代碼審查（codeinspections）走查（walkthrough）人工測試技術的重要性錯誤發(fā)現(xiàn)得越早，改正錯誤的成本越低，正確改正錯誤的可能性也越大；程序員在開始基于計算機的測試時似乎要經歷一個心理上的改變。壓力會急劇增長，且要“盡可能快地修正這個缺陷”。由于這些，所以，程序員在改正某個基于計算機測試發(fā)現(xiàn)的錯誤時所犯的失誤，可能要比改正早期發(fā)現(xiàn)的問題時所犯的失誤會更多一些的。4代碼審查(codeinspections)人員一個代碼檢查小組通常是由四人組成，一人發(fā)揮著協(xié)調作用一人是該程序的編碼人員一人是其他成員通常是程序的設計人員一人是測試專家。5代碼審查所謂的代碼審查，其實就是以組為單位閱讀代碼，是一系列規(guī)程和錯誤檢查技術的集合。該過程通常將注意力集中在發(fā)現(xiàn)錯誤上，而不是糾正錯誤。內容檢查代碼和設計的一致性檢查代碼對標準的遵循、可讀性檢查代碼的邏輯表達的正確性檢查代碼結構的合理性6代碼審查步驟：第一步：小組成員提前閱讀設計規(guī)格書、程序文本等相關文檔第二步：召開程序審查會，開發(fā)人員讀程序，審查小組討論、發(fā)現(xiàn)、解決問題第三步：跟蹤與報告7代碼審查在代碼審查過程中，一個重要的部分是需要對照一份編程錯誤列表，來分析程序是否存在常見的錯誤。錯誤列表

錯誤列表在很大程度上是獨立于編程語言的可以把自己使用的編程語言中特有的錯誤，以及代碼檢查發(fā)現(xiàn)的錯誤補充到這份錯誤列表中去8代碼審查錯誤列表的總的構架。該列表共分為八個部分：數(shù)據(jù)引用錯誤數(shù)據(jù)聲明錯誤運算錯誤比較錯誤控制流程錯誤輸入/輸出錯誤接口錯誤其他檢查。

每一部分中細分了很多項9代碼審查在代碼審查的時間和地點上的選擇上，應避免所有的外部干擾；

代碼審查會議的理想時間應在90-120分鐘之內；

大多數(shù)的代碼審查都是按每小時大約閱讀150行代碼的速度進行；

對大型軟件的審查應安排多個代碼檢查會議同時進行，每個代碼審查會議處理一個或幾個模塊或子程序。10代碼審查代碼審查附帶的幾個有益的作用程序員通常會得到編程風格、算法選擇及編譯技術等方面的反饋信息；其他參與者也可以通過接觸其他程序員的錯誤和編程風格而同樣受益匪淺；代碼檢查還是早期發(fā)現(xiàn)程序中最易出錯部分的方法之一，有助于在基于計算機的測試過程中將更多的注意力集中在這些地方。11代碼走查（walkthrough)人員三到四人最好一人是這段代碼的作者（可做會議主持）一個類似于檢查中的仲裁人一個人擔當秘書的角色（記錄所有發(fā)現(xiàn)的錯誤）一個人擔當測試人員的角色最佳人員組合一位極富經驗的程序員；一位程序設計語言專家；一位程序員新手（可以給出新穎、不帶偏見的觀點）；最終將維護程序的人員；一位來自其他不同項目的人員；一位來自該軟件編程小組的程序員。12代碼走查代碼走查就是對軟件文檔進行書面檢查。它通過人工模擬執(zhí)行源程序的過程，檢查軟件設計的正確性。人工模擬也像計算機執(zhí)行那樣，可以仔細推敲、校驗和核實每一步的執(zhí)行結果，進而確定其執(zhí)行邏輯、控制模型、算法和使用參數(shù)與數(shù)據(jù)的正確性。步驟第一步：小組成員提前閱讀設計規(guī)格書、程序文本等相關文檔第二步：利用測試用例，使程序邏輯運行，記錄程序的蹤跡，發(fā)現(xiàn)、討論、解決問題

第三步：跟蹤與報告

13代碼走查缺點功能性測試很難實現(xiàn)有太多的條件有太多的測試用例14代碼審查和代碼走查的共同之處方法：組成一個小組來閱讀或直觀檢查特定的程序；并在“頭腦風暴會”上要形成統(tǒng)一的目標：找出錯誤，但不必找出改正錯誤的方法。換句話說，是測試，而不是調試。該組開發(fā)人員（三至四人為最佳）是對代碼進行審核，其中參加者當中只有一人是程序編寫者；也可以說它是對過去桌面檢查過程的改進。優(yōu)點：一旦發(fā)現(xiàn)錯誤，就可以在代碼中對其進行精確定位，這就降低了調試的成本；還通常可以發(fā)現(xiàn)成批的錯誤，這樣就可以一同得到修正，這也優(yōu)于機器測試，因為后者只能暴露出錯誤的某個表癥。效果：通常是能夠有效地查找出30%-70%的邏輯設計和編碼錯誤，但不能有效地查找出高層次的設計錯誤。地位：是與計算機的測試互補的，缺少其中任何一種錯誤檢查的效率都會降低。15代碼審查和代碼走查的共同之處該處的錯誤發(fā)現(xiàn)率，并不是說所有錯誤中多達70%可能會被找出來，而是講這些方法在測試過程結束時，可以有效地查找出多達70%的已知錯誤。應始終記住的是：程序中的錯誤總數(shù)始終是未知的。否則就會浪費大量的精力跟人力，也會在經濟效益上或多或少有一些損失的就經驗而言，修改一個現(xiàn)存的程序比編寫一個新程序更容易產生錯誤，這依據(jù)于以每寫一行代碼的錯誤數(shù)量來計的。16桌面檢查桌面檢查可視為由單人進行的代碼檢查或代碼走查；并由一個人閱讀程序，對照錯誤列表檢查程序，對程序推演測試數(shù)據(jù)。由此，我覺得桌面檢查可以說是上述兩種方法的一個內核或者說是雛形吧。所以也可知其效率是相當?shù)偷摹?/p>

17同行評分需指明：其該方法與測試并無關系，因為其目標并不是為了發(fā)現(xiàn)錯誤的，只是它與代碼閱讀的思想有一定的關聯(lián)而已。定義上：同行評分是一種依據(jù)程序整體質量、可維護性、可擴展性、易用性和清晰性對匿名程序進行評價的技術。不難看出，該技術的目的是為程序員提供自我評價的手段。其小組成員的構成為：一位管理員，負責擔任該評分過程的管理工作；6-20名參與者，并要保持匿名性，且要具備相似的背景。評分的資料：由參與者自己挑出兩個由自己編寫的程序以供評審，其中一個應是自認為能代表其自身能力的最好作品；另一個是自認為質量較差的作品。18代碼走查19控制流分析

非結構化程序會給測試、排錯、和程序的維護帶來許多困難要求寫出的程序結構良好檢查程序的控制結構成為十分有意義的工作20程序流程圖

132521控制流圖12435abcdef22控制流圖程序的控制流圖：符號○為控制流圖的一個結點，表示一個或多個無分支的PDL語句或源程序語句。箭頭為邊，表示控制流的方向。23控制流圖節(jié)點標有編號的圓圈

程序流程圖中矩形框所表示的處理

菱形表示的兩個甚至多個出口判斷

多條流線相交的匯合點

24控制流圖控制流線或弧箭頭

與程序流程圖中的流線一致，表明了控制的順序

控制流線通常標有名字25控制流圖矩陣

acbdef123451234526控制流圖矩陣便于機器表示和處理控制流圖

連接弧的節(jié)點的號碼決定了矩陣中元素的位置注意控制流的方向兩個節(jié)點沒有弧線，所對應的位置也就沒有元素27程序結構的基本要求寫出的程序不應包含：轉向并不存在的標號

沒有用的語句標號

從程序入口進入后無法達到的語句

不能達到停機語句的語句

28數(shù)據(jù)流分析

查找引用未定義變量等程序錯誤

查找對以前未曾使用的變量再次賦值等數(shù)據(jù)流異常的情況

常見的錯誤表現(xiàn)形式錯拼名字名字混淆語句丟失29數(shù)據(jù)流如果程序中某一語句執(zhí)行時能改變某程序變量V的值，則稱V被該語句定義如果一語句的執(zhí)行引用了內存中變量V的值，則稱V被該語句引用例如：X=Y+Z;ifY>Zthenreturn;30控制流圖與數(shù)據(jù)流表1234106758911節(jié)點被定義變量被引用變量1X,Y,Z2XW,X3X,Y4Y,Z5YV,Y6ZV,Z7VX8WY9ZV10ZZ11Z31信息流分析通過對輸入數(shù)據(jù)、輸出數(shù)據(jù)、語句之間的關系的分析來檢查程序錯誤整除算法例子輸入：in_m是被除數(shù)，in_n是除數(shù)輸出：out_q是商，out_r是余數(shù)32整除算法例子out_q=0;out_r=in_m;While(out_r>=in_n){out_q++;out_r=out_r–in_n;}33信息流關系圖√√√√√√√in_min