測試計劃

1．簡介

1. 1目的

＜項目名稱＞的這一“測試計劃”文檔有助於實現以下目標：

確定現有項目的信息和應測試的軟件構件。

列出推薦的測試需求（高級需求）。

推薦可採用的測試策略，並對這些策略加以說明。

確定所需的資源，並對測試的工作量進行估計。

列出測試項目的可交付元素。

1.2背景

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

1.3範圍

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

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

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

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

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

2．測試參考文檔和測試提交文檔

2.1測試參考文檔

下表列出了制定測試計劃時所使用的文檔，並標明瞭各文檔的可用性：

注：可適當地刪除或添加文檔項。

文檔（版本/日期）	已創建或可用	已被接收或已經過複審	作者或來源	備註
可行性分析報告	是□　否□	是□　否□
軟件需求定義	是□　否□	是□　否□
軟件系統分析（STD,DFD,CFD,DD）	是□　否□	是□　否□
軟件概要設計	是□　否□	是□　否□
軟件詳細設計	是□　否□	是□　否□
軟件測試需求	是□　否□	是□　否□
硬件可行性分析報告	是□　否□	是□　否□
硬件需求定義	是□　否□	是□　否□
硬件概要設計	是□　否□	是□　否□
硬件原理圖設計	是□　否□	是□　否□
硬件結構設計（包含PCB）	是□　否□	是□　否□
FPGA設計	是□　否□	是□　否□
硬件測試需求	是□　否□	是□　否□
PCB設計	是□　否□	是□　否□
USB驅動設計	是□　否□	是□　否□
Tuner BSP 設計	是□　否□	是□　否□
MCU設計	是□　否□	是□　否□
模塊開發手冊	是□　否□	是□　否□
測試時間表及人員安排	是□　否□	是□　否□
測試計劃	是□　否□	是□　否□
測試方案	是□　否□	是□　否□
測試報告	是□　否□	是□　否□
測試分析報告	是□　否□	是□　否□
用戶操作手冊	是□　否□	是□　否□
安裝指南	是□　否□	是□　否□

2.2測試提交文檔

下面應當列出在測試階段結束後，所有可提交的文檔。

3.測試進度

測試活動	計劃開始日期	實際開始日期	結束日期
制定測試計劃
設計測試
集成測試
系統測試
性能測試
安裝測試
用戶驗收測試
對測試進行評估
產品發佈

4.測試資源

4.1人力資源

下表列出了在此項目的人員配備方面所作的各種假定。注：可適當地刪除或添加角色項。

角色	所推薦的最少資源（所分配的專職角色數量）	具體職責或註釋

4.2測試環境

下表列出了測試的系統環境

軟件環境（相關軟件、操作系統等）

硬件環境（網絡、設備等）

4.3測試工具

此項目將列出測試使用的工具：

用途	工具	生產廠商/自產	版本

5.系統風險、優先級

簡要描述測試階段的風險和處理的優先級

6.測試策略

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

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

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

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

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

6.1數據和數據庫完整性測試

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

測試目標：	確保數據庫訪問方法和進程正常運行，數據不會遭到損壞
測試範圍：
技術：	調用各個數據庫訪問方法和進程，並在其中填充有效的和無效的數據（或對數據的請求）。檢查數據庫，確保數據已按預期的方式填充，並且所有的數據庫事件已正常發生；或者檢查所返回的數據，確保正當的理由檢索到了正確的數據
開始標準：
完成標準：	所有的數據庫訪問方法和進程都按照設計的方式運行，數據沒有遭到損壞。
測試重點和優先級：
需考慮的特殊事項：	測試可能需要DBMS開發環境或驅動程序在數據庫中直接輸入或修改數據。進程應該以手工方式調用。應使用小型或最小的數據庫（記錄的數量有限）來使所有無法接受的事件具有更大的可視度。

6.2接口測試

