5-靜態(tài)測試的理解

• 1 介紹
• 2 靜態(tài)測試技術
• • 2.1 代碼檢查
  • • 2.1.1 代碼走查
    • 2.1.2 編碼風格與規(guī)范
    • 2.1.3 審查
    • • 2.1.3.1 代碼審查和代碼走查
      • 2.1.3.2 代碼審查清單
  • 2.2 靜態(tài)結(jié)構(gòu)分析
  • 2.3 代碼質(zhì)量度量

1 介紹

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

2 靜態(tài)測試技術

靜態(tài)測試是指不運行程序進行的測試–只是檢查和審閱。靜態(tài)測試包括包括代碼檢查、靜態(tài)結(jié)構(gòu)分析、代碼質(zhì)量度量等。

2.1 代碼檢查

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

2.1.1 代碼走查

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

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

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

2.1.2 編碼風格與規(guī)范

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

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

程序設計風格的原則根源于由實際經(jīng)驗中得到的常識，它不是隨意的規(guī)則或者處方。代碼應該是清楚的和簡單的-------具有直截了當?shù)倪壿嫛⒆匀坏谋磉_式、通行的語言使用方式。

2.1.3 審查

2.1.3.1 代碼審查和代碼走查

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

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

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

2.1.3.2 代碼審查清單

這個清單只對結(jié)構(gòu)化編程測試具有意義，不包括特殊應用領域和面向?qū)ο筌浖臏y試。

• 數(shù)據(jù)引用錯誤

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

• 數(shù)據(jù)聲明錯誤

數(shù)據(jù)聲明軟件缺陷產(chǎn)生的原因是不正確的聲明或使用變量和常量。

• 計算錯誤

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

• 比較錯誤

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

• 控制流程錯誤

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

• 子程序參數(shù)錯誤

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

• 輸出錯誤

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

• 其他檢查

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

2.2 靜態(tài)結(jié)構(gòu)分析

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

2.3 代碼質(zhì)量度量

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

---

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

總結(jié)

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

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。