測試計劃（詳細版）

測試計劃Testing plan，描述了要進行的測試活動的范圍、方法、資源和進度的文檔；是對整個信息系統應用軟件組裝測試和確認測試。?[1]??它確定測試項、被測特性、測試任務、誰執行任務、各種可能的風險。測試計劃可以有效預防計劃的風險，保障計劃的順利實施。

簡介

測試計劃的目的

制定測試計劃，要達到的目標如下：

（1）為測試各項活動制定一個現實可行的、綜合的計劃，包括每項測試活動的對象、范圍、方法、進度和預期結果。

（2）為項目實施建立一個組織模型，并定義測試項目中每個角色的責任和工作內容。

（3）開發有效的測試模型，能正確地驗證正在開發的軟件系統。

（4）確定測試所需要的時間和資源，以保證其可獲得性、有效性。

（5）確立每個測試階段測試完成以及測試成功的標準、要實現的目標。

（6）識別出測試活動中各種風險，并消除可能存在的風險，降低由不可能消除的風險所帶來的損失。

測試計劃的作用

測試計劃通常分內部作用和外部作用，內部作用有以下3種：

（1）作為測試計劃的結果，讓相關人員和開發人員來評審。

（2）存儲計劃執行的細節，讓測試人員進行同行評審。

（3）存儲計劃進度表、測試環境等更多的信息。

測試計劃的外部作用是為顧客提供一種信心，通常向顧客交代有關測試過程、人員的技能、資源、使用的工具等信息。

背景

[對測試對象（構件、應用程序、系統等）及其目標進行簡要說明。需要包括的信息有：主要的功能和性能、測試對象的構架以及項目的簡史。?

范圍

[描述測試的各個階段（例如，單元測試、集成測試或系統測試），并說明本計劃所針對的測試類型（如功能測試或性能測試）。

簡要地列出測試對象中將接受測試或將不接受測試的那些性能和功能。

如果在編寫此文檔的過程中做出的某些假設可能會影響測試設計、開發或實施，則列出所有這些假設。

列出可能會影響測試設計、開發或實施的所有風險或意外事件。

列出可能會影響測試設計、開發或實施的所有約束。

編寫條件

俗話說：凡事預則立，不預則廢！在測試項目之初就要制定相應的測試計劃。接下來談下如何編寫測試計劃問題。首先了解以下幾個問題：

1．為什么要編寫測試計劃？

1）領導能夠根據測試計劃做宏觀調控，進行相應資源配置等；

2）測試人員能夠了解整個項目測試情況以及項目測試不同階段的所要進行的工作等；

3）便于其他人員了解測試人員的工作內容，進行有關配合工作

2．什么時間開始編寫測試計劃？

（測試需求分析前總體測試計劃書/測試需求分析后詳細測試計劃書）

3．由誰來編寫測試計劃？

具有豐富經驗的項目測試負責人

4．測試計劃編寫6要素？（5W1H）

1）why——為什么要進行這些測試；

2) what—測試哪些方面，不同階段的工作內容；

3) when—測試不同階段的起止時間；

4) where—相應文檔，缺陷的存放位置，測試環境等；

5) who—項目有關人員組成，安排哪些測試人員進行測試

6) how—如何去做，使用哪些測試工具以及測試方法進行測試。

注意事項

1．測試計劃不一定要盡善盡美，但一定要切合實際，要根據項目特點、公司實際情況來編制，不能脫離實際情況；

2．測試計劃一旦制定下來，并不就是一成不變的，世界萬事萬物時時刻刻都在變化，軟件需求、軟件開發、人員流動等都在時刻發生著變化，測試計劃也要根據實際情況的變化而不斷進行調整，以滿足實際測試要求．

3．測試計劃要能從宏觀上反映項目的測試任務、測試階段、資源需求等，不一定要太過詳細．

評審總結

1.計劃評審

測試計劃編寫完成后，一般要對測試計劃的正確性、全面性以及可行性等進行評審，評審人員的組成包括軟件開發人、營銷人員、測試負責人以及其他有關項目負責人。

2.計劃總結

