軟件工程中有至關部分是關於軟件測試的:安全
一、測試概念的範疇工具
廣義上講,測試是指軟件產品生存週期內全部的檢查、評審和確認活動。如:設計評審、系統測試。性能
狹義上講,測試是對軟件產品質量的檢驗和評價。它一方面檢查軟件產品質量中存在的質量問題,同時對產品質量進行客觀的評價。單元測試
二、測試的目的測試
簡單地說,就是替用戶受過,測試的最終目的是確保最終交給用戶的產品的功能符合用戶的需求,把儘量多的問題在產品交給用戶以前發現並改正。在可接受的開銷下,提升對軟件的信心。設計
具體地講,測試通常要達到下列目標:接口
1) 確保產品完成了它所承諾或公佈的功能,而且全部用戶能夠訪問到的功能都有明確的書面說明------在某種意義上與ISO9001是同一種思想。最後,書面文檔的不健全甚至不正確,也是測試工做中遇到的最大和最頭痛的問題,它的直接後果是測試效率低下、測試目標不明確、測試範圍不充分,從而致使最終測試的做用不能充分發揮、測試效果不理想。生命週期
2) 確保產品知足性能和效率的要求事務
使用起來系統運行效率低(性能低)、或用戶界面不友好、用戶操做不方便(效率低)的產品不能說是一個有競爭力的產品。用戶最關心的不是你的技術有多先進、功能有多強大,而是他能從這些技術、這些功能中獲得多少好處。也就是說,用戶關心的是他能從中取出多少,而不是你已經放進去多少。資源
3) 確保產品是健壯的和適應用戶環境的
健壯性即穩定性,是產品質量的基本要求,尤爲對於一個用於事務關鍵或時間關鍵的工做環境中。另外就是不能假設用戶的環境(某些項目可能除外)。
三、 測試的原則---GoodEnough
對於相對複雜的產品或系統來講,zero-bug是一種理想,good-enough是咱們的原則。
Good-enough原則就是一種權衡投入 / 產出比的原則:不充分的測試是不負責任的;過度的測試是一種資源的浪費,一樣也是一種不負責任的表現。咱們的操做困難在於:如何界定什麼樣的測試是不充分的,什麼樣的測試是過度的。目前情況惟一可用的答案是:制定最低測試經過標準和測試內容,而後具體問題具體分析。
四、 測試的規律----木桶原理和80-20原則
1) 木桶原理。
在軟件產品生產方面就是全面質量管理(TQM)的概念。產品質量的關鍵因素是分析、設計和實現,測試應該是融於其中的補充檢查手段,其餘管理、支持、甚至文化因素也會影響最終產品的質量。應該說,測試是提升產品質量的必要條件,也是提升產品質量最直接、最快捷的手段,但決不是一種根本手段。反過來講,若是將提升產品質量的砝碼所有押在測試上,那將是一個恐怖而漫長的災難。
2) Bug的80-20原則。
通常狀況下,在分析、設計、實現階段的複審和測試工做可以發現和避免80%的Bug,而系統測試又能找出其他Bug中的80%,最後的5%的Bug可能只有在用戶的大範圍、長時間使用後纔會曝露出來。由於測試只可以保證儘量多地發現錯誤,沒法保證可以發現全部的錯誤。
五、傳統測試流程遇到的挑戰和對策----問題發現得越早,解決的代價就越小
對於測試理論,主要依據軟件生命週期V字模型
可見軟件測試貫穿了軟件開發週期的大半,其各級測試的依據是對應開發階段的各類詳細文檔。測試目前主要依賴於:測試人員的經驗和素質;產品說明文檔和項目組的技術諮詢;測試工具的使用;測試計劃的設計。
六、測試分類
按功能分:
–白盒測試(Whitetest)
–黑盒測試(BlackTest)
按測試時間來分:
–單元測試(UnitTest)
–集成測試(IntegrateTest)
–確認測試(ValidationTest)
–系統測試(SystemTest)
按運行狀態來分:
–靜態測試(StaticTest)
–動態測試(DynamicTest)
按方向來分:
–正向測試
–逆向測試
七、測試策略:
測試策略描述測試工程的整體方法和目標。描述目前在進行哪一階段的測試(單元測試、集成測試、系統測試)以及每一個階段內在進行的測試種類(功能測試、性能測試、覆蓋測試等)。
測試策略包括:
一、要使用的測試技術和工具;
二、測試完成標準;
三、影響資源分配的特殊考慮例如測試與外部接口或者模擬物理損壞、安全性威脅。測試計劃最關鍵的一步就是將軟件分解成單元,按照需求編寫測試計劃。
把軟件分解成單元有幾個好處:
一、軟件需求是測試設計和開發測試用例的基礎,分紅單元能夠更好地進行設計;
二、詳細的測試需求是用來衡量測試覆蓋率的重要指標;
三、測試的需求包括各類測試實際的開發以及所需資源。
測試計劃的輸入爲被測軟件、基於需求的測試設計;輸出爲測試過程和測試用例經過設計測試計劃建立能夠重用的測試過程和測試用例,同時維護測試過程、測試用例與相關測試需求的一一對應。