1、軟件測試簡介第十二章 軟件測試簡介軟件測試基本概念軟件測試分類自動化測試常見測試工具BUG管理流程軟件測試的定義：使用人工或自動的手段來運行或測定某個軟件系統的過程，其目的在于檢驗它是否滿足規定的需求或弄清預期結果與實際結果之間的差別。是幫助識別開發完成（中間或最終的版本）的計算機軟件（整體或部分）的正確度(Correctness) 、完全度(Completeness)和質量(Quality)的軟件過程；軟件測試是為了發現程序中的錯誤而執行的過程。定義軟件測試歷史1947年 ，測試等同于調試1957年，測試是為了表明程序正確而進行的1972年，測試是為發現錯誤而至此能夠的一個程序或者系統的過程

2、1996年，提出測試能力成熟度TCMM(Testing Capability Maturity Model)，測試支持度TSM（Testability Support Model)，測試成熟度TMM（Testing Maturity Model)，測試工具流行。2002年，測試是為了度量和提高被測軟件的質量，對測試件進行工程設計、實施和維護的整個生命周期過程。軟件測試著名失敗案例獅子王案例：缺乏配置測試Intel浮點除法軟件缺陷美國航天局火星登陸愛國者導彈防御系統軟件缺陷軟件未達到產品說明書（簡稱，SPEC）標明的功能；軟件出現了產品說明書指明不會出現的錯誤；軟件功能超出產品說明書指明范圍；軟

3、件未達到產品說明書雖未指出但應達到的目標，此條的目的是抓住產品說明書上遺漏之處；軟件測試員認為軟件難以理解、不易使用、運行速度緩慢，或者最終用戶認為不好。軟件模型或者說業務建模制定不正確，更直觀的理解是，SEPC本身不明確或有錯誤，沒有能很好的描述要開發的軟件，這類原因占了70%左右，并且很難于糾正；軟件龐大，功能十分復雜；編程過程出錯，此類原因導致的錯誤大概占20%，一般來說比較容易糾正；個別功能要求改變而影響到其他部分；與要開產的軟件對接的第三方軟件有缺陷；人為因素，常見的因素包括：項目組管理方法、項目進度要求時間緊、項目組配備人力不足、組內及組外溝通不充分等幾種情況。產生軟件缺陷的原因糾

4、錯階段糾錯階段單位費用單位費用1功能需求搜集分析/軟件設計階段1單位費用2編程或分塊測試階段5單位費用3整體或系統測試階段10單位費用4早期用戶試用或Beta測試階段15單位費用5軟件推出市場后30單位費用發現階段修正花費對照表軟件測試的原則為了能夠更好的進行軟件測試，提高測試的整體效率，降低項目的整體成本，我們在執行軟件測試過程中可以參照以下幾點原則：1、完全測試程序是不可能的，不可能找出軟件的所有缺陷，這是因為：輸入量太大輸出結果太多軟件實現途徑太多軟件說明書沒有客觀標準，從不同的角度來看，軟件缺陷的標準不同。2、軟件測試是有風險的行為，如果決定不去測試所有的情況，那就是選擇了風險。軟件測

5、試人員要學會的一個主要原則是如何把無邊無際的可能減少到可以控制的范圍，以及如何針對風險制訂作出明智抉擇，去粗存精。3、測試無法顯示潛伏的軟件缺陷，軟件測試工作與防疫員的工作極為相似，可以報告已發現的軟件缺陷，卻無法報告潛伏的軟件缺陷，更不可能保證找到全部的缺陷。4、找到的軟件缺陷越多，就說明軟件缺陷越多。生活中的寄生蟲和軟件缺陷幾乎完全一樣，兩者都成群出現。發現一個附近就會有一群。軟件測試的原則（續）5、殺蟲劑怪事，與農藥殺蟲是一樣的，軟件對測試方法及技術也有免疫力，只有發明新的殺蟲劑（測試技術或方法）去找蟲子。6、并非所有軟件缺陷都能修復。7、難以說清的軟件缺陷，因為開發小組使用的最佳工作方

6、式千差萬別，大家對缺陷的理解也不一致。8、產品說明書不斷變化，整個行業變化太快，同時軟件變得更龐大、更復雜，功能越來越多，這些都會導致用戶描述和定義軟件的產品說明書一變再變。9、軟件測試員在小組中不受歡迎，軟件測試員的任務是檢查和批評同事的工作，挑毛病，公布發現的問題。10、軟件測試是一項講究條理的技術專業，當前軟件行業已經發展到強制使用專業軟件測試員的階段了，因為生產低劣軟件的代價太高。軟件測試的原則（續）軟件常見的版本在整個軟件開發的生命周期中，可能會出現各種版，每個公司對版本的定義也不一樣，通常情況下有以下的幾個版本是比較通用的：1、Alpha版公司內部測試的版本，該版本的特征為：軟件的

