一份標準的軟體測試計劃文件 | 新手可以拿走
測試計劃
修訂歷史記錄
版本 | 日期 | AMD | 修訂者 | 說明 |
1.0 | XXXX年XX月XX |
（A-新增，M-修改，D-刪除）
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。 對於其他強度測試，應該使用多臺客戶機來執行相同的測試或互補的測試，以產生最繁重的事務量或最差的事務組合。] |
開始標準： | |
完成標準： | [所計劃的測試已全部執行，並且在達到或超出指定的系統限制時沒有出現任何軟體故障，或者導致系統出現故障條件的並不在指定的條件範圍之內。] |
測試重點和優先順序： | |
需考慮的特殊事項： | [如果要增加網路工作強度，可能會需要使用網路工具來給網路載入訊息或資訊包。
|