軟件測試課件9

1、軟件工程學科研究生課程 軟件質(zhì)量保證與測試1.導言2.特征描述3.假設(shè)前提4.測試方法5.測試套件(Test Suites)結(jié)構(gòu)6.測試環(huán)境7.測試執(zhí)行策略8.測試工作量估計9.安排進度和測試里程碑(Test Milestone)1.導言2.特征描述3.假設(shè)前提4.測試方法5.測試套件(Test Suites)結(jié)構(gòu)6.測試環(huán)境7.測試執(zhí)行策略8.測試工作量估計9.安排進度和測試里程碑(Test Milestone)測試計劃的結(jié)構(gòu)和目標1.導言2.特征描述3.假設(shè)前提4.測試方法5.測試套件(Test Suites)結(jié)構(gòu)6.測試環(huán)境7.測試執(zhí)行策略8.測試工作量估計9.安排進度和測試里程碑(Te

2、st Milestone)總結(jié)被測試的系統(tǒng)特征1.導言2.特征描述3.假設(shè)前提4.測試方法5.測試套件(Test Suites)結(jié)構(gòu)6.測試環(huán)境7.測試執(zhí)行策略8.測試工作量估計9.安排進度和測試里程碑(Test Milestone)由于各種原因，測試計劃中沒有進行設(shè)計的測試用例部分1.導言2.特征描述3.假設(shè)前提4.測試方法5.測試套件(Test Suites)結(jié)構(gòu)6.測試環(huán)境7.測試執(zhí)行策略8.測試工作量估計9.安排進度和測試里程碑(Test Milestone)識別出測試分類1.導言2.特征描述3.假設(shè)前提4.測試方法5.測試套件(Test Suites)結(jié)構(gòu)6.測試環(huán)境7.測試執(zhí)行策略

3、8.測試工作量估計9.安排進度和測試里程碑(Test Milestone)基于測試方法部分識別出的測試分類，在測試套件結(jié)構(gòu)中列出詳細測試組和下屬組1.導言2.特征描述3.假設(shè)前提4.測試方法5.測試套件(Test Suites)結(jié)構(gòu)6.測試環(huán)境7.測試執(zhí)行策略8.測試工作量估計9.安排進度和測試里程碑(Test Milestone)計劃并設(shè)計測試環(huán)境（也測試平臺或測試實驗室）1.導言2.特征描述3.假設(shè)前提4.測試方法5.測試套件(Test Suites)結(jié)構(gòu)6.測試環(huán)境7.測試執(zhí)行策略8.測試工作量估計9.安排進度和測試里程碑(Test Milestone)有用而高效的執(zhí)行策略必須考慮測試執(zhí)

4、行、缺陷檢查和缺陷修復該策略清晰地定義了開始系統(tǒng)測試的進入條件如何安排測試用例執(zhí)行的先后次序何時從一個測試周期過渡到下一個何時重新執(zhí)行失敗的測試用例何時暫停一個測試周期和啟動原因分析如何為回歸測試的最終測試周期選擇測試用例的子集測試周期由6個參數(shù)表示目標：假設(shè)測試執(zhí)行（測試優(yōu)先級排序）重做和延長標準行動退出條件（周期的結(jié)束）涉及5個功能交叉組：營銷硬件軟件技術(shù)發(fā)布和系統(tǒng)測試每個組有一到多個條件項，當所有條件項都滿足是，系統(tǒng)測試才開始應用回歸測試的概念基于以下幾點選擇：測試用例之前的執(zhí)行結(jié)果測試用例的成員屬性：基本要素、功能性、健壯性、互操作性、可擴展性、性能、負載、穩(wěn)定性測試用例與已經(jīng)修改的軟

