軟件測試之靜態測試

靜態測試包括代碼檢查、靜態結構分析、代碼質量度量等。它可以由人工進行，充分發揮人的邏輯思維優勢，也可以借助軟件工具自動進行。
代碼檢查 代碼檢查包括代碼走查、桌面檢查、代碼審查等，主要檢查代碼和設計的一致性，代碼對標準的遵循、可讀性，代碼的邏輯表達的正確性，代碼結構的合理性等方面；可以發現違背程序編寫標準的問題，程序中不安全、不明確和模糊的部分，找出程序中不可移植部分、違背程序編程風格的問題，包括變量檢查、命名和類型審查、程序邏輯審查、程序語法檢查和程序結構檢查等內容。
　　 在實際使用中，代碼檢查比動態測試更有效率，能快速找到缺陷，發現30%～70%的邏輯設計和編碼缺陷；代碼檢查看到的是問題本身而非征兆。但是代碼檢查非常耗費時間，而且代碼檢查需要知識和經驗的積累。代碼檢查應在編譯和動態測試之前進行，在檢查前，應準備好需求描述文檔、程序設計文檔、程序的源代碼清單、代碼編碼標準和代碼缺陷檢查表等。
　　 靜態結構分析 靜態結構分析主要是以圖形的方式表現程序的內部結構，例如函數調用關系圖、函數內部控制流圖。其中，函數調用關系圖以直觀的圖形方式描述一個應用程序中各個函數的調用和被調用關系；控制流圖顯示一個函數的邏輯結構，它由許多節點組成，一個節點代表一條語句或數條語句，連接結點的叫邊，邊表示節點間的控制流向。
檢查項：
* 代碼風格和規則審核
* 程序設計和結構的審核
* 業務邏輯的審核
走查、審查與技術復審手冊


靜態測試的要點：

3.挑選合適的復審員
復審活動人數控制在3-7個人，每次復審活動不要超過2小時，否則應該功能分解或者形式分解。準備充分的復審一小時以內完成。
疑問：每個公司的復審員是由誰來挑選的？
4.管理部門的參與
任何對使復審由只關注技術轉變為與人事產生關系的情況都應該避免。
技術經理分配復審給下面有潛力的員工是經理自己成長的必然之路。
為復審活動分配時間和資源
特殊情況關于時間、場地選取的一些建議。
IBM一個關于電話會議進行復審的一個案例。
6.復審活動啟動過程中的注意事項
結隊復審方法，對比結隊編程。 
10-12點是進行復審的完美時間，復審完成大家共進午餐可以幫助解決問題，想起新問題。
選擇那些不會引起爭論不休的內容作為每次初期復審對象。
對走查、審查和技術復審的活動指南進行復審，效果會很好。
復審規則：復審過程本身的目的是提出問題，而不是解決這些問題。
找一只愿意傾聽的耳朵，即使這樣，復審也會很有效果。（make sense on banian）
復審比培訓來得更有效，這是推廣新技術的好方法。
雙項目同時啟動，并且互相擔當復審主導的形式非常有效，還會有良性競爭出現。要求項目規模比較小。 
對復審領導進行工作中復審培訓一個月左右，10-16個領導就可以擔當一年內培養公司200名員工的任務。
正式復審與非正式復審的差距是由領導控制的，其中的靈活度，多少push，多少愉快的氣氛的培養正是做領導的藝術，也是他們拿那么多Money的原因。
認真去讀P58,沒再見過比這更好的比喻與闡述。
7.技術復審與項目管理
標準的項目管理示意圖：圖7-2
很多公司的模型是這樣：圖7-3，生產單元既是被告，又是法官。這顯然不make sense.
應該改成這樣的模型：圖7-4。
確定兩次復審之間的時間間隔的根據使你在完全失去對工作狀況的了解的情況下能夠堅持的最長時間。大多數這個時間是2-4個星期。
不管做什么都會犯錯誤，因此把錯誤犯在最安全的地方是一個不錯的策略，這也是復審活動“寧缺勿濫”的理由。
以隨即選定的方法對審核的工作進行抽樣，使會有風險的。盡量不要這么做。
8.復審領導
復審領導的工作是保證復審活動獲得成功- 或者是負責匯報復審活動未能獲得成功的原因。
未能成功原因比如：成員在材料充分的情況下依然沒有做好準備、預定的會議室發現泥水匠正在拆墻。
復審活動的成功與待復審產品的質量之間沒有必然聯系，復審領導不可能也不必承擔待復審產品的質量的責任，而只需對復審活動本身的質量負責。但一旦宣布檢驗出合格產品，他就獲得了一份對該產品因該承擔的責任。
復審領導應該有一些技術素質，至少應該精通開發的過程、使用的開發工具、現代的軟件方法，特別應該了解復審活動在整個開發過程中的位置。
對于復審領導的個人品質很難一概而論，一句話：結果比方式更重要。畢竟領導風格千千種，很難說那種是對是錯。
技術領導最糟糕的性格特點就是不能主動置身于他碰巧很感興趣的技術討論之外。一旦復審領

原文轉自：http://www.kjueaiud.com