測試目標	確保接口調用的正確性
測試範圍：	所有軟件、硬件接口，記錄輸入輸出數據
技術：
開始標準：
完成標準：
測試重點和優先級：
需考慮的特殊事項：	接口的限制條件

6.3集成測試

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

測試目標	檢測需求中業務流程，數據流的正確性
測試範圍：	需求中明確的業務流程，或組合不同功能模塊而形成一個大的功能。
技術：	利用有效的和無效的數據來執行各個用例、用例流或功能，以覈實以下內容：在使用有效數據時得到預期的結果。在使用無效數據時顯示相應的錯誤消息或警告消息。各業務規則都得到了正確的應用。
開始標準：	在完成某個集成測試時必須達到標準
完成標準：	所計劃的測試已全部執行。所發現的缺陷已全部解決。
測試重點和優先級：	測試重點指在測試過程中需着重測試的地方，優先級可以根據需求及嚴重來定
需考慮的特殊事項：	確定或說明那些將對功能測試的實施和執行造成影響的事項或因素（內部的或外部的）

6.4功能測試

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

測試目標	確保測試的功能正常，其中包括導航，數據輸入，處理和檢索等功能。
測試範圍：
技術：	利用有效的和無效的數據來執行各個用例、用例流或功能，以覈實以下內容：在使用有效數據時得到預期的結果。在使用無效數據時顯示相應的錯誤消息或警告消息。各業務規則都得到了正確的應用。
開始標準：
完成標準：
測試重點和優先級：
需考慮的特殊事項：	確定或說明那些將對功能測試的實施和執行造成影響的事項或因素（內部的或外部的）

6.5用戶界面測試

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

測試目標	覈實以下內容：通過測試進行的瀏覽可正確反映業務的功能和需求，這種瀏覽包括窗口與窗口之間、字段與字段之間的瀏覽，以及各種訪問方法（Tab鍵、鼠標移動、和快捷鍵）的使用窗口的對象和特徵（例如，菜單、大小、位置、狀態和中心）都符合標準。
測試範圍：
技術：	爲每個窗口創建或修改測試，以覈實各個應用程序窗口和對象都可正確地進行瀏覽，並處於正常的對象狀態。
開始標準：
完成標準：	成功地核實出各個窗口都與基準版本保持一致，或符合可接受標準
測試重點和優先級：
需考慮的特殊事項：	並不是所有定製或第三方對象的特徵都可訪問。

6.6性能評測

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

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

測試目標	覈實所指定的事務或業務功能在以下情況下的性能行爲：正常的預期工作量預期的最繁重工作量
測試範圍：
技術：	使用爲功能或業務週期測試製定的測試過程。通過修改數據文件來增加事務數量，或通過修改腳本來增加每項事務的迭代數量。腳本應該在一臺計算機上運行（最好是以單個用戶、單個事務爲基準），並在多個客戶機（虛擬的或實際的客戶機，請參見下面的“需要考慮的特殊事項”）上重複。
開始標準：
完成標準：	單個事務或單個用戶：在每個事務所預期時間範圍內成功地完成測試腳本，沒有發生任何故障。多個事務或多個用戶：在可接受的時間範圍內成功地完成測試腳本，沒有發生任何故障。
測試重點和優先級：
需考慮的特殊事項：	綜合的性能測試還包括在服務器上添加後臺工作量。可採用多種方法來執行此操作，其中包括：直接將“事務強行分配到”服務器上，這通常以“結構化語言”（SQL）調用的形式來實現。通過創建“虛擬的”用戶負載來模擬許多個（通常爲數百個）客戶機。此負載可通過“遠程終端仿真（Remote Terminal Emulation）工具來實現。此技術還可用於在網絡中加載“流量”。使用多臺實際客戶機（每臺客戶機都運行測試腳本）在系統上添加負載。性能測試應該在專用的計算機上或在專用的機時內執行，以便實現完全的控制和精確的評測。性能測試所用的數據庫應該是實際大小或相同縮放比例的數據庫。

6.7負載測試

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

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

