靜態測試

靜態測試包括代碼檢查、靜態結構分析、代碼質量度量等。它可以由人工進行，充分發揮人的邏輯思維優勢，也可以藉助軟體工具自動進行。代碼檢查包括代碼走查、桌面檢查、代碼審查等，主要檢查代碼和設計的一致性，代碼對標準的遵循、可讀性，代碼的邏輯表達的正確性，代碼結構的合理性等方面；可以發現違背程序編寫標準的問題，程序中不安全、不明確和模糊的部分，找出程序中不可移植部分、違背程序編程風格的問題，包括變數檢查、命名和類型審查、程序邏輯審查、程序語法檢查和程序結構檢查等內容。

在實際使用中，代碼檢查比動態測試更有效率，能快速找到缺陷，發現30%～70%的邏輯設計和編碼缺陷；代碼檢查看到的是問題本身而非徵兆。但是代碼檢查非常耗費時間，而且代碼檢查需要知識和經驗的積累。代碼檢查應在編譯和動態測試之前進行，在檢查前，應準備好需求描述文檔、程序設計文檔、程序的源代碼清單、代碼編碼標準和代碼缺陷檢查表等。靜態測試具有的發現缺陷早、降低返工成本、復蓋重點和發現缺陷的概率高的優點以及耗時長、不能測試依賴和技術能力要求高的缺點。

“靜態測試”在學術文獻中的解釋：

1、靜態測試是指無須執行被測代碼，而是藉助專用的軟體測試工具評審軟體文檔或程序，度量程序靜態複雜度，檢查軟體是否符合編程標準，藉以發現編寫的程序的不足之處，減少錯誤出現的概率；

2、靜態測試是指測試不運行的部分：只是檢查和審閱，如規範測試、軟體模型測試、文檔測試等。動態測試是通常意義上的測試，也就是運行和使用軟體；

3、通過評審文檔、閱讀代碼等方式測試軟體稱為靜態測試，通過運行程序測試軟體稱為動態測試。在動態測試中，通常使用白盒測試和黑盒測試從不同的角度設計測試用例，查找軟體代碼中的錯誤；

4、靜態測試是指不用執行程序的測試，它主要採取方案—代碼走查、技術評審、代碼審查的方法對軟體產品進行測試。(t)稱為：時刻的瞬時利息率(是無風險利率)。

結構分析：

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

檢查項：代碼風格和規則審核；程序設計和結構的審核；業務邏輯的審核；走查、審查與技術複審手冊。

一個項目或者一個企業，如果要下決心實施軟體質量，實施軟體工程，第一步要做的就是軟體編碼規範。編碼規範是程序編寫過程中必須遵循的規則，一般會詳細規定代碼的語法規則、語法格式等。企業實施怎樣的編碼規範，取決於很多個因素：l編程採用的語言，例如C、C++、JAVA、ADA等。項目的規範化程度。目前現成的C/C++編碼規範有很多，例如前幾年網路上比較流行的《華為公司編程規範》、《摩托羅拉C+編程規範》等。但項目不能完全照搬，應該根據自己所處的階段，定製屬於自己的規範，否則的話，會讓程序員無所適從，嚴重打擊程序員的積極性。

不同的行業對軟體的可靠性有不同的要求，例如航空/航天的嵌入式軟體對代碼的要求很高，而傳統的windows平台應用軟體則相對要寬鬆。在嵌入式軟體中，尤其是汽車行業，國際上目前流行的C語言編程規則為MISRA-C:2004，其中包括包括141條規則，其中121條是強制（Required）遵守的，20條是建議（Advisory）遵守的。

有了統一的規範后，測試工程師或者程序員自身，就可以實施編碼規範檢查了。要真正把編碼規範貫徹下去，單單靠測試員程序員的熱情，很難堅持下去，所以筆者建議藉助於一些專業的工具來實施。在C/C++語言的編程規則檢查方面，比較專業的工具有Coverity，C++Test、LINT工具、KlocWork（Insight）/QAC/QAC++等，這些工具通常可以和比較流行的開發工具集成在一起，程序員在編碼過程中，在編譯代碼的同時即同時完成了編程規則的檢查。

有了嚴格的編程規範，只能算是萬里長征邁出了第一步。要提高軟體的可重用性，以及軟體的可維護性，還需要進一步的努力，即靜態質量度量。靜態質量度量所依據的標準是ISO9126。在該標準中，軟體的質量用以下幾個方面來衡量，即功能性(Functionality)、可靠性(Reliability)、可用性(Usability)、有效性(Efficiency)、可維護性（Maintainability）、可移植性(Portability)。以ISO9126質量模型為基礎，可以構造質量度量模型。具體到靜態測試，這裡主要關注的是可維護性。

