軟件測試流程DOC

1、軟件測試流程1. 目的本文是對項目軟件測試的指導性文件，對軟件測試過程中所涉及到的測試理論、測試類型、測試方法、測試標準、測試流程及測試過程中涉及到的角色職責進行總體規(guī)范，以有效保證軟件質量。2. 范圍本文適用于軟件開發(fā)、測試人員，以及軟件項目管理人員。3. 參考資料缺陷管理規(guī)范測試執(zhí)行規(guī)范文檔測試指南項目測試計劃模版測試用例設計規(guī)范功能測試用例模版集成測試用例模版項目測試報告模版自動化測試計劃模版性能測試計劃模版4. 測試過程描述4.1 測試流程圖 4.2 需求評審 目的從源頭把握軟件質量，并確保開發(fā)結果與實際需求相一致 角色與職責需求人員：需求規(guī)格說明書的編寫，以及軟件開發(fā)過程中

2、需求規(guī)格說明書的修正；評審人員：評審需求規(guī)格說明書，從全面性、完整性、正確性、一致性、可靠性方面檢查需求規(guī)格說明書，將需求缺陷提交給需求人員，并跟蹤需求缺陷直至需求缺陷驗證關閉。 啟動標準需求規(guī)格說明書編寫完成 工作流程圖 輸入/輸出輸入：需求規(guī)格說明書輸出：需求缺陷 規(guī)范參見文檔評審指南4.3 測試計劃 目的明確測試內容、測試任務安排、測試進度、測試策略、測試資源、風險控制；保持測試過程的順暢，有效控制和跟蹤測試進度，應對測試過程中的各種變更。 角色與職責測試負責人：根據項目整體計劃、需求規(guī)格說明書編制測試計劃，明確測試內容、測試任務安排、測試進度、測試策略、測試資源、風險控制，以便測試工作

3、正常開展，測試計劃實際編寫內容參見項目測試計劃模版。 啟動標準需求評審完成，項目整體計劃編制完成。  工作流程圖  輸入/輸出輸入：需求規(guī)格說明書、項目整體計劃輸出：測試計劃 規(guī)范測試計劃編寫內容參加測試計劃模版。4.4 測試設計 目的通過多種測試方法編寫測試用例，以使最少的測試用例，實現最大的測試覆蓋，保證軟件功能的正確性，從而提升軟件質量。 角色和職責測試人員：采用多種測試方法編寫有效的測試用例，并對遺漏/錯誤的測試用例進行修正。評審人員：對測試人員編寫的測試用例進行評審，提出遺漏/錯誤的用例缺陷，并跟蹤直至用例缺陷的驗證關閉。 啟動標準需求文檔評審完成且測試計劃制定完

4、成。 工作流程圖  輸入輸出輸入：需求規(guī)格說明書輸出：測試用例、測試用例評審缺陷 規(guī)范測試用例實際內容參見測試用例模版，測試用例評審規(guī)范參見文檔測試規(guī)范。4.5  功能測試執(zhí)行 目的依據測試計劃，按照測試用例對軟件進行測試，驗證軟件功能與需求的實際匹配程度。 角色與職責測試人員：依據測試計劃，按照測試用例對軟件功能進行測試。對于發(fā)現的缺陷必須記錄，并且跟蹤缺陷的狀態(tài)，直至缺陷的驗證關閉。在測試執(zhí)行過程中發(fā)現的遺漏測試用例必須補充至測試用例，保證測試用例與實際測試的一致性。開發(fā)人員：對于測試人員提交的缺陷進行確認、修復。開發(fā)經理：對測試人員與實際開發(fā)人員意見不一的問題進行裁決

5、。 啟動標準測試用例編寫完成且用例評審完成 工作流程圖 輸入輸出輸入：功能測試用例輸出：功能測試缺陷 規(guī)范測試執(zhí)行過程需按照測試行為規(guī)范進行，缺陷管理需按照缺陷管理規(guī)范進行。4.6 集成/性能測試設計 目的為集成測試提供測試依據，記錄并保證集成測試覆蓋度；依據測試計劃及性能指標制定性能測試計劃、性能測試用例設計、性能測試腳本開發(fā)，保證性能測試有序進行。 角色和職責測試人員：以整個軟件為對象，確保新功能、老功能、新老功能接口正確進行用例設計；依據性能指標及測試計劃對性能測試進行計劃、以及性能測試用例/腳本的開發(fā)。 啟動標準功能測試完成 且 軟件功能無中斷 工作流程圖 輸入輸出輸入：功能測試用例、

