軟件測試基本理論和方法

1、1 CSIA軟件測試工程師培訓軟件測試工程師培訓 軟件測試基礎理論與方法軟件測試基礎理論與方法2引 言 軟件測試是保證軟件質(zhì)量的重要技術手段測試理論和測試方法測試過程及測試的管理測試工具3測試的原則原則一：窮盡測試是不可能的原則二：測試工作具有創(chuàng)造性，但很困難原則三：測試旨在防止錯誤的發(fā)生原則四：測試是有風險的原則五：測試需要有計劃性原則六：測試需要有獨立性4軟件測試技術基礎軟件測試技術基礎 6.1、測試的目的、測試的目的6.2、測試的原則、測試的原則6.3、測試的層次結構、測試的層次結構6.4、測試階段、測試階段6.5、測試方法、測試方法6.6、測試種類、測試種類6.7、測試自動化、測試自動

2、化6.8、小結、小結51、測試的目的、測試的目的 測試是通過運行程序來發(fā)現(xiàn)錯誤的過程測試是通過運行程序來發(fā)現(xiàn)錯誤的過程 測試可以說明軟件存在錯誤，但不能說測試可以說明軟件存在錯誤，但不能說明它不存在錯誤明它不存在錯誤 目的：用相對少的測試盡可能多地找到目的：用相對少的測試盡可能多地找到程序中的缺陷程序中的缺陷62、測試的原則、測試的原則 一個好的測試用例具有較高的發(fā)現(xiàn)過去未被發(fā)一個好的測試用例具有較高的發(fā)現(xiàn)過去未被發(fā)現(xiàn)過的錯誤的概率，而不應只表明程序運行正現(xiàn)過的錯誤的概率，而不應只表明程序運行正常常 自己不能測試自己編寫的程序自己不能測試自己編寫的程序 對期望結果的描述是每個測試用例的必要組成

3、對期望結果的描述是每個測試用例的必要組成部分部分 杜絕不能重現(xiàn)或匆忙的測試杜絕不能重現(xiàn)或匆忙的測試 既要編寫使用有效輸入條件的測試用例，也要既要編寫使用有效輸入條件的測試用例，也要編寫使用非法輸入條件的測試用例編寫使用非法輸入條件的測試用例 深入細致地審查測試結果深入細致地審查測試結果72、測試的原則、測試的原則 如果一段程序中發(fā)現(xiàn)的缺陷數(shù)量增加，則意味如果一段程序中發(fā)現(xiàn)的缺陷數(shù)量增加，則意味著有更多未被發(fā)現(xiàn)的缺陷的可能性也在增加著有更多未被發(fā)現(xiàn)的缺陷的可能性也在增加 讓最優(yōu)秀的人員去完成測試讓最優(yōu)秀的人員去完成測試 保證軟件可測試性是軟件設計的一個重要目標保證軟件可測試性是軟件設計的一個重要

4、目標 不要為了測試方便而修改程序不要為了測試方便而修改程序 測試工作必須在任務建立之初就確定目標測試工作必須在任務建立之初就確定目標83、測試的層次結構、測試的層次結構類型方法階段舉例：功能算法正向反向可用性邊界驗收測試確認測試集成測試單元測試白盒黑盒自頂向下自底向上模擬用戶操作94、測試階段、測試階段 單元測試單元測試 組裝測試組裝測試 確認測試確認測試 驗收測試驗收測試104.1、單元測試、單元測試 單元測試的目的是在一個隔離環(huán)境中對單元測試的目的是在一個隔離環(huán)境中對獨立的軟件模塊進行測試以發(fā)現(xiàn)其中的獨立的軟件模塊進行測試以發(fā)現(xiàn)其中的缺陷。缺陷。114.1、單元測試、單元測試124.2、集

5、成測試、集成測試 集成測試的目的是當模塊組裝后查找模集成測試的目的是當模塊組裝后查找模塊間接口的錯誤塊間接口的錯誤134.3、確認測試、確認測試 確認測試的目的是確定軟件是否滿足軟確認測試的目的是確定軟件是否滿足軟件需求規(guī)格說明所提出的所有需求件需求規(guī)格說明所提出的所有需求144.4、驗收測試、驗收測試 用戶參與的確認測試用戶參與的確認測試155、測試方法、測試方法 黑盒測試方法黑盒測試方法 白盒測試方法白盒測試方法 自頂向下方法自頂向下方法 自底向上方法自底向上方法 模擬用戶操作測試方法模擬用戶操作測試方法165.1、黑盒測試方法、黑盒測試方法 黑盒測試也稱功能測試或數(shù)據(jù)驅(qū)動測試，黑盒測試也

6、稱功能測試或數(shù)據(jù)驅(qū)動測試，它是在已知產(chǎn)品所應具有的功能，通過它是在已知產(chǎn)品所應具有的功能，通過測試來檢測每個功能是否都能正常使用。測試來檢測每個功能是否都能正常使用。176.5.2、白盒測試方法、白盒測試方法 白盒測試也稱結構測試或邏輯驅(qū)動測試，白盒測試也稱結構測試或邏輯驅(qū)動測試，它是知道產(chǎn)品內(nèi)部工作過程，可通過測它是知道產(chǎn)品內(nèi)部工作過程，可通過測試來檢測產(chǎn)品內(nèi)部動作是否按照規(guī)格說試來檢測產(chǎn)品內(nèi)部動作是否按照規(guī)格說明書的規(guī)定正常進行。明書的規(guī)定正常進行。186.5.3、自頂向下或自底向上方法、自頂向下或自底向上方法 依據(jù)模塊在模塊層次中的位置，對模塊依據(jù)模塊在模塊層次中的位置，對模塊組裝并測試

