1、軟件測試培訓教程,產品研發(fā)部,軟件測試理論基礎,定義：軟件測試就是為了發(fā)現(xiàn)錯誤而審查軟件文檔、檢查軟件數據和執(zhí)行程序代碼的過程。 軟件測試應該是對軟件形成過程的文檔,數據以及程序進行的測試,而不僅是對程序進行的測試。 60%以上的軟件錯誤并不是程序錯誤,而是分析和設計的錯誤,提倡軟件全生命周期測試的理念。,軟件測試定義,軟件測試的目的,想以最少的時間和人力，系統(tǒng)地找出軟件中潛在的各種錯誤和缺陷。 測試能夠證明軟件的功能和性能與需求說明相符合。 實施測試收集到的測試結果數據為可靠性分析提供了依據 測試不能表明軟件中不存在錯誤，它只能說明軟件中存在錯誤,所有的軟件測試都應追溯到用戶需求。 應當把“

2、盡早地和不斷地進行軟件測試”作為軟件測試者的座右銘。 完全測試是不可能的，測試需要終止。 測試無法顯示軟件潛在的缺陷。也就是說測試只能證明軟件存在錯誤而不能證明軟件沒有錯誤。,軟件測試的原則,軟件測試的對象,根據軟件定義，軟件包括程序，數據和文檔，所以軟件測試并不僅僅是程序測試，軟件測試應該貫穿整個軟件生命周期中。 需求分析，概要設計，詳細設計以及程序編碼等各階段所得到的文檔，包括需求規(guī)格說明，概要設計規(guī)格說明，詳細設計規(guī)格說明以及源程序。,軟件測試的對象,了解軟件工程，熟悉軟件測試過程和標準，熟悉配置管理技術和工具 能夠編制測試計劃、設計測試用例、編寫B(tài)ug報告和測試總結報告、使用測試工具、

3、開發(fā)測試腳本 熟練使用Windows或Unix或Linux操作系統(tǒng) 了解業(yè)務領域（ERP、OA、） 熟練掌握至少一種以上的測試工具，如TestDirector、QTP、LoadRunner、Robot,企業(yè)需要怎樣的測試人才？,一般的，我們將軟件測試活動分為以下幾類： 黑盒測試、 白盒測試、 灰盒測試、 靜態(tài)測試、 動態(tài)測試、 手動測試、 自動測試,軟件測試分類,黑盒測試又叫功能測試、數據驅動測試或基于需求規(guī)格說明書的功能測試。該測試類別注重于測試軟件的功能性需求。 測試工程師無需了解程序代碼的內部構造，完全模擬軟件產品的最終端用戶使用該軟件，檢查軟件產品是否達到了用戶的需求。 如圖1-4所示

4、為黑盒測試實例圖。 黑盒測試能更好的從用戶角度來考察被測系統(tǒng)的功能性需求實現(xiàn)情況。,軟件測試分類黑盒測試,白盒測試又稱結構測試、邏輯驅動測試或基于程序代碼內部構成的測試。 白盒測試需要測試工程師深入考查程序代碼的內部結構、邏輯設計等。 就像前面的例子，我們拆開手機，觀察手機電路板的設計，液晶屏的構成等。 對于白盒測試工程師來說，軟件產品的內部結構是敞開的。如圖1-5所示是白盒測試示例圖。,軟件測試分類白盒測試,灰盒測試介于白盒和黑盒測試之間。 灰盒測試一方面考慮程序代碼的功能性表現(xiàn)，另一方面，又需要考慮程序代碼的內部結構。 通俗地講，灰盒測試就是白加黑。 像我們的性能測試，自動化功能測試就是采

