::: xx公司
2020-01-01 :::
文件管理
合理地管理主文件， 確保文件版本的及時更新，同時保持備份文件和源文件的一致性。
版本管理
本版本修訂日期 2019-08-12 生效日期 2019-08-12
版本 生效日期 變更內容 編制人
v1.0 2020-01-01 初稿編寫完成 xx
範圍標識
本條應包含本文件及本文件適用的系統和軟體的完整標識，(若適用)包括標識號、標題、縮略詞語、版本號和發行號。
系統概述
本條應簡述本文件適用的系統和軟體的用途，它應描述系統和軟體的一般特性；概述系統開發、執行和維護的歷史；標識專案的開發方、業主方、總集方、監理方等；標識當前和計畫的執行現場等。
文件概述
本條應概述本文件的用途和內容，並描述與其使用有關的保密性和私密性的要求。
引用文件
提供此文件中用到的專門術語的定義和縮寫詞的原片語。
測試目標和測試內容
測試目標
描述本測試計畫的測試目標。如完成軟體的出廠測試，達到可交付驗證測試的目的。
測試的功能和特性
概要說明本次需要測試的功能和特性
不測的功能和特性
說明本次不測的功能、特性及原因
測試質量目標
簡要說明測試的質量目標,如：
測試計畫中所有測試方法和模組已經執行通過
所有的測試案例已經執行過
所有的重要等級bug已經解決並由測試驗證
說明最終需要交付的測試成果文件，包括軟體測試計畫、軟體測試說明(含測試用例)、軟體測試報告、測試問題報告等。文件名和數量因具體專案而異，應確定文件責任人。
測試策略
整體測試策略
說明基本的測試過程和策略。如測試人員在需求和設計階段參與需求評審和設計評審、在開發完成前實施測試案例設計和測試開發，在系統開發完成之後正式執行測試等。
問題等級劃分
缺陷** 缺陷等級 描述
a 嚴重缺陷 文件與軟體不符、文件嚴重不足、關鍵性內容錯誤。軟體需求明顯未實現。軟體不能正常執行,導致系統崩潰或資源嚴重不足。例如: 由程式引起的宕機、非法退出;死迴圈;導致資料庫發生死鎖;錯誤操作導致的程式中斷;與資料庫連線錯誤;資料通訊錯誤等 b 較嚴重缺陷中現 軟體能夠執行,但當前缺陷嚴重影響軟體基本功能的正確實現。例如:軟體功能與需求不符;程式介面錯誤;資料流錯誤;數值計算錯誤等。 c 一般性缺陷 軟體能夠執行,但當前缺陷影響部分功能的正確實現。例如:介面錯誤;列印內容或格式錯誤;簡單的輸入限制未放在前台進行控制;刪除操作未給出提示;資料輸入沒有邊界值限定或不合理等。 d 較小缺陷 軟體能夠執行,軟體功能基本實現,但當前缺陷使操作者不方便或遇到麻煩。例如:輔助說明描述不清楚;顯示格式不規範;系統處理未優化;長時間操作未給使用者進度提示;提示視窗文字未採用行業術語等。
開始/中斷/完成標準
測試啟動條件
說明啟動測試的條件。如對於出廠測試，已經過評審、測試人力資源已經具備、軟體需求規格說明/詳細設計文件/測試說明文件已經過確認、內部模組測試和組裝測試已經完成等。 其中業主方、總集方、監理方交付驗證測試的准入條件：
軟體源**正確通過編譯且為最終版本；
軟硬體測試平台已搭建並已配置完成；
業主方具有測試所需的各種文件（紙質、電子版）；
業主方獲得的各種文件均與最終版本的軟體相對應，且全部通過審核；
承建方、監理方已完成測試並提交測試報告。
說明測試中斷的條件。例如：
在測試中發現a類bug，並導致後續的測試無法繼續時；
已執行完所有的測試用例，並已報告給承建方，等待承建方在限期內改正時。
說明在什麼條件下終止本計畫所述產品交付驗收證測試。如：
正常終止條件：
按照測試計畫完成所有定義的測試用例；
客觀、詳細地記錄了軟體測試過程和軟體測試中發現的問題；
有效完成了定位缺陷的回歸測試迴圈；
測試中未發現a、b缺陷，以及少於n個c類缺陷；
提交測試報告。
異常終止條件
太多的a或b類缺陷以致測試無法進行或測試週期已結束。 或者針對軟體規模，規定c類bug不超過n個
說明需要用到的測試工具軟體，應包括軟體版本號。
測試流程
闡述或引用測試流程，應包括問題報告、審核、分配、跟蹤、回歸等各方面。測試流程與承建方內部質量管理制度和業主方的要求相關。
測試技術和方法
確定測試需要的技術或方法，如測試資料生成與驗證技術、測試資料輸入技術、測試結果獲取技術等；明確測試用例的設計和選擇方法，針對不同型別的測試(功能測試、效能測試、容量測試、使用者介面測試), 根據需要，應給出針對性的測試用例設計要求。
評價準則和方法
測試通過準則
定義系統測試通過準則，以下是乙個測試通過準則的示例：
可執行軟體與需求規格說明書、設計說明書是一致的；
測試覆蓋率應達到100%
測試用例通過率要達到95%；
軟體缺陷終結率達到100%
系統頁面風格符合規範化要求，程式**編寫以及各種命名符合規範化要求。
各模組正確銜接。
對異常資料應有相應的提示資訊，並能安全終止異常操作。
測試結果分為通過和未通過。測試達到通過準則的要求稱為"通過"，測試結果沒有達到測試通過準則的稱為"未通過"。說明對不同測試結果的處理方法。 測試專案組織與資源
參與部門和組織
說明參與測試的組織/部門
角色和職責
說明參與測試的組織/部門中各角色劃分及職責。
人員和培訓要求
說明參與測試的組織/部門的員及角色對應關係。以及是否需要預先進行相關培訓。
關鍵資源
說明需要用到的關鍵資源
測試活動和進度計畫 應根據測試資源和測試專案內容，分解測試活動，分配測試資源，編制測試進度計畫。以下是乙個進度計畫的示例：
測試階段 開始時間 完成時間 測試人員 階段完成標誌
制定測試計畫
需求 review
設計 review
設計測試用例
測試開發
測試環境準備
測試實施
功能測試
整合測試
效能測試
系統測試
驗收測試
文件編寫
風險分析及應對措施
風險分析是評測專案管理的重要內容。常見的風險包括供測試的軟體版本混亂、軟體缺陷修改時間過長、回歸不足引發新的問題、測試方和開發方對缺陷的認識存在差異等。建議以列表的方式給出識別的風險並提供針對性的緩解措施。
內容審核要點：
測試內容是否完整，是否涵蓋了測試目的、內容、方法策略、資源、進度安排等各方面；
測試進度安排是否合理；
測試資源要求是否充分；
測試技術和方法的選擇是否可行；
是否包含了對測試結果評價分析標準；
是否包含了對測試過程的跟蹤和控制規程。
軟體測試計畫
1.測試計畫是什麼？是在軟體測試工作正式實施之前明確測試的物件，並且通過對資源 時間 風險 測試範圍和預算等方面的綜合分析和規劃，保證有效的實時軟體測試。2.為什麼要制定測試計畫？1 對專案執行過程過程中的風險進行分析，並制定相關的應對策略 2 把知識和經驗轉化為執行任務的具體方法 3 促進團隊間關...
軟體測試計畫
1 討論你們的測試計畫 在進行正規測試之前先 一下系統可能發生的問題。比如使用者輸入什麼資料可能導致系統報什麼樣的錯誤。檢測各功能之間的邏輯關係是否符合使用者的需求。使用專業測試工具。盡可能多的對使用者進行細分，並按照他們的操作去完成軟體的功能。2 我們是否需要測試，直到我們的軟體是完美的？我們的技...
軟體測試計畫
1.1 編寫軟體測試計畫 5w1h 軟體測試的目標 是盡可能早地找出軟體缺陷,並保證其得以修復。關於測試計畫 概念 規定測試活動的範圍 方法 資源和進度 明確正在測試的專案 要測試的特性 要執行的測試任務 每個任務的負責人，以及與計畫相關的風險。軟體測試計畫 software test plan 是...