Web 應用程序 vs. 網頁（Web Pages）
貴公司已決定是時候在你的服務或產品前面加上一個字母“e”了。由網絡開發人員組成的團隊也已裝備好提供來自貴公司網站上的服務或產品了。你和你的團隊將負責測試這隻新的怪獸，web application。不管你公司的性質如何，你曾經都測試過企業應用程序或數據庫應用程序。因此這應該是相當簡單的，對嗎？ 它只是一捆網頁，或許是一些JavaScript，對嗎？ 很遺憾，你錯了。
我們說的“web application”是什麼意思呢？從一個簡單的帶有一些訂單填寫的公司站點到象Yahoo或Amazon一樣的站點，在web applications裏這是一個難以置信的複雜度範圍。一種考慮web application 架構的方法是採用傳統業務交易應用程序的模型，並用網站代替了用戶前端。一個客戶用錢以從你的公司獲得貨物和/或服務。使客戶和公司之間的交易適當的變得更容易些，這是我們的機制。 但不是一名銷售代表，辦事員或一名出納員，而是你有一個指向網站的瀏覽器。公司從未被關閉！用戶可以自己服務自己！
想一想自動販賣機。它基於用戶的輸入填寫訂單，驗證資金的轉移，並且有一個基本的用戶界面。現在增加一些複雜度。使這個用戶界面變爲一個基於瀏覽器的解決方案，它必須運行在多個操作系統的多個瀏覽器上，而不是在touchpad上。噢，在（實時的）跟蹤存貨時，讓機器直接填寫來自貨艙的訂單。並且爲完成那個過程，人們不用再往機器中投入錢幣，而是在讀卡機上刷一下信用卡－一次你將需要讓信用卡公司批准每一筆交易。嘿，另一個好點子就是爲一個客戶分配一個用戶名和PIN（個人身份號碼）以允許我們保留他們的信息。利用這個方法他們就不需要刷卡及輸入發貨信息。並且我猜想這些信息實際上也將安全些。
考慮到這個情景，現在很清楚了web application不是簡單的，帶些圖片和一些HTML或JavaScript的網站。他們和傳統的，在前端有些格外複雜度的交易系統很相似。那樣一個系統所需的測試工作量比爲沒有web界面的應用程序多的多。
開發的生命週期及其對測試的影響
我們中的大多人曾經都接觸過少數的軟件開發生命週期模型，例如Spiral 模型，瀑布模型等等。典型的軟件項目的階段有計劃，收集需求，分析和設計，實現（又叫編碼），集成，測試，發佈和維護。你的團隊需要知道對於一個web application的項目，這些階段該如何配合。
這些階段有些相似，但是沒有以前在工業中看到的不時的冗長的時間量度。Web application是軟件，並且同樣地和所有軟件開發項目一樣受到相同規則的影響：至少你需要需求，設計，實現和測試。如果你想限制風險，像其他任何的軟件項目一樣，你需要做出計劃和管理。即使速度和昨天市場部總是想要的產品相似。只不過現在“昨天”甚至更早了。
最好的減少在測試一個web application 時風險的方法是在項目生命週期的初期增加正式的測試計劃和分析。每個項目在項目生命週期的結束部分都有測試這一環節。當開發進度不理想時，測試的時間幾乎總是被縮短以便可以迎合發佈或“go-live”日期。在項目生命週期的初期增加測試計劃將允許測試人員基於風險，進度約束和測試人員的能力及態度區分他們測試工作的優先級別。當在“go-live”之前時間很緊張時，這對管理測試工作量就顯得非常重要。
現在就準備的5種方法
測試一個有着相對靜態內容和極少表格的網頁只要花很少的時間。測試一個web application將需要更加複雜的測試策略和更多的時間。由於web開發的本質，你的團隊或許不能獲得更多的時間，甚至可能比傳統開發項目更少。你可以通過利用在初期的“停工期（downtime）”提前來籌備你的測試團隊以節約時間。
更多地瞭解你將工作的環境
測試人員應該自己熟悉難以捉摸的瀏覽器，操作系統，web服務器和數據庫的差異。他們知道更多的關於腳本（ASP, XML, HTML等），數據庫（Oracle, SQL等），web服務器（IIS, Apache, 等）和在UI後面的數據傳遞的知識，他們就會更加有效率。測試人員不是簡單地只通過運行UI（在這裏，指的是瀏覽器）來測試功能。如果這樣他們將遺漏掉web application要求的其他所有的測試類型，例如性能，安全，數據庫完整性等。記住，解密高手不會利用瀏覽器去破壞網站，他們使用腳本。
尋找或創建合適的測試工具
成熟的測試工具的缺點是會使自動化變得困難。記得Java第一次擊中場景是什麼時候嗎？開發人員和項目經理都想使用這種新技術。突然間測試人員的負擔加重了，兩倍，三倍，或更多。僅僅因爲配置的數量和可用的成熟的測試和測試工具的缺乏。現在有很多的測試工具可以使用，但是仍然要花時間選擇一個適當的工具，學習它的細節，設置自定製它到你的環境中。如果工具是不可用的，你應該即刻查明，並且構建一些你自己的測試應用程序。
創建一個操作系統vs.瀏覽器版本的矩陣
要求大量的瀏覽器和操作系統的兼容性測試。 如果你創建了一個操作系統與瀏覽器版本的矩陣，你將有一種攻擊所有變化的方法。
用版本控制或其他配置管理efforts來定義你的開發和測試環境
如果你正在測試而沒有定義你的環境，你將面對以下的問題：
當你沒有先前的版本時，你如何回滾代碼變更?
新的功能或修復的缺陷如何放到每個版本中？
“內部版本（build）”術語意味着在web空間中的任何事情嗎？
如果源代碼沒有被歸檔或沒有打上標籤，或在版本控制庫中沒有進行分支，測試人員就不能夠恢復到一個“已知狀態”。當環境連續變得更復雜時，沒有一個可以用來恢復的先前版本使得隔離和分析缺陷更加困難。如果你安裝了一個友好的測試環境，你將不會必須面對由這些問題帶來的新問題。
安裝一個隔離的測試服務器
web測試人員的一個常見（並且危險）的習慣是在測試之前移植修復了缺陷和添加了新功能的代碼到一個live服務器上，並且在它上面測試。實際上，你的測試團隊不應關閉你的網站，他們應建立一個隔離的測試服務器。
這5 個步驟將幫助你提前爲挑戰性的任務而準備你的團隊。在後面的文章裏，我將略述一系列在開始你的測試計劃時你將要問到的具體問題，以及怎樣將這些問題的答案用於確定並集中你測試的策略。
