測試計劃模板(標準版)

1、精選優(yōu)質文檔-傾情為你奉上精選優(yōu)質文檔-傾情為你奉上專心-專注-專業(yè)專心-專注-專業(yè)精選優(yōu)質文檔-傾情為你奉上專心-專注-專業(yè)文檔編號：CIECC-EP-TP-0I2 項目名稱測試計劃（標準版）V1.0(版本號)擬 制 人_審 核 人_批 準 人_2010年9月9日中國國際電子商務中心China International Electronic Commerce Center變更歷史記錄日期版本說明作者審核批準2010-09-091.0首次建立項目測試計劃（標準版）模板文建東趙明秀2013-11-041.1對部分文字及格式進行微調丁曉蓓趙明秀目 錄 TOC o 1-3 h z u 引言目的簡述

2、本計劃的目的，旨在說明各種測試階段任務、人員分配和時間安排、工作規(guī)范等。測試計劃在策略和方法的高度說明如何計劃、組織和管理測試項目。測試計劃包含足夠的信息使測試人員明白項目需要做什么是如何運作的。另外，清晰的文檔結構能使任何一個讀者在瀏覽計劃的前面幾頁后，就能對項目有一個大概的認識。測試計劃只是測試的一個框架，很多細節(jié)需要跟開發(fā)人員或其他人員溝通，因此計劃不包括測試用例的細節(jié)和系統(tǒng)功能的詳細信息。在計劃目的中需要指明讀者對象。名詞解釋列出本計劃中使用的專用術語及其定義列出本計劃中使用的全部縮略語全稱及其定義表1 名詞解釋表縮寫詞或術語中文解釋測試摘要這一節(jié)主要說明測試計劃中重要的和可能有爭議的

3、問題。本節(jié)的主要目的是將這些信息傳遞給那些可能不會通讀整個測試計劃文檔的人員（比如經理或開發(fā)項目的負責人）。 重點事項列出測試的重點事項?？梢詫栴}按重要程度和優(yōu)先級羅列出來，然后在后面的章節(jié)中再對這些問題進行詳細說明，這樣就能讓對這些問題有重要影響的人員知道問題的所在。測試前約定列出測試前開發(fā)和測試之間的約束。風險評估列出可能會影響測試設計、開發(fā)或實施的所有風險或意外事件。列出可能會影響測試設計、開發(fā)或實施的所有約束時間進度簡要說明測試開始時間與發(fā)布時間。測試目標簡要說明測試發(fā)布的質量目標。例：測試計劃中所有測試方法和模塊已經執(zhí)行通過所有的測試案例已經執(zhí)行過所有的重要等級為嚴重/重要的Bug

4、已經解決并由測試驗證項目背景測試范圍說明本計劃涵蓋的測試范圍，比如功能測試、集成測試、系統(tǒng)測試、驗收測試等。通常說明什么是要測試的，什么是不要測試的是非常重要的。明確規(guī)定這些問題后，測試人員對該做什么有一個清晰的認識。（1）簡要地列出測試對象中將接受測試或將不接受測試的那些性能和功能。（2）如果在編寫此文檔的過程中作出的某些假設可能會影響測試設計、開發(fā)或實施，則列出所有這些假設。（3）列出可能會影響測試設計、開發(fā)或實施的所有風險或意外事件。（4）列出可能會影響測試設計、開發(fā)或實施的所有約束。提示和技巧：需要測試和特別注意測試那些部分？測試是否專么針對與某些問題的解決?哪些部分不需要測試，為什么

5、？哪些部分需要推遲測試,為什么?是否要驗證每個模塊的穩(wěn)定性？測試的優(yōu)先級和先后順序測試來源（誰提交的測試的測試申請、服務器放在什么地方等信息）聯(lián)系方式列出項目參與人員的職務、姓名、E-mail 和電話。表2 聯(lián)系方式表職務姓名E-Mail電話開發(fā)工程師CVS Builder總協(xié)調人開發(fā)經理測試負責人測試人員測試文檔列出測試過程中可能用到的參考文檔、相關的設計文檔以及保存位置，測試完成后應產生的文檔。測試參考文檔列出本計劃各處參考的經過核準的全部文檔和主要文獻。表3 參考文檔表文檔名稱文檔版本號/標識/日期測試輸出文檔表4 測試輸出文檔表文檔說明作者文檔位置測試計劃測試用例性能測試計劃性能測試報