5、用了灰盒測試的方法。 圖1-6是灰盒測試的示例圖。,軟件測試分類灰盒測試,定義：靜態(tài)的、不執(zhí)行被測對象程序代碼而尋找缺陷的過程。 在進行靜態(tài)測試時可采用一些代碼走查工具，如QAC+、C+Test等。,軟件測試分類靜態(tài)測試,實際的執(zhí)行被測對象的程序代碼，輸入實現(xiàn)設計好的測試用例，檢查程序代碼運行得到的結果與測試用力中設計的預期結果之間是否有差異，判定實際結果與預測結果是否一致。 動態(tài)測試有四部分組成：設計測試用例、執(zhí)行測試用例、分析比較輸出結果、輸出測試報告。 動態(tài)測試有三種主要方法：黑盒測試、白盒測試和灰盒測試,軟件測試分類動態(tài)測試,它是測試人員設計測試用例并執(zhí)行測試用例，然后根據實際的結果去

6、和預期的結果相比較并記錄測試結果，最終輸出測試報告的測試活動。 可充分發(fā)揮測試工程師的主觀能動性，將其智力體現(xiàn)在測試工作中，能發(fā)現(xiàn)許多的缺陷，但同時又有一定的局限性和單調枯燥性。,軟件測試分類手動測試,定義 利用測試工具，模擬用戶業(yè)務使用流程，讓他們自動運行來查找缺陷。 優(yōu)點 快、廣泛、可重復性工作 缺點 只可檢查比較主要的問題，如崩潰、死機，無法發(fā)現(xiàn)一般的日常錯誤。編寫腳本工作量 也很大，有時會超過手動測試時間。 我們要根據實際情況選擇或者不選擇測試工具，選擇使用何種測試工具，不能為了實用工具而可以的去使用工具。,軟件測試分類自動化測試,軟件測試流程,軟件測試雖然是軟件生存周期的一個獨立階段

7、，但測試工作卻滲透到從分析、設計直到編程的各個階段中（1-7是軟件測試所經階段的一般流程）。 需求測試、單元測試、集成測試、系統(tǒng)測試、性能測試、用戶測試、回歸測試,軟件測試流程圖,又稱模塊測試，就是對程序代碼中最小的涉及模塊單元進行測試。 在單元測試中我們主要采用靜態(tài)測試與動態(tài)測試相結合的辦法。 單元測試要求需要幾年的代碼編寫經驗，并且要十分熟悉當前的被測系統(tǒng)，以及該系統(tǒng)是否與其他系統(tǒng)的接口關聯(lián)情況。 單元測試在編碼階段占據非常重要的地位。 可以降低編碼的錯誤率，提高編碼質量,單元測試,又稱組裝測試，是將軟件產品各個模塊組裝起來，檢查接口是否存在問題，以及組裝后的整體功能、性能表現(xiàn)。 一般可采

8、用非增式集成方法、增式集成方法（自底向上集成、自頂向下集成、組合方式集成）等策略進行測試，利用一黑盒測試為主，白盒測試為輔的測試方法進行測試。 主要解決各個組成但源代碼是否符合開發(fā)規(guī)范、接口是否存在問題，整體功能有無錯誤、界面是否符合設計規(guī)范、性能是否滿足用戶需求等。,集成測試,回歸測試是經過一段時間以后再回過頭來對以前修復過的Bug重新進行測試，看該Bug是否會重新出現(xiàn)。 有些時候可采用自動化測試工具來進行回歸測試，如利用QTP 一般情況下，都由測試工程師手動的執(zhí)行一千的測試用例。來檢查用例通過情況。,回歸測試,軟件測試工作流程,1、人員構成 測試主管、測試組長、環(huán)境保障人員、配置管理員、測

9、試設計人員、測試工程師,測試部門組織結構,項目管理技術人員 要求掌握一般的項目管理知識，如配置管理、版本控制、評審管理、項目實施與進度控制等。 資源構成,測試部門組織結構,測試用例編寫,測試工作流程,測試開展階段 搭建測試環(huán)境測試組長，可根據說明說中的軟件產品運行環(huán)境配置要求搭建。測試環(huán)境最好與開發(fā)環(huán)境分開 文檔引入工作日報、功能測試報告、性能測試報告等模板 執(zhí)行測試根據項目的Bug管理流程，經過多次的版本迭代，完成測試工作。,測試工作流程,測試輸出階段 測試計劃 測試方案 測試用例 測試工程師的工作日報 功能測試報告 性能測試報告,測試工作流程,軟件測試用例設計方法,什么是測試用例,測試用例