7、，屬于增量組裝測試方法。組裝并測試，屬于增量組裝測試方法。196.5.4、模擬用戶操作測試方法、模擬用戶操作測試方法 著重對那些用戶可能發(fā)現(xiàn)的錯誤進行測著重對那些用戶可能發(fā)現(xiàn)的錯誤進行測試及修改工作試及修改工作206.6、測試類型、測試類型 功能測試功能測試 算法測試算法測試 正向測試正向測試 反向測試反向測試 可使用性測試可使用性測試 邊界測試邊界測試 平臺測試平臺測試 負載負載/ /強度測試強度測試216.7、自動化測試、自動化測試 6.7.16.7.1、屬性及優(yōu)點、屬性及優(yōu)點 6.7.26.7.2、主要分類、主要分類 6.7.36.7.3、實現(xiàn)類型、實現(xiàn)類型 6.7.46.7.4、注意的

8、問題、注意的問題226.7.1、屬性及優(yōu)點屬性及優(yōu)點 速度。速度。例如手工測試例如手工測試Windows計算器，假定平均每計算器，假定平均每5秒鐘執(zhí)行一個測試案例，那么數(shù)千個案例需要數(shù)小時秒鐘執(zhí)行一個測試案例，那么數(shù)千個案例需要數(shù)小時的時間。而自動化能夠以成千上萬倍的速度來執(zhí)行。的時間。而自動化能夠以成千上萬倍的速度來執(zhí)行。 效率。效率。測試工具減少了執(zhí)行測試案例的時間，有更測試工具減少了執(zhí)行測試案例的時間，有更多的時間進行測試計劃考慮新的測試用例。多的時間進行測試計劃考慮新的測試用例。 準確度和精確度。準確度和精確度。嘗試執(zhí)行百個測試用例之后，嘗試執(zhí)行百個測試用例之后，注意力就會分散，開始犯

9、錯誤。測試工具每次執(zhí)行同注意力就會分散，開始犯錯誤。測試工具每次執(zhí)行同樣的測試，并毫無差錯地檢查結果。樣的測試，并毫無差錯地檢查結果。 堅持不懈。堅持不懈。測試工具和自動化永遠不會累倒或半途測試工具和自動化永遠不會累倒或半途而廢。而廢。236.7.2、主要分類主要分類 回放類型自動測試工具回放類型自動測試工具 代碼分析器：復雜度等代碼分析器：復雜度等 覆蓋分析器覆蓋分析器 內(nèi)存分析器內(nèi)存分析器 強度測試工具強度測試工具 web測試工具測試工具 其它其它測試用例管理、文檔管理、測試用例管理、文檔管理、bug reporting、配置管理、配置管理 246.7.3、實現(xiàn)類型實現(xiàn)類型 宏錄制和回放。

10、宏錄制和回放。 最基本的測試自動化類型時錄制第一次執(zhí)最基本的測試自動化類型時錄制第一次執(zhí)行測試用例時的鍵盤和鼠標操作，然后在需行測試用例時的鍵盤和鼠標操作，然后在需要重新執(zhí)行時回放要重新執(zhí)行時回放 可編程的宏可編程的宏 編寫回放系統(tǒng)遵守的簡單指令編寫回放系統(tǒng)遵守的簡單指令 完全可編程的自動測試工具完全可編程的自動測試工具 提供編程語言提供編程語言256.7.4、注意的問題注意的問題 軟件變更軟件變更 人眼和直覺是不可替代的人眼和直覺是不可替代的 驗證難以實現(xiàn)驗證難以實現(xiàn) 容易過分依賴自動化容易過分依賴自動化 不要花費太多時間使用達不到測試軟件目的的不要花費太多時間使用達不到測試軟件目的的測試工

11、具和自動化測試工具和自動化 編寫宏、開發(fā)工具都屬于開發(fā)工作，應該遵守編寫宏、開發(fā)工具都屬于開發(fā)工作，應該遵守要求程序員遵守的相同標準和規(guī)范要求程序員遵守的相同標準和規(guī)范 某些工具是侵入式的，可能導致測試的軟件不某些工具是侵入式的，可能導致測試的軟件不正常失敗。正常失敗。266.8、小結、小結測試的目的測試的目的測試的原則測試的原則測試的層次結構測試的層次結構測試階段測試階段測試方法測試方法測試種類測試種類測試自動化測試自動化27軟件測試理解1 軟件測試活動2 測試過程3 測試方法4 測試類型5 測試策略6 小結281 軟件測試活動 測試是從大量的測試用例中選擇有限的測試用例發(fā)現(xiàn)軟件中的大部分缺