要衡量軟體的可維護性，可以從四個方面去度量，即可分析性（Analyzability）、可改變性（Changeability）、穩定性（Stability）以及可測試性（Testability）。具體到軟體的可測試性怎麼去衡量。又可以從三個度量元去考慮，例如圈複雜度、輸入/輸出的個數等。圈複雜度越大，說明代碼中的路徑越多；路徑越多，意味著要去做測試，需要寫更多的測試用例。輸入/輸出的個數同樣的道理。在具體的實踐中，專門的質量度量工具是必要的。沒有工具的支持，這一步很難只靠人工完成。在這個階段，比較專業的工具有Testbed、Logiscope等。

在傳統意義上認為，錯誤檢測應該是動態的系統測試的範圍。但在bug的成本上分析，有以下公認的結論。

bug發現的越晚，修正的成本就越高，測試階段修正bug的成本是編碼階段的約4倍的關係。為了減少成本，bug被發現的越早越好。在編程階段，靜態的分析代碼就能找到代碼的bug，是很多人的夢想。這個夢想在21世紀初變成了現實。以PolySpace、Klocwork、Coverity為代表的靜態分析軟體，實現了只要靜態分析代碼，就可以發現代碼的bug，例如數組越界、除數為0、緩衝區溢出等，雖然還不是特別完美。微軟在其最新的開發工具VisualStudio2005的teamsystemediton中集成了安全工具PREFix。PREFix原來就是著名的靜態分析工具，后被微軟收購過來。從微軟的傾向看發展走勢，類似的靜態工具未來會成為市場的主流。PolySpace詳細的信息可以參考另外一篇文章《嵌入式軟體動態運行時錯誤的檢測》。

複審活動人數控制在3-7個人，每次複審活動不要超過2小時，否則應該功能分解或者形式分解。準備充分的複審一小時以內完成。

任何對使複審由只關注技術轉變為與人事產生關係的情況都應該避免。技術經理分配複審給下面有潛力的員工是經理自己成長的必然之路。為複審活動分配時間和資源，特殊情況關於時間、場地選取的一些建議。IBM一個關於電話會議進行複審的一個案例。

結隊複審方法，對比結隊編程。10-12點是進行複審的完美時間，複審完成大家共進午餐可以幫助解決問題，想起新問題。選擇那些不會引起爭論不休的內容作為每次初期複審對象。對走查、審查和技術複審的活動指南進行複審，效果會很好。複審規則：複審過程本身的目的是提出問題，而不是解決這些問題。找一隻願意傾聽的耳朵，即使這樣，複審也會很有效果。（makesenseonbanian）複審比培訓來得更有效，這是推廣新技術的好方法。雙項目同時啟動，並且互相擔當複審主導的形式非常有效，還會有良性競爭出現。要求項目規模比較小。對複審領導進行工作中複審培訓一個月左右，10-16個領導就可以擔當一年內培養公司200名員工的任務。正式複審與非正式複審的差距是由領導控制的，其中的靈活度，多少push，多少愉快的氣氛的培養正是做領導的藝術，也是他們拿那麼多Money的原因。

確定兩次複審之間的時間間隔的根據在完全失去對工作狀況的了解的情況下能夠堅持的最長時間。大多數這個時間是2-4個星期。不管做什麼都會犯錯誤，因此把錯誤犯在最安全的地方是一個不錯的策略，這也是複審活動“寧缺勿濫”的理由。以隨即選定的方法對審核的工作進行抽樣，使會有風險的。盡量不要這麼做。

複審領導的工作是保證複審活動獲得成功-或者是負責彙報複審活動未能獲得成功的原因。未能成功原因比如：成員在材料充分的情況下依然沒有做好準備、預定的會議室發現泥水匠正在拆牆。複審活動的成功與待複審產品的質量之間沒有必然聯繫，複審領導不可能也不必承擔待複審產品的質量的責任，而只需對複審活動本身的質量負責。但一旦宣布檢驗出合格產品，他就獲得了一份對該產品因該承擔的責任。複審領導應該有一些技術素質，至少應該精通開發的過程、使用的開發工具、現代的軟體方法，特別應該了解複審活動在整個開發過程中的位置。對於複審領導的個人品質很難一概而論，一句話：結果比方式更重要。畢竟領導風格千千種，很難說那種是對是錯。技術領導最糟糕的性格特點就是不能主動置身於他碰巧很感興趣的技術討論之外。告訴那些以自己缺乏管理經驗為由拒絕出任複審領導的“專業程序員”，這次複審正是他提高技能的絕好的鍛煉機會。實際上，多人都可以勝任這個職位，確實是個不錯的鍛煉機會。

