軟體檢查

(重定向自軟體檢測

軟體檢查是針對軟體工作文件的同行評審,由受過訓練的人員進行,有事先定義的程序,目的是要找到軟體中的缺陷。有一種正式的軟體檢查法,稱為范根检查法,得名自創建者Michael Fagan。

介紹

軟體檢查是在軟體專案中最常見的評審活動。檢查的目的是為了識別缺陷。常見檢查的工作文件包括有需求分析以及測試計劃英语test plan。檢查時會選定一份文件,並且會召集成員開會來進行檢查. 會選定主持人來主持會議,每一個參與的檢查者會閱讀工作文件,標示其中的缺陷。檢查過程中的「缺陷」是指檢查者認為有問題,無法通過的文件內容。例如在檢查軟體需求規格時,「缺陷」就是檢查者不同意的需求文件內容。

檢查流程

檢查流程一開始是在1970年代中期發展[1],後來也有延展以及修改。

流程中需要有進入準則,確認大家是否已預備好進入檢查流程。這可以避免未完成的工作文件進入檢查流程。進入準則可能是一份查檢表,其中包括許多項目,例如「文件中使用的拼字正確。」

檢查流程中的各階段包括有:計劃、簡介會議、準備、檢查會議、修正及追蹤。其中的準備、檢查會議和修正可能會重複幾次。

  • 計劃(Planning):由主持人針對檢查進行規劃。
  • 簡介會議(Overview meeting):作者說明工作文件的背景。
  • 準備(Preparation):所有的檢查者檢查工作文件,看其中是否有缺陷 。
  • 檢查會議(Inspection meeting):在會議中朗讀者將工作文件的各部份唸出,檢查者指出各部份的缺陷。
  • 修正(Rework):作者依檢查會議的行動計劃修正工作文件。
  • 追蹤(Follow-up):檢查作者所做的所有修改,確認全部正確。

當流程滿足事先定義的結束準則時,主持人即可結束檢查流程。 「檢查」是在軟體工程專案執行過程中,很重要的一部份。

檢查的角色

在檢查過程中,會有以下的角色。

  • 作者:建立待檢查工作文件的人。
  • 主持人:領導檢查流程的人,主持人規劃檢查流程,並且進行協調。
  • 朗讀者:朗讀整份文件的人,一次讀出一部份,其他的檢查者會指出有缺陷之處。
  • 記錄:在檢查過程中記錄大家找到缺陷的人。
  • 檢查者:檢查工作文件中是否有缺陷的人。

相關的檢查類型

代码审查

代码审查也可以用軟體檢查的方式進行,由團隊來檢查程式碼,並且設法找出缺陷。在代码审查過程中,缺陷是指沒有正確實現需求的程式,沒有依設計者預期方式執行的程式,或是沒有不對,但還可以再進行改善的程式(例如可以提高可讀性,或是提昇其計算速度)。代码审查除了幫助團隊找到缺陷並且修正缺陷,在審查程式碼時,程式設計者也可以彼此訓練,新進的程式設計者也可以學習新的程式設計技巧。

同行評審

軟體同行評審是可以提早找到軟體缺陷,並學習軟體文件(artifact)的最佳實務之一。同行評審是由許多的Walkthrough和軟體檢查所組成,是軟體產品工作活動之一。有許多有組織的知識、技術以及行為有助於同行評審的最佳實務。同行評審的元素包括了結構化的檢查流程、傑出產品查檢表的標準、已定義的成員角色、表單以及報告。

軟體檢查是最嚴謹的同行評審方式,會充份使用這些元素來尋找軟體缺陷。軟體Walkthrough(走察)會選擇性的使用這些元素,協助參與者對軟體文件有更深入的瞭解,也讓參與者可以達成共識。由測量結果看出,同行評審可以加速學習,並且可以提早找到缺陷,這些投資回報十分值得。最好的情形下,同行評審是在組織中透過事先定義的計劃來達到的,計劃中包括有政策和程序的準備,訓練參與者和管理者、定義測量以及資料庫結構,並且持續維持這些基礎設施。

相關條目

參考資料

  1. ^ IBM Technical Report RC 21457 Log 96856 April 26, 1999.