測試目標	覈實所指定的事務或商業理由在不同的工作量條件下的性能行爲時間。
測試範圍：
技術：	使用爲功能或業務週期測試製定的測試。通過修改數據文件來增加事務數量，或通過修改腳本來增加每項事務發生的次數。
開始標準：
完成標準：	多個事務或多個用戶：在可接受的時間範圍內成功地完成測試，沒有發生任何故障。
測試重點和優先級：
需考慮的特殊事項：	負載測試應該在專用的計算機上或在專用的機時內執行，以便實現完全的控制和精確的評測。負載測試所用的數據庫應該是實際大小或相同縮放比例的數據庫。

6.8強度測試

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

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

測試目標	覈實測試對象能夠在以下強度條件下正常運行，不會出現任何錯誤：服務器上幾乎沒有或根本沒有可用的內存（RAM和DASD）連接或模擬了最大實際（實際允許）數量的客戶機多個用戶對相同的數據或帳戶執行相同的事務最繁重的事務量或最差的事務組合（請參見上面的“性能測試”）。注：強度測試的目標可表述爲確定和記錄那些使系統無法繼續正常運行的情況或條件。客戶機的強度測試在“配置測試”的第3.1.11節中進行了說明。
測試範圍：
技術：	使用爲性能評測或負載測試製定的測試。要對有限的資源進行測試，就應該在一臺計算機上運行測試，而且應該減少或限制服務器上的RAM和DASD。對於其他強度測試，應該使用多臺客戶機來運行相同的測試或互補的測試，以產生最繁重的事務量或最差的事務組合。
開始標準：
完成標準：	所計劃的測試已全部執行，並且在達到或超出指定的系統限制時沒有出現任何軟件故障，或者導致系統出現故障條件的並不在指定的條件範圍之內。
測試重點和優先級：
需考慮的特殊事項：	如果要增加網絡工作強度，可能會需要使用網絡工具來給網絡加載消息或信息包。應該暫時減少用於系統的DASD，以限制數據庫可用空間的增長。使多個客戶機對相同的記錄或數據帳戶同時進行的訪問達到同步。

6.9容量測試

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

測試目標	覈實測試對象在以下高容量條件下能否正常運行：連接或模擬了最大（實際或實際允許）數量的客戶機，所有客戶機在長時間內執行相同的、且情況（性能）最壞的業務功能。已達到最大的數據庫大小（實際的或按比例縮放的），而且同時執行多個查詢或報表事務。
測試範圍：
技術：	使用爲性能評測或負載測試製定的測試。應該使用多臺客戶機來運行相同的測試或互補的測試，以便在長時間內產生最繁重的事務量或最差的事務組合（請參見上面的“強度測試”）創建最大的數據庫大小（實際的、按比例縮放的、或填充了代表性數據的數據庫），並使用多臺客戶機在長時間內同時運行查詢和報表事務。
開始標準：
完成標準：	所計劃的測試已全部執行，而且達到或超出指定的系統限制時沒有出現任何軟件故障。
測試重點和優先級：
需考慮的特殊事項：	對於上述的高容量條件，哪個時間段是可以接受的時間？

6.10安全性和訪問控制測試

安全性和訪問控制測試側重於安全性的兩個關鍵方面：

應用程序級別的安全性，包括對數據或業務功能的訪問。

系統級別的安全性，包括對系統的登錄或遠程訪問。

應用程序級別的安全性可確保：在預期的安全性情況下，Actor只能訪問特定的功能或用例，或者只能訪問有限的數據。例如，可能會允許所有人輸入數據，創建新帳戶，但只有管理員才能刪除這些數據或帳戶。如果具有數據級別的安全性，測試就可確保“用戶類型一”能夠看到所有客戶消息（包括財務數據），而“用戶二”看見同一客戶的統計數據。

系統級別的安全性可確保只有具備系統訪問權限的用戶才能訪問應用程序，而且只能通過相應的網關來訪問。

