《軟件測試技術經典教程筆記(修)》由會員分享，可在線閱讀，更多相關《軟件測試技術經典教程筆記(修)（10頁珍藏版）》請在裝配圖網上搜索。

第一章 基礎知識 1.1、軟件 1)、軟件=程序+文檔 2)、分類 功能：系統+應用 架構：單機+C/S+B/S 用戶：產品+項目 規(guī)模：小型+中型+大型 1.2、Bug 1)、類型一(廣義上，軟件生命周期，與用戶需求不符的問題)： 完全沒有實現的功能 基本實現功能，但有功能上或性能上的問題 實現了用戶不需要的功能 2)、類型二(測試執(zhí)行階段的問題) Defect---------Requirements&Design Error-----------Development Bug------------Testing Failure---------Post production 1.3、測試 1)、概念： 測試是為了檢驗實際的軟件是否符合用戶需求，所以不能為了發(fā)現錯誤而發(fā)現錯誤。使用人工或自動手段，來運行或測試某個系統的過程。 2)、測試環(huán)境：硬件+軟件+網絡 要求：真實(項目、產品)+干凈+無毒+獨立(測試與開發(fā)) 1.4、測試用例 測試用例=輸入+輸出+測試環(huán)境 便于團隊交流，便于重復測試，便于跟蹤統計，比納與用戶自測 開發(fā)生命周期 需求分析 → 概要設計 → 詳細設計 → 編碼 → 維護 測試生命周期 測試計劃 → 測試設計 → 測試執(zhí)行 → 測試評估 需求分析和測試計劃完成后，根據《系統需求規(guī)格說明書》和軟件原型(DEMO)寫測試用例 1.5 其他 1)、測試人員素質要求：細心、耐心、信心、服務意識、團隊合作意識、溝通能力 2)、如何成為優(yōu)秀的測試工程師：1、不斷學習充電 2、閱讀原版書籍 3、閱讀缺陷管理系統中的缺陷報告 4、閱讀高手寫的測試用例 5、學習產品相關的業(yè)務知識 1.6 軟件測試的基本規(guī)則 1) Zero Bug 與 Good Enough Good Enough原則：不充分測試是不負責任，過分的測試是一種資源浪費。 參考：*遺留bug不超過10個，嚴重的不超過5個 *測試用例執(zhí)行率為100%，通過率為95% *單元測試，關鍵模塊語句覆蓋率達到100%，分支覆蓋率達到85% 2) 不要視圖窮舉法 3) 開發(fā)人員不能既是運動員又是裁判員 4) 軟件測試要盡早執(zhí)行 5) 軟件測試應該追溯需求 原始需求 需求分析 正確的規(guī)格說明 錯誤的規(guī)格說明 設計 正確的設計 錯誤的設計 對錯誤說明的設計 編碼 正確編碼 錯誤的編碼 對錯誤設計編碼 對錯誤說明設計的編碼 測試 正確功能 可改正的錯誤 不可改正的錯誤 潛伏的錯誤 不完善的軟件產品 6) 缺陷的二八定理 一般情況下，軟件80%的缺陷集中在20%的模塊中。 7) 缺陷具有免疫性 缺陷具有免疫性，需要根據新版本修改維護測試用例，另外，有一個值得注意的經驗：沒修復3-4個bug，可能會產生一個新bug。 第二章 測試分類 2.1、是否運行程序 Static Testing------------代碼規(guī)范、界面、文檔 Dynamic Testing--------運行程序 2.2、根據階段分類 Unit Testing(單元測試)----------10% 最小模塊，依據源程序和《詳細設計》 白盒測試人員||開發(fā)人員 編譯代碼→靜態(tài)測試→動態(tài)測試 樁模塊(Stub)、驅動模塊(Driver) Integration Testing(集成測試)----------20% 模塊間的接口，依據單元測試的模塊和《概要設計》 白盒測試人員||開發(fā)人員 一般單元和集成同步進行 System Testing(系統測試)----------40% 整個系統(功能、性能、軟硬件環(huán)境)，依據《需求規(guī)格說明書》 黑盒測試工程師 Acceptance Testing(驗收測試)----------20% 整個系統(功能、性能、軟硬件環(huán)境)，依據《需求規(guī)格說明書》和驗收標準 用戶，可配合黑盒測試工程師 α測試：內側 β測試：公測 2.3、是否查看代碼 1)、White-Box Testing-----源代碼的測試 2)、Black-Box Testing-----功能測試、性能測試 Function Testing(功能測試) Logic Function Testing(邏輯功能測試) UI Testing(界面測試)：窗口、下拉式菜單和鼠標操作 Usability Tseting(易用性測試) Installation Testing(安裝測試) Compatibility Testing(兼容性測試) 其他：恢復測試、裸機測試、確認測試、接口測試、數據庫測試、安全測試、配置測試 Performance Testing(性能測試) 時間性能：主要指一個事務的具體響應時間(Respind Time)。 空間性能：主要指軟件運行時所消耗的系統資源(CPU、內存、硬盤)。 分類：一般性能測試、穩(wěn)定性測試、負載測試、壓力測試 a、一般性能測試：讓被測系統在正常的軟硬件環(huán)境下運行，不向其施加任何壓力 b、穩(wěn)定性測試(也叫Reliability Testing 可靠性測試)：指連續(xù)運行被測系統，檢查系統運行時的穩(wěn)定程度。通常用MTBF(Mean Time Between Failure) c、負載測試(Load Testing)：讓被測系統在其能忍受的壓力極限范圍內連續(xù)運行，檢測系統的穩(wěn)定性。 d、壓力測試(Stress Testing)：持續(xù)不斷的給被測系統增加壓力，知道被測系統壓垮為止，用來測試系統能承受最大壓力。 2.4、回歸測試、冒煙測試、隨機測試 Regression Testing(回歸測試)：軟件新版本測試時，重新執(zhí)行上一個版本測試用例。可以在任何階段進行（單元測試、集成測試、系統測試、驗收測試等），既有黑盒測試的回歸，也有白盒測試的回歸。 Smoke Testing(冒煙測試)：對一個新版本進行系統大規(guī)模的測試之前，先驗證一下軟件的基本功能是否實現，是否具備可測性。 Random Testing(隨機測試)：指測試中所有的輸入數據都是隨機生成的，其目的是模擬用戶的真實操作，并發(fā)現一些邊緣性的錯誤。 第三章 測試技術 黑盒測試技術 3.1、等價類技術(Equivalence Class Testing) 等價類：某個輸入域的子集合。在該子集合中，各個輸入數據對于揭露程序中的錯誤都是等效的。 有效等價類：符合《需求規(guī)則說明書》，合理地輸入數據集合 無效等價類：不符合《需求規(guī)則說明書》，無意義的輸入數據集合 等價類劃分步驟： 1)先考慮輸入數據的類型(合法和非法) 2)再考慮數據范圍 3)畫出示意圖，區(qū)分等價類 4)為每個等價類編號 5)從等價類中選擇測試數據構造用例 3.2、邊界值技術(Boundary Value Testing) 3.3、因果圖法(Cause-Effect Graphs) 因果圖法步驟 1)找出所有的輸入條件和輸出，并編號 2)分析輸入條件之間的關系，是互斥還是可以同時滿足 3)畫出輸入條件的排列組合情況 4)編寫測試用例 因果圖試用于輸入條件過多 3.4、流程圖法(Workflow Method) 流程圖法步驟 1)詳細了解需求 2)根據需求說明或界面原型，找出業(yè)務流程的各個頁面及各頁面之間的流轉關系 3)畫出業(yè)務流圖 4)寫用例，覆蓋所有路徑分支 流程圖法是針對整個系統，而非某個頁面或模塊 還有其他如：判定表、錯誤推測、場景法等，例：ATM機取錢-場景法(不全) 場景 密碼 帳號 輸入金額 賬面金額 ATM現金 預想結果 場景1：成功提款 1 1 1 1 1 提款 場景2：ATM內無現金 1 1 1 1 0 不可提款 場景3：ATM內現金不足 1 1 1 1 0 提示，返回開始 場景4：密碼錯誤，可再次輸入 0 1 null 1 1 警告，返回開始 場景5：密碼錯誤，不可再次輸入 0 1 null 1 1 警告，卡預保留 白盒測試技術 3.5 白盒測試檢查點 *對程序模塊的所有獨立的執(zhí)行路徑至少測試一次 *對所有的邏輯判定，取’真’與’假’都至少測試一次 *在循環(huán)的邊界和運行界限內執(zhí)行循環(huán)體 *測試內部數據結構的有效性等 步驟：1)根據分析畫出流程圖 2)計算圈復雜度 = 判定節(jié)點數 + 1 3)寫出獨立路徑 4)根據獨立路徑設計測試用例 第四章 缺陷管理 4.1、Bug的分類 1)嚴重程度(Severity)：系統崩潰、嚴重、一般、次要、建議 2)優(yōu)先級(Priority)：高(High)、中(Middle)、低(Low) 嚴重程度高，優(yōu)先級不一定高，嚴重程度低，優(yōu)先級不一定低 3)按測試種類：邏輯功能類(Fcuntion)、性能類(Performance)、界面類(UI)、易用性類(Usability)、兼容性類(Compatibility) 4)按功能模塊 5)按生命周期：新建(New)、確認(Confirmed)、解決(Fixed)、關閉(Closed)、重新打開(Reopen) 4.2 缺陷報告 注意點： 1)確保重現Bug 2)用最少且必要步驟描述Bug 3)簡潔、準確、完整 4)一個Bug一個報告 4.3 缺陷管理工具 TrackRecord、Clearquest、Bugzilla(免費)、Mantis(免費)、JIRA(免費) Bugzilla：Terry Weissman研制，perl編寫，后臺數據庫是MySQL，最初是用來在Netscape內部跟蹤Bug的，可以在多種平臺運行 第五章 常用測試工具 分類：黑盒測試工具、白盒測試工具、測試管理工具 MI公司產品： 1、LoadRunner：性能測試工具 2、WinRunner：功能測試工具(QTP：MI的QTP代替占有市場) 3、TestDirector：測試管理工具(QC：HP收購MI公司后退出的一款TD升級產品) 性能學習LoadRunner，功能學些QTP，管理學習TD IBM Rational公司的產品： Rational Testmanager(測試管理工具) Rational ClearQuest(缺陷管理工具) Rational Robot(功能/性能工具) Rational Purify(白盒測試工具) Compuware公司產品 QACenter(測試管理) TrackRecord(缺陷管理) QARun(功能) QAload(性能) DevPartner(白盒測試) Telelogic公司產品 Telelogic Doors(需求管理)、Logiscope(白盒測試工具) 其他公司產品 微軟-WAS(性能測試) Radview公司-WebLoad(性能測試)，TestView Manager(測試管理) Parasoft公司-JTest(白盒測試)，C++ Test(白盒測試) 另外，很多缺陷管理工具是開源的，如：Bugzilla、Mantis、Jira 第六章 測試管理 6.1、測試與質量 軟件質量：軟件符合明確敘述的功能和性能需求、文檔中明確描述的開發(fā)標準，以及所 有專業(yè)開發(fā)的軟件都應具有的隱含特征的程度(需求一致、符合準則、隱含特征) SQA(Software Quality Assurance)：軟件質量保證，為確保軟件開發(fā)過程和結果符合預期 要求而建立的一系列規(guī)程，以及一照規(guī)程和計劃采取的一系列活動及其結果評價。 SQA需要做的工作： *建立軟件質量保證活動的實體 *制定軟件質量保證計劃 *堅持各階段的評審、審計、跟蹤 *監(jiān)控軟件產品的質量 *采集軟件質量保證活動的數據 *度量軟件質量保證活動 SQA需要達到目標： *通過監(jiān)控軟件開發(fā)過程來保證產品質量 *保證開發(fā)出來的軟件和軟件開發(fā)過程符合相應標準與規(guī)程(ISO90000 或 CMM) *保證軟件產品、軟件過程中存在的不符合問題得到處理，必要時將問題反映給高級 管理者 *確保項目組指定的計劃、標準和規(guī)程適合項目組需要，同時滿足評審和審計需要。 SQA工作人員：QA，QC工作人員：主要是TESTER QA與QC：QA-預防問題(Prevention)，貫穿于整個軟件生命周期中，預防錯誤的成因，重點是對軟件開發(fā)過程進行監(jiān)督、管 理、控制 QC-發(fā)現問題(Detection)，主要是測試人員，關注于最后的產品的質量活動，重點是對開發(fā)出的產品進行檢查 6.2、常用模型 CMM：能力成熟度模型 1)初始級(Initial)：軟件過程的特征是無序的，有時甚至是混亂的。 幾乎沒有過程定義，成功完全取決于個人的能力。 2)可重復級(Repeatable)：建立了基本的項目管理過程，能夠追蹤費用、進度和功能。有適當的必要的過程規(guī)范，使得可以重現以前類似項目的成功。 3)已定義級(Defined)：用于管理和工程活動的軟件過程己經文檔化、標準化，并與整個組織的軟件過程相集成。所有項目都使用文檔化的、 組織認可的過程來開發(fā)和維護軟件。 4)已管理級(Managed)：軟件過程和產品質量的詳細度量數據被收集，通過這些度量數據，軟件過程和產品能夠被定暈地理解和控制。 5)優(yōu)化級(Optimizing)：通過定量的反饋，進行不斷的過程改進，這些反饋來自于過程或通過測試新的想法和技術而得到。 CMM ISO ?質量模型 質量標準 ?評估 審查 ?給你改進建議 結果有通過和不通過 KPA(Key Process Area)：除第一級外，CMM的每一級是按完全相同的結構組成的。每一級包含了實現這一級目標的若干關鍵過程域，指出了企業(yè)需要集中力量改進的軟件過程。 CMM2:可重復階段 　　需求管理：requrement management 　　軟件項目計劃：software project planning 　　軟件項目跟蹤和監(jiān)督：software project tracking oversight 　　軟件子合同管理：software subcontract management 　　軟件質量保證：software quality assurance 　　軟件配置管理：software configuratione management CMM3:已定義階段 　　組織過程焦點：organization process focus 　　組織過程定義：organization process definition 　　培訓大綱：training program 　　集成軟件管理：intergrated software management 　　軟件產品工程：software product engineering 　　組間協調：intergroup coordination 　　同行評審：peer review CMM4:已管理階段 　　定量管理過程：quantitative process management 　　軟件質量管理：software quality management CMM5:優(yōu)化階段 　　缺陷預防：defect prevention 　　技術改革管理：technology change management 過程更改管理：process change management 成熟度 初始級 可重復級 已定義級 已管理級 優(yōu)化級 風險 常見的質量模型： *ISO90000族標準：國際標準(ISO/TC176)，適合所有行業(yè)，其中9000-3針對軟件開發(fā) *CMM標準：行業(yè)標準(卡耐基-梅隆大學)，針對軟件開發(fā)行業(yè)，分5等級，推出CMMI *TICKIT標準：行業(yè)標準(英國軟件行業(yè)協會)，針對軟件開發(fā)行業(yè)，不太流行 *ISO15504標準：國際標準(試圖結合1、2與軟件工程概念)，適用所有行業(yè)，有待實踐 其他模型： TMM：軟件測試成熟度模型 *初始級 *階段定義級 *集成級 *管理和度量級 *優(yōu)化、預防缺陷和質量控制級 McCall模型：【產品運行】正確性、健壯性、效率、完整性、可用性、風險 【產品修改】可理解性、可維護性、靈活性、可測試性 【產品轉移】可移植性、可再用性、互運行性 6.3、軟件的生命周期 軟件：可行性研究、需求分析→設計、編碼、測試→軟件發(fā)布維護→淘汰 軟件開發(fā)：需求分析→概要設計→詳細設計→編碼→維護 軟件測試：測試計劃→測試設計 測試執(zhí)行→測試評估 軟件生命周期模型： 1、Waterfall Model(瀑布模型)：計劃-需求-設計-編碼-測試-維護 開發(fā)的各個階段比較清晰 依賴早起需求調查，不適應需求變化 強調早期計劃及需求調查 單一流程，不可逆 適合需求穩(wěn)定的產品開發(fā) 風險往往遲至后期才發(fā)現，失去及早糾正機會 2、Spiral Model(螺旋模型)：重復執(zhí)行多個’瀑布模型’ 適合需求經常變化的軟件項目，但開發(fā)過程復雜，控制不好，容易混亂 3、V模型 用戶需求 驗收測試 規(guī)格定義 系統測試 概要設計 集成測試 詳細設計 單元測試 編碼 詳細表示了測試的各個階段及參考依據，但沒有說明在項目前期測試需要做哪些工作，且流程也是單項，不可逆 4、W模型 需求分析 需求測試 系統安裝 驗收測試 概要設計 概要設計 系統構建 系統測試 測試 詳細設計 詳細設計 模塊集成 集成測試 測試 編碼實現 單元測試 強調測試伴隨整個軟件開發(fā)生命周期，對象也不僅是程序，有利于盡早發(fā)現問題，但是需求設計編碼等活動也被視為串行，測試和開發(fā)也保持一種線性的前后關系。 W模型、H模型、X模型 通?？梢栽赪模型的框架下，運用H模型的思想進行獨立的測試，當有變更發(fā)生時，按X模型和前置模型的思想進行處理。(百度另幾種模型) 6.4 軟件測試計劃 撰寫測試計劃時，應注意一下四點： *增強測試計劃實用性注意體現項目的測試特點 *堅持”5W1H”規(guī)則，明確內容與過程 5W1H：”WHAT”,”WHY”,”WHEN”,”WHERE”,”WHO”,”HOW” what：明確測試范圍和內容 why：測試目的 when：確定測試開始和結束日期 where：給出測試文檔和軟件的存放位置 who：測試人員的分配 how：指出測試的方法和工具 *采用評審和更新機制，保證測試計劃滿足實際需求 *分別創(chuàng)建測試計劃與測試策略 其他 RUP： rational unified process 統一軟件開發(fā)過程 它定義了在整個軟件開發(fā)過程中：在什么時候，應該有誰，進行什么樣的開發(fā)活動，產生什么樣的結果，來確保按時提交筒質量的產品。 RUP總體結構 每個角色完成指定的活動 每個活動產出合格的產品 每個產品擁有相關的指南，模板等 RUP主要特點 迭代化軟件開發(fā) 以架構為核心的軟件開發(fā) 用例驅動的軟件開發(fā) 風險驅動的軟件開發(fā) 最佳經驗 迭代化開發(fā) 需求管理 基于構件的軟件架構 可視化建模 持續(xù)的質量驗證 配置管理 RUP適合任何項目 RUP在實施之前必須進行裁剪 RUP是個豐富的知識庫，需要你不斷的去查閱，選擇 實踐RUP是個持續(xù)的過程 國際化與本地化 Globalization testing 注意的是它與翻譯是沒什么太大關系的。 國際化測試關注產品是否達到了不同的時區(qū)、時間日期、貨幣格式和不同的文化習 慣等，當然還有政治規(guī)定方面的要求。 Localization testing 對一個軟件進行本地化測試就需要關注文本顯示的空間，因為不同語言的 長度不一樣，所以在設計界面的時候就要小心了！ 驗證軟件被翻譯完畢后，是否有什么錯誤，是否能夠正常工作。