簡介
在計算機系統中，執行錯誤檢測是指通過執行某種程式檢測計算機軟體和硬體錯誤。在實際套用，也有很多領域經常要執行錯誤檢測，例如發音學習系統中。執行錯誤檢測一般都是基於某種算法和策來實現檢測錯誤的意圖。
通信中執行錯誤檢測的方法
奇偶校驗位
奇偶校驗位（parity bit）是一種非常簡單的方案，可以用於檢測任何奇數個錯誤的發生。但如果發生的錯誤數量為偶數，則奇偶效驗位看上去是正確的。對奇偶效驗位的擴展和改變有縱向冗餘校驗、垂直冗餘檢查，以及雙或對角奇偶（在RAID-DP中使用）。
校驗和
校驗碼是傳送單元中各位的 和，用它可以使接收方檢測接收到 的數據是否正確。如果計算結果相 符，可以認為傳送過程結束。校驗 和是一個固定長度的數據塊，它是 作為密碼信息中每一位的函式而 產生的;用於校驗數據完整性或位 的和。TCP和用戶數據報協定 (UDP)通信都使用校驗和來檢測 傳送數據是否正確 。
循環冗餘校驗（CRC）
循環冗餘校驗（CRC）是一個非安全的散列函式，旨在檢測計算機網路中數字數據的意外變化。因此，它不適合檢測惡意引入的錯誤。循環碼有著非常適合檢測突發錯誤的有利特性。CRC尤其容易在硬體中實現，兵器因此常用在數字網路和諸如硬碟等存儲設備中。奇偶校驗是循環冗餘校驗的特殊案例，其中單比特CRC由除數x + 1生成。
加密散列函式
加密散列函式的輸出也稱訊息摘要，它可以提供強力的數據完整性保證，無論數據改變是偶然（例如由於傳輸錯誤）還是被惡意引入。對數據的任何修改都可用檢測散列值是否匹配判斷。此外，指出某些散列值並找到產生相同散列值的另一組輸入數據（原輸入數據除外）一般是不可行的。如果攻擊者不僅能改變訊息，還可以改變散列值，那么含密鑰散列或或訊息認證碼（MAC）可用於提供額外的安全性（即密鑰散列訊息認證碼）。在不了解密鑰的情況下，攻擊者不可能計算出結果正確的含密鑰散列值。
錯誤糾正碼
糾錯碼（error correcting code） ，是在接收端能自動地糾正數據傳輸中所發生差錯的碼。糾錯碼的基本思路是在所有的由傳送符號組成的序列中，僅挑出其中一部分做為信息的代表向信道傳送，並使得所挑出的這些序列之間有儘可能多的差異。每個被挑出的允許傳送的序列被稱為一個碼字，而碼字的總合稱為碼。在傳送端把信息變換成碼字的過程稱為編碼；在接收端從接收到的信號判定所發碼字、從而恢覆信息的過程稱為解碼（或解碼）。在解碼時，若收到的信號不是碼中的一個碼字，則可以肯定在傳輸中出現了差錯，從而著手對差錯進行糾正。糾錯的方法是找到與接收到的信號最接近的碼字，並將其判定為傳送信號。一般採用“距離”來度量信號間的接近程度，一種常用的“距離”稱為漢明距離，它被定義為兩碼字間對應位不同的個數總和。一個給定碼，其全部碼字兩兩之間距離的最小值被稱為這個碼的碼距。碼距是一個碼糾錯能力的重要參數，例如在漢明距離下，若接收到的信號出錯的位數不多於碼距的一半，則接收端總能正確地恢復所傳送的碼字，從而正確地恢復所傳送的信息。
糾錯編碼又稱信道編碼，它與信源編碼是信息傳輸的兩個方面。它們之間存在對偶的關係。套用信道解碼直接對一些自然信息進行處理，可以去掉剩餘度，以達到壓縮數據的目的。
為了使一種碼具有檢錯或糾錯能力，必須對原碼字增加多餘的碼元，以擴大碼字之間的差別，使一個碼字在一定數目內的碼元上發生錯誤時，不致錯成另一個碼字。準確地說，即把原碼字按某種規則變成有一定剩餘度的碼字，並使每個碼字的碼元間有一定的關係。關係的建立稱為編碼。碼字到達收端後，用編碼時所用的規則去檢驗。如果沒有錯誤，則原規則一定滿足，否則就不滿足。由此可以根據編碼規則是否滿足以判定有無錯誤。當不能滿足時，在可糾能力之內按一定的規則確定錯誤所在的位置，並予以糾正。糾錯並恢復原碼字的過程稱為解碼；碼元間的關係為線性時，稱為線性碼；否則稱為非線性碼。檢錯碼與其他手段結合使用，可以糾錯。檢錯反饋重發系統（ARQ系統）就是一例。
在構造糾錯碼時，將輸入信息分成 k位一組以進行編碼。若編出的校驗位僅與本組的信息位有關，則稱這樣的碼為分組碼。若不僅與本組的 k個信息位有關，而且與前若干組的信息位有關，則稱為格碼。這種碼之所以稱為格碼，是因為用圖形分析時它象籬笆或格架。線性格碼在運算時為卷積運算，所以叫卷積碼。
任何錯誤糾正碼都可用於錯誤檢測。最小漢明距離為d的編碼在碼字中最多可以檢測出d − 1個錯誤。如果對要檢測的最小錯誤數量有嚴格限制，使用基於最小距離的糾錯碼進行錯誤檢測則很合適。最小漢明距離d = 2的編碼是糾錯碼的退化情況，並可用於檢測單個錯誤。奇偶校驗位是單錯誤檢測的一個例子。
軟體中執行錯誤檢測的方法
軟體測試
為發現軟體中的錯誤而執行程式的過程。軟體測試只能用於查找程式中的錯誤，不能證明程式中沒有錯誤。由於測試的目標是暴露程式中的錯誤，從心理學角度看，由程式的編寫者自己進行全部測試是不恰當的，在綜合測試階段通常由其他人員組成的測試小組來完成測試工作。軟體測試是保證軟體質量的關鍵，它是對需求分析、設計和編碼的最後複審。因此，軟體工程要重視測試。軟體測試的方法一般有黑盒測試和白盒測試兩種。對於前者已經知道了軟體產品應該具有的功能，可通過測試來檢驗是否每個功能都能正常使用；對於後者，知道軟體產品內部工作過程，可以通過測試來檢驗產品內部動作是否按照規格說明書的規定正常進行。軟體測試過程與開發過程類似，必須分步驟進行，每個步驟在邏輯上是前一步驟(若有的話)的繼續，也是後一步驟(若有的話)的前提。大型軟體系統的測試基本上由模組測試、集成測試和驗收測試三個步驟組成 。
靜態程式分析
靜態程式分析（英語：Static program analysis）是指在不運行電腦程式的條件下，進行程式分析的方法。有些程式分析需要在程式運行時才能進行，這種程式分析稱為動態程式分析。大部分的靜態程式分析的對象是針對特定版本的原始碼，也有些靜態程式分析的對象是目標代碼。靜態程式分析一詞多半是指配合靜態程式分析工具進行的分析，人工進行的分析一般稱為程式理解或代碼審查。靜態程式分析的複雜程度依所使用的工具而異，簡單的只考慮個別敘述及宣告的行為，複雜的可以分析程式的完整原始碼。不同靜態程式分析產生的信息也有所不同，簡單的可以是標示可能的代碼錯誤（如lint），複雜的可以是形式化方法，也就是用數學的方式證明程式的某些行為匹配其設計規格。軟體度量和反向工程可以視為一種靜態程式分析的方式。在實務上，在定義所謂的軟體質量指針（software quality objectives）後，軟體度量的推導及程式分析常一起進行，在開發嵌入式系統時常會用這種方式進行。