測試目標	應用程序級別的安全性：覈實Actor只能訪問其所屬用戶類型已被授權訪問的那些功能或數據。系統級別的安全性：覈實只有具備系統和應用程序訪問權限的Actor才能訪問系統和應用程序。
測試範圍：
技術：	應用程序級別的安全性：確定並列出各用戶類型及其被授權訪問的功能或數據。爲各用戶類型創建測試，並通過創建各用戶類型所特有的事務來覈實其權限。修改用戶類型併爲相同的用戶重新運行測試。對於每種用戶類型，確保正確地提供或拒絕了這些附加的功能或數據。系統級別的訪問：請參見以下的“需考慮的特殊事項”。
開始標準：
完成標準：	各種已知的Actor類型都可訪問相應的功能或數據，而且所有事務都按照預期的方式運行，並在先前的應用程序功能測試中運行了所有的事務。
測試重點和優先級：
需考慮的特殊事項：	必須與相應的網絡或系統管理員一直對系統訪問權進行檢查和討論。由於此測試可能是網絡管理可系統管理的職能，可能會不需要執行此測試。

6.11故障轉移和恢復測試

故障轉移和恢復測試可可確保測試對象能成功完成轉移，並能從導致意外數據損失或數據完整性破壞的各種硬件、軟件可網絡故障中恢復。

故障轉移測試可確保：對於必須持續運行的系統，一旦發生故障，備用系統就將不失時機地“頂替”發生故障的系統，以避免丟失任何數據或事務。

恢復測試是一種對抗性的測試過程。在這種測試中，將把應用程序或系統置於極端的條件下（或者是模擬的極端條件下），以產生故障（例如設備輸入/輸出（I/O）故障或無效的數據庫指針和關鍵字）。然後調用恢復進程並監測和檢查應用程序和系統，覈實應用程序或系統和數據已得到了正確的恢復。

測試目標	確保恢復進程（手工或自動）將數據庫、應用程序和系統正確地恢復到預期的已知狀態。測試中將包括以下各種情況：客戶機斷電。服務器斷電。通過網絡服務器產生的通信中斷。 DASD和/或DASD控制器被中斷、斷電或與DASD和/或DASD控制器的通信中斷。週期未完成（數據過濾進程被中斷，數據同步進程被中斷）。數據庫指針或關鍵字無效。數據庫中的數據元素無效或遭到破壞。
測試範圍：
技術：	應該使用爲功能和業務週期測試創建的測試來創建一系列的事務。一旦達到預期的測試起點，就應該分別執行或模擬以下操作：客戶機斷電：關閉PC機的電源。服務器斷電：模擬或啓動服務器的斷電過程。通過網絡服務器產生的中斷：模擬或啓動網絡的通信中斷（實際斷開通信線路的連接或關閉網絡服務器或路由器的電源）。 DASD和DASD控制器被中斷、斷電或與DASD和DASD控制器的通信中斷：模擬與一個或多個DASD控制器或設備的通信，或實際取消這種通信。一旦實現了上述情況（或模擬情況），就應該執行其他事務。而且一旦達到第二個測試點狀態，就應調用恢復過程。在測試不完整的週期時，所使用的技術與上述技術相同，只不過應異常終止或提前終止數據庫進程本身。對以下情況的測試需要達到一個已知的數據庫狀態。當破壞若干個數據庫字段、指針和關鍵字時，應該以手工方式在數據庫中（通過數據庫工具）直接進行。其他事務應該通過使用“應用程序功能測試”和“業務週期測試”中的測試來執行，並且應執行完整的週期。
開始標準：
完成標準：	在所有上述情況中，應用程序、數據庫和系統應該在恢復過程完成時立即返回到一個已知的預期狀態。此狀態包括僅限於已知損壞的字段、指針或關鍵字範圍內的數據損壞，以及表明進程或事務因中斷面未被完成的報表。
測試重點和優先級：
需考慮的特殊事項：	恢復測試會給其他操作帶來許多的麻煩。斷開纜線連接的方法（模擬斷電或通信中斷）可能並不可取或不可行。所以，可能會需要採用其他方法，例如診斷性軟件工具。需要系統（或計算機操作）、數據庫和網絡組中的資源。這些測試應該在工作時間之外或在一臺獨立的計算機上運行。