5、件組件的關(guān)聯(lián)性第一個測試周期原理：允許最大數(shù)量的測試用例完全執(zhí)行而不被阻塞第二個測試周期原理：前一次測試中失敗的測試用例在本次測試周期中要盡早執(zhí)行第三個測試周期原理：與第二個測試周期相似測試工作量一人一天創(chuàng)建的測試用例數(shù)量一人一天執(zhí)行的測試用例數(shù)量測試用例數(shù)量估計基于測試組類別的估計基于功能點的估計通過分析需求文檔來估算資源，這種方法學最早由A.J. Albrecht提出一個系統(tǒng)的功能點由軟件生成的輸入、輸出、主文件、查詢這些數(shù)量的加權(quán)總和UFP= WFNIxNI + WFNOxNO + WFNQxNQ + WFNLxNL + WFNExNEUFP：未經(jīng)調(diào)整功能點數(shù)NI ：外部輸入類型數(shù)NO：

6、外部輸出類型數(shù)NQ：外部查詢類型數(shù)NF：內(nèi)部邏輯文件類型數(shù)NE：外部接口文件類型數(shù)WF ： 加權(quán)因子經(jīng)驗公式來計算一個系統(tǒng)的功能點FP FP = UFP x (0.65 + 0.01 x PCA)PCA：復雜度調(diào)整因子，由14種會影響一個項目的必需開發(fā)工作量的因子的評級總和構(gòu)成，每種因子會指定一個0 5之間的評級因此， FP的值通過PCA在正負35%的范圍內(nèi)波動測試用例數(shù)量通過下面兩種方式估計間接方式Caper Jones給出了一個功能點和軟件代碼行數(shù)LOC間的關(guān)系Hitachi Software經(jīng)過30年的研究結(jié)果，給出了沒10 15行代碼需要一個測試用例這樣一個標準直接方式Caper Jo

7、nes給出了如下關(guān)系：測試用例數(shù)量總和 = (FP) 1.2為測試項目制定日程表和里程碑的重要性測試項目管理面臨的問題：時間vs質(zhì)量測試工作量的估計和時間安排要反復進行以確保它們是可靠的用甘特（Gantt）圖來表示項目的時間表，包括各個任務(wù)的持續(xù)時間、任務(wù)依賴關(guān)系和他們的順序例如: 常見的項目管理工具MS Project等自動化測試的優(yōu)點：提高測試工程師的生產(chǎn)力回歸測試的覆蓋測試用例的可重用性一致性測試減少測試間隔降低軟件維護成本提高測試效率評估自動化測試準備就緒的先決條件：系統(tǒng)穩(wěn)定，功能定義良好需要自動化執(zhí)行的測試用例定義良好測試工具和基礎(chǔ)設(shè)施已到位測試人員已具有自動化測試的成功經(jīng)驗分配了充

8、足的預算用于采購軟件工具好的自動化測試利用計算機的能力利用計算機的能力去執(zhí)行人力無法有效執(zhí)行的測試 軟件發(fā)布前或維護時，可能需要執(zhí)行上百次、上千次、甚至百萬次的測試自動化測試不是測試工程師的替代品不是測試工程師的替代品 能思考的人執(zhí)行測試的作用遠遠超過機器有效地利用，自動化測試會節(jié)省大量的時間和開支選取windows自帶軟件或web站點為例組織學生討論 為確保軟件質(zhì)量需要進行哪些測試？ 哪些測試可以交由工具完成？ 哪些測試必須由工具完成？需要適用機器和軟件工具機器和軟件工具 用軟件把已存在的手工測試過程自動化模擬人工操作 設(shè)置測試環(huán)境 控制測試的執(zhí)行過程完成對被測試軟件的輸入 自動執(zhí)行對輸出結(jié)

9、果結(jié)果進行檢驗檢驗 比較實際結(jié)果和預期結(jié)果記錄測試結(jié)果測試結(jié)果 生成測試結(jié)果報告階段一：手工測試階段二：硬編碼測試自動化階段三：測試庫和框架階段四：數(shù)據(jù)驅(qū)動測試階段五：基于模型的測試手工測試的原因 有一些測試很難自動化 有些測試只需測試一次或有限次 產(chǎn)品功能變更頻繁 調(diào)整自動測試耗費大量成本手工測試可以是 仔細計劃的：系統(tǒng)性的、覆蓋關(guān)鍵場景 隨機的：嘗試不同的變量，測試未被計劃的場景不可輕視手工測試 容易進行，在特定情況下有效且高效手工測試的局限 只可能用于端到端的測試，不能用于不能用于APIAPI測試測試 本質(zhì)上不可重復 如果要重復執(zhí)行，代價較大， 如果發(fā)生人事變動，還要重新培訓比如 記錄和