12、陷的一種技術 好的測試用例的4個特性：n 檢測軟件質(zhì)量的有效性，是否能發(fā)現(xiàn)缺陷，或至少可能發(fā)現(xiàn)缺陷；n 可仿效的測試用例可以測試很多內(nèi)容，因而減少測試用例的數(shù)量；n 經(jīng)濟性，測試用例的執(zhí)行、分析和調(diào)試是否經(jīng)濟1.測試用例的可修改性，每次軟件修改后對測試用例的維護成本29測試活動 計劃 編制測試計劃：標志測試條件（確定測試什么）和測試的優(yōu)先級 設計 設計測試用例（確定怎么測試） 開發(fā) 測試開發(fā)（設計腳本、數(shù)據(jù)等） 執(zhí)行 執(zhí)行測試用例 將測試結果與期望結果進行比較 評估 30測試活動 1計劃階段內(nèi)容：人員、進度、資源。p測試條件取決于被測試驗證的項目或事件。p測試條件是被測環(huán)境的描述。可以用多種方

13、式描述：如簡單的語言，表格項形式或類似于流圖的圖表形式；p標識測試條件的活動最好與開發(fā)活動（即V模型左邊的活動）并行開展31測試活動 2 設計階段 內(nèi)容：設計測試用例、預期結果p測試用例（test case）是按一定順序執(zhí)行的與測試目標（test object, 測試理由或目的）相關的一系列測試。p測試用例設計將產(chǎn)生許多測試所包括的運行測試的有關信息（如環(huán)境要求，也稱為先決條件）、輸入值、期望結果。p期望輸出包括應輸出或建立的內(nèi)容，應修改或更新或應刪除的內(nèi)容。期望輸出集可以是一個很大的集合。32測試活動測試活動測試用例：POS1036先決條件： 作為數(shù)據(jù)輸入員注冊到定單系統(tǒng)顯示的主菜單 數(shù)據(jù)庫

14、系統(tǒng)必須含有標準數(shù)據(jù)集合 確保系統(tǒng)中沒有其他活躍的新定單活動 步驟輸入期望輸出測試條件1建立用任何一個標準的訂單項建立一個新訂單，設置訂單數(shù)為100顯示訂單確認信息VB10VB202確認訂單打印具有正確細目購置訂單VB103打印新訂單報表打印的新訂單報表就是新創(chuàng)建的訂單VB10VB234取消訂單打印正確的取消購置訂單信息VB85打印新訂單報表無打印訂單輸出VB833測試活動測試活動 3開發(fā)階段開發(fā)階段開發(fā)測試用例包括: 準備測試腳本、測試輸入、測試數(shù)據(jù)以及期望輸出。p測試腳本（test script）是具有正規(guī)語法的數(shù)據(jù)和指令的集合，在測試執(zhí)行自動工具使用中，通常以文件形式保存；p必須先完成測

15、試用例的先決條件（precondition），然后再執(zhí)行測試。測試用例可能要求專門的硬件或軟件，如網(wǎng)絡環(huán)境或打印機等；p期望輸出可以組成文件形式用于自動工具。對于手動測試，期望輸出僅僅只是簡單地記錄在手工測試過程或腳本中。對于自動測試，其期望輸出比設置用于手工測試的期望輸出復雜得多。在自動工具中要求每項內(nèi)容都要拼寫正確，而在手工測試中要求沒這么嚴格。p測試開發(fā)的任何工作可以提前進行（相對V模型左邊的活動進行），以后可以節(jié)省時間。34測試活動測試活動 4執(zhí)行階段執(zhí)行階段 執(zhí)行測試用例p對于手動測試：測試者按事先準備好的手工過程進行測試，測試者輸入數(shù)據(jù)、觀察輸出、記錄發(fā)現(xiàn)的問題。p對于自動測試：可

16、能只需要啟動測試工具，并告訴工具執(zhí)行哪些測試用例；p測試執(zhí)行只能在軟件開發(fā)完成后進行，即V模型右邊的活動。35測試活動 5評估階段 將測試結果與期望輸出進行比較p應該對每次測試的實際輸出進行分析研究，判斷軟件功能是否正確。p驗證可以是測試者的主觀判斷，也可以是將實際輸出與期望輸出進行嚴格準確的比較。p信息比較，如可以在執(zhí)行測試時進行顯示屏幕上的信息，另一些輸出比較，如修改數(shù)據(jù)庫記錄，只能在測試執(zhí)行結束后進行。p自動測試一般結合了信息比較的兩種方法。36軟件測試與軟件工程模型V模型介紹擴展：左邊的每一部分還包括評審，也是測試任務。需求需求驗收測試驗收測試系統(tǒng)測試系統(tǒng)測試集成測試集成測試單元測試單

17、元測試概設概設詳設詳設編碼編碼測試測試測試編碼測試編碼測試運行測試運行測試測試測試測試測試測試37測試設計基于需求分析 缺陷預防：是指各種錯誤遺留到后續(xù)開發(fā)階段之前，運用各種技術和過程來發(fā)現(xiàn)和避免這些錯誤。 最有效的測試工作應該開始于需求； 對于每一條需求，如果可以設計出一個過程來執(zhí)行所測試的功能，若輸出結果是可以預先知道的，并且能夠通過編程或者人工方法加以驗證，則稱該需求是可測試的； 測試人員需要徹底了解產(chǎn)品，只有這樣他們才能設計出更出色和更全面的測試計劃，測試設計和測試過程和測試用例。38測試人員及早介入 避免在項目生命周期中的后續(xù)階段對產(chǎn)品的功能行為不理解 了解應用程序的哪些方面對最終用

