【正文】 機系統的一個組成部分 ， 在實際運行中 ， 它要和計算機系統的其它元素一起工作 ，所以最終要把軟件與其它系統元素結合起來 ， 進行一系列的集成測試和有效性測試 。 系統測試的目的在于通過與系統的需求定義作比較 ， 發(fā)現軟件與系統定義不符合或與之矛盾的地方 。 調試 調試的步驟 調試的策略 退出 調試過程由兩個部分組成：首先 ， 確定程序中錯誤的確切性質和位置；然后 ， 對程序代碼進行分析 ， 確定問題的原因 ， 并設法改正這個錯誤 。 具體地說 ， 由以下步驟組成： （ 1） 從錯誤的外部表現入手 ， 確定程序中出錯的位置； （ 2） 分析有關程序代碼 ， 找出錯誤的內在原因； （ 3） 修改程序代碼 ， 排除這個錯誤； （ 4） 重復進行暴露了這個錯誤的原始測試以及某些回歸測試 ， 以確保該錯誤確實被排除且沒有引入新的錯誤； （ 5） 如果所作的修正無效 ， 則撤消這次改動 ， 重復上述過程 ， 直到找到一個有效的辦法為止 。 調試的步驟 調試的策略 強行排錯 這是目前使用較多但效率較低的一種調試方法 。 具體地說 ， 通常有三種措施： （ 1） 輸出存儲器內容 （ 2）打印語句 （ 3）自動調試工具 回溯法 采用回溯法排錯時 ， 調試人員首先分析錯誤征兆 ， 確定最先出現 “ 癥狀 ” 的位置 。 然后人工沿程序的控制流程往回追蹤源程序代碼 ， 直到找到錯誤根源或確定錯誤產生的范圍為止 。 實踐證明 ， 回溯法是一種可以成功地用在小程序中的很好的糾錯方法 。 通過回溯 ， 我們往往可以把錯誤范圍縮小到程序中的一小段代碼 ，仔細分析這段代碼 ， 不難確定出錯的準確位置 。但是 ， 隨著程序規(guī)模的擴大 ， 由于回溯的路徑數目越來越多 ， 回溯法會變得很困難 ， 以至于完全不可能實現 。 歸納法 歸納法就是從線索 （ 錯誤征兆 ） 出發(fā) ， 通過分析這些線索之間的關系而找出故障的一種系統化的思考方法 。 這種方法主要包括下述四個步驟： （ 1） 收集有關的數據 （ 2） 組織數據 （ 3） 提出假設 （ 4） 證明假設 演繹法 演繹法從一般原理或前提出發(fā) ， 經過排除和精化的過程推導出結論 。 演繹法排錯的過程是這樣的：測試人員首先列出所有可能出錯的原因或假設 ， 然后再用原始測試數據或新的測試 ，逐個排除不可能正確的假設 ， 最后 ， 證明剩下的原因確實是錯誤的根源 。 列舉可能的原因排除不適當的原因對保留的假設繼續(xù)推斷有剩余 證明假設能 糾正錯誤沒有剩余收集更多的數據不能 軟件可靠性 軟件可靠性的定義 軟件正確性證明 退出 硬件可靠性可以用平均故障間隔時間 （ MTBF） 來測量： MTBF＝ MTTF十 MTTR 其中 ， MTTF和 MTTR分別是平均無故障時間和平均修復時間 。 軟件可靠性可以根據與技術系統可靠性接近的平行定義來表示 。 我們可以這樣來定義軟件可靠性：程序故障的頻率和臨界值 。 這里 ， 故障是指在許可的運行條件下一個不可接受的結果或行為 。 同硬件一樣 ， 軟件可靠性可以用錯誤出現和被糾正的速率來表示 。 軟件可靠性的定義 程序正確性證明是一項復雜的課題 ， 涉及到許多復雜的領域 。 采用諸如利用數學歸納法或謂詞演算的人工的正確性證明 ， 在評價小程序時可能有些價值 ， 但是在證明大型軟件的正確性時 ， 不僅工作量太大 ， 而且在證明的過程中也很容易引進一些新的錯誤 ， 因此并不實用 。 目前 ， 已經開發(fā)出了一些自動的計算機軟件正確性證明方法 。 自動的正確性證明程序一般涉及到程序邏輯的形式化描述 ， 這種描述可以由宏編譯程序來開發(fā) 。 宏編譯程序產生軟件的符號表示 ， 利用以人工智能理論和謂詞演算為基礎的自動化技術來 “ 證明 ” 程序的正確性 。 目前已經研究出了 PASCAL和 LISP等的正確性證明程序 ， 正在對這些系統進行評價和改進 。 這些系統目前還只能對較小的程序進行評價 。 程序正確性證明 測試工具 人工測試 自動測試工具 退出 （ 1） 檢查變量的交叉引用 （ 2） 檢查標號的交叉引用 （ 3） 檢查子程序 、 宏 、 函數 （ 4） 常量檢查 （ 5） 標準檢查 （ 6） 風格檢查 （ 7） 比較控制流 （ 8） 選擇 、 激活路徑 （ 9） 對照程序的規(guī)格說明 ， 詳細閱讀源代碼 （ 10） 補充文檔 人工測試 桌前檢查 代碼評審一般由三至五人組成小組 ， 成員組成包括：組長 ， 秘書和測試人員 。 首先，組長提前把設計規(guī)格說明書、控制流程圖、程序文本及有關要求、規(guī)范等分發(fā)給小組成員，作為評審的依據。小組成員要先充分閱讀這些材料，為評審會做好準備。第二步是召開程序審查會，首先由測試人員進行講解，其它成員可以提問并展開討論。通過講解和討論，可以暴露許多程序員以前沒有發(fā)現的錯誤。討論過程中不討論任何糾錯問題，主要是發(fā)現錯誤，否則違背了測試的目的。在代碼會審之后，需要把發(fā)現的錯誤登記造表，并交給程序員；若發(fā)現錯誤較多，或發(fā)現重大錯誤，則在改正之后，還要再次組織代碼會審。 代碼評審 走查與代碼評審基本相同 ， 但要求更加嚴格 。 其過程分為兩步： 第一步把有關材料先發(fā)給走查小組每個成員 ， 讓他們先認真閱讀材料 ， 準備好意見 。 第二步是開會 ， 開會的程序與代碼會審不同 ， 首先由測試組成員準備好一批有代表性的測試用例 ， 提交給走查小組 。 開會時 ， 集體扮演計算機角色 ， 讓測試用例沿程序的邏輯運行一遍 ， 并隨時記錄程序的蹤跡 ， 供分析和討論用 。 利用測試用例的媒介作用對程序的邏輯和功能提出各種疑問 ， 結合問題開展熱烈的討論和爭議 ， 能夠發(fā)現更多的問題 。 走查 （ 1） 靜態(tài)分析程序 （ 2） 斷言處理程序 （ 3） 測試數據生成程序 （ 4） 測試覆蓋監(jiān)視程序 （ 5） 測試處理程序 （ 6） 輸出比較程序 自動測試工具