6、告測試報告測試需求列出需要測試的內容。功能測試注：如開發(fā)部門提供需求文檔，則測試需求引用此文檔；如開發(fā)部門不提供需求文檔或需求文檔不完整，則測試需求中列出高級別測試需求。舉例說明：核實是否可以輸入和檢索訂戶信息。核實是否可以插入和顯示內容和類別。核實是否可以輸入和顯示廣告商簡檔和賬戶信息。核實是否可以跟蹤特定訂戶的使用信息。 用戶界面測試注：根據界面規(guī)范列出用戶界面測試的要點。舉例說明：核實必錄字段是否為紅色。核實系統(tǒng)中所有字體大小是否統(tǒng)一。性能測試注：如開發(fā)部門提供需求文檔，則測試需求引用此文檔；如開發(fā)部門不提供需求文檔或需求文檔不完整，則測試需求中列出高級別測試需求。舉例說明：單用戶操作數

7、據錄入中保存一條記錄時間不超過5秒。配置測試注：在此節(jié)列出所要進行配置測試的各種環(huán)境配置與測試內容。舉例說明：測試環(huán)境一：IE6.0。測試內容：安裝卸載測試、功能測試（詳細說明是所有功能還是個別功能）。安全性測試說明是否進行SQL腳本注入、跨腳本注入和.BAK文檔檢查測試數據和數據庫完整性測試故障轉移和恢復測試業(yè)務周期測試可靠性測試病毒測試文檔測試注：在此列出要進行測試的文檔質量目標描述本階段測試目標和要求。質量目標應該包括產品的質量目標和測試小組的質量目標。質量不僅是衡量系統(tǒng)的功能或性能是否正常。對系統(tǒng)來說，在開發(fā)過程中盡早建立全面的質量標準與系統(tǒng)的及時發(fā)布是一樣重要的。質量目標是一個強有力

8、的工具，應該在系統(tǒng)開發(fā)過程中盡早建立。一個定義準確的質量目標在以后的產品開發(fā)過程中幫助決策。例如，系統(tǒng)是否能夠正式發(fā)行？在代碼完成后，應該修復那些缺陷？在系統(tǒng)完成后那種類型的測試是最合適的？產品質量目標可以是產品的質量達到什么樣的目標，產品的流程聯(lián)通性達到什么樣的要求。表5 產品質量目標表測試質量目標確認者測試已實現的產品是否達到設計的要求，包括：各個功能點是否以實現，業(yè)務流程是否正確產品規(guī)定的操作和運行穩(wěn)定測試質量目標評價本項目的測試質量目標可以有：表6 測試質量目標表測試質量目標確認者所設計的測試用例覆蓋率應達到軟件需求的100%所有的測試案例已經執(zhí)行過所有的測試腳本已經執(zhí)行通過所有的嚴重

9、、重要Bug已經解決并由測試驗證每一部分的測試已經被Test Lead確認完成發(fā)現錯誤等級為嚴重、重要、一般的Bug的速率正在下降并接近0在最后的三天內沒有發(fā)現錯誤等級為嚴重、重要的Bug量測統(tǒng)計數不能超10%=（問題總數-原問題總數）/問題總數量測統(tǒng)計，應該無嚴重BUG，重要問題不能超5%=（總重要問題數-原重要問題數）/問題總數資源需求培訓資料表7 培訓資料表培訓需求培訓內容培訓人員開始時間完成時間業(yè)務流程安裝配置工具使用測試環(huán)境按下表格記錄測試。表8 測試環(huán)境表服務器端序號機型網速IP地址cpu內存操作系統(tǒng)軟件預計空間1客服端序號機型/機器名網速IP地址cpu內存操作系統(tǒng)軟件預計空間測試