項目完成后，應該對計劃的執行情況進行評審，看有哪些不合理的地方，以便為編寫下一個項目測試計劃做經驗積累。

參考模版

測試計劃

1　引言

1．1編寫目的

本測試計劃的具體編寫目的，指出預期的讀者范圍。

1．2背景

說明：

a 測試計劃所從屬的軟件系統的名稱；

b．該開發項目的歷史，列出用戶和執行此項目測試的計算中心，說明在開始執行本測試計劃之前必須完成的各項工作。

1．3定義

列出本文件中用到的專門術語的定義和外文首字母組詞的原詞組。

1．4參考資料

列出要用到的參考資料，如：

a．本項目的經核準的計劃任務書或合同、上級機關的批文；

b．屬于本項目的其他已發表的文件；

c．本文件中各處引用的文件、資料，包括所要用到的軟件開發標準。列出這些文件的標題、文件編號、發表日期和出版單位，說明能夠得到這些文件資料的來源。

2　計劃

2．1軟件說明

提供一份圖表，并逐項說明被測軟件的功能、輸入和輸出等質量指標，作為敘述測試計劃的提綱。

2．2測試內容

列出組裝測試和確認測試中的每一項測試內容的名稱標識符、這些測試的進度安排以及這些測試的內容和目的，例如模塊功能測試、接口正確性測試、數據文卷存取的測試、運行時間的測試、設計約束和極限的測試等。

2．3測試1（標識符）

給出這項測試內容的參與單位及被測試的部位。

2．3．1進度安排

給出對這項測試的進度安排，包括進行測試的日期和工作內容（如熟悉環境。培訓、準備輸入數據等）。

2．3．2條件

陳述本項測試工作對資源的要求，包括：

a．設備所用到的設備類型、數量和預定使用時間；

b．軟件列出將被用來支持本項測試過程而本身又并不是被測軟件的組成部分的軟件，如測試驅動程序、測試監控程序、仿真程序、樁模塊等等；

c．人員列出在測試工作期間預期可由用戶和開發任務組提供的工作人員的人數。技術水平及有關的預備知識，包括一些特殊要求，如倒班操作和數據鍵入人員。

2．3．3測試資料

列出本項測試所需的資料，如：

a．有關本項任務的文件；

b．被測試程序及其所在的媒體；

c．測試的輸入和輸出舉例；

d．有關控制此項測試的方法、過程的圖表。

2．3．4測試培訓

說明或引用資料說明為被測軟件的使用提供培訓的計劃。規定培訓的內容、受訓的人員及從事培訓的工作人員。

2．4測試2（標識符）

用與本測試計劃2．3條相類似的方式說明用于另一項及其后各項測試內容的測試工作計劃。

3　測試設計說明

3．1測試1（標識符）

說明對第一項測試內容的測試設計考慮。

3．1．1控制

說明本測試的控制方式，如輸入是人工、半自動或自動引入、控制操作的順序以及結果的記錄方法。

3．1．2輸入

說明本項測試中所使用的輸入數據及選擇這些輸入數據的策略。

3．1．3輸出

說明預期的輸出數據，如測試結果及可能產生的中間結果或運行信息。

3．1．4過程

說明完成此項測試的一個個步驟和控制命令，包括測試的準備、初始化、中間步聚和運行結束方式。

3．2測試2（標識符）

用與本測試計劃K．3．l條相類似的方式說明第2項及其后各項測試工作的設計考慮。

4　評價準則

4．1范圍

說明所選擇的測試用例能夠接查的范圍及其局限性。

4．2數據整理

陳述為了把測試數據加工成便于評價的適當形式，使得測試結果可以同，已知結果進行比較而要用到的轉換處理技術，如手工方式或自動方式；如果是用自動方式整理數據，還要說明為進行處理而要用到的硬件、軟件資源。

4．3尺度。

說明用來判斷測試工作是否能通過的評價尺度，如合理的輸出結果的類型、測試輸出結果與預期輸出之間的容許偏離范圍、允許中斷或停機的最大次數。

4．4測試人員需求　?4．5其他（儀器、服務器等）

