任何一個測試的開始都要制定一個完整的測試計劃，現在我們就從web安全測試的測試計劃開始
要做一個測試計劃首先要明確測試需求。在寫測試計劃之前必須要明確測試需求，
暗含的要求：例如很少看到這樣明確話的文檔要求：“入侵這相應手冊中不許友拼寫錯誤”但同時有些組織是允許拼寫錯誤存在的。這樣暗含的要求我們就要明確，可以通過和主管部門或是用戶溝通來明確這樣的要求。
不完全的或模糊的要求
比如：“所有的網站都應該安裝SP3補丁”這樣的要求就是模糊不清的，因為沒有指明是操作系統還是網站服務軟件，或是某些具體的系統軟件。這樣的需求就應該有需求提出的人來明確，確定在什么系統上安裝sp3補丁。
未指明的要求
如：“必須使用強密碼”看起來還向沒什么問題，但從測試觀點看，設么是強密碼呢？是常超過7個字符的，還是應該有大小寫的。這樣的要求我們就應該根據密碼要求標準具體化，比如：要求密碼加強必須大于7個字符。
籠統的要求
比如“站點必須是安全的”盡管每個人都會同意這個要求，但展點能夠徹底安全的唯一方法就是，斷開展點的所有連接，內網的外網的，然后鎖在一個加了封條的屋子里。但是這并不是要求的本意。這樣的要求應該具體化，制定要求達到的安全程度。
好了要求明確了，下面就說一下就話的結構。呵呵我也是學來的，照別人的說吧，也有我的體會
測試計劃的結構
測試計劃可以依照工業標準（例如軟件文檔標準——Std.829）組織，也可以基于內部摸版，甚至可以用創獻禮的全新個是編排。但大家一定要注意一點，測試計劃重要的不是個是而是創建測試計劃的過程一定要獲得測試組的認可。但有的測試必須用規格的測試計劃格式，行業內部摸版或行業標準，這樣的測試如：政府機構、保險承銷商等。
測試計劃可以長達幾百頁，也可以簡單的只有一張紙，關鍵測試計劃必須實用，也不必要把大量的人力和物理花費在測試計劃上，要根據具體情況來確定。
根據IEEE Std.829-1998(軟件測試文檔標準1998年修訂版)來介紹測試計劃的內容
1.測試計劃標題
就是說沒個測試計劃和每個測試計劃的版本都應該有一個公司內部的獨一無二標示，這也是文檔控制和版本控制的基本要求，我覺得在正規公司的同仁們都應該明白。
2.介紹
這一部分適度測試的一個總的概括，通過這一部分一該讓讀者明白此項目的準確目標和測試組如何達到這些目標。根據情況也可以做一些基本概念的解釋，比如為什么要做安全測試等等。
3項目范圍
在這一部分中明確項目的測試目標，如果在介紹中已經描述的測試目標的話在這一部分應該詳盡的介紹測試目標。同時在這一部分可以列出在測試中不設計的測試項。
4變動控制過程
這一部分主要是解決再測試中如果有需要變動的測試項應做如何處理，可參考CCB(變動控制委員會)的意見進行適當的變動。
5待測的特性（還沒吃飯呢，同志們現在不寫了好嗎，等明天在寫吧，好了寫玩這一部分！堅持）
這一部分應該是對測試對象的描述，測試組應該對則是對象進行研究，對測試對象進行可行性檢查。因該根據具體情況對測試項進行刪改，比如：應該確定是否有足夠的時間和資金來測試每一樣特性。測試組極有可能沒有得到想要的足夠資源，在這種情況下，必須做出決定應重點測試哪些方面，而那些方面可以相對簡單。達成這一點的方式是使用風險分析。（好了不行了，餓暈了，等有時間在寫吧）未完待續
6不測的特性
這一部分主要說明因為測試項目多，可能測試的過程中有的重要的測是項目可能會被忽略�！耙驗樵跍y試計劃的各自測試范圍拼合的不是很緊密，可能出現系統的某個特性就完全沒有測試，因為企業里的每個人都以為其他人會測試系統的這個方面�！苯鉀Q的辦法就是：不僅在某個測試計劃中記錄下什么項將被測試，也紀錄下這些項的哪些方面將會測試而那些將是在測試計劃范圍之外的。從而明確澄清各個測試計劃的范圍會涉及到什么和不涉及什么。一句話就是在測試計劃重要把這些都確定下來，不能含糊不清。
7方法
測試計劃的這部分一般用來闡明測試組達成選前確定的測試目標所用的策略。無需深入到每個測試策略決定的詳盡細節。但是應該明確主要的決定。例如：將執行什么層級的測試和在系統生命周期內何時執行測試。下面對一些概念進行介紹：
1）ant: normal; font-weight: normal; font-size: 7pt; line-height: normal; font-size-adjust: none; font-stretch: normal;"> 測試的層級
測試分為多測試階段（或測試層）的一個策略是按照某個測試可運行前系統必須完成的測試程度來劃分測試。比如一個測試可以分為單元測試（在系統一個組件上單獨進行的測試也可稱為模塊測試。 ）、整合級、串級或連級測試（設計用來測試系統的兩個或個多組件見的通信的測試。）、系統測試等。 根據測試的具體情況將一個或幾個層寫到一個測試計劃中。
2） 何時測試
這一部分解決測試應該在何時進行，反對以前的那種當軟件設計完成后才進行的安全測試，軟件測試應該貫穿整個軟件開發周期。
3） 何時再測試
這個概念是說只要系統在運行安全測試就應該不斷地進行測試，測試的頻率由執行這些測試的資源的可用性及系統隨時間變動的程度來決定。因為系統完成開發運行后可能出現新的安全隱患如：以前所用的操作系統的一個未知的漏洞現在被黑客團體知道了；系統增加了一些復述設備（防火墻，服務器，路由器）以使之符合更高的使用要求等等。
4） 再測試什么
這里的再測試就是軟件測試中的回歸測試，測試在前期測試過程中出現的bug是否已經修復。測試是否出現新的安全風險等等。
8通過/未通過的標準
在安全測試中通過/未同過的結果比較難下，建議在測試之前先對測試的預期結果過進行文檔化操作。最好這個結果應該由負責做出決策的人來定，而不是測試組，測試組需要做的應該是如何把測試成果提交給負責做出決策的人。（建議測試組提交一份通過測試結果評估出來的系統運行后可能出現的安全風險的報告，而不是自動化檢測工具檢測出來的安全漏洞的列表）。如果必須有測試組指明通過不同過的標準最好用這樣的標示方法：“有信息安全經理決定網站中全部探測到的/或嚴重部分是否需要返工或再測試”而不應該用“通過95%的測試用例系統可視為系統通過”
9暫停標準或重測
測試計劃這一部分可用來標明在何種情況下可以謹慎的暫停整個（或部分）測試工作及因此要達到什么樣要求才能恢復暫停測試。例如：建議在主要網站服務器上的操作系統計劃要安裝最新的補丁包之前，不要運行滲透性測試。相反如果暫停等到服務器上的操作系統安裝了最新的補丁，并重新進行了配置，就可以重新進行測試了。
10測試交付物
在這一部分應該記錄在安全測試工作中應該交付的測試結果文 件。在安全測試結果中應該交付如下這些文件
1） 測試日志
以時間順序記錄測試執行中發生的事件。
2） 測試事件報告
測試事件報告是在測試過程中出現的一些問題的報告，比如測試過中重出現的一些系統的錯誤信息等等，在測試過程中可以由測試成員以觀察報告的形式記錄下來，由最終出報告的人來進行分析。
3） 漏洞追查報告
就是用自動化工具檢查出來的漏洞結果。
4） 度量
就是衡量一個事物的單位，比如每天出現15個漏洞等等。
5） 測試總結報告
就是總結在測試工作中所找到的一切東西。
11環境需求
在測試計劃的這一部分主要描述測試所需要的環境。和在環境中需要一些什么設施。
12配置管理
配置管理是及時的以離散點標識（什么）、控制（庫管理）、追查（誰和何時）和報告（誰需要知道）系統組件的過程，其主要目的是為了維護系統的完整性。
13責任
在測試計劃中這一部分主要是確定，某些事情應該由誰來負責協調，或某些人應該負責什么等。就是說在這一部分應該確定部門責任。如公司層 負責鏡網站的物理安全評估；部門層：負責安裝配置測試環境等等。
14提供人員和培訓需要
測試計劃在這一部分要求計劃制定者考慮自己測試組的能力，如果需要可以進行人員培訓計劃。
15測試進度
在測試計劃的這一部分主要是制定測試每一個階段需要花費的時間，進度控制等。對于打得測試項目可以考慮單獨的作為一個文檔來做這個測試進度可以應用一種進度控制工具（Easy Schedule Maker等）進行管理，進度的細節可以在其他的計劃文檔中詳細描述。
16預計風險和應急措施
在測試計劃的這一部分應該有計劃的制定者考慮到在測試中可能遇到的風險，以及遇到這種風險的解決辦法，以條款的形式列出。做一個風險百分比圖，通過這個圖可以知道在測試中什么風險占的比例最大，再測試中應該進行避免這種風險的出現。
17審批
在測試計劃這一部分就是確定評審組的成員，既由那些人來評審你的測試計劃，有哪些人來評審你的測文檔等�？赡懿煌墓拘枰脑u審程度不一樣，根據自己公司的具體需要來定。但前面提到的糧店是必不可上的。
小結：
無論選擇測試計劃的格式是基于工業標準， 還是內部模版，或是為具體項目配置的獨特摸版，其測試計劃和相關文檔一定要經過修訂以確保其充分說明了下表測試計劃要考慮的因素：
測試計劃考慮因素列表
|
是 |
否 |
描述 |
|
|
|
是否系統的安全要求以被澄清并做了文檔化操作 |
|
|
|
是否已經明確定以了測試工作的目標（及其范圍） |
|
|
|
是否標明了所有待測項（及其版本） |
|
|
|
是否未列出重要的不測項 |
|
|
|
是否定以了變動控制過程并標明了那些有權限批準測試范圍變動的人 |
|
|
|
是否標明了所有待冊特性 |
|
|
|
是否未列出重要的不測特性 |
|
|
|
是否以對測試方法（策略）進行文檔化操作 |
|
|
|
是否以將把系統視為通過的標準（如果有）進行文檔化操作 |
|
|
|
是否以將測試終止（和恢復）的標準（如果有）進行文檔化操作 |
|
|
|
是否以將測試工作要產生的文檔進行文檔化操作 |
|
|
|
是否研究過將測試工作所有的環境需要進行文檔化操作 |
|
|
|
是否將待測項的配置管理策略進行文檔化操作 |
|
|
|
是否以將測試腳本和測試數據（測試套件）的配置管理策略進行文檔化操作 |
|
|
|
是否以指派了所有測試工作的責任 |
|
|
|
是否以指派了所有測試工作所依賴的責任 |
|
|
|
是否標明了人事需要的來源 |
|
|
|
是否標明了培訓需要的來源 |
|
|
|
是否創建了測試進度 |
|
|
|
是否以考慮了項目圓滿結束的必須步驟 |
|
|
|
是否以標明了預計的最嚴重的風險 |
|
|
|
是否以設計并通過了預計的最嚴重的風險的規避風險措施 |
|
|
|
是否以將所有的問題、假設、約束和依賴進行文檔化操作 |
|
|
|
是否以定義了所有的不常見的簡寫和術語 |
|
|
|
是否以標明并互相引用了支持文檔 |
|
|
|
是否以標明了負責批準計劃的人 |
|
|
|
是否以標明了負責接收測試結果的人 |
|
|
|
是否以標明了需要通報測試工作進展的人 |
文章來源于領測軟件測試網 http://www.kjueaiud.com/