10、工具此項目將使用以下工具：注：可適當地刪除或添加工具項。表9 工具使用情況表工具產商/自產版本測試管理缺陷跟蹤用于功能性測試的 ASQ 工具用于性能測試的 ASQ 工具配置管理DBMS 工具人力資源下表列出了在此項目的人員配備方面所作的各種假定。注：可適當地刪除或添加角色項。表10 角色分派表人力資源角色所推薦的最少資源（所分配的人員）具體職責或注釋測試設計員如有多個人員，則詳細說明具體的工作內容。如設計測試用例，要說明具體設計哪些模塊的測試用例（考慮對不同系統(tǒng)的公共模塊避免重復進行測試設計）。職責： 生成測試計劃 生成測試用例 評估測試測試員執(zhí)行測試職責： 按照測試用例執(zhí)行測試 提交錯誤報告

11、測試策略測試策略提供了對測試對象進行測試的推薦方法。對于每種測試，都應提供測試說明，并解釋其實施和執(zhí)行的原因。如果將不實施和執(zhí)行某種測試，則應該用一句話加以說明，并陳述這樣做的理由。例如，“將不實施和執(zhí)行該測試。該測試不合適”。制定測試策略時所考慮的主要事項有：將要使用的技術以及判斷測試何時完成的標準。下面列出了在進行每項測試時需考慮的事項，除此之外，測試還只應在安全的環(huán)境中使用已知的、有控制的數據庫來執(zhí)行。單元測試單元測試由研發(fā)人員進行單元測試代碼編寫、執(zhí)行。集成測試集成測試的目的是確保程序滿足概要設計說明書的要求。它所測試的內容包括模塊的功能，模塊間的接口以及集成后的功能，并且對以前集成的

12、build進行增量式測試。集成測試策略：描寫集成測試策略。例：主要在系統(tǒng)測試的第一輪中進行。開發(fā)完一個模塊，就測一個模塊，確保集成測試與開發(fā)進度相吻合。集成測試以功能測試為主，同時兼顧用戶界面測試，易用性測試，數據和數據庫完整性測試及性能測試。系統(tǒng)測試系統(tǒng)測試是通過與系統(tǒng)的需求規(guī)格作比較，發(fā)現軟件與系統(tǒng)需求規(guī)格不相符合或與之矛盾的地方。它將通過確認測試的軟件，作為整個基于計算機系統(tǒng)的一個元素，與計算機硬件、外設、某些支持軟件、數據和人員等其他系統(tǒng)元素結合起來，在模擬實際運行（使用）環(huán)境下，對系統(tǒng)進行的測試。系統(tǒng)測試主要進行業(yè)務流程方面的測試，同時進行回歸測試。系統(tǒng)測試策略：描寫系統(tǒng)測試策略。例

13、本次一共分三輪測試。使用交叉測試法、因果關系法、等價劃分法和約束法。第一輪測試 開發(fā)完一個模塊，就測一個模塊。以功能測試為主，同時兼顧用戶界面測試，易用性測試，數據和數據庫完整性測試及性能測試。盡可能將存在的問題暴露出來。確保業(yè)務流程能走通，盡可能將需求中的功能點核實。所設計的測試用例都執(zhí)行完。并補充相應的測試用例。第二輪測試 保證系統(tǒng)正常功能正確的情況下對邊界和一些特殊的情況。保證系統(tǒng)界面符合界面規(guī)范和友好性符合用戶操作習慣。保證多用戶并發(fā)操作時模塊功能實現正確。系統(tǒng)中所有功能按正常流程都能正確實現。在規(guī)定的測試時間段內按要求完成測試。經過測試保證系統(tǒng)符合項目規(guī)范；網頁可讀性；網頁下載速度；