5．風險評估

5．1人力方面；

5．2時間方面；

5．3環境方面；

5．4資源方面

5．5部門合作方面

6．其他內容

測試策略

簡介

提供了對測試對象進行測試的推薦方法。

對于每種測試，都應提供測試說明，并解釋其實施的原因。

制定測試策略時所考慮的主要事項有：將要使用的技術以及判斷測試何時完成的標準。

下面列出了在進行每項測試時需考慮的事項，除此之外，測試還只應在安全的環境中使用已知的、有控制的數據庫來執行。

注意：不實施某種測試，則應該用一句話加以說明，并陳述這樣的理由。例如，“將不實施該測試。該測試本項目不適用”。

數據和數據庫完整性測試

[要<項目名稱>中，數據庫和數據庫進程應作為一個子系統來進行測試。在測試這些子系統時，不應將測試對象的用戶界面用作數據的接口。對于數據庫管理系統（DBMS），還需要進行深入的研究，以確定可以支持以下測試的工具和技術。]

測試目標：[確保數據庫訪問方法和進程正常運行，數據不會遭到損壞]

測試范圍：

技術：[調用各個數據庫訪問方法和進程，并在其中填充有效的和無效的數據（或對數據的請求）。

檢查數據庫，確保數據已按預期的方式填充，并且所有的數據庫事件已正常發生；或者檢查所返回的數據，確保正當的理由檢索到了正確的數據]

完成標準：[所有的數據庫訪問方法和進程都按照設計的方式運行，數據沒有遭到損壞。]

測試重點和優先級：

需考慮的特殊事項：[測試可能需要DBMS開發環境或驅動程序在數據庫中直接輸入或修改數據。

進程應該以手工方式調用。

應使用小型或最小的數據庫（記錄的數量有限）來使所有無法接受的事件具有更大的可視度。]

接口測試

測試目標：確保接口調用的正確性

測試范圍：所有軟件、硬件接口，記錄輸入輸出數據

技術：

開始標準：

完成標準：

測試重點和優先級：

需考慮的特殊事項：接口的限制條件

集成測試

[集成測試―主要目的檢測系統是否達到需求對業務流程及數據流的處理是否符合標準，檢測系統對業務流處理是否存在邏輯不嚴謹及錯誤，檢測需求是否存在不合理的標準及要求。此階段測試基于功能完成的測試。]

測試目標：檢測需求中業務流程，數據流的正確性

測試范圍：需求中明確的業務流程，或組合不同功能模塊而形成一個大的功能。

技術：[利用有效的和無效的數據來執行各個用例、用例流或功能，以核實以下內容：在使用有效數據時得到預期的結果。

在使用無效數據時顯示相應的錯誤消息或警告消息。各業務規則都得到了正確的應用。]

開始標準：在完成某個集成測試時必須達到標準

完成標準：[所計劃的測試已全部執行。所發現的缺陷已全部解決。]

測試重點和優先級：測試重點指在測試過程中需著重測試的地方，優先級可以根據需求及嚴重來定

需考慮的特殊事項：[確定或說明那些將對功能測試的實施和執行造成影響的事項或因素（內部的或外部的）]

功能測試

[對測試對象的功能測試應側重于所有可直接追蹤到用例或業務功能和業務規則的測試需求。這種測試的目標是核實數據的接受、處理和檢索是否正確，以及業務規則的實施是否恰當。此類測試基于黑盒技術，該技術通過圖形用戶界面（GUI）與應用程序進行交互，并對交互的輸出或結果進行分析，以此來核實應用程序及其內部進程。以下為各種應用程序列出了推薦使用的測試概要：]

測試目標：[確保測試的功能正常，其中包括導航，數據輸入，處理和檢索等功能。]

測試范圍：

技術：[利用有效的和無效的數據來執行各個用例、用例流或功能，以核實以下內容：在使用有效數據時得到預期的結果。

在使用無效數據時顯示相應的錯誤消息或警告消息。各業務規則都得到了正確的應用。]

開始標準：

完成標準：

測試重點和優先級：

