白箱测试、黑箱测试「白箱测试」有时称为「玻璃箱测试」是内（66页）.pptxVIP

;軟體測試Software Testing;P17-14迴圈複雜性--應改為--循環複雜性---較好。 P17-16圖17.4中line14,25中的D999--999. P17-17Line1:16.4.1--17.4.1 p17-17圖17.5 (7)--(8) P17-17行7，…加上1… P17-20圖17.7 2-1應下一行。 P17-25 Line 10:USE(S)={...} P17-34等量劃分---應改為--等價分割---較好！ p17-38倒7行(1,1,2,1)~和(1,1,1,3)應刪去。…. P17-39 P2 p1;軟體系統的發展包含了一系列的產品活動， 其中由人類所造成錯誤機會相當的多。錯誤可 能在一開始的定義階段…，也可能在最後的設 計階段…。由於人類無法完美地工作及溝通， 因此軟體發展過程中必須伴隨品質保證的活動。 由於軟體在系統中的地位愈來愈重要，軟體失敗所付出的的代價，也相對提高！所以常常有30~40%的花費是投資在軟體測試上！甚至於可能花費其他工程步驟總和的三到五倍(80%以上) ！！(如飛航管制、 核能反應監督系統);測試在軟體工程程序中，可視為是一個「破壞性」而不是建設性的步驟！！ 只要寫程式就可能需要除錯，即使用結構化程式設計、由上而下、決策表、非常小心、非常嚴僅的寫法，仍可能會出錯！ 所以最好是有測試專家來加入軟體工程。 測試只能證明「錯誤存在」，而無法顯示是沒有錯誤及沒有瑕疵的！;[MYE79]的測試目標法則： 1.測試是為了現錯誤而執行程式的過程。 2.好的測試案例具有極高可能性發現尚未發的錯誤。 3.成功的測試可發現尚未暴露的錯誤！ 希望可設計出一種測試，能用最少的時間與精力，以便可以有系統的發現各種錯誤！ 若滿足上述目標，則： 第一優點是：可發現軟體中的錯誤。 第二優點是：在標準規格下運作正常，而且能夠滿足所需的績效！;在[DAV95]建議了一些測試原則： 所有的測試應源自於客戶的需求：測試時，最嚴重的缺失(以客戶觀點)就是無法滿足用戶的需求。 測試應該在測試開始之前規劃好：測試可在程式面產生前就計畫好。 將Pareto原則應用於軟體測試：Pareto原則 「80%的錯誤可能來至於所有程式模組的20%」所以要努力隔離這些可疑的模組，?對之作完整的測試。;4.測試應由小處作起，而漸漸往大處發展：(參考Fig18-1)應先作單元測試，再作整合、系統… 5.繁重的測試是不可能的：“路徑”的排列組 合數量，是太大的！所以雖然不可能全測完， 但應儘可能妥善的涵蓋程式來確認所有狀況！ (※參考17.6.5--正交陣列測試) 6.為了達到“有效”，測試應由獨立的協力廠 商來執行(independent third party)：因為系統建立者不會故意留下bug！也就不易發現自己的bug， 所以不是最佳的測試人員！;軟體工程師在設計系統、產品時，不能忘記“測試性”，因為將使測試案例設計者，更容易設計 出測試案例！ 在[James Bach1994]軟體測試性係指“測試電腦程式”的難易程度。因為測試也是很困難，所以如何提高它的效率是要付出代價的！ 如果程式設計師願意作一些事情來輔助測試程序而可能的設計點、特性的清單對此是有用的。 “測試性”是良好設計的結果！;可用的：它工作地愈好，則愈能有效率地被測試。 (※若錯誤很多，那進行中的測試將會被迫暫停！而且錯誤多，則測試的報告也變得更多！) 可見的：你所看見的正是你所測試的。(※每一輸入可對應出明顯的輸出，若異常輸入，也易被辨識。最好有異動記錄…) 可控制的：我們愈能控制軟體，則愈能使測試自動化與最佳化。(※測試才可輕易被指定、易自動化…) 可分解的：經由控制測試的範圍，我們可更快速地隔離問題?更聰明地再次執行測試。 簡易性：測試的項目愈少，則測試速度就愈快。(※結構簡明，才較易限制錯誤的擴散…) 穩定性：改變愈少，測試就愈少中斷。 可瞭解的：擁有的資訊愈多，則我們愈能聰明地測;好的測試具有發現錯誤較高的機率。 好的測試?不會太冗長。---應該能把握住重點！(因為實際的完整樣本往往都太多了！例如 SaftHome的密碼若設為8080，而且已準備測試1234的錯誤 試驗，然後，1235,...應可跳過，但8081,8090...因為與正確密碼很接近，所以是重要測試而不是多餘的測試！) 好的測試應是“最好的訓練”。 好的測試不應太簡單或太複雜。;測試的目的在發現什麼？;誰來測試軟體？;測試案例設計(Test Case Design);任何工業產品均能以兩種方式之一來作測試： 測試功能的黑箱測試。 (2)測試內部細節的白箱測試。 其中黑箱是對軟體界面的測試，也可用來表達軟體功能是否正確。 白箱因為要對程序細節作仔細檢查，所以須要有原始碼。 ※白箱測