在“測試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測試用例。這是一個最小值。你仍然將不得不仔細檢查需求及其關聯的測試用例以確保測試計劃的水準對于所有的需求而言是足夠。使測試用例可以追溯到原始的需求將使這個任務更簡單些。
文章來源于領測軟件測試網 http://www.kjueaiud.com/
