5-靜態測試的理解

• 1 介紹
• 2 靜態測試技術
• • 2.1 代碼檢查
  • • 2.1.1 代碼走查
    • 2.1.2 編碼風格與規范
    • 2.1.3 審查
    • • 2.1.3.1 代碼審查和代碼走查
      • 2.1.3.2 代碼審查清單
  • 2.2 靜態結構分析
  • 2.3 代碼質量度量

1 介紹

• 靜態測試包括包括代碼檢查、靜態結構分析、代碼質量度量等。
• 它可以由人工進行，充分發揮人的邏輯思維優勢，也可以借助軟件工具自動進行。
• 動態測試在完成靜態測試之后進行，這樣，就需要設計一系列的測試用例來確保測試的完整性和有效性，而在測試用例的設計中，通常會把白盒測試和黑盒測試結合起來使用。

2 靜態測試技術

靜態測試是指不運行程序進行的測試–只是檢查和審閱。靜態測試包括包括代碼檢查、靜態結構分析、代碼質量度量等。

2.1 代碼檢查

• 代碼檢查包括代碼走查、代碼審查等，主要檢查代碼和設計的一致性，代碼對標準的遵循、可讀性，代碼的邏輯表達的正確性，代碼結構的合理性等方面；
• 可以發現違背程序編寫標準的問題，程序中不安全、不明確和模糊的部分，找出程序中不可移植部分、違背程序編程風格的問題，包括變量檢查、命名和類型審查、程序邏輯審查、程序語法檢查和程序結構檢查等內容。

2.1.1 代碼走查

代碼走查的一個問題是全部的代碼是否都需要走查，在實踐中，通常是不可行的，測試者必須找到那些必須要走查的代碼，例如，由于在將來的版本中引入缺陷的風險，由于維護階段的費用很高，將會留下一些代碼或者隨機檢查，或者按照優先權次序。

代碼走查過程中的最大的問題是勸說開發者要遵循一定的標準，開發人員對于代碼走查可能會有這樣的態度：我寫的代碼為什么要別人批評我寫代碼的方式。代碼走查要采用一個公認的標準以便所有人都能夠同意接受它的要求，所有這些都要小心選擇并能夠全面反映團隊的工作環境。

正規的走查是把代碼打印出來，邀請別的同行開會檢查代碼的缺陷。但這種方法太耗時間，所以一般在走查會議上各開發人員自己講解自己的邏輯、寫法，讓別人提意見。在編碼階段這種會議有助于大家了解整個項目情況，也有助力于各開發人員及早發現問題。

2.1.2 編碼風格與規范

在程序設計中要使程序結構合理、清晰，形成良好的編程習慣，對程序的要求不僅是可以在機器上執行，給出正確的結果，而且要便于程序的調試和維護，這就要求編寫的程序不僅自己看得懂，而且也要讓別人能看懂。有時候會出現過了一年半載，連編程者自己也讀不懂程序的情況。程序如同一篇文章，應該易于被人看懂，讀起來流暢，必要時又容易修改，可以從源程序代碼中得到提示從哪里修改。好的程序設計風格有助于提高程序的正確性、可讀性、可維護性、可用性。

好的風格對于好的程序設計具有關鍵性作用。寫好一個程序，當然需要使它符合語法規則、修正其中的錯誤和使它運行得足夠快，但是實際應該做的遠比這多得多。一個寫得好的程序比那些寫得差的程序更容易讀、更容易修改。經過了如何寫好程序的訓練，生產的代碼更可能是正確的。

程序設計風格的原則根源于由實際經驗中得到的常識，它不是隨意的規則或者處方。代碼應該是清楚的和簡單的-------具有直截了當的邏輯、自然的表達式、通行的語言使用方式。

2.1.3 審查

2.1.3.1 代碼審查和代碼走查

代碼審查是提高代碼質量的良藥。但良藥苦口，也有很多問題。

