【文章內容簡介】 調試。 代碼檢查與走查已經廣泛運用了很長時間。我們認為，它們的成功與本書第2章所述的一些原則有關。 在代碼走查中，一組開發(fā)人員（三至四人為最佳）對代碼進行審核。參加者當中只有一個人是程序編寫者。因此，軟件測試的主要工作是有其他人，而不是軟件編寫者本人來完成，這符合“軟件編寫者往往不能有效地測試自己編寫的軟件”的測試原則。 代碼檢查與走查是對過去桌面檢查過程（在提交測試前由程序員閱讀自己程序的過程）的改進。與原方法相比，代碼檢查與走查更為有效，同樣是因為在實施過程中，除了軟件編寫者本人，還有其他人參與進來。 菜嗎走查的另一個有點在于，一旦發(fā)現錯誤，通常就能在代碼中對其進行精確定位，這就是降低了調試（錯誤修改）的成本。另外，這個過程通常發(fā)現成批的錯誤，這樣錯誤就可以一同得到修改。而基于計算機的測試通常只能暴露出錯誤的某個表征（程序不能停止，或打印出了一個無意義的結束），錯誤通常是逐個地被發(fā)現并的得到糾正的。 在典型的程序中，這些方法通常會有效地查找出30%~70%的邏輯設計和編碼錯誤。但是，這些方法不能有效地查找出高層次的設計錯誤，例如在軟件需要分析階段的錯誤。請注意，所謂30%~70%的錯誤發(fā)現率，并不是說所有錯誤中多達70%可能會被找出來，而是講這些方法在測試過程結束時可以有效地查找出多大70%的已知錯誤。請記住，地2章告訴我們，程序中的錯誤總數始終是未知的。 當然，可能存在對這些統計數字的批評，即人工方法只能發(fā)現“簡單”的錯誤（即與基于計算機的測試方法相對比，所發(fā)現的問題顯得微不足道），而困難的、不明顯的或微妙的錯誤只能用于計算機的測試方法才能找到。然而，一些測試人員在使用了人工方法之后發(fā)現，對于某些特定的錯誤，人工方法比基于計算機的方法更有效，而對于其他錯誤類型，基于計算機的方法更有效。這就意味著，代碼檢查/走查與基于計算機的測試是互補的。缺少其中任何一種，錯誤檢查的效率都會降低。 最后，不但這些測試過程對于測試新開發(fā)的程序有著不可估量的作用，而且對于測試更改后的程序，這些測試過程具有相同的作用，甚至更大。根據我們的經驗，修改一個現存的程序比編寫一個新程序更容易產生錯誤（以每寫一行代碼測錯誤數量計）。因此，出來回歸測試方法之外，更改后的程序還要進行這些人工方法的測試。 代碼檢查 所謂代碼檢查，是以組為單位閱讀代碼，它是一些列規(guī)程和錯誤檢查技術的集合。對代碼檢查的大多數討論都集中在規(guī)程，所要填寫的表格等。這里對整個規(guī)程進行簡短的概述，之后我們將重點討論實際的錯誤檢查技術。一個代碼檢查小組通常由四人組成，其中一個人發(fā)揮著協調作用。協調人應該是個職稱的程序員，但不是該程序的編碼人員，不需要對程序的細節(jié)了解的很清楚，協調人的職責包括以下幾點：u 為代碼檢查分發(fā)材料、安排進程。u 在代碼檢查中起主導作用。u 紀錄發(fā)現的所有錯誤。u 確保所有錯誤隨后得到改正。協調人就像是質量控制工程師。小組中的第二個成員是該程序的編碼人員。小組中的其他成員通常是程序的設計人員（如果設計人員不同于編碼人員的話），以及一名測試專家。 在代碼檢查之前的幾天，協調人將程序清單和設計規(guī)范分發(fā)給其他成員。所有成員應在檢查之前熟悉這些材料。在檢查進行時，主要進行兩項活動：1．由程序編碼人員逐條語句講述程序的邏輯結構。在講述的過程中，小組其他成員應提問題、判斷是否存在錯誤。在講述中、很可能是程序編碼人員本人而不是其他小組成員發(fā)現了大部分錯誤。換句話說，對著大家大聲朗讀程序，這種簡單的做法看來是一個非常有效的錯誤檢查方法。 （該列表將在下一節(jié)中介紹） 協調人負責確保檢查回憶的討論高效地進行、每個參與者都將注意力集中于查找錯誤而不是修改錯誤（錯誤的修改正由程序員在檢查會議之后完成）。 會議結束之后，程序員會得到一份已發(fā)現錯誤的清單。如果發(fā)現的錯誤太多，或者某個錯誤涉及對程序做根本的改動，協調人可能會在錯誤修改后安排對程序進行再次檢查。這份錯誤清單也要進行分析、歸納，用以提煉錯誤列表，以便提高以后代碼檢查的效率。 如上所述，這個代碼檢查過程通常將注意力集中在發(fā)現錯誤上，而不是糾正錯誤。然而，有些小組可能會發(fā)現，當檢查出某個小問題之后，有兩三個人（包括負責該代碼的程序本人）會建議對設計進行明顯的修補以解決這個特例。那么，對這個小問題的討論，反過來會將整個小組的注意力集中在設計的某個部分。在探討修補設計來解決這個小問題的最佳方法時，有人可能會注意到另外的問題。既然小組已經發(fā)現了設計中同一部分的兩個相關問題，那么每隔幾段代碼就可能需要密集的注釋。幾分鐘之內，整個設計就被徹底檢查完，任何問題都會一目了然。 在代碼檢查的時間及地點的選擇上，應避免所有的外部干擾。代碼檢查會議的理想時間應在90~120分鐘之間。由于開會是一項繁重的腦力勞動，會議時間越長效率越低。大多數的代碼檢查是都是按每小時大約閱讀150行代碼的數度進行。因此，對大型軟件的檢查應安排多個代碼檢查會議同時進行，每個代碼檢查會議處理一個或幾個模塊或子程序。 請注意，要是檢查過程有效，必須樹立正確的態(tài)度。如果宣傳員將代碼檢查視為對其人格的攻擊、采取了防范的態(tài)度，那么檢查過程就不會有效果。正確的做法是，程序員必須懷著非自我本位的態(tài)度來對待檢查過程，對整個過程采取積極和建設性的態(tài)度：代碼檢查的目標是發(fā)現程序中的錯誤，從而改進軟件的質量。正是因為這個原因，大多數人建議應對代碼檢查的結果進行保密，僅限于參與者范圍內部。尤其是如果管理人員想利用代碼檢查結果，那么就與檢查過程的目的背道而馳了。 出了可以發(fā)現錯誤這個主要作用之外，代碼檢查還有幾個有益的附帶作用。其一，程序員通常會得到編程風格、算法選擇及編程技術等方面的反饋信息 。其他參與者也可以通過接觸其他程序員的錯誤和編程風格而同樣受益匪淺。還有，代碼檢查還是早期發(fā)現程序中最容易出錯部分的方法之一，有助于在基于計算機的測試過程中將更多的注意力集中在這些地方（本書地2章中的測試原則之一）。 用于代碼檢查的錯誤列表 代碼檢查過程的一個重要部分就是對照一份錯誤列表，來檢查程序發(fā)、是否存在常見錯誤。遺憾的是，有些錯誤列表更多地注重編程風格而不是錯誤（例如，“注釋是否準確且有意義？”，“IF—ELSE代碼段和DO—WHILE代碼段是否縮進對齊？”），錯誤檢查太過模糊而實際上沒有用（例如，“代碼是否滿足設計的需求？”）。本節(jié)鎮(zhèn)南關討論的錯誤列表是經多年對軟件錯誤的研究編輯而成的。該錯誤列表在很大程度上是獨立于編程的，也就是說，大多數的錯誤都可能出現在任意語言編寫的程序中。讀者可以把自己使用的編程語言中特有的錯誤，以及代碼檢查發(fā)現的錯誤補充到這份錯誤列表中去。 數據引用錯誤1. 是否有引用的變量未賦值或未初始化？這可能是最常見的編程錯誤，在各種環(huán)境中都可能發(fā)生。在引用每個數據項（如變量、數據元素、結構中的域）時，應試圖非正式地“證明”該數據項在當前位置具有確定的值。2. 對于所有的數組引用，是否每一個下標的值都在相應維規(guī)定的界限內？3. 對于所有的數組的引用，是否每個下標的值都是整數？雖然在某些語言中這不是錯誤，但這樣做是危險的。4．對于所有的通過指針或引用變量的引用，當前引用的內存單元是否分配？這就是所謂的“虛調度（dangling reference）”錯誤。當指針的生命期大于所引用內存單元的生命期時，錯誤就會發(fā)生。當指針引用了過程中的一個局部變量，而指針的值有被賦給一個輸出參數或一個全局變量，過程返回（釋放了引用的內存單元）結束，爾后程序試圖使用指針的值時，這種錯誤就會發(fā)生。與前面檢查的方法類似，應試圖非正式地“證明”，對于每個使用指針值的引用，引用的內存單元都存在。，當通過別名進行引用時，內存域中的數據值是否具有正確的屬性？在FORTRAN語言中對EQUIVALENCE語句而成為同一內存域的別名。如果程序先對A賦值，然后又引用變量B，由于機器可能會將內存中用浮點位表示的實數當作整數，在這種情況下錯誤就可能發(fā)生。？當C、C++或COBOL程序將某個記錄讀到內存中，并使用一個結構來引用它時，由于記錄的物理表示與結構定義在差異，這種情況下錯誤就可能發(fā)生。，當內存分配的單元小于內存可尋址的單元大小時，是否存在直接或間接的尋址錯誤？例如，在某些條件下，定長的位串不必以字節(jié)邊界為起點，但是地址又總是指向字節(jié)邊界的。如果程序計算一個位串的地址，稍后又通過該地址引用這個位串，可能會指向錯誤的內存位置。將一個位串參數傳送給一個子程序時，也可能發(fā)生這種情況。，被引用的內存的屬性是否編譯所預期的一致？這種錯誤的一個例子是，當一個指向某個數據結構的C++指針，被賦值為另為的數據結構的地址。，那么每個過程或子程序對該個、結果的定義是否都相同？，當對數組進行索引操作或下標引用，字符的邊界取值是否有“僅差一個”（off—by—one）的錯誤？，是否所有的繼承需求都在實現類中得到了滿足？ 數據申明錯誤1. 是否所有的變量都進行了明確的聲明？沒有明確聲明雖然不一定是錯誤，但通常卻是麻煩的源頭。舉例來說，如果一個程序的子程序接收一個數組參數，卻未將該參數定義為數組（如用DIMENSION 語句），對該數組的引用（如C=A （I））會被解釋為一個函數調用，導致計算機試圖將此數組當作程序執(zhí)行。另外，如果某個變量在一個內部過程或程序壞中沒有明確聲明，是否可以理解為該變量在這個程序塊中被共用？2. 如果變量所有的屬性在聲明中沒有明確說明，那么說明默認的屬性能否被正確理解？舉例來說，在JAVA語言中，程序接收到的惡魔人屬性往往是導致意外發(fā)生的源頭。3. 如果變量在聲明語句中被初始化，那么它的初始化是否正確？在很多語言中，數組和字符串的初始化比較復雜，因此也成為容易錯誤的地方。4. 是否每個變量都被賦予了正確的長度和數據類型？5. 變量的初始化是否與其存儲空間的類型一致？舉例來說，如果FORTRAN語言子程序中的一個變量在每次調用子程序時都需要重新初始化一次，那么必須使用賦值語句對其初始化，而不應該用DATA語句。6. 是否存在著相似名稱的變量（如VOLT和VOLTS）？這種情況不一定是錯誤、但應被視為警告，這些名稱可能會在程序中發(fā)生混淆。 運算錯誤1. 是否存在不一致的數據類型（如非算術類型）的變量的運算？2. 是否有混合模式的運算？例如，將浮點變量與一個整形變量做加法運算。這種情況并不一定是錯誤，但應該謹慎使用，確保程序語言的轉換規(guī)則能夠被正確理解?？聪旅娴腏AVA程序片段，顯示了整數運算中可能發(fā)生的取整誤差：int x = 1。int y = 2。int z = 0。z = x/y。(“z = “+ z)。Output。Z = 0。3. 是否有相同數據類型、不同字長變量間的運算？4．賦值語句的目標變量的數據類型是否小于右邊表達的數據類型或結果？5. 在表達式的運算中是否存在表達向上或向下溢出的情況？也就是說，最終的結果看以來是個有效的值、但中間結果對于編程 語言的數據類型可能過大或過小。6. 除法運算中的除數是否可能為0？7 如果計算機表達變量的基本方式是基于二進制的，那么運算結果是否不精確？也就是說，在一個二進制計算機上，10* 。.8. 特定場合，變量的值是否超出了有意義的范圍？例如，對變量PROBABILITY賦值的語句可能需要進行檢查。9. 對于包含一個以上操作符的表達式，賦值順序和操作符的優(yōu)先順序是否正確？10. 整數的運算是否有使用不當的情況，尤其是除法？舉例來說，如果i是一個整形變量，表達式2*i/2= =i是否成立，取決于i是奇數還是偶數，或是先運算乘法，還是先運算除法。，例如，將字符串與地址、日期或數字相比較？，或不同長度的變量間的比較運算？如果有，應確保程序能正確理解轉換規(guī)則。？程序員經常混淆“至多”、“至少”、“大于”、“不大于”、“小于”和“等于”等比較關系。？在編寫涉及“與”、“或”或“非”的表達式時，測試員經常犯錯。？比較運算符和布爾運算符是否錯誤地混在了一起？這是一類經常會犯的錯誤，這里我們描述幾個典型錯誤的例子。如果想判斷i是否在2~10之間，表達式2i 10是不正確的；相反，正確的應該是（2 i）amp。amp。( i 10)。如果想判斷i是否大于x或y，表達式ix||y也是不正確的，正確的應該是（ix）||(i)y。如果要比較三個數字是否相等，表達式if（a= =b = = c）的實際意思卻大相徑庭。如果許啊喲驗證數學關系xyz,正確的表達式應該是（xy）amp。amp。(yz)。，是否有二進制表示的小數或浮點數的比較運算？由于四舍五入，以及用二進制表示十進制數的近似度，這往往是錯誤的根源。，賦值順序以及運算的優(yōu)先級是否正確？也就是說，如果碰到如同（if ( (a = =2)amp。amp。(b = =2))||（c= = 3））的表達式，程序能否正確理解是“與”運算在先還是“或”運算在先？？例如，語句if（x = =0 amp。amp。( x/y)z）對于有的編譯來說是可接受的，因為其認為一旦“與”運算的一側為FALSE時，另一側就不用計算；但是對于其他編譯來說，卻可能起一個被0除的錯誤。 控制流錯誤 1. 如果測試包好多條分支路徑，比如有計算GO TO語句，索引變量的值是否會大于可能的分支數量？例如，在語句GO TO （200 ，300，400），i？應設計一個非正式的證明或論據來證明每一個循環(huán)打擊都會終止。、模塊或子程序是否最終終止了？，循環(huán)是否有可能從未執(zhí)行過？如果確實發(fā)生這種情況，這里是否是一處疏漏？例如，如果循環(huán)一下的語句作為開頭：For (I = =x。 i=z。i ++){…}While (NOTFOUND){…}當NOTFOUND初始時就為假，或者x大于z時，情況會如何呢？（如一個搜索循環(huán)），如果循環(huán)越界（fallthrough）了，后果會如何？例如，偽指令循環(huán)以 DO I=1 TO TABLESIZE WHILE (NOTFOUND)開頭，如果NOTFOUND永不為假，會發(fā)生什么結果呢？6．是否存在“僅差一個”的錯誤，如迭代數量恰恰多一次或少一次？這在從0開始