可信赖的软体开发课件

可信賴的軟體開發 1 n可信賴度 n關鍵系統規格 n可信賴的軟體開發 n驗證與確認 n測試 2 可信賴度 nDependability n使用者信任某個關鍵系統的程度 3 概念 n就關鍵系統而言，系統的可信賴度是最重 要的系統特性。 n系統的可信賴度反映了使用者對於系統信 任的程度 n它也反映了使用者的信心程度，也就是它 的操作能達到使用者的期待，而且在正常使用 情況下不會造成當機。 n有用(usefulness)和信任(trustworthiness)是不 同的意思 n一個不可靠的系統可能會很有用。 4 可信賴度的涵蓋範圍 5 可維護性 nMaintainability 是一種系統的屬性，表示在 電腦故障或是變更系統以納入新特性時， 系統是否容易修復。 n這項屬性對於關鍵系統非常重要，因為維 護的問題經常會讓系統發生錯誤。 n可維護性與可信賴度的其他涵蓋範圍不同 ，它是靜態而非動態的系統屬性，故本章 先不討論它。 6 存活能力 nSurvivability n在面對已知或意外的侵害時，系統仍然能 夠繼續傳送服務給使用者的一種能力。 n對安全性可以妥協的分散式系統而言，存 活能力是越來越重要的屬性。 nSurvivability包含恢復的觀念 - 即不管元件 是否故障，系統仍然能夠繼續操作的能力 。 7 成本與可信賴度曲線 8 可信賴度成本 n當可信賴度的程度逐漸增加時，可信賴度 成本也會呈指數增加。 n上述情形的生成原因有兩個: n為了達到較高程度的可信賴度，必須使用 越來越多昂貴的開發技術和硬體。 n為了達到要求的可信賴程度，必須增加能 夠讓系統用戶信服的測試與系統驗證。 9 可信賴度與執行效能 n使用者可能會拒絕使用不可靠的系統 n系統發生錯誤所造的成本可能會很大 n要調整一系統讓它更可被信賴是很困難的 n系統執行效能的缺失比較容易彌補 n不可靠的系統可能會造成有價值的資料的 遺失 10 可信賴度的經濟因素 n因為達成可信賴度的成本非常高，因此有 時候接受不可靠的系統而付出系統故障的 成本可能會比較合乎經濟效益。 n然而，這些都必須視社會和政治的因素而 定。產品的聲譽如果不值得信賴的話，就 有可能會喪失未來的商機。 n根據系統類型的不同會有程度不同的可信 賴度可適用，尤其是對商業系統而言。 11 可用性和可靠性 n可靠性(Reliability) n表示在某段時間內，於某個給定的環境中 ，針對特定的目的而執行的操作不發生錯誤的 機率。 n可用性(Availability) n表示在某個時間點能夠操作和提供服務要 求的機率。 n可靠性和可用性這兩種屬性可以用量化的 方式表示。 12 可用性和可靠性 n某些情況下，可用性可能會包含於可靠性 之中。 n很明顯的，如果系統無法使用就不能提供 指定的系統服務。 n可能會有某一種系統，它的可靠度很低但 必須能夠被使用。只要系統的故障可以馬 上被修復而不會損壞到資料，可靠度低可 能不會構成問題。 n可用性需將修復時間列入考慮。 13 可用性和可靠性 n可靠性的正式定義並不一定都反映了使用 者對系統可靠性的認知 n對系統使用環境的假設可能不正確 n某系統在辦公室環境中的用法可能和大 學環境裡的用法完全不同。 n系統故障的結果對可靠性的認知有所影響 n汽車上不可靠的雨刷若在乾燥氣候地區 可能沒有什麼關係。 n影響嚴重的系統故障(例如車子引擎拋錨 )對使用者來說比只引起不方便的故障要來得重要 。 14 可用性和可靠性 n可靠性的達成 n避免錯誤(Fault avoidance) n利用開發的技術減少錯誤發生的機率， 或在這些錯誤引發系統故障之前找出錯誤之所在 。 n錯誤偵測和移除(Fault detection and removal) n使用確認與認證的技術增加錯誤發現的 機會，並且在系統使用之前更正這些錯誤。 n容錯(Fault tolerance) n使用一些技術以確保這些系統缺陷不會 讓系統出錯，且(或)確保系統錯誤不會造成系統 故障 15 可靠性的改善 n移除系統中X%的錯誤移除並不一定就能相 對地對可靠度改善X%。 n程式的缺陷也許是很少使用的部分程式碼 ，所以使用者可能不會碰到這種情形。將 這些程式碼移除並不會影響到使用者對可 靠性的感受。 n因此，某個帶有已知缺陷的程式也許仍然 會被使用者認為是具有可靠性的。 16 安全性 n安全性(Safety)也是系統的一項屬性，它能 夠反映出系統正常或不正常的運作能力， 是否不會危害到人體或系統環境。 n軟體的安全性考量越來越重要，因為越來 越多的設備都加入了以軟體為主的控制系 統。 n安全性的需求是一種排除性的需求，亦即 它是排除不理想的情況，而不是指定所需 的系統服務。 17 安全性和可靠性 n系統的安全性和可靠性互有關係但也有所 區別 n一般來說，可靠性和可用性是系統所需但 卻不足以構成系統安全性的條件。 n可靠性必須符合定義的規格以及提供的服 務。 n不管安全性是否符合規格，它必須確保系 統不會造成傷害。 18 不安全但可靠的系統 n規格錯誤 n如果系統規格不正確，系統可能會按照訂 定的規格運作，但是仍然可能會導致意外的事 故發生。 n硬體故障產生不正確的輸入 n很難預先在規格中發現 n與環境有關的指令，亦即在不當時機發出 正確的指令 n通常是操作錯誤所產生的結果 19 安全性的達成 nHazard avoidance n將系統設計成讓某些類別的危險不致發生 。 nHazard detection and removal n將系統設計成可以在發生意外之前偵測到 危險並且將它移除。 nDamage limitation n在系統中包含保護功能並且降低意外所導 致的損害。 20 21 保全性 n系統的保全性(security)也是一種系統特性 ，它能夠反映系統保護自己免於受到意外 或外來攻擊的能力。 n由於大部分系統都已接上網路，外部可以 透過網際網路對系統進行存取，所以保全 性也變得日益重要。 n保全性是可用性、可靠性和安全性最重要 的先決條件。 22 基本的保全性 n如果系統是連接網路但保全性不夠，那麼 有關它的可靠性和安全性的敘述就都不可 信賴。 n這些敘述是對運作中的系統而言，但是對 開發的系統也是相同的。外來的侵入會變 更運作中的系統和(或)系統的資料。 n因此，可靠性和安全性的保證就不再有效 。 23 確保保全性的方法 n避免弱點 n將系統設計成可以避開弱點的系統。例如，如果 系統不和外界網路相連，那麼就不會遭受到外來的攻 擊。 n偵測與移除攻擊 n將系統設計成可以偵測外來攻擊並且能在資料外 洩之前移除此攻擊。例如，病毒檢查程式可以發現病 毒並且在感染系統之前將病毒移除。 n限制資料曝光 n將系統設計成可以把遭受攻擊後的不良後果降低 。例如，用備份方式將受損的資料復原。 24 25 26 關鍵系統規格 27 功能性和非功能性需求 n系統的功能性需求可以用來定義錯誤查核 與復原機制及與功能，以提供對系統發生 故障的保護措施。 n非功能性需求可以用來定義系統必需的可 靠度(reliability)和可用性(availability)。 28 系統可靠度規格 n硬體可靠度(Hardware reliability) n硬體元件故障的可能性以及修復該元件所 需的時間。 n軟體可靠度(Software reliability) n軟體元件產生不正確輸出的可能性。軟體 故障不同於硬體故障，軟體不會用太久而損壞 。在產生不正確的結果之後，它還是能夠繼續 正常地操作。 n操作員可靠度(Operator reliability) n系統操作員製造錯誤的可能性。 29 系統可靠度工程 n它是系統工程中的一個子領域，專門研究 系統可靠度的評估。 n它必須考慮到系統中各種不同元件的故障 率。 n例如，某個系統有兩個元件A和B，A的故 障率為P(A)，B的故障率為P(B)。 30 故障機率 n如果系統只有這兩個元件，而且系統的操 作也依賴這兩個元件，那麼系統的故障機 率為: nP(S) = P(A) + P(B) n元件數量越多，系統整體故障機率也會越 高。 n如果是一群相同的複製元件，整體故障率 為: nP(S) = P(A)n (所有元件都發生故障) 31 功能性的可靠度需求 n系統必須預先定義操作員可能輸入的所 有輸入值範圍，系統也應該檢查操作員 的所有輸入是否符合預先定義的範圍。 n做為初始化程序的一部分，系統應該檢 查所有磁碟是否有壞掉的區塊。 n系統應該使用N版的程式設計來實作煞 車控制系統。 n系統必須以Ada的安全子集來實作，並 且使用靜態分析方式做檢查。 32 n系統可靠度需求的程度應該量化表示。 n可靠度是一個動態的系統屬性，所以若以 原始碼來定義可靠度規格是沒有意義的。 n軟體的錯誤應該在每1000行中不超過N個 錯誤。 n非功能性的可靠度規格只有在產品完成後 的分析時才有用，通常會用來評估你的開發技 術有多好。 n整體的系統可靠度必須選擇適合的可靠度 度量指標(reliability metric)。 非功能性的可靠度規格 33 n可靠度度量指標是測量系統可靠度的單位 。 n系統可靠度是以計算操作的故障次數來衡 量，而這些都與對系統的要求以及系統上 線運作的時間有關。 n關鍵系統的可靠度必須以長期的測量程式 來測量。 可靠度度量指標(量測值) 34 可靠度度量指標 量測值說明 POFOD 服務故障率 當使用者提出服務要求時，系統失敗而無法提供服 務的可能性。若POFOD為0.001，表示一千個服務 要求中可能會有一次發生故障。 ROCOF 出錯率 非預期行為可能發生的頻率，若ROCOF為2/100， 表示每100個操作時間單位內可能會有2次的故障發 生。這個量測值有時候稱為故障強度。 MTTF 平均故障時間 系統發生故障的平均時間。若MTTF為500，表示每 500個時間單位可以預期的會出現一次故障。 AVAIL 可用率 系統在某個給定時間可否使用的機率。若可用率為 0.998，表示每1000個時間單位內，系統可以使用的 時間有998個時間單位。 35 可用率(Availability) n系統在某段時間可否使用的比率 n必須考慮修復與重新啟動的時間 n可用率0.998表示每1000個時間單位內，系 統可以使用的時間有998個單位 n常用於不停機、連續運作的系統 n電話交換系統、鐵路號誌系統 36 服務故障率(POFOD) n系統無法提供使用者提出之服務要求的可 能性。這個度量指標在服務要求為間歇性 ，且不常發生的情況下最有用。 n適合用在偶爾有服務要求，且若無法提供 服務則會造成嚴重後果的系統保護上。 n適合許多具例外管理元件的安全關鍵系統 。 n例如，化工廠的緊急關機系統 37 出錯率(ROCOF) n系統發生故障的機率。 n若ROCOF為0.002，表示每100個操作時間 單位內可能會有2次的故障發生，例如每 1000小時操作時間中發生2次故障。 n適合需要處理大量且經常發生類似要求的 作業系統或異動處理系統。 n例如，信用卡處理系統、機票預訂系統 38 平均故障時間(MTTF) n每個故障發生之間的間隔時間。在一個穩 定的系統中這個度量指標與服務故障率 (ROCOF)成反比。 n若MTTF為500，表示每500個時間單位內 故障與故障之間的平均時間。 n適合應用於具有長時間異動的系統，也就 是需要花很長時間處理的系統。MTTF應 該會比異動時間更長。 n例如，設計師需要花費數小時使用的電腦 輔助設計系統以及文書處理系統。 39 故障的後果 n可靠度的量測並沒有考慮故障的後果。 n暫時的故障不會有真正的結果，但是其他 的故障可能會引起資料的流失或損壞以及 喪失系統的服務功能。 n可能需要識別出不同的故障類別，並且使 用不同的度量指標來識別。同時也必須建 立可靠度的規格。 40 故障的後果 n在規定可靠度時不只要看系統發生的故障 次數，而且要看這些故障造成的後果。 n有嚴重後果的故障比可修復和復原的故障 有更大的損害。 n因而，在某些情況下必須為不同的故障類 型定義不同的可靠度規格。 41 故障類型 故障類型說明 暫時(Transient)只有在輸入某些值時才會發生 永久(Permanent)所有輸入值均會發生 可復原(Recoverable)不用操作人員介入系統可以自行復原 不可復原 (Unrecoverable) 需要由操作人員介入才能從故障中復原 無毀損(Non-corrupting)故障不會毀損系統狀態或資料 毀損(Corrupting)故障會毀損系統狀態或資料 42 n針對每個子系統分析可能故障的後果。 n將系統故障分析的結果做適當的分類。 n對每一種故障類別使用適當的可靠度度量 指標定出它的可靠度。對於不同的可靠度 需求也可以使用不同的度量指標。 n找出功能性的可靠度需求以降低關鍵故障 的機會。 建立可靠度規格的步驟 43 銀行自動櫃員機系統 n網路上的每部機器每天大約使用300次 n銀行有1000部這樣的機器 n軟體的壽命為兩年 n每部機器大約可以處理200,000筆交易 n每天大約有300,000筆資料庫交易要處理 44 可靠度規格的範例 故障類別範例可靠度量測值 永久、無毀損系統無法處理輸入的任何卡， 軟體必須重新啟動才能修正這 個故障。 ROCOF 1次/1000天 暫時、無毀損輸入沒有受損的卡片，但是系 統無法讀取卡片上的磁帶資料 。 ROCOF 1000次交易中出現1 次 暫時、毀損某種跨網路的交易模式造成資 料庫的毀損 不合格的！系統的壽 命期限內不應該發生 45 規格確認 n極高的可靠度規格不可能憑使用經驗來確 認。 n不能有資料庫的損毀表示POFOD在2億個 交易中必須小於1 。 n如果每筆交易需花一秒，那麼模擬網路上 一天的交易量大約要花3.5天。 n因此，若要測試系統的可靠度可能必須花 比系統壽命更長的時間。 46 重點整理 n可信賴度需求分為功能性和非功能性兩種 。 n非功能性的可用率和可靠度需求必須以量 化來表示。 n可以使用的度量指標有AVAIL、 POFOD 、 ROCOF 和 MTTF。 n在制定可靠度規格時，不同錯誤類型所產 生的後果也必須列入考慮。 47 安全規格 n系統的安全需求必須分開規定。 n這些需求應該以可能的危險和風險分析為 基礎。 n安全需求通常應用於整體系統而不是個別 的子系統。在系統工程名詞中，系統的安 全性是一個突顯的性質。 48 安全生命週期 Ian Sommerville 2000Dependable systems specification Slide 49 49 安全程序 n危險和風險分析(Hazard and risk analysis) n評估和系統有關的損壞危險和風險 n安全需求規格(Safety requirements specification) n規定一套應用於系統的安全需求 n安全關鍵系統的指定(Designation of safety-critical systems) n找出不正確操作會危及系統安全的子系統。在理 想壯況下，這些子系統應該只佔整個系統的一小部分 。 n安全確認(Safety validation) n檢查整體的系統安全 50 危險和風險分析 51 n找出會發生並危及系統安全的危險，以及 評估與這些危險有關的風險。 n建立不同類別的危險分析，並且徹底執行 規格到實作的軟體程序。 n對每個識別出的危險都應該執行風險分析 並加以記錄，並且採取必要動作以確保最 嚴重與可能發生的危險不會造成意外。 危險和風險分析 52 危險分析程序 n危險識別(Hazard identification) n找出可能出現的危險 n風險分析和危險分類(Risk analysis and hazard classification) n評估和每個危險有關的風險 n危險分解(Hazard decomposition) n分解危險以找出它們可能的根本原因 n降低風險的評估(Risk reduction assessment) n定義設計系統時如何將每一個危險列入考 慮 53 n危險分析的方法是從一個識別出來的故障 開始追溯錯誤的原因。 n它可以用在危險分析的各個階段，從初步 的分析到詳細的軟體檢查階段均可。 n屬由由上而下的危險分析方法。它也可以 和由下而上的分析方法併用，由下而上的 方法是從系統故障開始尋找危險的地方。 故障樹分析 54 故障樹分析 n找出危險。 n找出危險可能的原因。通常有一些其他原 因。在故障樹上使用or和and來連 結這些原因。 n繼續分析直到找出根本原因為止。 n下列的例子是有關一些正在進行備份處理 的系統，可能發生資料流失的情形。 55 風險評估 n評估危險的嚴重性、危險的可能性以及意外事故 的可能性。 n風險評估的結果是一份可接受度敘述，分為： n無法忍受(Intolerable)：必須永不發生或造成意外 事故。 n盡可能降低危險(As low as reasonably practical, ALARP)：在給定的成本與時間限制下必須降低危險 的可能性。 n可接受(Acceptable)：危險的結果是可接受的，而 且不需增加成本來降低危險的可能性。 56 風險等級 57 風險可接受度 n風險可接受度(acceptability)是由人、社會、 政治 等因素所決定。 n各個可接受度區域的界線已經漸漸往下移動，也 就是說社會大眾已經較不願意接受風險。 n例如，清除污染情況的費用可能比安裝污染防治 系統更便宜，但是卻可能不會被社會大眾所接受。 n風險評估是主觀的 n風險的情況是以可能、不可能來判定， 但是這樣的評估方式會因人而異。 58 降低風險 n系統應該指定規格，以避免發生危險和意外事 故。 n避免危險(Hazard avoidance) n系統必須設計成在正確的運作期間不會發生危險 。 n偵測與移除危險(Hazard detection and removal) n系統必須設計成可以能夠在產生意外事故發生之 前偵測並制止危險。 n限制損害程度(Damage limitation) n系統必須設計成能夠將意外事故的後果降到最低 。 59 規定禁止的行為 n系統不應該允許使用者修改不是他建立的 任何檔案之存取權限。(保全性) n在飛機飛行途中，系統不應該允許操作人 員選擇反轉推進模式。(安全性) n系統不應該允許同時有超過三個警報訊號 被啟動。(安全性) 60 保全規格 n保全需求規格有些和安全需求規格一樣 n不可能用量化來規定保全需求 n保全需求通常是規定不應該而不是 應該的需求 n差異點 n保全管理的保全壽命期沒有很好的概念定 義 n它面臨的是廣泛的威脅而不是系統特定的 危險 n雖然有成熟的保全技術(例如加密)，但是 很難將它們移轉成通用的情況。 61 保全規格制定程序 62 保全規格制定階段 n資產識別與預估 n識別資產(資料和程式)與它們需保護的程度。 所需保護的程度依據資產的價值而定，所以一個密 碼檔案通常比一堆公開網頁更有價值。 n威脅分析與風險評估 n識別對保全上可能的威脅，並且預估這些威脅 相關的風險。 n威脅指定 n識別出與資產有關的威脅，並且為每項識別出 的資產列出一連串相關的威脅。 63 保全規格制定階段 n技術分析 n評估可用的保全技術以及對已識別威脅的 適用性。 n保全需求規格 n指定保全需求規格。在適當的時機明確地 辨認出可能用來保護系統免於不同威脅的一些 保全技術。 64 65 軟體的可信賴度(dependability) n一般來說，軟體客戶期望所有的軟體都是 可信賴的。但是，對於非關鍵應用程式而 言，它們可能願意接受某種小的系統故障 。 n然而，某些應用程式確有極高的可信賴度 需求，必須使用特殊的程式技術來達到這 個需求。 66 可信賴度的達成 n避免錯誤(Fault avoidance) n軟體的開發應該避免人為的錯誤而將系統 錯誤減到最少 n開發程序應該被建構成可以偵查軟體中的 錯誤，並且在錯誤傳送給客戶之前予以修復 n容錯(Fault tolerance) n軟體應該被設計成軟體的錯誤不會造成系 統的故障 67 錯誤最小化 n最新的軟體工程方法可以開發出無錯誤 (fault-free)的軟體。 n無錯誤軟體是指符合規格的軟體，但並不 代表軟體會永遠正確的運作，因為規格也 可能會發生錯誤。 n生產無錯誤軟體的費用非常高，只有在特 殊的情況下才會符合成本效益。如果接受 軟體錯誤則會比較便宜。 68 錯誤移除成本 69 無錯誤的軟體開發 n需要一個精確的(最好是正規的)規格。 n需要一個重視品質的公司文化。 n以資訊隱藏和封裝為主的軟體設計。 n應該使用強式型別和執行時期檢查功能的 程式語言。 n應該避免容易出錯的程式設計結構。 n可信賴和可重複的開發程序。 70 結構化程式設計 n最早於1970年代被提出討論 n不使用goto敘述的程式設計 n程式中的控制結構只能使用迴圈和 If 敘述 n由上而下的設計 n重要的概念，因為它推動了程式設計的概 念和相關的討論 n可產生易讀且易了解的程式 71 容易錯誤的結構 n浮點數 n原本就不是很精確，所以不精確的浮點數會導致 無效的比較。 n指標 n參考到錯誤記憶體區域的指標會損毀資料，別 名(Aliasing)技術會讓程式很難理解及變更。 n動態記憶體配置 n在執行時期配置記憶體可能會造成記憶體溢位(用 完)。 n平行處理 n因為很難預知平行程序之間在時序上的互動情形 ，平行處理會造成難以捉摸的時序錯誤。 72 容易錯誤的結構 n遞廻(Recursion) n遞廻中的錯誤會造成記憶體溢位。 n中斷 n中斷會引起某個關鍵操作被終止，且使程 式很難被了解。 它們可比得上goto敘述。 n繼承 n相關的程式碼不會全部放在同一個地方， 在進行程式變更時會引起非預期的行為，使得 行為更難以理解。 n這些結構不須避免但必須謹慎使用。 73 資訊隱藏 n資訊只能洩漏給那些需要存取資訊的部份程式。 此動作包含物件或抽象資料型別的建立，它們是 用來保存狀態和對狀態的操作。 n基於下列三個理由，資訊隱藏可以避免錯誤的發 生： n資訊被意外損壞的可能性。 n資訊是以防火牆被保護住，所以問題較不可 能蔓延到程式的其他部分。 n因為所有資訊不會全部放在同一個地方，所以程 式設計師較不可能出錯，而審核者則較可能發現錯誤 。 74 可靠的軟體程序 n為了確保最少的軟體錯誤，擁有良好定義 且可重複執行的軟體程序是很重要的。 n一個有良好定義的可重複執行程序是完全 不依賴個人的技巧，也不會由不同的人來 詮釋。 n為了達到錯誤最小化，很明顯的程序活動 必須包含重要的確認和驗證動作。 75 76 容錯(Fault tolerance) n在重要的情況下，軟體系統必須能夠容錯 。在高可用率需求或系統故障成本極高的 情形下，都需要有容錯的機制。 n容錯是指不管軟體是否故障，系統都能夠 繼續運作。 n即使系統為不會發生錯誤的系統，它也必 須有容錯機制，因為也許會有規格的錯誤 或是確認有誤的情形發生。 77 容錯 n錯誤偵測(Fault detection) n系統必須能夠偵測錯誤(不正確的系統狀態)是否 發生。 n損害評估(Damage assessment) n已受到錯誤影響的系統狀態部分必須能夠被偵測 出來。 n錯誤復原(Fault recovery) n系統必須能夠回復到已知的安全狀態。 n錯誤修復(Fault repair) n系統可以被修改使錯誤不再復發。因為許多軟體 錯誤都只是短暫的狀態，所以通常不需要錯誤修復。 78 容錯的方法 n防禦式程式設計(Defensive programming) n程式設計師先假設系統的程式碼有錯誤然 後加入重複的程式碼，檢查修改後的系統狀態 ，以確認狀態的改變是否一致。 n容錯架構(Fault-tolerant architectures) n包含能支援硬體和軟體備援的硬體和軟體 系統架構，以及一個能偵測問題和支援錯誤復 原的容錯控制器。 n上述這兩個方法是互補的，不是互相對立 的技術。 79 例外管理 n一個程式的例外狀況(exception)是一個錯誤 或一些意外的事件，例如電源發生故障。 n例外狀況的處理結構可以處理這些事件， 而不用持續檢查系統狀態來偵測這些例外 狀況。 n使用正常控制結構在一連串巢狀程序呼叫 中偵測例外狀況時需要加入許多額外敘述 與處理時間。 80 81 驗證與確認 n保證軟體系統符合使用者的 需求 82 靜態與動態驗證 n軟體檢查( Software inspections) 與分析靜態 系統的表示方式來發現問題有關(靜態驗證 ) n可使用文件和原始碼的分析工具來輔助 n軟體測試( Software testing) 與實作完成的 軟體並檢視其輸出行為有關(動態驗證) n提供測試資料實作系統，並檢視其操作過 程是否按照預期的行為執行 83 程式測試 n能夠揭示錯誤存在而非不存在 n能夠發現一個或一個以上的錯誤便是成功 的測試 n這是對非功能性需求唯一的確認技術 n應該與靜態驗證合併使用以擴大 V&V的涵 蓋範圍 84 測試的類別 n缺失測試 (Defect testing) n設計測試案例找出系統缺失 . n成功的缺失測試是能揭露出系統中的缺失 . n將在第20章中將介紹這一類測試 n統計測試 (Statistical testing) n設計測試案例反映使用者的輸入頻率. n用於可靠度預估(reliability estimation). n將在第21章中將介紹這一類測試 85 測試與除錯 n缺失測試和除錯是不同的處理程序 n驗證與確認著重於讓程式的缺失得以浮現 n除錯著重於找出缺失並加以改正 n除錯需要先界定出與程式執行行為有關的 假設，再分別測試這些假設以找出系統錯 誤 86 軟體測試 n測試系統常用的部分比測試只是偶而使用 到的部分還重要 n等價分割是產生不同群的測試案例，對於 同一群的測試案例，程式會以相同的方式 來執行其行為 n黑箱測試主要是參考系統規格 n結構測試是以執行程式的所有路徑來決定 測試案