需考慮的特殊事項：[確定或說明那些將對功能測試的實施和執行造成影響的事項或因素（內部的或外部的）]

用戶界面測試

[用戶界面（UI）測試用于核實用戶與軟件之間的交互。UI測試的目標是確保用戶界面會通過測試對象的功能來為用戶提供相應的訪問或瀏覽功能。另外，UI測試還可確保UI中的對象按照預期的方式運行，并符合公司或行業的標準。]

測試目標：[核實以下內容：

通過測試進行的瀏覽可正確反映業務的功能和需求，這種瀏覽包括窗口與窗口之間、字段與字段之間的瀏覽，以及各種訪問方法（Tab鍵、鼠標移動、和快捷鍵）的使用窗口的對象和特征（例如，菜單、大小、位置、狀態和中心）都符合標準。]

測試范圍：

技術：[為每個窗口創建或修改測試，以核實各個應用程序窗口和對象都可正確地進行瀏覽，并處于正常的對象狀態。]

開始標準：

完成標準：[成功地核實出各個窗口都與基準版本保持一致，或符合可接受標準]

測試重點和優先級：

需考慮的特殊事項：[并不是所有定制或第三方對象的特征都可訪問。]

性能評測

[性能評測是一種性能測試，它對響應時間、事務處理速率和其他與時間相關的需求進行評測和評估。性能評測的目標是核實性能需求是否都已滿足。實施和執行性能評測的目的是將測試對象的性能行為當作條件（例如工作量或硬件配置）的一種函數來進行評測和微調。

注：以下所說的事務是指“邏輯業務事務”。這種事務被定義為將由系統的某個Actor通過使用測試對象來執行的特定用例，添加或修改給定的合同。]

測試目標：[核實所指定的事務或業務功能在以下情況下的性能行為：正常的預期工作量預期的最繁重工作量]

測試范圍：

技術：[使用為功能或業務周期測試制定的測試過程。通過修改數據文件來增加事務數量，或通過修改腳本來增加每項事務的迭代數量。腳本應該在一臺計算機上運行（最好是以單個用戶、單個事務為基準），并在多個客戶機（虛擬的或實際的客戶機，請參見下面的“需要考慮的特殊事項”）上重復。]

開始標準：

完成標準：[單個事務或單個用戶：在每個事務所預期時間范圍內成功地完成測試腳本，沒有發生任何故障。][多個事務或多個用戶：在可接受的時間范圍內成功地完成測試腳本，沒有發生任何故障。]

測試重點和優先級：

需考慮的特殊事項：[綜合的性能測試還包括在服務器上添加后臺工作量。可采用多種方法來執行此操作，其中包括：直接將“事務強行分配到”服務器上，這通常以“結構化語言”（SQL）調用的形式來實現。通過創建“虛擬的”用戶負載來模擬許多個（通常為數百個）客戶機。此負載可通過“遠程終端仿真（Remote Terminal Emulation）工具來實現。此技術還可用于在網絡中加載“流量”。使用多臺實際客戶機（每臺客戶機都運行測試腳本）在系統上添加負載。性能測試應該在專用的計算機上或在專用的機時內執行，以便實現完全的控制和精確的評測。性能測試所用的數據庫應該是實際大小或相同縮放比例的數據庫。]

負載測試

[負載測試是一種性能測試。在這種測試中，將使測試對象承擔不同的工作量，以評測和評估測試對象在不同工作量條件下的性能行為，以及持續正常運行的能力。負載測試的目標是確定并確保系統在超出最大預期工作量的情況下仍能正常運行。此外，負載測試還要評估性能特征，例如，響應時間、事務處理速率和其他與時間相關的方面。]

[注：以下所說的事務是指“邏輯業務事務”。這各事務被定義為將由系統的某個最終用戶通過使用應用程序來執行的特定功能，例如，添加或修改給定的合同。]

測試目標：[核實所指定的事務或商業理由在不同的工作量條件下的性能行為時間。]

測試范圍：

技術：[使用為功能或業務周期測試制定的測試。通過修改數據文件來增加事務數量，或通過修改腳本來增加每項事務發生的次數。]