沒有習慣代碼審查的開發員的心理抵觸。當指出代碼中的問題時，很多程序員會感到難堪。特別是不直接影響程序功能的代碼，比如，不良代碼風格。另外，現在的軟件開發常常是多人維護的，如果不良代碼是別人寫的，總感覺象代人受過一樣。這時，不得不反復說明，代碼審查目的是幫助找到問題，而不是針對個人。

如果代碼審查沒有目標，則很容易使得代碼審查變得很無趣，變成了程序邏輯報告會。通常，在代碼審查之前，先確定一個審查目標，比如今天主要看代碼風格，或安全問題等。這樣容易找出問題。如果能事先通報一個檢查列表，審查之前表態：今天主要審查這些條目，那會更有效。

2.1.3.2 代碼審查清單

這個清單只對結構化編程測試具有意義，不包括特殊應用領域和面向對象軟件的測試。

• 數據引用錯誤

是指使用未經正確初始化用法和引用方式的變量、常量、數組、字符串或記錄而導致的軟件缺陷。如：變量未初始化、數組和字符串下標越界、對數組的下標操作遺漏[0]、變量與賦值類型不一致、引用的指針未分配內存。

• 數據聲明錯誤

數據聲明軟件缺陷產生的原因是不正確的聲明或使用變量和常量。

• 計算錯誤

計算或者運算錯誤是基本的數學邏輯問題。計算無法得到預期結果。如：不同數據類型或數據類型相同但長度不同的變量計算、計算過程中或計算結果溢出、賦值的目的變量上界小于賦值表達式的值、除數/模為0、變量的值超過有意義的范圍（如概率的計算結果不在0－1范圍內）。

• 比較錯誤

小于、大于、等于、不等于、真、假。比較和判斷錯誤很可能是邊界條件問題。如：混淆小于和小于等于、邏輯表達式中的操作數不是邏輯值。

• 控制流程錯誤

控制流程錯誤的原因是編程語言中循環等控制結構未按預期方式工作。通常由計算或者比較錯誤直接或間接造成。如：模塊或循環無法終止、存在從未執行的代碼、由于變量賦值錯誤而意外進入循環。

• 子程序參數錯誤

子程序參數錯誤的來源是軟件子程序不正確的傳遞數據。如：實際傳送的參數類型或次序與定義不一致、更改了僅作為輸入值的參數。

• 輸出錯誤

包括文件讀取、接受鍵盤或者鼠標輸入以及向打印機或者屏幕等輸出設備寫入錯誤。如：軟件沒有嚴格遵守外部設備讀寫數據的專用格式、文件或外設不存在或者為準備好的錯誤情況發生時沒有相應處理、未以預期的方式處理預計錯誤、錯誤提示信息不正確/不準確。

• 其他檢查

軟件是否使用其他外語？處理字符集的范圍（ASCII或Unicode）？是否需要移植？是否考慮兼容性？編譯時是否產生警告或提示信息？

2.2 靜態結構分析

• 靜態結構分析主要是以圖形的方式表現程序的內部結構，例如函數調用關系圖、函數內部控制流圖。
• 函數調用關系圖以直觀的圖形方式描述一個應用程序中各個函數的調用和被調用關系；
• 控制流圖顯示一個函數的邏輯結構，它由許多節點組成，一個節點代表一條語句或數條語句，連接結點的叫邊，邊表示節點間的控制流向。

2.3 代碼質量度量

ISO/IEC 9126國際標準所定義的軟件質量包括六個方面：功能性、可靠性、易用性、效率、可維護性和可移植性。軟件的質量是軟件屬性的各種標準度量的組合。

---

【特別說明】：知識來源于網絡、各種資料、書本、網站等，本文僅用于學習使用，不做他用，如果涉及版權問題，請聯系博主刪除，謝謝

總結

以上是生活随笔為你收集整理的软件测试基础理论体系学习5-静态测试的理解的全部內容，希望文章能夠幫你解決所遇到的問題。

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