18、戶而言是最關鍵以及哪些元素的風險最大 測試重點放在應用程序中最重要的部分，避免對不經(jīng)常使用的部分過度測試而對重要的部分又測試不充分。39RequirementsspecificationRequirementsverificationFunctional designspecificationFunctional designverificationCode and spec modification System and acceptance validationCode and spec modification Function validation Code and spec modi

19、fication Integration validation Product simulation Usability test Code Code verification Code and spec modification Unit validation Internal designspecificationInternal design verification40測試的生命周期測試的生命周期p在軟件開發(fā)生命周期中，軟件是通過迭代來不斷加以完善的。p在這種環(huán)境中，對于每個作為測試目標的工作版本，測試的生命周期還都必須具有一種迭代方法。41測試的生命周期測試的生命周期42測試活動的信

20、息流 被測模塊 設 軟 系統(tǒng) 客 計 件 其他 戶 信 需 元素 參 息 求 與 被測模塊 被測模塊 單元測試 單元測試 單元測試 集成測試 確認測試 系統(tǒng)測試 驗收測試 已經(jīng)測試過的模塊 已集成的軟件 已確認的軟件 可交付的軟件 43測試階段的信息流測試階段的輸入信息有兩類：p軟件配置：這是測試的對象，包括 需求說明書 設計說明書 被測的源程序等。p測試配置：包括 測試計劃 測試步驟 測試用例（測試數(shù)據(jù)） 具體實施測試的測試程序 測試工具等 44RUP中 定義測試的目的在于： pFinding and documenting defects in software quality. pGen

21、erally advising about perceived software quality. pProving the validity of the assumptions made in design and requirement specifications through concrete demonstration. pValidating the software product functions as designed. pValidating that the requirements have been implemented appropriately. 45RU

22、PActivities活動46RUP-2001Artifacts工件472 測試過程2.1 單元測試2.2 集成測試2.3 系統(tǒng)測試2.4 驗收測試482.1 單元測試p目的：分別完成每個單元的測試任務，以確保每個模塊能正常工作。 p單元測試-RUP 單元測試在迭代的早期實施，側重于核實軟件的最小可測試元素。單元測試通常應用于實施模型中的構件，核實是否已覆蓋控制流和數(shù)據(jù)流，以及構件是否可以按照預期工作。這些期望值建立在構件參與執(zhí)行用例的方式的基礎上，參與方式可參見該用例的序列圖。實施員在單元的開發(fā)期間執(zhí)行單元測試。實施工作流程對單元測試作出了詳細描述。49單元測試的考慮 p算法和邏輯p模塊接口

23、p數(shù)據(jù)結構（全局和局部）p邊界條件p獨立的路徑p錯誤處理 50單元測試的輔助模塊 p驅(qū)動程序：用于模擬主程序的運行p樁模塊：用于模擬子程序的運行51單元測試的過程 522.2 集成測試p為什么進行集成測試？ 一個模塊可能對另一個模塊產(chǎn)生不利的影響 將子功能合成時不一定產(chǎn)生所期望的主功能 獨立可接受的誤差，在組裝后可能會超過可接受的誤差限度 可能會發(fā)現(xiàn)單元測試中未發(fā)現(xiàn)的接口方面的錯誤 在單元測試中無法發(fā)現(xiàn)時序問題（實時系統(tǒng)） 在單元測試中無法發(fā)現(xiàn)資源競爭問題p集成測試的目的：在模塊組裝后查找模塊間接口的錯誤53集成測試-RUPp執(zhí)行集成測試是為了確保當把實施模型中的構件集成起來執(zhí)行用例時，這些構

24、件能夠正常運行。p測試對象是實施模型中的一個包或一組包。p要集成的包通常來自于不同的開發(fā)組織。p集成測試將揭示包接口規(guī)約中不夠完全或錯誤的地方。54集成測試的方法p非增式測試：采用一步到位的方法來構造測試：對所有模塊進行個別的單元測試后，按程序結構圖將各模塊聯(lián)接起來，把聯(lián)接后的程序當作一個整體進行測試。p增式測試 ：把下一個要測試的模塊同已經(jīng)測試好的模塊結合起來進行測試，一次增加測試的模塊。55非增式測試 56增式測試 增式測試把單元測試與集成測試結合起來進行，將模塊逐步集成起來，逐步完成集成測試。 實施方法： 自頂向下結合 自底向上結合 57兩種集成方法的比較非增式測試增式測試工作量工作量大

25、工作量小接口錯誤發(fā)現(xiàn)錯誤較晚發(fā)現(xiàn)錯誤早錯誤定位錯誤定位難錯誤定位易測試程度測試不徹底測試徹底需要的機器量需要機器量少需要機器量多測試的并行性并行性好并行性差58自頂向下增式測試 p集成步驟：主控模塊作為測試驅(qū)動，所有與主控模塊直接相連的模塊作為樁模塊；根據(jù)集成的方式（深度或廣度），每次用一個替換從屬的樁模塊；在每個模塊被集成時，都必須已經(jīng)進行了單元測試；進行回歸測試以確定集成新模塊后沒有引入錯誤p上述過程從第2步重復進行，直到整個系統(tǒng)結構被集成完成。 59自頂向下增式測試60自底向上增式測試p工作程序： 組裝從最底層的模塊開始，組合成一個構件，用以完成指定的軟件子功能 編制驅(qū)動程序，協(xié)調(diào)測試用

