檔案狀態： [ ] 草稿 [√] 正式發布 [ ] 正在修改
xx專案
測試方案
方案編號： val-02
版本號： 0.1
原作者：
建立日期：
說明：方案版本維護表，用於測試方案版本的維護，a：增加，m：修改
目錄1. 概述 3
2. 適用物件和範圍 3
3. 術語、名詞定義 3
3.1. 系統測試 3
3.2. 功能測試 3
3.3. 介面測試 3
3.4. 壓力測試 4
3.5. 效能測試 4
3.6. 安全測試 4
3.7. 可靠性測試 4
4. 測試參考文件和測試提交文件 5
4.1. 測試參考文件 5
4.2. 測試提交文件 5
5. 測試資源 5
5.1. 人力資源 5
5.2. 測試環境 6
5.3. 測試工具 6
6. 確認測試 6
6.1. 新增或修改內容驗證 6
6.2. 使用者反饋問題確認 7
7. 通過測試的標準 7
8. 測試策略 7
8.1. 功能測試 7
8.2. 資料交換測試 8
8.3. 使用者介面測試 8
介面規範性測試 8
相容性測試 9
8.4. 效能測試 9
8.5. 壓力測試 10
8.6. 容量測試 10
8.7. 安全性和訪問控制測試 11
9. 需求跟蹤矩陣 12
為了提高檢測出錯誤的機率，使測試能有計畫地、有條不紊地進行，就必須要編制測試相關檔案。而標準化的測試檔案就如同一種通用的參照體系，可達到便於交流的目的。檔案中所規定的內容可以作為對測試過程完備性的對照檢查表，故採用這些檔案將會提高測試過程的每個階段的能見度，極大地提高測試工作的可管理性。
主要針對物件為軟體管理人員、軟體開發人員和軟體測試人員。
系統測試是通過與系統的需求規格作比較，發現軟體與系統需求規格不相符合或與之矛盾的地方。它將通過確認測試的軟體，作為整個基於計算機系統的乙個元素，與計算機硬體、外設、某些支援軟體、資料和人員等其他系統元素結合起來，在實際執行（使用）環境下，對計算機系統進行的測試。
黑盒測試是基於系統需求規格，在不知道系統或元件的內部結構的情況下進行的測試。通常又將黑盒測試叫做：基於規格的測試、輸入輸出測試、功能測試或資料驅動測試。
是基於使用者觀點出發的測試。主要是驗證功能是否符合需求，包括原定功能的檢驗、是否有冗餘功能、遺漏功能。
程式設計師對各個模組進行系統聯調的測試，包含程式內介面和程式外界面測試。這個測試，在單元測試階段進行了一部分工作，而大部分都是在整合測試階段完成的。建議由開發人員進行。
對系統不斷施加壓力的測試，是通過確定乙個系統的瓶頸或者不能接收的效能點，來獲得系統能提供的最大服務級別的測試。例如測試乙個web 站點在大量的負荷下，何時系統的響應會退化或失敗。
在交替進行負荷和強迫測試時常用的術語。效能測試關注的是系統的整體。它和通常所說的強度、壓力/負載測試有密切關係。所以壓力和強度測試應該於效能測試一同進行。
主要是測試系統在沒有授權的內部或者外部使用者對系統進行攻擊或者惡意破壞時如何進行處理，是否仍能保證資料的安全。測試人員可以學習一些黑客技術，來對系統進行攻擊。
這裡是比較狹義的可靠性測試，它主要是對系統能否穩定執行進行乙個統計，在實際工作中如果沒有條件可以不必特意去做。重點做好與之緊密相關的功能測試、健壯性測試就可以了。
下表列出了制定測試計畫時所使用的文件，並標明了各文件的可用性：
測試伺服器：
無一般有「基於測試用例」和「基於缺陷密度」兩種評比準則，在這裡我們採用前者。
準則如下：
功能性測試用例通過率達到100％；
非功能性測試用例通過率達到95％；
沒有高於優先順序3以上的問題。
備選通過辦法：
根據實際情況由軟體開發部門的經理、專案經理和測試負責人等共同討論確定本階段是否結束。
專案測試方案
摘要 簡要描述該文件的內容。修改歷史 目錄1 概述 4 2 測試特性 4 3 測試策略 4 4 測試資源和環境 4 4.1 硬體配置 4 4.2 軟體配置 4 4.3 測試資料 4 5 測試步驟 4 6 測試通過標準 4 7 追溯表 4 本節描述專案測試方案的目的和測試範圍，測試的基準，所需的資源，...
專案測試方案
摘要 簡要描述該文件的內容。修改歷史 目錄1 概述 4 2 測試特性 4 3 測試策略 4 4 測試資源和環境 4 4.1 硬體配置 4 4.2 軟體配置 4 4.3 測試資料 4 5 測試步驟 4 6 測試通過標準 4 7 追溯表 4 本節描述專案測試方案的目的和測試範圍，測試的基準，所需的資源，...
專案測試經驗
詢問 測試架構師的工作職責只適合大公司。如果是乙個只有10個測試人員或更少的測試人員的小公司，可沒資源來做這些測試活動了。那麼應該開展哪些測試活動才是最適合小公司的。其實我工作的第一家公司，雖然測試人員也有大幾十號人，但是運作上其實還是乙個小公司，資源缺乏，人力不足，產品時間緊。因此，對於小公司測試...