10、（ Test Case ）是指對一項特定的軟件產品進行測試任務的描述，體現(xiàn)測試方案、方法、技術和策略。內容包括測試目標、測試環(huán)境、輸入數據、測試步驟、預期結果、測試腳本等，并形成文檔。,測試用例包含要素,每個具體測試用例都將包括下列詳細信息：編制人、審定人、編制日期、版本、用例類型、設計說明書編號、用例編號、用例名稱、輸入說明、期望結果（含判斷標準）、環(huán)境要求、備注等。 具體可以參考建行測試用例模板,黑盒測試案例設計技術,測試用例設計：將軟件測試的行為活動，作為一個科學化的組織歸納。 測試用例：設計一個情況，軟件程序在這種情況下，必須能夠正常運行并且達到程序所設計的執(zhí)行結果。 因為我們不可能進

11、行窮舉測試，為了節(jié)省時間和資源、提供測試效率，必須從數量極大的可用測試數據精心挑選出具有代表性或者特殊性的測試數據來進行測試。,測試測試用例的好處,在開始實施測試之前設計好測試用例，可以避免盲目測試并提高測試效率。 測試用例的使用令軟件測試的實施重點突出、目的明確。 在軟件版本更新后只修正少部分的測試用例便可展開測試工作，降低工作強度，縮短項目周期。 功能測試模塊的通用化和復用化使軟件易于開發(fā)，而測試用例的通用化和復用化則會使軟件測試易于開展，并隨著測試用例的不斷精化其效率也不斷攀升。,常見黑盒測試用例設計方法,等價類劃分法 邊界值分析法 錯誤推測法 因果圖法 判定表驅動法 正交試驗設計法 功

12、能圖法 場景法,等價類表,設計測試用例,軟件缺陷,什么是軟件缺陷,符合下面 5 條規(guī)則之一的問題稱為軟件缺陷： 1、軟件未達到產品說明書標明的功能。 2、軟件出現(xiàn)產品說明書指明不會出現(xiàn)的錯誤。 （如果軟件含有產品說明中根本沒有存在的功能，這是缺陷） 3、軟件功能超出產品說明書指明的范圍。 4、軟件未達到產品說明書未指出但應達到的目標。 （產品說明書雖然沒有提到，但是按照常理應該達到的功能） 5、軟件測試人員或用戶認為軟件難以理解，不易使用，運行速度緩慢等問題。,缺陷的生命周期,簡單周期： 測試員找到并登記軟件缺陷，軟件缺陷移交到程序員=程序員修復軟件缺陷，軟件缺陷移交到測試員=測試員確定軟件缺

13、陷被修復，測試員關閉軟件缺陷。,缺陷的生命周期,復雜周期： 發(fā)現(xiàn)缺陷（測試員發(fā)現(xiàn)并登記缺陷，軟件缺陷轉到程序員）=軟件缺陷移交到項目管理員=（以不修復形式解決）項目管理員認為軟件缺陷不重要，軟件缺陷移交到測試員=重新激活缺陷（測試員不同意，找出通用失敗案例，軟件缺陷移交到項目管理員）=項目管理員同意缺陷需要修復，缺陷轉給程序員=以修復形式解決（測試員確認軟件缺陷得以修復，測試員關閉軟件缺陷）=缺陷關閉,報告缺陷的要點,復雜周期： 發(fā)現(xiàn)了軟件缺陷，需要記錄下來，不但要記錄結果，同時需要詳細描述發(fā)現(xiàn)的步驟，以備程序員重現(xiàn)問題，并解決它。 要求報告寫的清楚明了和準確。有時利用截屏技術把當時的情況保存