26、例的輸入與輸出； 測試集成后的構件 按程序結構向上組裝測試后的構件，同時除掉驅(qū)動程序61自底向上增式測試62兩種集成測試方法的比較 優(yōu)點缺點自頂向下測試 可以自然地做到逐步求精，一開始便能讓測試者看到系統(tǒng)的框架 需要提供樁模塊 在輸入/輸出模塊接入系統(tǒng)以前，在樁模塊中表示測試數(shù)據(jù)有一定困難 由于樁模塊不能模擬數(shù)據(jù)，如果模塊間的數(shù)據(jù)流不能構成有向的非環(huán)狀圖，一些模塊的測試數(shù)據(jù)難于生成； 觀察和解釋測試輸出往往也是困難的 自底向上測試 由于驅(qū)動模塊模擬了所有調(diào)用參數(shù)，即使數(shù)據(jù)流并未構成有向的非環(huán)狀圖，生成測試數(shù)據(jù)也沒有困難 特別適合于關鍵模塊在結構圖底部的情況 直到最后一個模塊被加進去之后才能看到

27、整個程序（系統(tǒng)）的框架 只有到測試過程的后期才能發(fā)現(xiàn)時序問題和資源競爭問題63討 論p在你的工作中采用了集成測試嗎？如何做的？p集成測試過程中最關鍵的問題是什么？642.3 系統(tǒng)測試 p系統(tǒng)測試實際上是針對系統(tǒng)中各個組成部分進行的綜合性檢驗。p盡管每一個檢驗有著特定的目標，然而所有的檢測工作都要驗證系統(tǒng)中每個部分均已得到正確的集成，并能完成指定的功能 。p系統(tǒng)測試-RUP當將軟件作為整體運行或?qū)嵤┟鞔_定義的軟件行為子集時，即可進行系統(tǒng)測試。這種情況下的目標是系統(tǒng)的整個實施模型。65認識系統(tǒng)測試 什么是系統(tǒng)測試為了發(fā)現(xiàn)缺陷并度量產(chǎn)品質(zhì)量，按照系統(tǒng)的功能和性能需求進行的測試 一般使用黑盒測試技術

28、一般由獨立的測試人員完成對于模塊之間交互性比較強的軟件，還會有單獨的集成測試，用來發(fā)現(xiàn)模塊接口之間的錯誤66認識系統(tǒng)測試 客戶和用戶 Customer v.s. User都是利益相關者，但是終極關注的是客戶 客戶是衣食父母，不是上帝尊重客戶的需求與客戶溝通，讓他理解你的困難和方案，給他咨詢 客戶是人，人就會犯錯誤67認識系統(tǒng)測試 系統(tǒng)測試的常見內(nèi)容1、功能測試 目標：對產(chǎn)品的功能進行測試，檢驗是否實現(xiàn)、是否正確實現(xiàn) 方法：覆蓋產(chǎn)品的功能 工具：回歸測試時候可以使用工具68認識系統(tǒng)測試 系統(tǒng)測試的常見內(nèi)容2、性能測試 目標：對產(chǎn)品的性能進行測試，檢驗是否達標、是否能夠保持 方法：覆蓋系統(tǒng)的性能需

29、求，一般和負載測試結合使用 工具：在需要大訪問量時候尤其需要使用工具69認識系統(tǒng)測試 系統(tǒng)測試的常見內(nèi)容3、負載測試 目標：在人為設置的高負載(大數(shù)據(jù)量、大訪問量)的情況下，檢查系統(tǒng)是否發(fā)生功能或者性能上的問題 方法：人為生成大數(shù)據(jù)量，并利用工具模擬頻繁并發(fā)訪問 工具：一般需要使用工具70認識系統(tǒng)測試 系統(tǒng)測試的常見內(nèi)容4、壓力測試 目標：在人為設置的系統(tǒng)資源緊缺情況下，檢查系統(tǒng)是否發(fā)生功能或者性能上的問題 方法：人為減少可用的系統(tǒng)資源，包括：內(nèi)存、硬盤、網(wǎng)絡、CPU占用、數(shù)據(jù)庫反應時間 工具：一般需要使用工具71認識系統(tǒng)測試 系統(tǒng)測試的常見內(nèi)容5、疲勞測試 目標：在一段時間內(nèi)(經(jīng)驗上一般是連

30、續(xù)72小時)保持系統(tǒng)功能的頻繁使用，檢查系統(tǒng)是否發(fā)生功能或者性能上的問題 方法：人為設置不同功能的連續(xù)重復操作 工具：一般需要使用工具72認識系統(tǒng)測試 系統(tǒng)測試的常見內(nèi)容6、易用性測試 目標：檢查系統(tǒng)界面和功能是否容易學習、使用方式是否規(guī)范一致，是否會誤導用戶或者使用模糊的信息 一般與功能測試結合使用 方法：可以采用用戶操作、觀察(錄像)、反饋并評估的方式73認識系統(tǒng)測試 系統(tǒng)測試的常見內(nèi)容7、安裝測試 目標：檢查系統(tǒng)安裝是否能夠安裝所有需要的文件/數(shù)據(jù)并進行必要的系統(tǒng)設置；檢查系統(tǒng)安裝是否會破壞其他文件或配置；檢查系統(tǒng)安裝是否可以中止并恢復現(xiàn)場；檢查系統(tǒng)是否能夠正確卸載并恢復現(xiàn)場；檢查安裝和