6、功能測試缺陷、測試計劃、性能指標輸出：集成測試用例、性能測試計劃、性能測試用例、性能測試腳本 規(guī)范集成測試用例實際內容參見集成測試用例模版；性能測試計劃實際內容參見性能測試計劃模版。4.7 集成測試/ 目的以整個軟件為對象，以測試計劃為指導，按照集成測試測試用例對新功能、老功能、新老功能接口進行測試和性能測試，保證測試的全面性和完整性。 角色和職責測試人員：以整個軟件為對象，以測試計劃為指導，按照集成測試測試用例對新功能、老功能、新老功能接口進行測試，并依據性能測試計劃對軟件性能進行測試。 啟動標準集成/性能測試設計完成 工作流程圖 輸入輸出輸入：集成測試用例、測試計劃之集成測試事項、性能測試

7、計劃、性能測試用例輸出：集成測試缺陷 規(guī)范測試執(zhí)行過程需按照測試行為規(guī)范進行，缺陷管理需按照缺陷管理規(guī)范進行。4.8 文檔測試 目的保證對客戶的指導與實際系統(tǒng)的使用狀況相一致。 角色和職責測試人員：對用戶操作手冊及在線幫助進行測試，記錄文檔描述缺陷，并跟蹤直至缺陷的驗證關閉。需求人員：對測試人員提出的文檔描述缺陷進行修正。 啟動標準用戶操作手冊或在線幫助編寫完成 工作流程圖 輸入輸出輸入：用戶操作手冊、在線幫助輸出：文檔缺陷 規(guī)范參見文檔測試指南4.9 測試報告 目的真實、客觀反映測試過程中各測試階段、測試項的情況，并將結果進行數字化/圖像化進行分析，真實反映軟件質量實際情況。 角色與職責測試

8、負責人：真實、客觀地對測試過程中各測試階段、測試項的情況，并以數字/圖像的形式對實際情況進行分析，真實反映軟件實際測試狀況。 啟動標準集成測試完成 工作流程圖 輸入輸出輸入：各測試階段、測試項實際測試情況輸出：項目測試報告 規(guī)范5 新產品或工程管理流程5.1 需求調研在軟件需求分析階段，測試人員從軟件生命周期的需求階段就開始介入，在需求階段的測試人員參與軟件需求調研，以測試角度分析需求的可測性，可構思將來對其測試的方法、原則等；同時全面了解系統(tǒng)需求，從客戶角度考慮軟件測試需求達到的驗證狀態(tài)，即何些功能點需重點測試、何些無需，以便將來制定測試計劃。5.2 制定測試計劃進行每一種測試之前，測試負責

9、人要根據“產品定義書”及“總體設計說明”和“詳細設計文檔”制定“測試計劃”，制定總體的測試計劃，詳細闡明本次測試目的、對象、方法、范圍、過程、環(huán)境要求、接收標準以及測試人員和測試時間等內容，“測試計劃”經過審查通過，才能實施。5.3 需求Review開發(fā)在完成軟件需求分析之后，會提交需求分析文檔，測試人員根據需求調研所了解的需求以及產品需求說明文檔等資料，對需求分析文檔進行Review，檢查文檔是否滿足了需求，是否與需求一致等等。5.4 設計Review在軟件分析設計階段，測試人員參與設計討論，了解系統(tǒng)的實現方式和原則，并對概要設計和詳細設計提出自己的見解。設計結束之后，開發(fā)提交概要設計文檔和

10、詳細設計文檔，測試人員對設計進行Review，檢查設計規(guī)劃和實現方案是否合理，如果不合理，存在的問題是什么、如何改進等等。5.5 測試設計在設計測試方案時，首先分解測試內容，對于一個復雜的系統(tǒng)，通?？梢苑纸獬蓭讉€互相獨立的子系統(tǒng)，正確地劃分這些子系統(tǒng)及其邏輯組成部分和相互間的關系，可以降低測試的復雜性，減少重復和遺漏，也便于設計和開發(fā)測試用例，有效的組織測試，將系統(tǒng)分析人員的開發(fā)分析文檔加工成以測試為角度的功能點分析文檔，重要的是描述對系統(tǒng)分解后每個功能點逐一的校驗描述，包括何種方法測試、何種數據測試、期望測試結果等。然后以功能點分析文檔作為依據進行測試用例的設計，設計測試用例是關系到測試效果

11、以至軟件質量的關鍵性一步，也是一項非常細致的工作，根據對具體的被測系統(tǒng)的分析和測試要求，逐步細化測試的范圍和內容，設計具體的測試過程和數據，同時將結果寫成可以按步執(zhí)行的測試文檔。每個測試用例必須包括以下幾個部分：（1）標題和編號（2）測試的目標和目的（3）輸入和使用的數據和操作過程（4）期望的輸出結果（5）其他特殊的環(huán)境要求、次序要求、時間要求等5.6 開發(fā)測試工具和準備測試數據在軟件測試中，為了提高測試工作的效益和質量，只要條件許可，應盡可能采用計算機自動或半自動測試的方法，利用軟件工具本省的優(yōu)勢來提高工作效率。5.7 測試執(zhí)行當所有必須的測試準備工作都已完成，并且產品已經開發(fā)完畢并提交測試

