軟體工程/質量/程式碼檢查簡介
在軟體工程中，檢查是指由經過培訓的個人對任何工作產品進行同行評審，他們使用定義良好的流程尋找缺陷。檢查也可能被稱為Fagan檢查，以Michael Fagan的名字命名，他是非常流行的軟體檢查流程的創造者。
檢查是軟體專案中最常見的審查實踐之一。檢查的目標是讓所有檢查者就工作產品達成共識，並批准其在專案中的使用。通常檢查的工作產品包括軟體需求規格說明和測試計劃。在檢查中，選擇一個工作產品進行審查，並召集一個團隊進行檢查會議以審查該工作產品。選擇一名主持人來主持會議。每個檢查者在會議前都要閱讀工作產品，並記錄每個缺陷。檢查的目的是識別缺陷。在檢查中，缺陷是指工作產品的任何部分，會阻止檢查者批准它。例如，如果團隊正在檢查軟體需求規格說明，每個缺陷將是文件中檢查者不同意的文字。
檢查流程是由Michael Fagan在20世紀70年代中期開發的，後來被擴充套件和修改。
該流程應具有確定是否可以開始檢查流程的准入標準。這可以防止未完成的工作產品進入檢查流程。准入標準可能是一個清單，其中包括“文件已拼寫檢查”等專案。
檢查流程中的階段包括：計劃、概述會議、準備、檢查會議、返工和跟蹤。準備、檢查會議和返工階段可能會被迭代。
- 計劃： 檢查由主持人計劃。
- 概述會議： 作者描述工作產品的背景。
- 準備： 每個檢查者檢查工作產品以識別可能的缺陷。
- 檢查會議： 在此會議期間，閱讀者逐部分閱讀工作產品，檢查者指出每個部分的缺陷。
- 返工： 作者根據檢查會議的行動計劃修改工作產品。
- 跟蹤： 檢查作者的更改以確保一切正確。
主持人會在檢查滿足某些預定義的退出標準時結束檢查流程。
在檢查期間，使用以下角色。
- 作者： 建立正在檢查的工作產品的人員。
- 主持人： 這是檢查的領導者。主持人計劃並協調檢查。
- 閱讀者： 逐項閱讀文件的人員。其他檢查者會指出缺陷。
- 記錄者/抄寫員： 記錄檢查期間發現的缺陷的人員。
- 檢查者： 檢查工作產品以識別可能的缺陷的人員。
程式碼審查可以作為一種特殊的檢查來完成，其中團隊檢查程式碼樣本並修復其中的任何缺陷。在程式碼審查中，缺陷是指沒有正確實現其要求的程式碼塊，沒有按照程式設計師預期的方式執行，或者不是錯誤的，但可以改進（例如，可以使其更易讀或可以改進其效能）。除了幫助團隊查詢和修復錯誤外，程式碼審查還有助於跨培訓程式設計師審查的程式碼以及幫助初級開發人員學習新的程式設計技術。
同行評審被認為是軟體工程的最佳實踐，可以儘早發現軟體缺陷並瞭解軟體工件。同行評審包括軟體演練和軟體檢查，是軟體產品工程活動不可或缺的一部分。協調的知識、技能和行為的集合促成了同行評審的最佳實踐。同行評審的要素包括結構化的評審流程、卓越的產品清單標準、參與者的定義角色以及表格和報告。
軟體檢查是同行評審中最嚴格的形式，在檢測缺陷時充分利用了這些要素。軟體演練選擇性地利用這些要素來幫助生產者獲得對工件的最深入理解，並在參與者之間達成共識。衡量結果表明，同行評審產生了透過加速學習和早期缺陷檢測獲得的具有吸引力的投資回報。為了獲得最佳結果，同行評審是在整個組織中透過定義的計劃實施的，該計劃包括制定政策和程式、培訓從業人員和管理人員、定義度量並填充資料庫結構以及維持實施基礎設施。
- 審查和檢查實踐
- 文章軟體檢查由Ron Radice撰寫
- 不同檢查和審查技術的比較