Web 應用程序 vs. 網頁（Web Pages）
貴公司已決定是時候在你的服務或產品前面加上一個字母“e”了。由網絡開發人員組成的團隊也已裝備好提供來自貴公司網站上的服務或產品了。你和你的團隊將負責測試這只新的怪獸，web application。不管你公司的性質如何，你曾經都測試過企業應用程序或數據庫應用程序。因此這應該是相當簡單的，對嗎？ 它只是一捆網頁，或許是一些JavaScript，對嗎？ 很遺憾，你錯了。
我們說的“web application”是什么意思呢？從一個簡單的帶有一些訂單填寫的公司站點到象Yahoo或Amazon一樣的站點，在web applications里這是一個難以置信的復雜度范圍。一種考慮web application 架構的方法是采用傳統業務交易應用程序的模型，并用網站代替了用戶前端。一個客戶用錢以從你的公司獲得貨物和/或服務。使客戶和公司之間的交易適當的變得更容易些，這是我們的機制。 但不是一名銷售代表，辦事員或一名出納員，而是你有一個指向網站的瀏覽器。公司從未被關閉！用戶可以自己服務自己！
想一想自動販賣機。它基于用戶的輸入填寫訂單，驗證資金的轉移，并且有一個基本的用戶界面�，F在增加一些復雜度。使這個用戶界面變為一個基于瀏覽器的解決方案，它必須運行在多個操作系統的多個瀏覽器上，而不是在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要求的其他所有的測試類型，例如性能，安全，數據庫完整性等。記住，解密高手不會利用瀏覽器去破壞網站，他們使用腳本。
文章來源于領測軟件測試網 http://www.kjueaiud.com/