10、回放用戶界面測試 直接使用目標API取樣測試優(yōu)點 容易并且快速自動化局限性 脆弱：只在有限幾種環(huán)境下可以工作，極小的變更都會導極小的變更都會導致無法工作致無法工作 維護：產(chǎn)品做了極小變更都會導致對自動化腳本的極大變更適用的場景 測試自動化概念驗證 用于測試那種一旦完成就不輕易改變的功能測試那種一旦完成就不輕易改變的功能建構(gòu)一個測試庫/測試框架（Test Harness） 常見任務(wù)使用庫優(yōu)勢 更多的代碼共享和重用 更強健的測試代碼 更低的維護和改進成本 編寫額外測試代碼更快 更適應變化基于不同類型的數(shù)據(jù)輸入，編寫一次測試代碼，就可以覆蓋不同的測試場景 容易增加新的測試用例而不用編寫新代碼 絕大部

11、分或者全部測試用例及其衍生場景，都可以使用數(shù)據(jù)來描述（例如，參數(shù)、文件、數(shù)據(jù)庫） 更大的適應性和擴展性、更低的維護成本 局限 需要花時間來理解測試代碼部署配置系統(tǒng)的自動化工具針對某個場景的自動化工具簡單多次重復的測試手工測試無法實現(xiàn)的場景（API測試）高頻率執(zhí)行的回歸測試需要精確數(shù)據(jù)的測試測試開發(fā)標準測試維護標準測試執(zhí)行標準測試結(jié)果標準測試管理標準GUI測試能力標準供應商資格標準定價標準波動?。簻y試用例穩(wěn)定了重復性：如回歸測試高風險易于實現(xiàn)自動化手工難以執(zhí)行繁瑣耗時很多非功能測試都適合自動化 API自動化測試 性能測試 負載測試 壓力測試 安全性測試 國際化/本地化測試用于度量軟件系統(tǒng)對用戶各

12、種操作的響應時間 度量產(chǎn)品在受限環(huán)境下的性能常見任務(wù) 定義性能目標、建立性能基準，不斷進行系統(tǒng)調(diào)優(yōu) 驗證穩(wěn)定性和可靠性，預知高并發(fā)下系統(tǒng)運行情況 決定硬件和軟件采購計劃模擬許多用戶同時訪問一臺服務(wù)器的情況負載測試可用于 冒煙測試：確定在短時間內(nèi)負載較小時應用程序如何執(zhí)行 壓力測試：確定在較長時間內(nèi)負載較大時應用程序是否能成功運行 容量測試：確定在各種容量下應用程序如何執(zhí)行壓力測試是性能測試的一種專門形式 目的是使應用程序產(chǎn)生故障 通過增加處理負載使其性能降低 直到由于資源飽和或發(fā)生錯誤而使應用程序開始出問題壓力測試在強負載（大數(shù)據(jù)量、大量并發(fā)用戶等）下的測試，查看應用系統(tǒng)的某項功能隱患、系統(tǒng)是

13、否具有良好的容錯能力和可恢復性能力 并發(fā)性能 疲勞強度 大數(shù)據(jù)量關(guān)鍵業(yè)務(wù)應用必須應用此測試關(guān)鍵業(yè)務(wù)應用必須應用此測試查找應用程序或系統(tǒng)的潛在軟肋 避免被利用來對系統(tǒng)進行攻擊作用 提升客戶滿意度 降低安全風險微軟安全性測試的經(jīng)驗總結(jié) 不要使用“系統(tǒng)管理員”權(quán)限來運行測試 在一個安全的文件系統(tǒng)上進行測試 不修改任何在注冊表HKLM下的條目和%programfiles%目錄下的文件 不使用明文存儲或發(fā)送機密信息微軟安全性測試的經(jīng)驗總結(jié) 使用壞數(shù)據(jù)來挑戰(zhàn)應用極限 在有2個或者2個以上處理器的計算機上進行測試 盡可能利用工具 多分析源代碼威脅建模（Threat modeling） Review（微軟的一

