測試Web Application之一：準備團隊
---www.qalabs.com《Testing Web Applications Part 1: Priming the Team》
---Kiki翻譯于2005/8/15
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要求的其他所有的測試類型，例如性能，安全，數據庫完整性等。記住，解密高手不會利用瀏覽器去破壞網站，他們使用腳本。
- 尋找或創建合適的測試工具
成熟的測試工具的缺點是會使自動化變得困難。記得Java第一次擊中場景是什么時候嗎？開發人員和項目經理都想使用這種新技術。突然間測試人員的負擔加重了，兩倍，三倍，或更多。僅僅因為配置的數量和可用的成熟的測試和測試工具的缺乏�，F在有很多的測試工具可以使用，但是仍然要花時間選擇一個適當的工具，學習它的細節，設置自定制它到你的環境中。如果工具是不可用的，你應該即刻查明，并且構建一些你自己的測試應用程序。
- 創建一個操作系統vs.瀏覽器版本的矩陣
要求大量的瀏覽器和操作系統的兼容性測試。 如果你創建了一個操作系統與瀏覽器版本的矩陣，你將有一種攻擊所有變化的方法。
如果你正在測試而沒有定義你的環境，你將面對以下的問題：
- 當你沒有先前的版本時，你如何回滾代碼變更?
- 新的功能或修復的缺陷如何放到每個版本中？
- “內部版本（build）”術語意味著在web空間中的任何事情碼？
如果源代碼沒有被歸檔或沒有打上標簽，或在版本控制庫中沒有進行分支，測試人員就不能夠恢復到一個“已知狀態”。當環境連續變得更復雜時，沒有一個可以用來恢復的先前版本使得隔離和分析缺陷更加困難。如果你安裝了一個友好的測試環境，你將不會必須面對由這些問題帶來的新問題。
- 安裝一個隔離的測試服務器
web測試人員的一個常見（并且危險）的習慣是在測試之前移植修復了缺陷和添加了新功能的代碼到一個live服務器上，并且在它上面測試。實際上，你的測試團隊不應關閉你的網站，他們應建立一個隔離的測試服務器。
這5 個步驟將幫助你提前為挑戰性的任務而準備你的團隊。在后面的文章里，我將略述一系列在開始你的測試計劃時你將要問到的具體問題，以及怎樣將這些問題的答案用于確定并集中你測試的策略。
測試Web Application之二：準備作戰
---www.qalabs.com《Testing Web Applications Part 2: Preparing for Battle!》
---Kiki翻譯于2005/8/18
何時做計劃：
一旦市場需求被搜集好并且已經穩定了/被簽署批核了，測試計劃就應該認真地開始了。這個經驗法則應該用于所有的軟件開發項目，但是對于web application，就必須應用這個規則。因為這種類型項目的時間是那么的短，并且它們在如此緊張的壓力下要在規定日期里上線（go live），以致于測試計劃必須盡快開始。
怎樣做計劃：
在計劃測試一個web application時，我已經列出了一組濃縮的需要考慮的項目。通常這類型的信息用任何書面形式，甚至或用口頭形式，對測試人員來說都是不適用的。大多數的測試團隊在開始他們的測試計劃活動時會被一個不完整的景象捆住。以下的項目是用于幫助你填補缺口，在那里信息常常被錯誤傳達或根本沒有交流。事先考慮下在發布之前的二周里，產品經理對測試團隊說：“你們已經在Mac9.0上的IE4.5上測試過了，對嗎？”的時候。這是保證你可以回答上問題的一種方法。 如果只是從你的測試計劃中排除非目的因素，這是非常有用的。例如，如果站點的首要目的是信息交換其中之一，而不是電子商務，那么測試計劃將只有較少的描述站點電子商務功能的細節或焦點。 了解這一點將幫助你集中在用戶的類型和它們最常在站點上執行的功能上，同樣還有他們的期望。然后就可以很容易地創建有用的用戶場景以幫助你定義你的測試范圍和焦點。 或許可靠性和安全性是可以集中你測試的關鍵區域；或許是速度和性能。問這些類型的問題將幫助你集中精力在最重要的地方。如果性能和負載測試是你web application的標準，而且你以前從未做過此類型的測試，那么從在這一領域中有著更多技術頭腦的人中獲得幫助 。開始的合適位置是利用內部的開發資源，可能他們可以創建一些直接測試web服務器并能模擬很多用戶的測試腳本 。 那么就開始計算它們。這將讓你產生為測試web application功能而需測試用例數量的球場的（ball-park）估計。一個快速的經驗法則（rule of thumb）是每個不同的功能需求最少有4個測試用例：一個有效的用例，一個無效的和兩個邊界的用例（最高的和最低的）。一次更密切的對功能需求本身的檢查將顯示需要比最小量更多的測試用例以取得足夠的功能覆蓋率。
例如：100個功能需求×4個測試用例/需求＝ 400測試用例。這是一個最小值。你仍然將不得不仔細檢查需求及其關聯的測試用例以確保測試計劃的水準對于所有的需求而言是足夠。使測試用例可以追溯到原始的需求將使這個任務更簡單些。
5). 定義網站的非功能性需求
因為這個領域將以最快的速度增加你的測試工作量，得到一個對項目管理所期望范圍的全面了解是一種好主意。這是一個測試計劃能夠揭示由于在測試時間表增加一額外的瀏覽器或者操作系統所帶來巨大影響的地方。 這也是一個謹慎談判，預計劃，和風險管理可以維持你的測試進度表在控制之下的地方。你對測試所需操作系統/ 瀏覽器的組合了解的越清楚，你就能越容易地溝通花在其他平臺和/或瀏覽器上額外測試的費用。
例如：400個測試用例×4種環境＝總共1,600測試用例。每個額外的測試環境（例如，操作系統和瀏覽器的組合）就要為你的測試工作量增加400個測試用例。試想一下如果它花1個人/周（5個工作日）來執行100個測試用例，每個額外的測試環境將增加4人/周的測試時間。 嘗試不要太詳細或過度得正式：這份文檔是一個讓測試團隊在整個項目中使用的概要視圖（high-level view）。它不是為項目組的其他成員使用而設計的，也不是其他項目文檔的替代品。有希望地是，大量的信息將已經寫在其他一些你可以參考的文檔中。一旦完成了這份文檔，讓項目的涉眾者審查以保證它的正確性。 我建議你按這種順序創建測試用例：有效功能測試用例，無效功能測試用例；邊界功能測試用例，用戶場景測試用例。因此，你將在創建你的邊界功能測試用例之前創建一組有效功能測試用例。同樣地，你通過連接你的有效功能測試用例創建用戶場景（注意用戶場景是由功能測試用例組成地，并且因此在步驟中提到的“球場數量”仍然是有效的）。如果你的時間非常短，在創建邊界功能測試用例之前創建用戶場景（這將給你的前進帶來更大的沖擊）；否則的話在邊界測試用例之后創建用戶場景以確保你測試了所有的邊界條件。根據重要性和頻率為它們劃分優先級別。你將運行最頻繁或測試重要功能的測試用例比你將很少運行或僅僅運行一次的測試用例將擁有更高的優先級。
1). 定義網站的目標
2). 定義網站的訪客對象
3). 定義網站的質量標準
4). 定義網站的功能性需求
6). 將所有的這些信息寫到一份文檔中
7). 創建你的測試用例并為它們劃分優先級
文章來源于領測軟件測試網 http://www.kjueaiud.com/
