軟件測試管理及其應用重點

1、第一章 明確為什么不能測試所有可能性 :1) 可能進行測試的數(shù)目是無限的2) 真正能執(zhí)行的測試只是代表性的案例3) 很難確定理想的可能測試的數(shù)目4) 用較少的測試資源獲取更多的信息1) 可用測試資源2使用適當?shù)臏y試技術和方法3明確具體軟件測試任務測試準備 單元測試集成測試系統(tǒng)測試內(nèi)部驗收1. 制定測試策略1.單元測試方案1.集成測試方案2.明確測試用例3.執(zhí)行單元測試4.缺陷分析交付成果：單元測試方案集成測試方案系統(tǒng)測試方案內(nèi)部驗收報告單元測試用例集成測試用例系統(tǒng)測試用例單元測試 bug 記錄表集成測試 bug 記錄表系統(tǒng)測試 bug 記錄表單元測試報告集成測試報告系統(tǒng)測試報告4.軟件測試管理

2、定義：就是對每一種具體測試任務、流程、體系、結果、工具等進行具體監(jiān)督和管理5. 常見的實踐是可以把軟件測試管理分為8 類：1軟件測試需求管理2軟件測試質(zhì)量管理3軟件測試團隊管理4軟件測試文檔管理5軟件測試缺陷管理6軟件測試環(huán)境管理7軟件測試流程管理8軟件測試執(zhí)行管理6. 單元測試的考慮：1模塊接口2算法和邏輯3數(shù)據(jù)結構全局和局部4邊界條件5獨立的路徑6錯誤處理7.1敏捷開發(fā)迭代流程圖：=輸入需求 -設計 -開發(fā)-測試需求 方案 -設計-執(zhí)行 - -發(fā)布輸出 =2敏捷方法 中迭代周期短，測試人員盡早開始測試，包括及時對需求、開發(fā)設計進行評審，更重要的是能夠及 時、 持續(xù)地對軟件產(chǎn)品質(zhì)量進行反應。

3、 簡單地說， 敏捷測試管理 要特別注意的就是持續(xù)地對軟件質(zhì)量問題進行及 時反應。有 HP Agile Manager 和微軟的 Visual Studio 2022,包括 TFS 2022、Scrum 模板、Test Manager 2022、Coded UI Test 是確保軟件測試在軟件質(zhì)量保證中發(fā)揮應有的關鍵作用。 特別表達在以下 5 個方面： 1對軟件產(chǎn)品的評估和測量2對軟件產(chǎn)品的缺陷識別和控制3產(chǎn)品設計和開發(fā)的驗證4軟件過程的監(jiān)視和測量5有流程和標準指導10.ISO 9000 質(zhì)量管理體系的 8 大原那么原那么 1:：以用戶為關注焦點原那么 2：領導作用原那么 3：全員參與原那么 4

4、：過程方法原那么 5：管理的系統(tǒng)方法原那么 6：持續(xù)改進原那么 7：基于事實的決策方法原那么 8：互利的供方關系11. TMM 軟件測試能力成熟度 5 級TL1 初始級TL2 階段定義級TL3 集成級TL4 管理和測試級TL5 優(yōu)化級12. 測試管理體系的架構：制定測試需求設計測試用例生成測試執(zhí)行用例執(zhí)行單元測試執(zhí)行集成測試執(zhí)行系統(tǒng)測試分析測試結果制定測試策略定義測試過程建立測試腳本建立測試結果記錄測試結果記錄測試結果提出變更請求明確資源進度定義測試環(huán)境回歸測試回歸測試回歸測試分析測試情況評審測試方案生成測試報告制定測試方案 - 測試方案 測試執(zhí)行 - 單元測試 - 集成測試 - 系統(tǒng)測試 評

5、估測試13. 軟件測試的 5個要素 /測試管理的 5 要素： 質(zhì)量、人員、技術、資源、流程14. 測試管理金字塔和關系實例圖： 一個中心 -1 人以人為本 -2 個目標 關注點：測試覆蓋率、測試效率 -3 個支撐人員、流程、 技術 -5 要素或 5 個工作面 -8 關系 13 原那么21 關鍵域 -34 個方法5 個工作面：1質(zhì)量 - 人員 - 技術2質(zhì)量 -人員 -資源3質(zhì)量 -技術 -流程4質(zhì)量 -流程 -資源5人員 -技術 -流程 -資源15. 為什么要進行軟件測試管理？ 1軟件測試的工作量要占整個軟件開發(fā)工作量的40以上，對于高可靠、高平安的軟件來說，這一比例可能會到達60%70%。因

