代碼檢查、走查與評審

3.1代碼檢查與走查

代碼檢查、走查以及可用性測試是三種主要的人工測試方法。這些測試方法可以用在軟件開發的任何階段。

代碼檢查和走查都要求人們組成一個小組來閱讀或直觀檢查特定的程序。無論采用哪種方法，參加者都需要完成一些準備工作。準備工作的高潮是在參加者會議上進行的所謂“頭腦風暴會”。“頭腦風暴會”的目標是找出錯誤來，但不必找出改正錯誤的方法。換句話說，是測試，而不是調試。 優點： 1.代碼檢查與走查是對過去桌面檢查過程（在提交測試前由程序員閱讀自己程序的過程）的改進。因為在實施過程中，除了軟件編寫者本人，還有其他人參與進來。 2.代碼走查的另一個優點在于，一旦發現錯誤，通常就能在代碼中對其進行精確定位，這就降低了調試的成本。另外，這個過程通常發現成批的錯誤，這樣錯誤就可以一同得到修正。 缺點： 1.這些方法不能有效地查找出高層次的設計錯誤，例如在軟件需求分析階段的錯誤，

3.2代碼檢查

代碼檢查，是以組為單位閱讀代碼，它是一系列規程和錯誤檢查技術的集合，

3.2.1代碼檢查小組

代碼檢查小組通常由四人組成：協調人、代碼作者、程序設計人員和測試專家。 協調人：（1）為代碼檢查分發材料、安排進程；（2）在代碼檢查中起主導作用；（3）記錄發現的所有錯誤；（4）確保所有錯誤隨后得到改正。

3.2.2檢查議程與注意事項

1.所有人員提前熟悉程序清單和設計規范。 2.檢查時，由程序編碼人員逐條講解程序的邏輯結構，其他人可提問題、判斷是否存在錯誤。 3.檢查時，參考常見的編碼錯誤列表分析程序。 4.代碼檢查會議時間不宜過長（90-120min），環境安靜，避免外部干擾。

3.2.3對事不對人，和人有關的注意事項

代碼檢查的目的是發現程序中的錯誤，從而改進軟件的質量。 程序員不可將代碼檢查視為對其人格的攻擊、采取了防范的態度，那么檢查過程就不會有效果。

3.2.4代碼檢查的衍生功效

除了發現錯誤這個主要作用之外，代碼檢查還有其他的衍生作用。 1.程序員通常會得到編程風格、算法選擇和編程技術等方面的反饋信息。 2.其他參與者也可以通過接觸程序員的錯誤和編程風格而同樣受益匪淺。通常來說，這種類型的測試方法能夠增強項目中團隊的凝聚力，減少消極人際關系滋長的可能性，有利于打造高度合作、高效的以及信得過的開發模式。

3.3用于代碼檢查的錯誤列表

3.3.1數據引用錯誤

1.是否有引用的變量未賦值或未初始化？ 2.對于所有的數組引用，是否每一個下標的值都在相應維規定的界限之內？ 3.對于所有的數組引用，是否每一個下標的值都是整數？雖然在某些語言中這不是錯誤，但這樣做是危險的。 4.對于所有的通過指針或引用變量的引用，當前引用的內存單元是否分配？（“虛調用”錯誤，編碼中要保證每個使用指針的引用，引用的內存單元都存在。） 5.如果一個內存區域具有不同屬性的別名，當通過別名進行引用時，內存區域中的數據值是否真正具有正確的屬性？（實型A和整型B成為同一內存區域的別名，對A賦值后，引用變量B可能會出現此種錯誤） 6.變量值的類型或屬性是否與編譯器所預期的一致？（程序將記錄讀到內存中，并使用一個結構來引用它時，由于記錄的物理表示與結構定義存在差異，這種情況下錯誤就可能發生。） 7.是否計算位串的地址？是否傳遞位串參數？（當內存分配的單元小于內存可尋址的單元大小時，是否存在直接或間接的尋址錯誤？如：在某些條件下，定長的位串不必以字節邊界為起點，但是地址又總是指向字節邊界的。） 8.基礎的存儲屬性是否正確？（錯誤的例子：一個指向某個數據結構的C++指針，被賦值為另外的數據結構的地址。） 9.跨過程的結構定義是否匹配？（每個過程或子程序對該結構的定義是否都相同？） 10.索引或下標操作是否有“僅差一個”的錯誤？（邊界值） 11.繼承需要是否得到滿足？

3.3.2運算錯誤

1.是否存在非算術變量間的運算？（避免不一致的數據類型的變量間運算。） 2.是否存在混合模式運算？（如：將浮點變量和整型變量做加法運算。盡量避免，存在時要保證轉換規則正確。） 3.是否存在相同數據類型、不同字長變量間的運算？ 4.目標變量的大小是否小于賦值大小？ 5.中間結果是否上溢或下溢？ 6.是否存在被0除？ 7.是否存在二進制的不精確度？ 8.變量的值是否超過了有意義的范圍？ 9.操作符的優先順序是否被正確理解？ 10.整數除法是否正確？

3.3.3數據聲明錯誤