31、卸載過程的用戶提示和功能是否出現(xiàn)錯誤有時候?qū)惭b測試作為功能測試的一部分74認識系統(tǒng)測試 系統(tǒng)測試的常見內(nèi)容8、配置測試 目標：在不同的硬件配置下，在不同的操作系統(tǒng)和應用軟件環(huán)境中，檢查系統(tǒng)是否發(fā)生功能或者性能上的問題 方法：一般需要建立測試實驗室，IE4.0測試實驗室建立花費了$200萬75認識系統(tǒng)測試 系統(tǒng)測試的常見內(nèi)容9、文檔測試 目標：檢查系統(tǒng)的文檔是否齊全，檢查是否有多余文檔或者死文檔，檢查文檔內(nèi)容是否正確/規(guī)范/一致，檢查CI是否正確 方法：一般由單獨的一組測試人員實施76認識系統(tǒng)測試 系統(tǒng)測試的常見內(nèi)容10、安全測試(包括病毒、加密、權限) 目標檢查系統(tǒng)是否有病毒檢查系統(tǒng)是否正確

32、加密檢查系統(tǒng)在非授權的內(nèi)部或外部用戶訪問或故意破壞時候是否出現(xiàn)錯誤77認識系統(tǒng)測試 系統(tǒng)測試的常見內(nèi)容11、恢復測試 目標：在人為使發(fā)生系統(tǒng)災難(系統(tǒng)崩潰、硬件損壞、病毒入侵等)的情況下，檢查系統(tǒng)是否能夠恢復被破壞的環(huán)境和數(shù)據(jù)78認識系統(tǒng)測試 系統(tǒng)測試的常見內(nèi)容12、回歸測試 目標：檢查系統(tǒng)變更之后是否引入新的錯誤或者舊的錯誤重新出現(xiàn)，尤其是在每次Biuld之后和穩(wěn)定期測試的時候 工具：一般使用工具，一般依賴于測試用例庫和缺陷報告庫79認識系統(tǒng)測試 系統(tǒng)測試的常見內(nèi)容13、健全測試 目標：檢查系統(tǒng)的功能和性能是否基本可以正常使用，來確定是否可以繼續(xù)進行系統(tǒng)測試的其他內(nèi)容 方法：正常安裝，并使用

33、正常情況下的測試用例對主要功能進行測試；同時檢查系統(tǒng)文檔是否齊全80認識系統(tǒng)測試 系統(tǒng)測試的常見內(nèi)容14、交付測試 目標：關閉所有缺陷報告，確保系統(tǒng)達到預期的交付標準 方法：一般需要結合回歸測試，并謹慎處理新出現(xiàn)的Bug 交付測試也稱為穩(wěn)定期測試，有時候與系統(tǒng)測試獨立劃分81認識系統(tǒng)測試 系統(tǒng)測試的常見內(nèi)容15、演練測試 目標：在交付給用戶之前，利用相似的用戶環(huán)境進行測試例如：奧運會MIS系統(tǒng)在2008年前用于其他比賽82認識系統(tǒng)測試 系統(tǒng)測試的常見內(nèi)容16、背靠背測試 目標：設置一組以上的測試團隊，在互相不進行溝通的情況下獨立進行相同的測試項目，用來評估測試團隊的效果并發(fā)現(xiàn)更多的錯誤 開始用

34、于測試外包，現(xiàn)在也用于內(nèi)部測試83認識系統(tǒng)測試 系統(tǒng)測試的常見內(nèi)容17、度量測試 目標：在系統(tǒng)中人為地放入錯誤(播種)，并根據(jù)被發(fā)現(xiàn)的比例來確定系統(tǒng)中遺留的錯誤數(shù)量 開始用于測試外包，現(xiàn)在也用于內(nèi)部測試84認識系統(tǒng)測試 系統(tǒng)測試的常見內(nèi)容18、比較測試 目標：與競爭產(chǎn)品及本產(chǎn)品的舊版本測試同樣的內(nèi)容，來確定系統(tǒng)的優(yōu)勢和劣勢 嚴格地說，比較測試屬于系統(tǒng)測評的內(nèi)容 BenchMarking是一種特殊的比較測試85認識系統(tǒng)測試 系統(tǒng)測試的常見內(nèi)容實際上，以上18種測試內(nèi)容并不是都要進行的，而是在制定測試策略和測試計劃的時候有不同的側重點，這與測試目標、測試資源、軟件系統(tǒng)特點和業(yè)務環(huán)境有關。862.4