6、此，軟件測試是軟件開發(fā)過程中的一項重要工作，必須對其進行科學有效的管理。 2一項軟件測試工作涉及到技術、方案、質(zhì)量、工具、人員等各個方面，是一項復雜的工作，因此需要對其 進行管理。3任何軟件測試工作都是在一定的約束條件下進行的，要做到完全徹底的測試是不可能的。 4只有系統(tǒng)化、 標準化的軟件測試才能有效地發(fā)現(xiàn)軟件缺陷，才能對發(fā)現(xiàn)的軟件缺陷實施有效的追蹤和管理，才能在軟件缺陷修改后進行有效的回歸測試。第二章1. 軟件需求的定義 ：1正在構建的系統(tǒng)必須符合的條件或具備的功能 2一種獲取，組織并記錄系統(tǒng)需求的系統(tǒng)優(yōu)化方案，以及一個使客戶與工程團隊對不斷變更的系統(tǒng)需求達成并 保持一致的過程2. 測試需求

7、和測試設計的區(qū)別： 1測試需求并不等同于簡單的測試范圍，也不是測試方案。因此也有專家定義測試需求不是對測試提出的要求 的總和，而是根據(jù)程序文件和質(zhì)量目標對軟件測試活動所提的要求。2測試需求不同于測試設計。按照IEEE 標準，測試設計的目的是：細化測試方案中描述的測試途徑，確定要包含的特性和測試，確定完成測試所用到的測試用例和測試規(guī)程，最后給出測試失效和通過的標準。就是對軟件測定要解決的問題進行詳細分析4. 測試需求分析主要有兩個任務： 1通過對測試活動需要解決問題及環(huán)境的理解、分析和綜合，建立分析模型； 2在完全弄清所有測試活動干系人對測試確實切要求的根底上，用“軟件測試需求規(guī)格說明書把測試需

8、求以 正式書面形式確定下來軟件測試需求分析環(huán)節(jié)：建立軟件測試需求模型 編寫測試需求說明書5. 軟件測試需求分析的最通用的方法：通過 軟件需求推導軟件測試需求6. 軟件測試需求分析步驟：1根據(jù)軟件開發(fā)需求說明書逐條列出軟件開發(fā)需求，并判斷其可測試性，如果不具備可測試性，那么需要提交申 請對軟件開發(fā)需求說明書進行變更，任何軟件開發(fā)需求都應具備可測試性。通常來說，對軟件開發(fā)需求說明書 的可測試性檢查應該在軟件開發(fā)需求說明書的評審過程中提出并解決。2對步驟 1中列出的每一條開發(fā)需求，形成可測試性的描述。針對這條開發(fā)需求需要進行測試范圍的界定。開發(fā)需求和需要進行測試的范圍不是1:1的關系，可能是1: n

9、或n： 1,必要情況下，需要對開發(fā)需求進行分解和合并。3對步驟 2中形成的每一條測試范圍,根據(jù)質(zhì)量標準,逐條制定質(zhì)量需求,即測試通過標準,用以判斷測試 成功和失敗。4對步驟 3確定的質(zhì)量需求,分析測試執(zhí)行時需要實施的測試類型,至此形成專業(yè)的測試需求。 5建立測試需求跟蹤矩陣,輸入測試需求管理系統(tǒng),對測試需求實施嚴格有效的管理。7. 軟件測試需求分析過程中還有許多其他重要的環(huán)節(jié)：軟件測試需求分析干系人分析、測試需求的收集與分析/整理、測試需求的優(yōu)先級排序和評審測試需求8. 評審的內(nèi)容 包括 完整性檢查和準確性檢查 評審的形式,有以下常用幾種：1 相互評審、交叉評審2輪查3走查4小組評審9. 軟件

10、測試需求管理的內(nèi)容：1 定義測試需求2確認測試需求3建立測試需求狀態(tài)4測試需求評審5測試需求責任制6測試需求跟蹤10. 為什么變更？變更的原因 ;1) 客戶的需求2市場的需求3技術或非技術的其他原因11軟件測試需求變更的主要任務：1提出變更2分析變更的必要性和合理性，確定是否實施變更3記錄變更信息，填寫變更控制單，提交變更申請4做出更改，并交上級審查5修改相應的軟件測試工作，如更新測試用例等，確定新的版本6評審后，正式發(fā)布新版本的軟件測試需求說明書12. 測試需求狀態(tài)轉 換：1Open2Analyzed3Reviewed4Resolved5 Passed6Un resolved7Closed8