14、成圖片，可以達到一圖勝千言的效果。,缺陷的嚴重性分類,A類致命性： 不能完全滿足系統(tǒng)要求，基本業(yè)務功能未實現(xiàn)系統(tǒng)崩潰、不穩(wěn)定或掛起等導致系統(tǒng)不能繼續(xù)運行、導致系統(tǒng)出現(xiàn)不可預料的嚴重錯誤的問題。,缺陷的嚴重性分類,B 類 嚴重錯誤： 嚴重地影響系統(tǒng)要求或基本功能的實現(xiàn)，且沒有辦法更正（重新安裝 或重新啟動不屬于更正辦法）。使系統(tǒng)不穩(wěn)定、破壞數據、產生錯誤結果，部分功能無法執(zhí)行 。,缺陷的嚴重性分類,C 類 一般性錯誤： 1、界面錯誤。 2、非重要功能無法正確執(zhí)行， 實現(xiàn)不正確， 實現(xiàn)不完整，但不影響功能 3、非嚴重性產生錯誤結果，但不影響一起功能。 4、正確性不受影響，但系統(tǒng)性能和響應時間受到影

15、響。,缺陷的嚴重性分類,D 類 輕微錯誤： 使操作者不方便或遇到麻煩，但它不影響執(zhí)行工作功能或重要功能， 或對最終結果影響有限的問題。,缺陷的嚴重性分類,E 類 測試建議： 不影響系統(tǒng)運行，對系統(tǒng)的可用性等提示的建議性的問題。 例如： 1、系統(tǒng)各個位置初始值的建議。 2、流程優(yōu)化建議等等。,缺陷分析報告,可以將缺陷計數作為時間的函數來報告，即創(chuàng)建缺陷趨勢圖或報告； 也可以將缺陷計數作為一個或多個缺陷參數的函數來報告，如作為缺陷密度報告中采用的嚴重性或狀態(tài)參數的函數。 這些分析類型分別為揭示軟件可靠性的缺陷趨勢或缺陷分布提供了判斷依據,軟件測試的技巧,需求測試 回歸測試 錯誤處理測試 支持手冊的

16、測試 系統(tǒng)兼容測試 控制性測試 并行測試,功能測試技巧,目標 程序修改后，確保功能的正確性 如何使用 重新測試應用程序中沒有改變的部分 例子 重新執(zhí)行以前的測試用例 什么時間使用 當新的程序有可能影響老的功能的時候,回歸測試,目標 檢驗當使用適當的參數和數據時，需要的信息可以在兩個系統(tǒng)中正確的交換 如何使用 文件和數據被用來在多系統(tǒng)之間傳遞。 例子 典型的由一個系統(tǒng)到另一個系統(tǒng)的數據交換程序。 什么時候使用 當兩個應用程序之間的參數有可能發(fā)生變化的時候,兼容性測試,測試計劃,定義測試目標 開發(fā)測試矩陣 軟件模型 結構特性 批量測試的階段和用例 為在線系統(tǒng)作概念上的測試腳本 軟件測試矩陣 定義測

17、試管理 測試計劃的一般性信息 定義測試里程碑 定義管理上的檢查點 書寫測試計劃,建立測試計劃,正式評審中的角色 緩和劑（SQA） 讀者 記錄者 作者 檢測員 正式評審發(fā)現(xiàn)的缺陷應包含的信息 起因 類型 分類 級別,評審測試計劃,計劃和組織 通篇的講解（可選） 個人準備 評審會議 修訂和反復,評審流程,手冊，回歸，功能點測試 一致性測試（授權） 功能點測試（完整性） 功能點測試（審計，追蹤） 覆蓋性的測試（測試的連續(xù)性） 壓力測試（服務水平） 一致性測試（安全性） 依照預先定義的測試方法 功能點測試（正確性） 支持手冊的測試（易用性） 檢查（可維護性） 災難性的測試（可攜帶性） 功能和回歸測試（耦合性） 一致性的測試（性能） 操作性的測試（易用性）,典型測試類型,測試方法 測試用例的概念是簡單的 建立有效的測試用例是復雜的 設計測試文件 測試用例應當包含合法的和非法的輸入 每一個動作只進行一次關鍵操作 輸入測試數據 分析結果 嘗試將測試文件違反程序的規(guī)則進行輸入 容量測試的測試工具 以大信息量的數據進行輸入 這是一個昂貴的測試，應根據需要來選擇 在線系統(tǒng)需要做壓力測試,建議測試方法,測試總結,目標 表示出目前項目的實際狀況 明確什么是測試做的工作，