35、 驗收測試 驗收測試是檢驗軟件產(chǎn)品質(zhì)量的最后一道工序。驗收測試的目的是確保軟件準備就緒，并且可以供最終用戶用于執(zhí)行軟件的既定功能和任務。驗收測試主要在于它突出了客戶的作用，這是與前面討論的各種測試活動不同之處。用戶在現(xiàn)場或直接參與測試。驗收測試可以重復確認測試中所使用的全部測試或部分測試，或采用完全由用戶自己開發(fā)的測試。 87驗收測試正式驗收非正式驗收或Alpha測試Beta測試p選擇的策略通常建立在合同需求、組織和公司標準以及應用領域的基礎上。p某些驗收測試（如工廠驗收而不是現(xiàn)場驗收）是部署軟件之前的最后一個測試操作。此時采用后兩種測試方法88驗收測試的范圍 明確驗收項目，規(guī)定驗收測試通過的

36、標準；確定測試方法；決定驗收測試的組織機構和可供利用的資源；選定測試結果分析方法；制定驗收測試計劃并進行評審；設計驗收測試所用測試用例；審查驗收測試準備工作；執(zhí)行驗收測試；分析測試結果；闡明驗收測試結論，決定通過驗收或是拒絕 89確認測試p 確認測試是檢驗所開發(fā)的軟件是否能按顧客提出的要求運行。p若能達到這一要求，則認為開發(fā)的軟件是合格的，確認測試也稱為合格性測試 90測試和測試通常由用戶或其他人（非開發(fā)人員和測試人員）來完成測試：在開發(fā)即將完成時對應用進行的測試，此時仍然允許對設計作微小的變動;測試：在開發(fā)基本完成時進行，于正式發(fā)布之前尋找程序中的錯誤913 測試方法p靜態(tài)方法和動態(tài)方法 p

37、黑盒測試和白盒測試p回歸測試方法p自頂向下方法和自底向上方法p模擬用戶操作測試方法p自動方法和手工方法92靜態(tài)方法和動態(tài)方法 p靜態(tài)方法的主要特征是在用計算機測試源程序時，計算機并不真正運行被測試的程序，只對被測程序進行特性分析。因此，靜態(tài)方法常稱為“分析”，靜態(tài)分析是對被測程序進行特性分析的一些方法的總稱。p動態(tài)方法的主要特征是計算機必須真正運行被測試的程序，通過輸入測試用例，對其運行情況(輸入/輸出的對應關系)進行分析。 93黑盒測試 p黑盒測試（Blackbox Testing）又稱功能測試、數(shù)據(jù)驅(qū)動測試或基于規(guī)格說明的測試，是一種從用戶觀點出發(fā)的測試。p被測程序被當作一個黑盒，不考慮程

38、序內(nèi)部結構和內(nèi)部特性，測試者只知道該程序輸入和輸出之間的關系或程序的功能，依靠能夠反映這一關系和程序功能的需求規(guī)格說明書考慮確定測試用例和推斷測試結果的正確性。p軟件的黑盒測試被用來證實軟件功能的正確性和可操作性。 94白盒測試白盒測試（Whitebox Testing）又稱結構測試、邏輯驅(qū)動測試或基于程序的測試。它依賴于對程序細節(jié)的嚴密檢驗，針對特定條件和/與循環(huán)集設計測試用例，對軟件的邏輯路經(jīng)進行測試。在程序的不同點檢驗“程序的狀態(tài)”以判定其實際情況是否和預期的狀態(tài)相一致。軟件的白盒測試用來分析程序的內(nèi)部結構95白盒測試 白盒測試要求對某些程序的結構特性做到一定程度的覆蓋，或者說是“基于覆

39、蓋的測試” 。 最為常見的程序結構覆蓋有：語句覆蓋：它要求被測程序的每一可執(zhí)行語句在測試中盡可能都檢驗過，這是最弱的邏輯覆蓋準則；分支覆蓋或判定覆蓋：要求程序中所有判定的分支盡可能得到檢驗；條件覆蓋：當判定式中含有多個條件時，要求每個條件的取值均得到檢驗；判定條件覆蓋：同時考慮條件的組合值及判定結果的檢驗；路徑覆蓋：只考慮對程序路徑的全面檢驗。取得測試覆蓋的方法程序插裝 96黑盒測試與白盒測試的比較 黑 盒 測 試 白 盒 測 試 測 試 規(guī) 劃 根據(jù)用戶的規(guī)格說明，即針對命令、信息、報表等用戶界面及體現(xiàn)它們的輸入數(shù)據(jù)與輸出數(shù)據(jù)之間的對應關系，特別是針對功能進行測試。 根據(jù)程序的內(nèi)部結構，比如

40、語句的控制結構，模塊間的控制結構以及內(nèi)部數(shù)據(jù)結構等進行測試。 優(yōu) 點 能站在用戶立場上進行測試。 能夠?qū)Τ绦騼?nèi)部的特定部位進行覆蓋測試。 特 點 缺 點 不能測試程序內(nèi)部特定部位。 如果規(guī)格說明有誤，則無法發(fā)現(xiàn)。 無法檢驗程序的外部特性。 無法對未實現(xiàn)規(guī)格說明的程序內(nèi)部欠缺部分進行測試。 方 法 舉 例 基于圖的測試 等價類劃分 邊值分析 比較測試 語句覆蓋 判定覆蓋 條件覆蓋 判定/條件覆蓋 基本路徑覆蓋 循環(huán)覆蓋 模塊接口測試 97回歸測試p目標： 修改的或增加的部分是正確的 沒有引起其他部分產(chǎn)生錯誤p應用：增量開發(fā) 版本控制 軟件維護98回歸測試方法舉例： 全部再測試（Retest Al