11、 Cancle9FailedUnresolved缺陷多種原因：1測試問題2需求分析問題13. 軟件測試需求跟蹤是指跟蹤軟件測試需求使用期限的全過程。需求跟蹤包含的正向跟蹤和逆向跟蹤合稱為雙 向跟蹤。軟件開發(fā)需求到測試需求從測試需求回溯軟件測試需求到測試用例從測試用例回溯測試用例正向跟蹤逆向跟蹤14. 惠普應用生命周期管理流程 報告和分析 指定版本-指定需求-方案測試-執(zhí)行測試-追蹤缺陷第三章1. 測試團隊角色：1測試經(jīng)理：他們負責測試方案和測試統(tǒng)籌安排，具備軟件測試、質(zhì)量管理、工程管理和人員管理等領域的知識和經(jīng)驗，能指導和管理其他測試人員的工作2測試設計人員：他們需要掌握測試方法、流程和測試規(guī)

12、格說明等，具備測試設計、測試分析以及軟件工程等領域的知識和經(jīng)驗3測試自動化人員：測試自動化人員不但具備測試的根底知識，還有編程經(jīng)驗以及豐富的測試工具和腳本語言知識。4測試環(huán)境管理員：負責測試環(huán)境的技術人員。一般是安裝和操作測試環(huán)境方面的專家，具備系統(tǒng)管理員知識。建立、維護和支持測試環(huán)境， 需要經(jīng)常與系統(tǒng)管理員和網(wǎng)絡管理員進行協(xié)調(diào)。他們也幫助一般測試工程師和開發(fā)工程師搭建測試環(huán)境。5測試執(zhí)行人員：他們執(zhí)行測試并編寫缺陷報告，具備IT根底知識、測試根底知識，能應用測試工具，熟悉被測試對象。2. 測試團隊與開發(fā)團隊的比例測試比例不是唯一確定的1質(zhì)量風險2測試意識3發(fā)布流程4測試效率5合理估計工程的開

13、發(fā)測試比例的方法 1.看工程的性質(zhì)，遇到問題影響范圍是100%的核心任務，投入開發(fā)與測試比例至少為1:12. 遇到缺陷影響范圍可控或有替代方式的業(yè)務，上線步驟是遞進的，開發(fā)和測試之比2:1 或更高3. 有些工程對質(zhì)量要求不是很高的，只需做簡單驗證性測試即可發(fā)布，只需設立一到兩名測試人員即可 6手工測試工程師和自動化測試工程師的比例第四章1.測 試過程實施所必備的核心測試文檔包括： 測試方案、測試標準、測試用例和軟件測試報告2.測試文檔的必要性 ;1) 提高工程測試過程的透明度2) 文檔化能標準測試，能提高測試效率3) 便于團隊成員之間的交流與合作4) 測試文檔的重要性還表現(xiàn)在對于工程“傳承的重

14、要性5) 測試文檔是測試人員經(jīng)驗提升的最正確途徑6) 有利于工程測試的監(jiān)控作用3. 工程測試文檔 是用來記錄、描述、展示測試過程中一系列測試信息的處理過程，通過書面或圖示的形式對工程 測試活動過程或結果進行描述、定義及報告4. 測試方案 ：描述測試活動的范圍、 方法、資源和進度。它規(guī)定被測試的項、 被測試的特征、 應完成的測試任務、 負責每項工作的人員以及與本方案有關的風險等。5. 測試說明包括三類文檔：1測試設計說明2測試用例說明3測試規(guī)程說明6.測試報告包括 4 類文檔：1測試項傳遞報告2) 測試日志3) 測試事件報告4) 測試總結報告7. 國際 IEEE 829 標準：1測試方案2測試設

15、計規(guī)格3測試用例規(guī)格4) 測試過程規(guī)格5) 測試記錄6) 測試附加報告7) 測試摘要報告8. 測試策略和測試方案的區(qū)別：測試策略定義 ：在一定的軟件測試標準、 測試標準的指導下， 依據(jù)測試工程的特定環(huán)境約束而規(guī)定的軟件測試的 原那么、方式、方法的集合。通俗地講， 測試策略描述了要進行哪些種類的測試和如何測試的問題。測試方案： 5W1H what where when who why how9. 簡述制定軟件測試策略的過程1首先要明確制定軟件測試策略的輸入 2其次要明確軟件測試策略的輸出 1.確定測試的需求 2.評估風險并確定測試優(yōu)先級3.確定測試策略10. 測試方案定義 ; 一個表達了預定的測