7、所有功能已基本實現所有的功能已通過測試，一般情況下推向市場前不再增減（一般為集成測試）已到的缺陷中，嚴重級別的已修正并通過復測軟件性能測試可提供基本數據2、Beta版對外發布公測，該版本的特征為：次嚴重缺陷基本完成修正并通過復測完成測試計劃中的每一項具體測試（一般為系統測試計劃）一段時間內缺陷的發現離低于修正率所有相關文件（用戶指南、軟件說明、版本說明等）得到最后修正3、發布版正式發布版本，該版本的特征為：缺陷發現率低于修正率，此距離逐漸拉開并一直保持穩定的一段時間測試部門對所有已修正的缺陷重新測試并通過技術支持部門對產品的提出認為可行所有用戶反饋都已妥善處理所有文件準備就緒得到測試部門認可軟

8、件常見的版本（續）優秀軟件測試員必備想成為一名優秀的軟件測試員，可以從以下幾方面去努力：1、探索精神，軟件測試員不會害怕進入陌生環境。2、故障排除能手，軟件測試員善于發現問題的癥結，喜歡猜謎。3、不懈努力，軟件測試員總是不停嘗試。4、創造性想出富有創意甚至超常的手段來尋找軟件缺陷。5、追求完美，他們力求完美，但是知道某些無法企及時，不去苛求，而是盡力接近目標。6、判斷準確，軟件測試員要決定測試內容、測試時間，以及看到的問題是否算作真正的缺陷。7、老練穩重，軟件測試員不害怕壞消息，必須告訴程序員，你的孩子很丑，知道和不夠冷靜的程序員怎樣合作。8、表達能力，軟件測試員要善于表達觀點，表明軟件缺陷為

9、何必須修復，并通過實際演示力陳觀點。9、在編程方面受過教育。第十二章 軟件測試簡介軟件測試基本概念軟件測試分類自動化測試常見測試工具BUG管理流程軟件測試分類按軟件測試特性可以把軟件測試分為白盒測試、灰盒測試和黑盒測試三種，其特征及包含的內容如下：、白盒測試測試人員直接在軟件的源程序上進行測試、修改、復測。要求測試工程師對軟件的內部結構及邏輯有深入的了解，并掌握寫成該源程序的語言。分為：語句測試；分支測試；路徑測試；條件測試；目測、灰盒測試介于白、黑兩者之間，是兩者的結合。測試工程師對軟件程序結構有一定了解，但了解的程度又不需要達到白盒測試的深度。、黑盒測試測試人員不必深入了解軟件的內部設計，

10、只是從一個終端用戶的角度，根據產品說明書的指標，從外部測試軟件的各項功能及性能。黑盒測試主要是功能測試。按軟件開發過程可以把軟件測試分為單元測試、集成測試、系統測試、用戶驗收測試以及回歸測試。此分類一般可以使用V模型來表示，如下圖所示：軟件測試分類（續）各類測試用時表按開發過程分類測試用時按軟件測試要求可以把軟件測試分為基本功能測試、全面測試和基準測試。按此方法分類的各種測試解釋如下：、基本功能測試（Smoke test）：只對軟件的關鍵功能做測試，而不必卷入細致的測試，不必面面俱到。、全面測試（Sanity test）：不僅對軟件關鍵功能測試，還要覆蓋軟件的全部功能，是回歸測試的主要組成部分

11、。、基準測試（Benchmark test）：對指定的一個或一組程序及數據在不同的計算機上執行測試，以測定其在標準情況下、特定配置下的工作性能，并將其執行速度、完成需時等加以比較。軟件測試分類（續）l按軟件特性可以把軟件測試分為功能測試和非功能測試：功能測試主要包括：等價區間測試，把輸入空間劃分幾個“等價區間”，在每個區間中只需要測試一個典型值即可；邊界值測試；隨機測試；狀態轉換測試；流程測試等。非功能測試主要包括：安裝/卸載測試；使用性測試；恢復測試；兼容性測試；安全測試；性能測試；強度/壓力測試；容量測試；任意測試等。軟件測試分類（續）第十二章 軟件測試簡介軟件測試基本概念軟件測試分類自動

12、化測試常見測試工具BUG管理流程自動化測試優點l自動化測試：就是使用（自動化測試）工具來進行的測試，一般不需要人干預。l自動化測試優點：一旦積累了一套自動化測試的程序，日后自動化測試節省大量的時間和資源；沒有時間限制一般安排在下班后；可以反復執行；保證測試執行過程的一致性及準確性；有較高的功能測試覆蓋率；模擬操作，進行壓力測試，這是手測很難實現的。并非所有的測試都可用自動測試來實現，比如使用性測試、兼容性測試等；沒有創造性，只能安排設計好的用例去測，碰到新問題不會應變；受具體項目資源限制：受時間及人力的限制，因為自動化測試編程很費時；受資金預算的限制，商用測試軟件價格比較高；對測試工程師要求比