任何可能因為職位的原因引起利益衝突的人都不應該出現在複審現場，所以，領導對自己的團隊進行複審應該儘力避免。複審活動前，複審領導應該準備好充分的文檔，並在會議當天應用CheckList檢查是否符合開會條件。會議中要確保準備充分的參加者能夠有時間闡述自己意見，否則以後的會議之前沒人會認真準備。如果複審偏離主題，複審領導首先要做的是，留心觀察這次跑題是否是某些成員掩蓋其缺乏準備的一個詭計。如果不是，提醒大家注意本次會議的目的。如果還不行，可以直接介入，公開終止對技術細節的討論，還要告訴記錄員把它記下來。如果再有人沒有停下來，提醒他本次會議的目的是提出問題，而不是解決問題。他的意見會被紀錄，複審會議后解決問題時再被討論。如果真的有人蓄意妨礙，複審領導可以宣布這次會議不再有建設性而終止會議。並且記錄你認為終止會議的真正原因上報，還要同事做好為自己做辯護的準備。對於沒有勇氣直接發言的靦腆成員可以直接提問題給他，沒有人會害羞到不能回答直接提問的地步。據說“專家就是在自己犯了大錯誤的過程中還在挑剔別人小錯誤的人”。複審領導應該保證複審組中沒有這樣的專家。如果再次複審的原因的成員的準備不夠充分，那麼下次進行複審還應該是原班人馬。關於如何鼓勵複審組成員有勇氣職責別人的工作，可以要求每人分別給出一個正面評價和一個負面評價。把批評儀式化，這樣有利於得到真實正確的建議。如何對待遲到早退，這是每個領導一直會遇到的問題，可以參考溫伯格的意見，也可以自按照從前的經驗來。如果找麻煩的人想重新設計這個產品以“是他變得更好”，可以打斷她，然後要求他提出一些“是產品變的更糟”的辦法。這會增加一些幽默的氣氛，同時讓他們看到該產品並非遭到一無是處，進而讓他們知道他們的意見不怎麼樣。溫伯格是如何控制開會的公共議程與每個人自己的私人議程：其中包含一個小的實驗，驗證會議每個人的真實私人議程。要求每個人說出材料中是否有遺漏是一個檢查這個人對材料是否準備好了的好辦法。只要牢記一條簡單的規則，複審領導就能輕鬆些的結束會議，那就是：作為複審領導，保證複審的高效率。如果認為這個目標沒法實現，則終止這次複審。

記錄員的首要職責是為確保複審報告的準確性提供信息。最好使用活動掛圖，投影等方式使得記錄員的即時記錄信息能被大家同時看到。或者用高級可列印白板。最好不要使用錄像機在正式的場合，會導致某些人不自然，而且複審會議也不需要那麼大的信息量。不要讓複審領導同時擔當記錄員，首先它會在進行記錄的時候失去對會議的控制，其次，記錄原有很大權利，很容易忘記或者多記一些內容，因此要使用分權這一屢試不爽的辦法。不要懷疑，任何人都可以作為記錄員，因此可以自己進行調度。還可以在會議開始的時候依次問詢大家對這次複審的意見，挑選在某的session沒什麼話好說的人作為這個session的記錄員。確信會議中的任何人都可以很方便的看到記錄，尤其是複審領導。當自己在做記錄員並且有話要說的時候，把筆或者電腦交給身邊的人。每個被安排為記錄員的成員需要去檢查CheckList。

準備好工作。不要掩飾。要樂意合作。時刻注意自己評審的是產品而不是同事，任何人都可能犯錯。注意語言。不要以“為什麼”開頭，最好用“不明白…”。正面和負面的評價。實在沒有正面的評價可以“喜歡用來評審的水筆的顏色。”提出問題，但不要解決問題。可以在吃午飯的時候討論解決方案。不要討論風格。要遵循標準否則就扔掉它。只允許有技術能力的人參加複審。不是排斥技術新人，是為避免政治目的的人。所有的問題都要公開記錄。堅持討論技術問題。不要忘了教育。不要評價生產者。要儘早分發複審報告。讓生產者決定他們的產品接受複審的時間。否則就是浪費時間。

要表現出對複審過程的信任。要為複審過程安排時間。要做好準備讓真正合適的人去參加複審。鼓勵複審活動的參與者做好準備工作。要幫忙解決會場問題。不要小事聰明大事糊塗。要獎勵那些發現劣質產品的優質複審不管產品怎樣，一定要懲罰所有的劣質複審要懲罰糟糕的複審行為。推翻複審決定只會讓自己擔風險。

缺乏技術能力，不能為複審做出貢獻的人不該出現在複審現場。生產者通常會試圖讓自己不能理解他們那些絕妙的產品而感到自卑，這是需要站穩立場，讓他們在問題列表上寫下這樣的語句：“用戶代表不能理解。”