14、系統(tǒng)便用性；瀏覽器兼容性等多個方面。第三輪測試 達到第3章質量目標 測試類型 可以根據產品或項目的實際情況對下方的測試類型進行刪減功能測試對測試對象的功能測試應側重于所有可直接追蹤到用例或業(yè)務功能和業(yè)務規(guī)則的測試需求。這種測試的目標是核實數據的接受、處理和檢索是否正確，以及業(yè)務規(guī)則的實施是否恰當。此類測試基于黑盒技術，該技術通過圖形用戶界面 (GUI) 與應用程序進行交互，并對交互的輸出或結果進行分析，以此來核實應用程序及其內部進程。以下為各種應用程序列出了推薦使用的測試概要：表11 功能測試策略表測試目標：確保測試對象的功能正常，滿足功能需求技術：利用有效的和無效的數據來執(zhí)行各個用例、用例流

15、或功能，以核實以下內容：在使用有效數據時得到預期的結果。在使用無效數據時顯示相應的錯誤消息或警告消息。各業(yè)務規(guī)則都得到了正確的應用。完成標準：所設計的功能測試用例已全部執(zhí)行。所發(fā)現的缺陷除推遲解決的問題外已全部解決，推遲的問題需經評審通過。需考慮的特殊事項：確定或說明那些將對功能測試的實施和執(zhí)行造成影響的事項或因素（內部的或外部的）用戶界面測試用戶界面 (UI) 測試用于核實用戶與軟件之間的交互。UI 測試的目標是確保用戶界面會通過測試對象的功能來為用戶提供相應的訪問或瀏覽功能。另外，UI 測試還可確保 UI 中的對象按照預期的方式運行，并符合公司或行業(yè)的標準。 表12 用戶界面測試策略表測試

16、目標：核實以下內容：通過測試對象進行的瀏覽可正確反映業(yè)務的功能和需求，這種瀏覽包括窗口與窗口之間、字段與字段之間的瀏覽，以及各種訪問方法（Tab 健、鼠標移動、和快捷鍵）的使用窗口的對象和特征（例如，菜單、大小、位置、狀態(tài)和中心）都符合標準。符合界面規(guī)范。技術：為每個窗口創(chuàng)建或修改測試，以核實各個應用程序窗口和對象都可正確地進行瀏覽，并處于正常的對象狀態(tài)。完成標準：成功地核實出各個窗口都與基準版本保持一致，或符合可接受標準。符合界面規(guī)范。所設計的界面測試用例已全部執(zhí)行。所發(fā)現的缺陷除推遲解決的問題外已全部解決，推遲的問題需經評審通過。需考慮的特殊事項：并不是所有定制或第三方對象的特征都可訪問。

17、性能測試對響應時間、事務處理速率和其他與時間相關的需求進行評測和評估。性能評測的目標是核實性能需求是否都已滿足。實施和執(zhí)行性能評測的目的是將測試對象的性能行為當作條件（例如工作量或硬件配置）的一種函數來進行評測和微調。注：以下所說的事務是指“邏輯業(yè)務事務”。這種事務被定義為將由系統(tǒng)的某個 Actor 通過使用測試對象來執(zhí)行的特定用例，例如，添加或修改給定的合同。表13 性能測試策略表測試目標：核實所指定的事務或業(yè)務功能在以下情況下的性能 行為：正常的預期工作量預期的最繁重工作量技術：使用為功能或業(yè)務周期測試制定的測試過程。通過修改數據文件來增加事務數量，或通過修改腳本來增加每項事務的迭代數量。

18、腳本應該在一臺計算機上運行（最好是以單個用戶、單個事務為基準），并在多個客戶機（虛擬的或實際的客戶機，請參見下面的“需要考慮的特殊事項”）上重復。完成標準：單個事務或單個用戶：在每個事務所預期或要求的時間范圍內成功地完成測試腳本，沒有發(fā)生任何故障。多個事務或多個用戶：在可接受的時間范圍內成功地完成測試腳本，沒有發(fā)生任何故障。所設計的性能測試用例已全部執(zhí)行。所發(fā)現的缺陷除推遲解決的問題外已全部解決，推遲的問題需經評審通過。需考慮的特殊事項：綜合的性能測試還包括在服務器上添加后臺工作量。 可采用多種方法來執(zhí)行此操作，其中包括： 直接將“事務強行分配到”服務器上，這通常以“結構化查詢語言”(SQL)