開始標準：

完成標準：[多個事務或多個用戶：在可接受的時間范圍內成功地完成測試，沒有發生任何故障。]

測試重點和優先級：

需考慮的特殊事項：[負載測試應該在專用的計算機上或在專用的機時內執行，以便實現完全的控制和精確的評測。

負載測試所用的數據庫應該是實際大小或相同縮放比例的數據庫。]

強度測試

[強度測試是一種性能測試，實施和執行此類測試的目的是找出因資源不足或資源爭用而導致的錯誤。如果內存或磁盤空間不足，測試對象就可能會表現出一些在正常條件下并不明顯的缺陷。而其他缺陷則可能由于爭用共享資源（如數據庫鎖或網絡帶寬）而造成的。強度測試還可用于確定測試對象能夠處理的最大工作量。]

[注：以下提到的事務都是指邏輯業務事務。]

測試目標：[核實測試對象能夠在以下強度條件下正常運行，不會出現任何錯誤：服務器上幾乎沒有或根本沒有可用的內存（RAM和DASD）連接或模擬了最大實際（實際允許）數量的客戶機多個用戶對相同的數據或帳戶執行相同的事務最繁重的事務量或最差的事務組合（請參見上面的“性能測試”）。注：強度測試的目標可表述為確定和記錄那些使系統無法繼續正常運行的情況或條件。

客戶機的強度測試在“配置測試”的第3.1.11節中進行了說明。]

測試范圍：

技術：[使用為性能評測或負載測試制定的測試。要對有限的資源進行測試，就應該在一臺計算機上運行測試，而且應該減少或限制服務器上的RAM和DASD。對于其他強度測試，應該使用多臺客戶機來運行相同的測試或互補的測試，以產生最繁重的事務量或最差的事務組合。]

開始標準：

完成標準：[所計劃的測試已全部執行，并且在達到或超出指定的系統限制時沒有出現任何軟件故障，或者導致系統出現故障條件的并不在指定的條件范圍之內。]

測試重點和優先級：

需考慮的特殊事項：[如果要增加網絡工作強度，可能會需要使用網絡工具來給網絡加載消息或信息包。應該暫時減少用于系統的DASD，以限制數據庫可用空間的增長。使多個客戶機對相同的記錄或數據帳戶同時進行的訪問達到同步。]

容量測試

[容量測試使測試對象處理大量的數據，以確定是否達到了將使軟件發生故障的極限。容量測試還將確定測試對象在給定時間內能夠持續處理的最大負載或工作量。例如，如果測試對象正在為生成一份報表而處理一組數據庫記錄，那么容量測試就會使用一個大型的測試數據庫。檢驗該軟件是否正常運行并生成了正確的報表。]

測試目標：[核實測試對象在以下高容量條件下能否正常運行：連接或模擬了最大（實際或實際允許）數量的客戶機，所有客戶機在長時間內執行相同的、且情況（性能）最壞的業務功能。已達到最大的數據庫大小（實際的或按比例縮放的），而且同時執行多個查詢或報表事務。]

測試范圍：

技術：[使用為性能評測或負載測試制定的測試。應該使用多臺客戶機來運行相同的測試或互補的測試，以便在長時間內產生最繁重的事務量或最差的事務組合（請參見上面的“強度測試”）創建最大的數據庫大小（實際的、按比例縮放的、或填充了代表性數據的數據庫），并使用多臺客戶機在長時間內同時運行查詢和報表事務。]

開始標準：

完成標準：所計劃的測試已全部執行，而且達到或超出指定的系統限制時沒有出現任何軟件故障。]

測試重點和優先級：

需考慮的特殊事項：[對于上述的高容量條件，哪個時間段是可以接受的時間？]

安全性和訪問

安全性和訪問控制測試