14、個威脅模型工具） SDL Threat Modeling Tool靜態(tài)分析（Static analysis） prefix,prefast,fxcop,BadApi運行時分析（動態(tài)分析，Runtime analysis） AppVerifier攻擊表面分析（Attack surface analysis） XRAY滲透性攻擊（Penetration） fuzzing, elevation of privileges國際化模型 i18N internationalization model比如 在windows系統(tǒng)通過修改“區(qū)域設(shè)置”中的默認習俗設(shè)置來達成包括修改 數(shù)字格式、貨幣格式 時間格式、

15、日期格式 日歷格式、字符集1.決定使用自動化測試2.取得測試工具3.測試計劃、設(shè)計與開發(fā) 計劃、feature、測試用例、測試工具、應用framework或自己寫工具4. 執(zhí)行并管理測試 執(zhí)行、調(diào)用目標應用程序執(zhí)行預定義操作 取得結(jié)果（截屏、取控件值） 比照結(jié)果 結(jié)論與報告 跟蹤Bug&新build流程 測試狀態(tài)跟蹤5. 測試活動的審查和評估簡單化：測試用例應有一個單一的目標，測試步驟不超過10-15（不包括設(shè)置和清除步驟）模塊化健壯性和可靠性可重復使用：避免硬編碼可維護有記錄獨立自足：數(shù)據(jù)值獨立失敗獨立最終狀態(tài)獨立1)簡單的自動化測試只需要啟動一個程序或一段腳本2)大型的自動化測試則

16、依賴復雜的構(gòu)造框架（framework）確保一輪測試（test pass）產(chǎn)生格式一致、通用的測試報告3) 構(gòu)造完好的自動化測試系統(tǒng)應該使得完成整個測試套件的執(zhí)行就像是按一下按鈕 Test Harness + Automation Framework + Set of Tools = Infrastructure (基礎(chǔ)設(shè)施 ) 測試用例例 Test Cases自動化框架 Automation Framework測試框架/工具 Test Harness /Tools1) 用于測試軟件的自動化工具 包含軟件和測試數(shù)據(jù)（數(shù)據(jù)經(jīng)過配置） 測試一個程序單元 控制測試在不同的條件下運行 監(jiān)控行為和輸出

17、2) 一般特點 結(jié)構(gòu)化 自我文檔化 自動并可重復執(zhí)行 基于已知數(shù)據(jù) 被設(shè)計為可測試正常和異常的行為 尤其適合于在不同機器上進行測試的實現(xiàn) 3) 一般結(jié)構(gòu)：測試執(zhí)行引擎+測試腳本儲存庫 Test Harness 的目標 測試過程自動化。 執(zhí)行測試用例。 生成相關(guān)的測試報告. Test Harness的組成部分 TCM (Test Case management)測試用例管理 測試代碼框架 UI庫 測試代碼結(jié)構(gòu) 報告系統(tǒng) 測試用例執(zhí)行引擎 自動化測試設(shè)計-測試框架的典型執(zhí)行過程 自動執(zhí)行測試用例（測試用例）保存數(shù)據(jù) 確定附加的數(shù)據(jù)傳遞正常 順序執(zhí)行 隨機執(zhí)行 指定順序（取決于Test Harnes

18、s或者數(shù)據(jù) 包括測試狀態(tài) 到文件、調(diào)試器或其他位置自動化測試設(shè)計-自動化框架1）測試腳本的基礎(chǔ)代碼（Libraries）2）測試的規(guī)范3）測試慣例的集合自動化框架的實例1）UI Libraries -Windows UI Library -Web UI Library2）日志（Logging）3）錯誤處理自動化框架-日志目標（Logging）1）測試日志應該易于診斷 -在不需要使用或參考debugger、產(chǎn)品源代碼、測試源代碼 -這并不代表產(chǎn)品或測試的源代碼不能在問題解決前被引用 -僅從執(zhí)行情況的記錄中，測試員應該有能力判定并區(qū)分錯誤的原因 -為區(qū)分一個錯誤異常，測試和產(chǎn)品代碼必須了解的信息都應該在log內(nèi)出現(xiàn)2）測試日志