在“測試Web Applications之一：準備團隊”中，我論述了一些測試web application和測試其他一些應用程序不同的原因，例如桌面應用程序。在這篇文章中，我將要概要說明一些可以幫助你保持注意力並且有希望讓你在計劃你的測試工作量時避免一些常見錯誤的關鍵點。
何時做計劃：
一旦市場需求被蒐集好並且已經穩定了/被簽署批覈了，測試計劃就應該認真地開始了。這個經驗法則應該用於所有的軟件開發項目，但是對於web application，就必須應用這個規則。因爲這種類型項目的時間是那麼的短，並且它們在如此緊張的壓力下要在規定日期裏上線（go live），以致於測試計劃必須儘快開始。
怎樣做計劃：
在計劃測試一個web application時，我已經列出了一組濃縮的需要考慮的項目。通常這類型的信息用任何書面形式，甚至或用口頭形式，對測試人員來說都是不適用的。大多數的測試團隊在開始他們的測試計劃活動時會被一個不完整的景象捆住。以下的項目是用於幫助你填補缺口，在那裏信息常常被錯誤傳達或根本沒有交流。事先考慮下在發佈之前的二週裏，產品經理對測試團隊說：“你們已經在Mac9.0上的IE4.5上測試過了，對嗎？”的時候。這是保證你可以回答上問題的一種方法。
1).定義網站的目標
如果只是從你的測試計劃中排除非目的因素，這是非常有用的。例如，如果站點的首要目的是信息交換其中之一，而不是電子商務，那麼測試計劃將只有較少的描述站點電子商務功能的細節或焦點。
2).定義網站的訪客對象
瞭解這一點將幫助你集中在用戶的類型和它們最常在站點上執行的功能上，同樣還有他們的期望。然後就可以很容易地創建有用的用戶場景以幫助你定義你的測試範圍和焦點。
3).定義網站的質量標準
或許可靠性和安全性是可以集中你測試的關鍵區域；或許是速度和性能。問這些類型的問題將幫助你集中精力在最重要的地方。如果性能和負載測試是你web application的標準，而且你以前從未做過此類型的測試，那麼從在這一領域中有着更多技術頭腦的人中獲得幫助 。開始的合適位置是利用內部的開發資源，可能他們可以創建一些直接測試web服務器並能模擬很多用戶的測試腳本 。
4).定義網站的功能性需求
那麼就開始計算它們。這將讓你產生爲測試web application功能而需測試用例數量的球場的（ball-park）估計。一個快速的經驗法則（rule of thumb）是每個不同的功能需求最少有4個測試用例：一個有效的用例，一個無效的和兩個邊界的用例（最高的和最低的）。一次更密切的對功能需求本身的檢查將顯示需要比最小量更多的測試用例以取得足夠的功能覆蓋率。例如：100個功能需求×4個測試用例/需求＝ 400測試用例。這是一個最小值。你仍然將不得不仔細檢查需求及其關聯的測試用例以確保測試計劃的水準對於所有的需求而言是足夠。使測試用例可以追溯到原始的需求將使這個任務更簡單些。
5).定義網站的非功能性需求
因爲這個領域將以最快的速度增加你的測試工作量，得到一個對項目管理所期望範圍的全面瞭解是一種好主意。這是一個測試計劃能夠揭示由於在測試時間表增加一額外的瀏覽器或者操作系統所帶來巨大影響的地方。 這也是一個謹慎談判，預計劃，和風險管理可以維持你的測試進度表在控制之下的地方。你對測試所需操作系統/ 瀏覽器的組合瞭解的越清楚，你就能越容易地溝通花在其他平臺和/或瀏覽器上額外測試的費用。例如：400個測試用例×4種環境＝總共1,600測試用例。每個額外的測試環境（例如，操作系統和瀏覽器的組合）就要爲你的測試工作量增加400個測試用例。試想一下如果它花1個人/周（5個工作日）來執行100個測試用例，每個額外的測試環境將增加4人/周的測試時間。
6).將所有的這些信息寫到一份文檔中
嘗試不要太詳細或過度的正式：這份文檔是一個讓測試團隊在整個項目中使用的概要視圖（high-level view）。它不是爲項目組的其他成員使用而設計的，也不是其他項目文檔的替代品。有希望地是，大量的信息將已經寫在其他一些你可以參考的文檔中。一旦完成了這份文檔，讓項目的涉衆者審查以保證它的正確性。
7).創建你的測試用例併爲它們劃分優先級
我建議你按這種順序創建測試用例：有效功能測試用例，無效功能測試用例；邊界功能測試用例，用戶場景測試用例。因此，你將在創建你的邊界功能測試用例之前創建一組有效功能測試用例。同樣地，你通過連接你的有效功能測試用例創建用戶場景（注意用戶場景是由功能測試用例組成的，並且因此在步驟中提到的“球場數量”仍然是有效的）。如果你的時間非常短，在創建邊界功能測試用例之前創建用戶場景（這將給你的前進帶來更大的衝擊）；否則的話在邊界測試用例之後創建用戶場景以確保你測試了所有的邊界條件。根據重要性和頻率爲它們劃分優先級別。你將運行最頻繁或測試重要功能的測試用例比你將很少運行或僅僅運行一次的測試用例將擁有更高的優先級。