12、，則可以按照預定的測試計劃和測試方案逐項進行測試。在測試過程中發(fā)現的任何與預期目標不符的現象和問題都必須詳細記錄下來，填寫測試記錄。為了能準確的找出問題產生的原因，及時的解決問題，保證測試工作的順利進行，一般來說所發(fā)現的問題必須是能夠重視的。5.8 回歸測試在測試中發(fā)現的任何問題和錯誤都必須有一個明確的解決方法。一般來說，經過修改的軟件可能仍然包含著錯誤，甚至引入了新的錯誤，因此，對于修改以后的程序和文檔，按照修改的方法和影響的范圍，必須重新進行有關的測試。另一方面，對于版本更新后的軟件也必須進行同樣的測試過程。5.9 測試分析報告測試結束后要及時地進行總結，對測試結果進行分析，由測試負責人提

13、交“測試分析報告”。5.10 產品發(fā)布測試完畢，整理產品發(fā)布和相關文檔并發(fā)布。對于新產品來說，必要的文檔必須包括：（1）安裝操作手冊（2）產品白皮書（3）管理維護手冊（4）用戶操作手冊（5）測試報告5.11 版本控制新版本軟件發(fā)布之后，馬上對代碼進行質量控制。（1）Build Master給新版本的源代碼打一個cvs tag，方便代碼回滾check out。比如，發(fā)布版本為p2p3.3.2，則給該軟件源代碼也打一個與發(fā)布版本相同名字的tag p2p3.3.2.這樣做的一個好處是，在目前的軟件的基礎上做了修改并發(fā)布的新版本后，如果需要check out某個版本的源代碼，則可以通過這個版本的tag

14、來check out，代碼的修改可以在該版本上進行。（2）Build Master對新發(fā)布的軟件源代碼進行cvs lock，不允許開發(fā)人員在軟件發(fā)布之后commit源代碼，直到有新版本需要修改再給開發(fā)人員開放commit權限。這樣做的好處是避免開發(fā)人員隨意修改和commit源代碼，確保源代碼服務器上的源版本與當前最新的發(fā)布版本一致。6 工程維護管理流程6.1 收集新需求新功能和不緊急的故障，其代碼的修改操作不必馬上進行，取而代之的是做好新需求與故障統(tǒng)計；對已經確認的故障也可以先在bug管理系統(tǒng)報bug，但只是記錄，不需求馬上修改。當然了，對于緊急的工程故障，需要馬上修改和測試。6.2 確認新需

15、求與工程人員或客戶或產品經理確認新需求，確保需求被理解正確。6.3 需求討論當需求與故障積累到一定數量或者工程有新版本需求，進行一次發(fā)布測試，在新版本開始修改之前把近期積累的需求與故障整理，與相關開發(fā)人員、測試人員、項目經理和測試經理討論，確認哪些新功能可以實現、新功能的實現方法與業(yè)務流程、新功能開發(fā)修改時間、測試版本、測試時間與發(fā)布時間。6.4 bug跟蹤管理確認所有需要修改的新功能和需求錄入bug跟蹤管理系統(tǒng)，并在bug跟蹤管理系統(tǒng)中詳細描述新功能需求和解決方法，同時整理相關bug列表，交付開發(fā)修改。6.5 制定測試計劃A、根據用戶需求，定義并完善測試需求，作為測試的標準B、確定重點測試事

16、項，哪些功能需要重點測試C、測試時間計劃，并詳細計劃具體測試任務與時間D、風險說明E、測試準備，提前對測試環(huán)境和測試資源進行準備F、發(fā)布具體時間G、資源需求：測試人員、硬件需求、軟件需求和培訓計劃6.6 編寫測試案例根據功能需求編寫測試案例6.7 測試開發(fā)開發(fā)自動測試腳本，補充自動測試案例6.8 測試實施按照測試計劃進行測試，發(fā)現并申報bug6.9 測試評估A、哪些需求通過了測試B、有哪些遺留問題C、測試效率評估D、開發(fā)質量度量和評估E、并根據評估編寫測試報告6.10 發(fā)布新版本A、編寫新功能文檔，給工程提供新功能說明B、編寫升級文檔，給工程提供升級參考方案C、軟件發(fā)布，包括新版本軟件、新功能文檔、升級文檔和測試報告6.11 代碼版本控制新版本軟件發(fā)布之后，馬上對代碼進行質量控制。A、Build Master給新版本的源代碼打一個cvs tag，方便代碼回滾check out。比如，發(fā)布版本為p2p3.3.2，則給該軟件源代碼也打