13、較高。自動化測試缺點l根據自動化測試的特點，建議以下測試優先考慮自動測試：回歸測試，每次有新版本發布前都必須執行，在整個開發過程中需要多次執行，很適合編寫成自動測試程序。涉及大量不同數據輸入的功能測試。如各種各樣的邊界值測試，需要大量時間去完成的網頁連接測試等等。用手測完成難度較大的測試，如性能測試、壓力（負荷）測試、強度測試等。例如：對于一個網站，要測試1萬個用戶在某一時間內同時登錄時，服務器運行是否正常及速度是否仍然可以接受，這是手測很難完成的。自動化測試應用場景編寫測試用例；分析、分析、驗證測試用例；對已有測試用例歸類，編寫測試自動化計劃方案；編寫自動化測試程序；盡量用“數據驅動”來提高

14、測試覆蓋率；將測試用例編寫成自動測試程序；執行測試程序，記錄并反饋BUG；不斷完善自動化測試系統或程序。自動化測試實現步驟第十二章 軟件測試簡介軟件測試基本概念軟件測試分類自動化測試常見測試工具BUG管理流程不是專業測試工具的工具查看器和監視器，各類編譯器的代碼調試器均可看作查看器；任何能夠洞察系統，看到一般用戶看不到的數據的工具，都可以稱之為查看測試工具；驅動程序，用于控制和操作測試軟件的工具，最簡單的是批處理文件；仿真器，為測試工具或程序提供數據或響應軟件發送的數據；分析工具，電子表格軟件、文件比較軟件、抓屏軟件和比較軟件、計算器、秒表等；干擾發射器和噪聲發生器，模擬由于數據中斷、干擾能產

15、生的通信錯誤。常見測試工具窗口/網絡軟件用戶界面測試WinRunner、QuickTest ProfessionalSilkTestFunctional TesterTest PartnerVisualTest性能測試LoadRunnerSilkPerformerRational Performance TesterQALoad常見測試工具（續)軟件測試管理工具TestDirectorSilkCentral Test ManagerRational TestManager/ClearQuestQADirector/TrackRecordX窗口軟件測試X Runner自開發測試軟件，適用于特定領

16、域第十二章 軟件測試簡介軟件測試基本概念軟件測試分類自動化測試常見測試工具BUG管理流程微軟研發中的BUG管理微軟有一個研發框架叫MSF（微軟解決方案框架），開發過程中主要有三個角色：PM(程序規劃經理）、Dev（軟件開發工程師）、Tester（軟件測試工程師）。在研發過程中，三者分工明確、接口清晰。PM來定義需求、書寫每個功能特性的設計文檔(SPEC)；Dev寫代碼來實現這些SPEC；Tester來測試Dev做出來的東西是否符合PM定義的SPEC。微軟不少項目都使用完善的研發管理工具，其中Bug管理系統（原來叫Raid系統，現集成在VSTS中）居于核心地位。整個軟件研發過程中，特別是在測試產

17、品、修復BUG的中后期，團隊中所有人都生活在Raid中。Tester只要發現問題就立即新建一個Bug予以跟蹤并指派給相關的開發小組長（Dev Leader)，開發小組長會判斷這個BUG屬于某個特定的開發人員并指派他處理。開發人員會根據BUG的詳細描述信息找到問題所在，修改程序解決這個BUG，并把BUG返回給當初的測試人員；或者有爭議的時候，把BUG指派給這個需求定義者PM，要求澄清說明。測試人員在看到某個BUG被解決后，就去驗證這個BUG是否真的不存在了，根據最初的發現步驟去證實問題真的解決了就關閉這個BUG；否則，可以激活這個BUG，返回給當初的開發人員做進一步處理。當測試人員與開發人員無法

18、達成一致意見時，由對應的PM出面做協調，判斷這個BUG的嚴重程序，對用戶可能的影響。根據產品的進度和項目資源做出評估，是否真的需要解決這個問題。管理團隊利用BUG管理系統來跟蹤整個進度，單個人的工作、小組的進度、整個產品研發進度。微軟研發中的BUG管理（續）l在微軟的BUG管理或者說研發管理思想里有以下幾點需要注意：報告BUG不僅僅是測試人員的事情，團隊的每個人發現問題時都會提交一個BUG來跟蹤；BUG管理系統不僅僅是跟蹤軟件功能方面的BUG，其他各種問題，如需求文檔的變更、界面上錯別字、幫助文檔的語言、某項任務指源等都可以通過此來跟蹤。在VSTS中全部被稱之為工作項。Everything should be tracked in VSTS（Raid）。微軟研發中的BUG管理（續）通用BUG管理流程l比較通用的Bug管理流程如下：BUG登記測試工程師，初始；指派任務項目經理，激活；修改BUG開發工程師，修改；驗證測試工程師，通過則轉第五步，否則轉二步，狀態為再激活；關閉測試工程師。l為了能使開發人員準確理解Bug，Bug描述應當具有以下特征：短小只解釋