16、試活動的范圍、途徑、資源及進度安排的文檔。它確認了測試項、被測特征、測試任務、人 員安排以及任何偶發(fā)事件的風險。 軟件測試方案是指導測試過程的綱領性文件， 是測試文檔中的重中之重。 它包 含了產(chǎn)品概述、 測試策略、測試方法、測試區(qū)域、 測試配置、測試周期、 測試資源、 測試交流、風險分析等內(nèi)容。 根本要素：1編號2) 標題3) 重要級4) 測試輸入5) 操作步驟6) 預期結果12. 編寫缺陷報告的5c準那么；1Correct(準確)2Clear清晰3Concise簡潔4Complete完整5 Consistent 一致 缺陷報告生命周期提交缺陷報告 -分配缺陷報告 -處理缺陷報告 -反測報告

17、-反測通過 關閉缺陷報告 反測未通過處理缺陷報告13. 對測試方案的可行性、全面性以及正確性等進行評審1 4 .評審的內(nèi)容：1 用例設計的結構安排是否清晰、合理，是否利于高效地對需求進行覆蓋 2優(yōu)先級安排是否合理3是否覆蓋測試需求的所有功能點 4用例是否具有很好可執(zhí)行性5是否刪除冗余的用例 6是否包含充分的的負面測試用例7是否從用戶層面來設計用戶使用場景和使用流程的測試用例 8是否簡潔，是否便于重復使用15. 使用 ALM 進行測試管理包括 4 個步驟：1 明確條件2測試方案3執(zhí)行測試4跟蹤缺陷16. 最正確測試用例的設計原那么：1 依據(jù)原那么2全覆蓋原那么3標準原那么4全面原那么17. 最正

18、確測試用例的特點：1 完整性2準確性3簡潔性4清晰性5可維護性6適當性7可復用性8其他18. 測試用例的粒度： 是指一個測試用例覆蓋軟件功能點的范圍，覆蓋面廣被稱為力度粗大，覆蓋面窄被稱為力度細小19. 設計測試用例時應考慮以下因素：1工程的進度2軟件工程師的情況3客戶需求4工程是否具有延續(xù)性20. 測試用例生命周期：確定測試需求 -測試用例設計 - 測試用例執(zhí)行 -測試用例管理21. 測試用例管理：包括測試用例組織、測試用例跟蹤和測試用例維護22. 幾大測試文檔有哪些？具體內(nèi)容是什么？測試需求文檔：測試執(zhí)行方案：測試方案： 一個表達了預定的測試活動的范圍、途徑、資源及進度安排的文檔 。它確認

19、了測試項、被測特征、 測試任務、 人員安排以及任何偶發(fā)事件的風險。 軟件測試方案是指導測試過程的綱領性文件， 是測試文檔中的重 中之重。它包含了產(chǎn)品概述、測試策略、測試方法、測試區(qū)域、測試配置、測試周期、測試資源、測試交流、風 險分析等內(nèi)容，包含了測試的背景、人員和內(nèi)容、以及方案要做的測試。測試用例 ：是對于方案中要做的測試內(nèi)容、測試項生成的用例。測試結果報告 :：包含了用例測試的結果和總結，以便將來維護時使用測試標準： 為了一個特定的測試目的，對被測軟件產(chǎn)品或功能進行測試所需的有關文件。軟件測試報告：測試策略 ：在一定的軟件測試標準、 測試標準的指導下， 依據(jù)測試工程的特定環(huán)境約束而規(guī)定的軟

20、件測試的原那么、 方式、方法的集合。通俗地講， 測試策略描述了要進行哪些種類的測試和如何測試的問題。缺陷報告： 為便于管理測試發(fā)現(xiàn)的軟件錯誤， 通常要采用軟件缺陷數(shù)據(jù)庫， 將發(fā)現(xiàn)的每一個錯誤輸入到缺陷報告 中，軟件缺陷數(shù)據(jù)庫的每一條記錄稱為一個軟件問題報告第五章1. 缺陷狀態(tài)New Open Fixed Reopen Closed Rejected Pending Distract Cancelled一個好的缺陷報告應該包含哪些信息？唯一的缺陷 ID ，精確描述但簡短的標題、缺陷類型、嚴重級別、優(yōu)先級別、報告人、詳細準確的重現(xiàn)步驟包 含位置、操作、現(xiàn)象等三要素 ，UI 截圖、所屬模塊、負責人、預期結果、實際結果，重現(xiàn)環(huán)境、前置條件等等 信息其余可以補充 。事件 / 缺陷 ID：XXX缺陷標題： 號不合法也能注冊成功報告者： XXX報告的日期： 2022/10/20狀態(tài)： New嚴重度：