41、l) 再測試風險用例(Retest Risky Use Case) 按綱要再測試(Retest by Profile) 再測試修改的段(Retest Changed Segments) 防火墻內(nèi)再測試（Retest Within Firewall）99模擬用戶操作測試方法p基于對用戶如何使用被測試軟件的了解來開發(fā)測試的方法。p經(jīng)驗告訴我們，復雜的軟件產(chǎn)品有許多錯誤，但用戶一般只能找出這些錯誤中很少的一部分。p為給用戶帶來最大利益，要著重對那些用戶可能發(fā)現(xiàn)的錯誤進行測試和修改工作。1004 測試類型p（質(zhì)量維度1） 可靠性測試p完整性測試：側重于評估測試對象的強壯性（防止失敗的能力），語言、語法

42、的技術兼容性以及資源利用率的測試。該測試針對不同的測試對象實施和執(zhí)行，包括單元和已集成單元。 p結構測試：側重于評估測試目標是否符合其設計和構造的測試。通常對基于 Web 的應用程序執(zhí)行該測試，以確保所有鏈接都已連接、顯示正確的內(nèi)容以及沒有孤立的內(nèi)容。101測試類型（質(zhì)量維度2） 功能測試p配置測試：側重于確保測試對象在不同的硬件和/或軟件配置上按預期運行的測試。該測試還可以作為系統(tǒng)性能測試來實施。 p功能測試：側重于核實測試對象按計劃運行，提供需求的服務、方法或用例的測試。該測試針對不同的測試對象實施和執(zhí)行，包括單元、已集成單元、應用程序和系統(tǒng)。 p安裝測試：側重于確保測試對象在不同的硬件和

43、/或軟件配置上，以及在不同的條件下（磁盤空間不足或電源中斷）按預期安裝的測試。該測試針對不同的應用程序和系統(tǒng)實施和執(zhí)行。 p安全測試：側重于確保只有預期的主角才可以訪問測試對象、數(shù)據(jù)（或系統(tǒng)）的測試。該測試針對多種測試對象實施和執(zhí)行。 p容量測試：側重于核實測試對象對于大量數(shù)據(jù)（輸入和輸出或駐留在數(shù)據(jù)庫內(nèi)）的處理能力的測試。容量測試包括多種測試策略，如創(chuàng)建返回整個數(shù)據(jù)庫內(nèi)容的查詢；或者對查詢設置很多限制，以至不返回數(shù)據(jù)；或者返回每個字段中最大數(shù)據(jù)量的數(shù)據(jù)條目。102測試類型（質(zhì)量維度（質(zhì)量維度3 3） 性能測試性能測試p基準測試：一種性能測試，該測試將比較（新的或未知的）測試對象與已知的參照負

44、載和系統(tǒng)的性能。 p競爭測試：側重于核實測試對象對于多個主角對相同資源（數(shù)據(jù)記錄、內(nèi)存等）的請求的處理是否可以接受的測試。 p負載測試：一種性能測試，用于在測試的系統(tǒng)保持不變的情況下，核實和評估系統(tǒng)在不同負載下操作極限的可接受性。 評測包括負載和響應時間的特征。如果系統(tǒng)結合了分布式構架或負載平衡方法，將執(zhí)行特殊的測試以確保分布和負載平衡方法能夠正常工作。 p性能曲線：在該測試中，將監(jiān)測測試對象的計時配置文件，包括執(zhí)行流、數(shù)據(jù)訪問、函數(shù)和系統(tǒng)調(diào)用，以確定并解決性能瓶頸和低效流程。 p強度測試：一種性能測試，側重于確保系統(tǒng)可在遇到異常條件時按預期運行。系統(tǒng)面對的工作強度可以包括過大的工作量、不充足

45、的內(nèi)存、不可用的服務/硬件或過低的共享資源。103測試類型其他測試術語其他測試術語p恢復測試（例如，硬件故障或用戶不良數(shù)據(jù)引起的一些情況）p兼容性測試 對軟硬件、操作系統(tǒng)、網(wǎng)絡的兼容性測試p比較測試 與同類產(chǎn)品進行比較，列出優(yōu)缺點 p算法測試 確定是否已正確實現(xiàn)算法p正向測試 確定正確使用軟件是軟件某一特性產(chǎn)生的結果是否與需求一致p逆向測試 確定軟件無效輸入或非法操作的處理是否合理p邊界測試 測試產(chǎn)品特定的限制，如最大值、最小值，確定軟件在這些特定的限制下是否能正常工作p時序測試p突變測試（mutation testing） 判斷測試用例是否有效的方法 p等等1045 測試策略測試階段目的執(zhí)行者測試方法單元測試查找獨立模塊中邏輯錯誤、數(shù)據(jù)錯誤和算法錯誤軟件工程師結構測試集成測試查找模塊之間接口錯誤軟件工程師測試人員結構測試、自頂向下或自底向上回歸測試確