1.是否所有的變量都已聲明？ 2.默認的屬性是否被正確理解？ 3.數組和字符串的初始化是否正確？ 4.變量是否賦予了正確的長度、類型和存儲類？ 5.初始化是否與存儲類相一致？ 6.是否有相似的變量名？

3.3.4比較錯誤

1.是否存在不同類型變量間的比較？ 2.是否存在混合模式的比較運算？（不同長度的變量間的比較運算，應確保程序能正確理解轉換規則。） 3.比較運算符是否正確？ 4.布爾表達式是否正確？ 5.比較運算是否與布爾表達式相混合？（比較運算符和布爾運算符是否錯誤的混在一起使用了？） 6.是否存在二進制小數的比較？（由于四舍五入，以及用二進制表示十進制數的近似度，這往往是錯誤的根源。） 7.操作符的優先順序是否被正確理解？ 8.編譯器對布爾表達式的計算方式是否被正確理解？

3.3.5 控制流程錯誤

1.是否超出了多條分支路徑？ 2.是否每個循環都終止了？ 3.是否每個程序都終止了？ 4.是否存在由于入口條件不滿足而跳過循環體？ 5.可能的循環越界是否正確？ 6.是否存在“僅差一個”的迭代錯誤（循環次數多一次或少一次）？ 7.do/end語句是否匹配？ 8.是否存在不能窮盡的判斷？ 9.輸出信息中是否有文字或語法錯誤？

3.3.6輸入/輸出錯誤

1.文件屬性是否正確？ 2.open語句是否正確？ 3.i/o語句是否符合格式規范？ 4.緩沖大小與記錄大小是否匹配？ 5.文件在使用前是否打開？ 6.文件在使用后是否關閉？ 7.文件結束條件是否被正確處理？ 8.是否處理了i/o錯誤？

3.3.7接口錯誤

1.形參數量是否等于實參的數量？ 2.形參的屬性是否與實參的屬性相匹配？（如：數據類型和大小） 3.形參的量綱是否與實參的量綱相匹配？（如：形參以度為單位，而實參以弧度為單位。） 4.傳遞給被調用模塊的實參個數是否等于其形參個數？ 5.傳遞給被調用模塊的實參屬性是否與其形參屬性匹配？ 6.傳遞給被調用模塊的實參量綱是否與其形參量綱匹配？ 7.調用內部函數的實參的數量、屬性、順序是否正確？ 8.如果某個模塊或類有多個入口點，是否引用了與當前入口點無關的形參？（避免引用與當前入口點有關的形參） 9.是否改變了某個原本僅為輸入值的形參？ 10.全局變量的定義在模塊間是否一致？ 11.常數是否以實參形式傳遞過？（避免常數以實參形式傳遞）

3.3.8其他檢查

1.在交叉引用列表中是否存在未引用過的變量？（如果編譯器建立了一個標識符交叉引用列表，那么對該列表進行檢查，查看是否有變量從未引用過，或僅被引用過一次。） 2.屬性列表是否與預期的相一致？（檢查變量的屬性，確保沒有賦予過不希望的默認屬性值。） 3.是否存在“警告”或“提示”信息？（程序編譯通過了，但存在“警告”或“提示”信息，檢查處理“警告”或“提示”信息。） 4.是否對輸入的合法性進行了檢查？ 5.是否遺漏了某個功能？

3.4代碼走查

代碼走查與代碼檢查很相似，都是以小組為單位進行代碼閱讀，是一系列規程和錯誤檢查技術的集合。代碼走查和代碼檢查大體相同，但是規程稍微有所不同，采用的錯誤檢查技術也不一樣。 相同點：開始的過程相同，參與者在走查會議的前幾天得到材料，這樣可以專心研究程序。 不同點：會議的規程不同，走查會議不僅閱讀程序或使用錯誤檢查列表，代碼走查的參與者“使用了計算機”。被指定為測試人員的那個人會帶著一些書面的測試用例（程序或模塊具有代表性的輸入集及預期的輸出集）來參加會議。在會議期間，每個測試用例都在人們腦中進行推演。程序的狀態記錄在紙張或白板上以供監視。

3.5桌面檢查

桌面檢查是人工查找錯誤的一種古老方法。可視為由單人進行的代碼檢查或代碼走查：由一個人閱讀程序，對照錯誤列表檢查程序，對程序推演測試數據。 缺點：效率低，原因一，它是一個完全沒有約束的過程。原因二，缺少小組中的相互促進作用。

3.6同行評審

同行評審是一種依據程序整體質量、可維護性、可擴展性、易用性和清晰性對匿名程序進行評價的技術。該項技術的目的是為程序員提供自我評價的手段。 執行過程：一個程序員擔任管理員，挑選6-20名相似背景的參與者（同為java程序員），每個參與者提供兩段自己編寫的程序（一段“最好的”，一段“最差的”），然后將所有程序隨機發給每個參與者（每人4段程序，兩段“最好”，兩段“最差”，參與者未知），進行評閱打分。評審結束后每個程序員會收到一個匿名評價表。（自己的兩段程序的評價表及自己評審的程序的評價與其他評審人對同一程序的評價情況。）

總結

以上是生活随笔為你收集整理的软件测试的艺术（二）的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。