19、 調用的形式來實現。通過創(chuàng)建“虛擬的”用戶負載來模擬許多個（通常為數百個）客戶機。此負載可通過“遠程終端仿真”(Remote Terminal Emulation) 工具來實現。此技術還可用于在網絡中加載“流量”。使用多臺實際客戶機（每臺客戶機都運行測試腳本）在系統(tǒng)上添加負載。 性能測試應該在專用的計算機上或在專用的機時內執(zhí)行，以便實現完全的控制和精確的評測。性能測試所用的數據庫應該是實際大小或相同縮放比例的數據庫。配置測試配置測試核實測試對象在不同的軟件和硬件配置中的運行情況。在大多數生產環(huán)境中，客戶機工作站、網絡連接和數據庫服務器的具體硬件規(guī)格會有所不同。客戶機工作站可能會安裝不同的軟件例

20、如，應用程序、驅動程序等而且在任何時候，都可能運行許多不同的軟件組合，從而占用不同的資源。表14 配置測試策略表測試目標：核實測試對象可在所需的硬件和軟件配置中正常運行。技術：使用功能測試腳本。測試必須覆蓋系統(tǒng)支持的操作系統(tǒng)和瀏覽器。測試IE的COOKIES與歷史記錄全部清除與不清除兩種情況下，瀏覽的正確性。測試IE的時區(qū)設置及時間格式設置對瀏覽操作的影響。完成標準：對于測試對象軟件和非測試對象軟件的各種組合，所有事務都成功完成，沒有出現任何故障。所設計的配置測試用例已全部執(zhí)行。所發(fā)現的缺陷除推遲解決的問題外已全部解決，推遲的問題需經評審通過。需考慮的特殊事項：需要、可以使用并可以通過桌面訪問

21、哪種非測試對象軟件？通常使用的是哪些應用程序？應用程序正在運行什么數據？例如，在 Excel 中打開的大型電子表格，或是在 Word 中打開的 100 頁文檔。作為此測試的一部分，應將整個系統(tǒng)、Netware、網絡服務器、數據庫等都記錄下來。 安全性測試說明是否進行SQL腳本注入、跨腳本注入和.BAK文檔檢查測試。表15 安全性測試策略表測試目標：技術：完成標準：需考慮的特殊事項：數據和數據庫完整性測試在 中，數據庫和數據庫進程應作為一個子系統(tǒng)來進行測試。在測試這些子系統(tǒng)時，不應將測試對象的用戶界面用作數據的接口。對于數據庫管理系統(tǒng) (DBMS)，還需要進行深入的研究，以確定可以支持以下測試的

22、工具和技術。表16 數據和數據庫完整性測試策略表測試目標：確保數據庫訪問方法和進程正常運行，數據不會遭到損壞。技術：調用各個數據庫訪問方法和進程，并在其中填充有效的和無效的數據（或對數據的請求）。檢查數據庫，確保數據已按預期的方式填充，并且所有的數據庫事件都已正常發(fā)生；或者檢查所返回的數據，確保為正當的理由檢索到了正確的數據完成標準：所有的數據庫訪問方法和進程都按照設計的方式運行，數據沒有遭到損壞。需考慮的特殊事項：測試可能需要 DBMS 開發(fā)環(huán)境或驅動程序在數據庫中直接輸入或修改數據。進程應該以手工方式調用。應使用小型或最小的數據庫（記錄的數量有限）來使所有無法接受的事件具有更大的可視度。故障轉移和恢復測試故障轉移和恢復測試可確保測試對象能成功