上課第八章.ppt

潛在的介接問題 一個傳統系統的測試問題是「千夫所指(finger-pointing)」。 這發生在當某個錯誤被揭發時，每位系統元素的開發者都為此問題而責備其他的人。 軟體工程師應該預先考慮潛在的介接問題，和： 設計錯誤處理路徑以測試來自系統其他元素的資訊。 導入一系列的測試，模擬錯誤資料或在軟體介面的其他潛在的錯誤。 記錄測試的結果，如果千夫所指的情況確實發生時，可以使用做為「證據」。 參與系統測試的計畫與設計，以確保軟體充分地測試。 系統測試 系統測試(system testing)實際上是一系列不同的測試，其主要的目的是完整地操練這個以電腦為基礎的系統。 雖然每項測試都有一個不同的目的，所有的工作都是要驗證系統元素已經適當地整合，並實行所配置的功能。 13.6.1 恢復測試(Recovery Testing) 許多以電腦為基礎的系統必須要在預先指定的時間內從錯誤中恢復並重新處理。 某些案例中，系統必須是可容錯的(fault tolerant) 。 處理錯誤必須不能導致整體系統的功能終止。 在其他的案例中，系統的錯誤必須要在一段指定的時間之內改正，否則會發生嚴重的經濟損失。 恢復測試 恢復測試(recovery testing)是一種系統測試，它以各種方式迫使軟體失去作用，並驗證恢復能被適當地實施。 如果恢復是自動的(由系統本身實行)，重新初始化、檢查點機制(checkpoint mechanisms)、資料恢復和重新啟動等會被評估其正確性。 如果恢復需要人為的干預，則平均修復時間(mean-time-to-repair, MTTR)被用來評估，以決定它是否在可接受的限度中。 13.6.2 安全測試 任何管理敏感性的資訊或導致對個人不正當損害(或益處)動作的電腦系統都是非法侵入的目標。滲透跨越範圍廣大的活動：電腦駭客為了娛樂而嘗試滲透系統；不高興的員工嘗試滲透做為報復；不誠實的個人為了自己不法的獲益而嘗試滲透。 安全測試 安全測試(security testing)驗證建造於一個系統內的保護機制事實上是可以保護而不被滲透的。 引用Beizer的敘述： 「當然，系統的安全必須被測試，使得對於正面攻擊是無懈可擊的-但也必須要測試來自側面或後面的攻擊。」 進行系統滲透 在安全測試期間，測試者扮演想要滲透系統的角色。可以進行任何滲透！ 測試者要嘗試經由外部的手段取得密碼。 可以用設計破壞任何防衛建構的客製化軟體攻擊系統。 可以使系統不知所措，因而拒絕對其他的服務。 可能故意引起系統的錯誤，希望能在恢復期間進行滲透。 可能經由瀏覽不安全的資料，希望發現進入系統的關鍵。 給予充足的時間與資源，良好的安全測試終將滲透到系統中。 系統設計者的角色是讓滲透的花費遠超過所將獲得資訊的價值。 13.6.3 壓力測試(Stress Testing) 壓力測試是設計來對付程式不正常的情況。 基本上，執行壓力測試的測試者要問： 「在它失敗前，我們可以加速(crank)到多高？」 壓力測試 壓力測試(stress testing)以要求不正常數量、頻率或容積(volume)資源的方法執行一個系統。例如： 當其每秒的平均中斷數為一個或二個時，特別的測試可被設計成每秒產生十個中斷。 輸入資料的速率可能增加十倍，以決定輸入的功能將如何反應。 執行需要最大記憶或其他資源的測試案例。 設計可能會引起記憶體管理問題的測試案例。 產生可能引起磁碟駐留(disk-resident)資料過度搜尋(excessive hunting)的測試案例。 基本上，測試者嘗試使程式不知所措。 敏感度測試技術 壓力測試的變化是一種稱為敏感度測試(sensitivity testing)的技術。 在某些情形(最普遍出現在數學的演算法中)，包含在一個程式有效資料界限中的一個非常小的資料範圍，它可能導致極端的行為和甚至不正確的處理，或很大的效能衰退。 敏感度測試嘗試揭發有效輸入類型中可能造成不穩定或不正常處理的資料組合。 13.6.4 效能測試 對於即時與嵌入式系統，提供所需要的功能，但是不能符合效能需求的軟體是無法被接受的。 效能測試(performance testing)是設計在整合的系統環境中測試軟體執行時期(run-time)的效能。 效能測試發生在測試流程中所有各方面的步驟。 甚至在單元層級的測試導入時，個別模組的效能可能會被評估。 要到所有的系統元素都完全整合後，系統的真實效能才能確定。 量測儀器的使用 效能測試時常與壓力測試結合，並且經常需要硬體與軟體的測試儀器。 時常需要以嚴格的方式量測資源的利用(例如，處理器週期)。 外部的測試儀器可以監控執行的間歇(intervals)、在它們發生時記錄事件(例如中斷)和定期對機械的狀態進行取樣。 藉由使用儀器量測系統，測試者可以揭發