6.12配置測試

配置測試覈實測試對象在不同的軟件和硬件配置中的運行情況。在大多數生產環境中，客戶機工作站、網絡連接和數據庫服務器的具體硬件規格會有所不同。客戶機工作站可能會安裝不同的軟件　例如，應用程序、驅動程序等　而且在任何時候，都可能運行許多不同的軟件組合，從而佔用不同的資源。

測試目標	覈實測試可在所需的硬件和軟件配置中正常運行。
測試範圍：
技術：	使用功能測試腳本。在測試過程中或在測試開始之前，打開各種與非測試對象相關的軟件（例如Microsoft應用程序：Excel和Word），然後將其關閉。執行所選的事務，以模擬Actor與測試對象軟件和非測試對象軟件之間的交互。重複上述步驟，儘量減少客戶機工作站上的常規可用內存。
開始標準：
完成標準：	對於測試對象軟件和非測試對象軟件的各種組合，所有事務都成功完成，沒有出現任何故障。
測試重點和優先級：
需考慮的特殊事項：	需要、可以使用並可以通過桌面訪問哪種非測試對象軟件？通常使用的是哪些應用程序？應用程序正在運行什麼數據？例如，在Excel中打開的大型電子表格，或是在Word中打開的100頁文檔。作爲此測試的一部分，應將整修系統、Netware、網絡服務器、數據庫等都記錄下來。

6.13安裝測試

安裝測試有兩個目的。第一個目的是確保該軟件在正常情況和異常情況的不同條件下　例如，進行首次安裝、升級、完整的或自定義的安裝　都能進行安裝。異常情況包括磁盤空間不足、缺少目錄創建權限等。第二個目的是覈實軟件在安裝後可立即正常運行。這通常是指運行大量爲功能測試製定的測試。

測試目標	覈實在以下情況下，測試對象可正確地安裝到各種所需的硬件配置中：首次安裝。以前從未安裝過＜項目名稱＞的新計算機更新。以前安裝過相同版本的＜項目名稱＞的計算機更新。以前安裝過＜Project Name>的較早版本的計算機
測試範圍：
技術：	手工開發腳本或開發自動腳本，以驗證目標計算機的狀況　首次安裝＜項目名稱＞從未安裝過；＜項目名稱＞安裝過相同或較早的版本。啓動或執行安裝。使用預先確定的功能測試腳本子集來運行事務。
開始標準：
完成標準：	＜項目名稱＞事務成功執行，沒有出現任何故障。
測試重點和優先級：
需考慮的特殊事項：	應該選擇＜項目名稱＞的哪些事務才能準確地測試出＜項目名稱＞應用程序已經成功安裝，而且沒有遺漏主要的軟件構件。

7.問題嚴重度描述

問題嚴重度	描述	響應時間
高	例如使系統崩潰	程序員在多長時間內改正此問題
中
低

8.附錄：項目任務

以下是一些與測試有關的任務：

制定測試計劃

n 確定測試需求

n 評估風險

n 制定測試策略

n 確定測試資源

n 創建時間表

n 生成測試計劃

設計測試

n 準備工作量分析文檔

n 確定並說明測試用例

n 確定測試過程，並建立測試過程的結構

複審和評估測試覆蓋

實施測試

n 記錄或通過編程創建測試腳本

n 確定設計與實施模型中的測試專用功能

n 建立外部數據集

執行測試

執行測試過程

評估測試的執行情況

恢復暫停的測試

覈實結果

調查意外結果

記錄缺陷

對測試進行評估

評估測試用例覆蓋

評估代碼覆蓋

分析缺陷

確定是否達到了測試完成標準與成功標準