評審在軟件質量保證中的地位
評審質量和進度
評審一般包括兩種類型：管理的和技術的，管理評審用于評估進度和建議糾正之中。它們
著眼于花費和計劃。管理評審是重要的，但是不是本書討論的主題。
技術評審也可用于評估進度，但是它要求技術進度是可評估的。這通常意味著以下二個問
題：（1）技術工作是否正在進行之中？（2）技術工作是否做得較好？以上問答是技術評審的副
產品。
檢 查
檢查是一種特殊類型的評審，它在錯誤檢查中被證明是行之有效的，并且和測
一種相對較為經濟的辦法。檢查方法由 Michael Fagan 所發明，并在 IBM 應用了
Fagan 將其出版發行。雖然任何評審方法都包括閱讀設計資料或代碼，檢查和走
觀是不同的：
· 檢查表將檢查者的注意力集中在過去所遇到的問題的領域中
· 檢查側重于錯誤檢查而不是糾錯
· 評審者在檢查之前應先舉行預備會議，而他們最后得出的問題應是經過共
· 所有的參加者被分配以不同的任務
· 檢查協調者并不是被檢查產品一方的人
· 協調者在協調檢查方面受過一定的訓練
· 每次檢查所得數據都被收集起來，以便反饋給今后的檢查以提高檢查質量
· 一般管理人員并不參加檢查會議，而技術主管則有可能參加會議
檢查概述
檢查表可使檢查員注意力集中在某一類錯誤上。由于檢查過程有標準的檢查表和標準的各
司其職的人員，它是一個有組織的過程。它也是一個自我優化過程，因為它使用有正規的反饋
循環以提高檢查表質量、監控準備和檢查速度。有了以上對過程的控制和優化，不管它怎樣開
始的，檢查很快就成為一種強有力的方法。軟件工程學會（SEI）已經定義了用于度量軟件開發
過程效率的技術標準。檢查過程表明了何為最高水平。同時，檢查過程應是有組織的、可重復
的，并能使用可度量反饋以提高檢查質量。你同樣可將本方法實際應用于本書所討論過的任何
技術中。在開發過程中將這些思想歸納起來，那么簡單地說，它們可使你所在機構向著最高質
量和生產率的層次進軍。
其它評審方法
普查
普查是一種流行的評審方法。普查這個詞定義并不嚴密，因為人們實際上可稱任何類型的
評審方法為“普查”。
由于普查定義不嚴密，所以也就很難對其給出確切的定義。當然，普查包括二人或多人討
論設計或代碼這種情況。普查可能就像即席的隨意探討會一樣不正式。有時它也可能像一個預
定的會議或送給管理者的總結報告一樣正規。在某種意義上講，“什么地方有兩或三個人聚在一
起”，什么地方就存在普查。普查方法的支持者贊成使用這樣一個寬松的定義。所以本文只打算
找出普查的一些共同之處，剩余的細節留給你自己去處理。
普查通常由接受評審的設計或代碼的主持者所采用。
· 普查的目的是為了提高程序的技術質量，而不是評估程序。
· 所有參與者通過閱讀設計或代碼為普查做準備并尋找錯誤。
· 普查可為老資格程序員向新手提供傳播經驗和合作精神的機會，它也為年輕的程序員
提出新方法，并向一些過時的結論挑戰提供機會。
· 普查通常需花費 30 到 60 分鐘的時間。
· 普查側重于發現錯誤，而不是糾正錯誤。
· 管理人員并不參加普查。
· 普查這個概念是靈活的，它也適應于特定的場合。
在排除錯誤方面，檢查比普查顯得更為有效。但是為什么有人愛用普查呢？
如果你擁有一個較大的評審組，普查不失為一種較好的評審方法，因為它給接受評審的程
序帶來多種不同的見解。如果所有參加普查的人都相信解答是正確的，就不會有大的缺陷。
如果有來自其它組織中的評審員，普查也可能是可行的。在檢查中，每個人的職責分工是
明確的，在人們有效地運用它們之前需要一個實踐過程，讓以前未曾參加過檢查的人當評審員
是不利的。如果你想讓他們出一份力，普查可能是最好的選擇。
檢查比普查更有所側重也能獲得更好的收獲。如果你想為所在組織選擇一個評審標準,在作出選擇之前好好考慮一下
代碼閱讀
代碼閱讀是對檢查和普查的另一種選擇。在代碼閱讀時，你能讀源代碼并尋找錯誤。你也
同時對代碼的質量如其設計、風格、可讀性、可維護性和有效性提出你的見解。
對美國宇航局軟件工程實驗室的一項研究表明，代碼閱讀平均每小時可發現 3.3 個錯誤。
調試平均每小時可發現 1.8 個錯誤（Card 1987）。代碼閱讀在軟件生存期中要比其它調試方式
多發現 20%到 60%的錯誤。
同普查一樣,代碼閱讀的定義并不嚴格。代碼閱讀通常是二人或多人各自閱讀代碼然后和代
碼的開發者一起討論。以下是閱讀的方法：
· 在開會之前，代碼開發者將源代碼分發給代碼閱讀者。代碼長度通常從 1000 到10000
行不等。典型的是 4000 行。
· 一個或多個人共同閱讀代碼。最少應有 2 個人，以便激勵在評審者間的競爭。如果你
使用的人數多于 2 個，你應度量每個人的貢獻，以便了解多余的幾個人究竟有多大的
貢獻。
· 評審者獨立地閱讀代碼。其速度大約是每天 1000 行。
· 當評審者完成代碼閱讀后，代碼開發者主持召開代碼閱讀討論會。會議持續時間為 1
個或 2 個小時，其側重點是代碼閱讀者所發現的問題。通常人們并不是一行一行通讀
代碼。本會議不是必需的。
· 代碼開發者確定由評審者所發現的錯誤。
代碼閱讀和檢查、普查的區別在于代碼閱讀側重于個人對代碼的評審,而不是著重于會議上
的討論。其結果是,評審者的時間大都花費在尋找代碼的問題了。這樣，花費在開會上的時間將
減少因為每人只需花費少部分時間在這上面。因為會議所花時間對一個中等組來說是可觀的。
除非各組員能在二小時內碰頭,開會耽擱的時間也少。代碼閱讀在當評審員不在一起時是相當有
價值的。
小 結
· 總的來說，評審在發現錯誤方面較測試要好。
· 評審側重于錯誤發現而不是糾錯。
· 評審往往比測試要能發現更多種不同的錯誤，意味著你應使用評審或調試方法以確保
軟件的質量。
· 使用檢查表、準備良好的分工、連續的處理以便最大限制地提高檢錯能力，檢查往往
較普查能發現更多的錯誤。
· 普查和代碼閱讀是檢查的候補方法。代碼閱讀可有效地利用每個人的時間。