訪問控制測試側重于安全性的兩個關鍵方面：應用程序級別的安全性，包括對數據或業務功能的訪問。系統級別的安全性，包括對系統的登錄或遠程訪問。應用程序級別的安全性可確保：在預期的安全性情況下，Actor只能訪問特定的功能或用例，或者只能訪問有限的數據。例如，可能會允許所有人輸入數據，創建新帳戶，但只有管理員才能刪除這些數據或帳戶。如果具有數據級別的安全性，測試就可確保“用戶類型一”能夠看到所有客戶消息（包括財務數據），而“用戶二”看見同一客戶的統計數據。系統級別的安全性可確保只有具備系統訪問權限的用戶才能訪問應用程序，而且只能通過相應的網關來訪問。] 測試目標：應用程序級別的安全性：[核實Actor只能訪問其所屬用戶類型已被授權訪問的那些功能或數據。]系統級別的安全性：[核實只有具備系統和應用程序訪問權限的Actor才能訪問系統和應用程序。] 測試范圍：技術：應用程序級別的安全性：[確定并列出各用戶類型及其被授權訪問的功能或數據。][為各用戶類型創建測試，并通過創建各用戶類型所特有的事務來核實其權限。] 修改用戶類型并為相同的用戶重新運行測試。對于每種用戶類型，確保正確地提供或拒絕了這些附加的功能或數據。系統級別的訪問：[請參見以下的“需考慮的特殊事項”。] 開始標準：完成標準：[各種已知的Actor類型都可訪問相應的功能或數據，而且所有事務都按照預期的方式運行，并在先前的應用程序功能測試中運行了所有的事務。] 測試重點和優先級：需考慮的特殊事項：[必須與相應的網絡或系統管理員一直對系統訪問權進行檢查和討論。由于此測試可能是網絡管理可系統管理的職能，可能會不需要執行此測試。]

故障轉移和恢復測試

[故障轉移和恢復測試可可確保測試對象能成功完成轉移，并能從導致意外數據損失或數據完整性破壞的各種硬件、軟件可網絡故障中恢復。故障轉移測試可確保：對于必須持續運行的系統，一旦發生故障，備用系統就將不失時機地“頂替”發生故障的系統，以避免丟失任何數據或事務。恢復測試是一種對抗性的測試過程。在這種測試中，將把應用程序或系統置于極端的條件下（或者是模擬的極端條件下），以產生故障（例如設備輸入/輸出（I/O）故障或無效的數據庫指針和關鍵字）。然后調用恢復進程并監測和檢查應用程序和系統，核實應用程序或系統和數據已得到了正確的恢復。]

測試目標：[確保恢復進程（手工或自動）將數據庫、應用程序和系統正確地恢復到預期的已知狀態。

測試中將包括以下各種情況：客戶機斷電、服務器斷電、通過網絡服務器產生的通信中斷DASD和/或DASD控制器被中斷、斷電或與DASD和/或DASD控制器的通信中斷

周期未完成（數據過濾進程被中斷，數據同步進程被中斷）、數據庫指針或關鍵字無效、數據庫中的數據元素無效或遭到破壞]

測試范圍：

技術：[應該使用為功能和業務周期測試創建的測試來創建一系列的事務。一旦達到預期的測試起點，就應該分別執行或模擬以下操作：

? 客戶機斷電：關閉PC機的電源。

? 服務器斷電：模擬或啟動服務器的斷電過程。

? 通過網絡服務器產生的中斷：模擬或啟動網絡的通信中斷（實際斷開通信線路的連接或關閉網絡服務器或路由器的電源）。

? DASD和DASD控制器被中斷、斷電或與DASD和DASD控制器的通信中斷：模擬與一個或多個DASD控制器或設備的通信，或實際取消這種通信。

? 一旦實現了上述情況（或模擬情況），就應該執行其他事務。而且一旦達到第二個測試點狀態，就應調用恢復過程。

? 在測試不完整的周期時，所使用的技術與上述技術相同，只不過應異常終止或提前終止數據庫進程本身。

? 對以下情況的測試需要達到一個已知的數據庫狀態。當破壞若干個數據庫字段、指針和關鍵字時，應該以手工方式在數據庫中（通過數據庫工具）直接進行。其他事務應該通過使用“應用程序功能測試”和“業務周期測試”中的測試來執行，并且應執行完整的周期。]