From: http://blog.csdn.net/planisnothing/article/details/7252957
測試設計入門
我們在這一章中提供的信息，對測試自動化的新手和有經驗的QA專業人士都是有幫助的。此處我們描述最公共的自動化測試類型。我們也描述常用的、在測試自動化中的“設計模式”，用於改善你的自動化測試集的可維護性和可擴展性。富有經驗的讀者將覺得這些內容是有意思的，如果還沒有使用這些技術。
測試的類型
你應測試你的應用程序的那個部分？這依賴於你的項目的各個方面：用戶的期望，項目允許的時間，項目經理設置的優先級等等。一旦項目的邊界被定義，你，作爲測試者，將必定可以做出測試內容的決定。
在此，我們創建了幾個術語，用於分類你可能在你的Web應用程序上執行的測試的類型。這些術語絕不是標準，儘管我們在此提出的概念典型地用於Web應用程序的測試。
靜態內容測試
最簡單的測試類型，內容測試，是一個簡單的對靜態的、沒有變化的、UI元素的存在性測試。例如：
- 每一頁是否有預期的頁面標題？這可以被用於驗證你的，在追隨一個連接後發現一個預期的頁面的測試。
- 應用程序的主頁包含一個預期的圖像在頁面的頂端麼？
- Web站點的每一頁包含一個帶有到公司聯繫人頁面的鏈接，隱私權策略，和商標信息的頁腳區域麼？
- 每個頁面開始於帶有<h1>標記的標題文本麼？並且，每一頁有正確的文本在那個標題中麼？
你可能或可能不需要內容測試。如果你頁面的內容不太可能被影響，那麼手工地測試頁面內容可能是更有效率的。如果，例如，你的應用程序涉及的文件被移動到不同的位置，內容測試可能是有價值的。
鏈接測試
Web站點的頻繁的錯誤來源是中斷的鏈接，或缺失鏈接後面的頁面。測試涉及點擊每個鏈接並驗證預期的頁面。如果靜態鏈接不是頻繁地改變則手工測試可能是有效的。然而，如果你的Web設計者頻繁地變更鏈接，或文件偶爾被重新定位，鏈接測試應該被自動化。
功能測試
這些是在你的應用程序中的特定功能的測試，需要某些類型的用戶輸入，並且返回某些類型的結果。時常一個功能測試會涉及多個頁面，每個帶有基於窗體的輸入頁面，包含輸入域的集合，提交和取消操作，以及一個或多個響應頁面。用戶輸入可以通過文本輸入域，複選框，下拉列表框或任何瀏覽器支持的輸入。
功能測試時常是你將自動化的最複雜的測試，但通常也是最重要的。典型的測試可能是登錄，註冊到站點，用戶帳號操作，帳號設置改變，複雜的數據存取操作，以及其他。功能測試典型地反映用戶的使用場景，用於限定功能，設計或你的應用程序。
動態元素測試
時常一個Web頁面元素有一個唯一的標識符，用於唯一地在頁面中定位那個元素。通常這被實現使用html標記的“id”或“name”屬性。這些名稱可能是靜態的，諸如不變的字符串常量。它們也可以是動態生成的值，將隨每個頁面的示例而變化。例如，某些Web服務器可能在一個頁面實例中命名一個顯示的文檔爲doc3861，在另一個不同的頁面實例中爲doc6248，取決於用戶存取啥文檔。一個驗證那個文檔存在性的測試腳本，可能沒有一個一致的標識符用於定位那個文檔。時常，帶有可變的標識符的動態元素是，在基於用戶動作的某個類型的結果頁面上。這必定依賴於Web應用程序的功能。
這是一個示例：
<input type="checkbox" value="true" id="addForm:_ID74:_ID75:0:_ID79:0:checkBox"/>
這顯示一個HTML複選框。它的id（addForm:_ID74:_ID75:0:_ID79:0:checkBox）是一個動態生成的值。下次打開相同的頁面，它可能是一個不同的值。
Ajax測試
Ajax是支持動態改變用戶接口元素的，可以動態改變元素而無需瀏覽器重新裝載頁面的技術，諸如動畫，RSS訂閱，以及實時的數據更新等等。有無數的方法，Ajax可以被用來更新頁面上的元素。但，在Ajax驅動的應用程序中，被認爲是最容易的方式是，數據可以從應用程序服務器存取，然後顯示在頁面上，而無需重新裝載整個頁面。只有頁面的一部分，或嚴格地說元素自身被重新裝載。
驗證結果
斷言和驗證
何時應該使用斷言（assert）命令，何時應該使用驗證（verify）命令？這取決於你。差別在於當檢查失敗的時候你想要什麼發生。你想要你的測試終止，或繼續並簡單地記錄失敗的檢查麼？
這是需要權衡的。如果你使用一個斷言，測試將停止在那個點，不運行任何隨後的檢查。有時，或許是經常，那就是你想要的。如果測試失敗，你會立即知道測試沒有通過。測試引擎，諸如TestNG和JUnit有常用的開發環境（第五章）的插件，可以方便地標記這些測試做失敗的測試。優點：你可以立即看到檢查是否通過。缺定：當一個檢查失敗時，其他的檢查將永遠也不會執行，這樣你就無法得到有關它們狀態的信息。
反之，驗證命令不會終止測試。如果你的測試僅僅使用驗證命令，不論檢查是否找到缺陷你可以確保（假如沒有非預期的異常出現）測試會運行完成。缺點：你必須做更多的檢查測試結果的工作。也就是說，你不會得到回饋從TestNG或JUnit。你將需要檢查控制檯打印輸出或日誌輸出的結果。並且你每次運行測試，你都需要花費時間瀏覽整個輸出。如果你正在運行數百個測試，每一個有自己的日誌，這將是一個耗時的工作，則即時反饋的斷言可能是更合適的。由於即時的反饋，斷言比驗證更常用。
權衡： assertTextPresent, assertElementPresent, assertText
你現在應該熟悉這些命令，和使用它們的技術。如果不熟悉，請首先參考第三章。當構造你的測試時，你將需要決定：
- 我僅僅檢查頁面上的文本存在麼？（verify/assertTextPresent）
- 我僅僅檢查頁面上的HTML元素存在麼？也就是說，文本，圖像，或其他內容不做檢查，僅僅和HTML標記相關。 (verify/assertElementPresent)
- 我必須測試兩者，元素和它的內容麼？(verify/assertText)
沒有直接的答案。它依賴於你的測試的需求。當然，取決於你測試的應用程序的需求。如果不能肯定，使用assertText，因爲這是最嚴格的檢查類型。你可以稍後改變它，但至少你不會錯過任何潛在的失敗。
Verify/assertText是最特定的測試類型。它會失敗，如果HTML元素（標記）或文本不是你的測試所預期的。或許你的Web設計者正在頻繁地改變頁面，你不希望你的測試在每次他們做出改變時測試失敗，因爲這些改變是預期的。然而，假定你仍然需要檢查頁面上的某些東西，比如一個段落，或標題文本，或一個圖像。在這種情況下，你可以使用verify/assertElementPresent。這將確保特定類型的元素存在（如果使用XPath還可以確保元素相對於頁面上的其它元素存在）。但你不關心內容是啥。你僅僅關注一個特定的元素，比如說，一個圖像在特定的位置。
要對做出這些類型的決定有感覺需要一些時間和一點點經驗。它們是容易的概念，容易在你的測試中做出改變。
定位策略
選擇一個定位策略
在頁面中選擇對象有許多種方法。但啥是這些定位類型的選擇依據？回顧一下我們可以定位一個對象使用：
- 元素的id
- 元素的name屬性
- 一個XPath語句
- 一個鏈接文本
- 對象文檔模型（DOM）
從測試的性能方面來說，假定頁面源代碼中的id或name屬性具有良好的命名，使用id或name屬性定位器是最有效的，而且是使你的測試代碼更可讀的。XPath語句需要花費更長的時間進行處理，因爲瀏覽器必須運行它的XPath處理器。在Internet Explorer 7中，XPath據知是特別慢。通過鏈接文本定位時常是便利和性能良好的。儘管這個技術是特定於鏈接。同樣，如果鏈接文本可能頻繁改變，使用<a>元素定位可能是更好的選擇。
儘管有時，你必須使用XPath定位器。如果頁面源代碼沒有id或name屬性，你可能不得不選擇使用XPath定位器。（DOM定位器不再常用，因爲XPath可以做它可以做的任何事情甚至更多。DOM定位器是可得到的，僅僅爲了支持遺留的測試。）
使用XPath有一個使用id或name屬性定位沒有的優點。使用XPath（和DOM）你可以定位一個對象與頁面上另外一個對象的關係。例如，如果一個鏈接必須出現在一個<div>節的第二個段落裏，你可以使用XPath來指定。使用id和name定位器，你只可以指定它們在頁面上出現，也就是說，在頁面的某個地方。如果你必須測試一個圖像，顯示在公司的logo出現在頁面的頂端，在一個頁頭，XPath可能是更好的選擇。
定位動態元素
正如在較早的，有關測試類型一節所描述的，一個動態元素是一個頁面元素，它的標識符隨每個頁面的實例而變化。例如，
<a class="button" id="adminHomeForm" onclick="return oamSubmitForm('adminHomeForm','adminHomeForm:_ID38');" href="#">View Archived Allocation Events</a>
這個HTML錨標記定義一個帶有“adminHomeForm”id屬性的按鈕。與大多數HTML標記比較，這是一個相當複雜的錨標記，但它仍然是一個靜態標記。這個HTML在每次瀏覽器裝載這個頁面的時候都是相同的。它的id保持不變，在所有這個頁面的實例中。也就是說，當這頁被顯示的時候，這個UI元素總是有這個標識符。如此，對你的點擊這個按鈕的測試腳本，僅僅需要使用下面的selenium命令。
click adminHomeForm或者，在Selenium 1.0中
selenium.click("adminHomeForm");你的應用程序，不管怎樣，可能動態生成HTML，在那裏對Web頁的不同實例標識符可能是變化的。例如，對一個動態頁面，HTML可能看起來像這樣。
<input type="checkbox" value="true" id="addForm:_ID74:_ID75:0:_ID79:0:checkBox"name="addForm:_ID74:_ID75:0:_ID79:0:checkBox"/>
這定義一個複選框。它的id和name屬性（addForm:_ID74:_ID75:0:_ID79:0:checkBox）是動態生成的值。在這種情況下，使用一個標準的定位器可能看起來像下面的。
click addForm:_ID74:_ID75:0:_ID79:0:checkBox或者，在Selenium RC
selenium.click("addForm:_ID74:_ID75:0:_ID79:0:checkBox");
對給定的動態生成的標識符，這種方法可能不工作。下次頁面裝載，標識符可能是一個不同於使用在Selenium命令中的值，並因此將不會被找到。點擊操作將失敗帶有一個“element not found（元素沒有找到）”錯誤。
要糾正這一點，一個簡單的解決方案是僅僅使用XPath定位器，而不是試圖去使用id定位器。如此，對這個複選框你可以簡單地使用：
click //input或者，如果它不是第一個在頁面上的input元素（它很可能不是），可以試一下一個更詳細的XPath語句：
click //input[3]或
click //div/p[2]/input[3]如果不管如何，你都需要使用id去定位這個元素，則需要一個不同的解決方案。你可以從Web站點捕捉這個id，先於使用它在一個Selenium命令。它可像這樣做。
String[] checkboxids = selenium.getAllFields(); // Collect all input IDs on page.for(String checkboxid:checkboxids) {
if(checkboxid.contains("addForm")) {
selenium.click(expectedText);
}
}
這個方法是可行的，如果只有一個複選框的id包含“expectedText”文本。
定位Ajax元素
正如提供在上面的測試類型節，一個帶有Ajax實現的頁面元素是一個可以被動態刷新的元素，而不必刷新整個頁面。定位和驗證一個Ajax元素的最佳方式是使用Selenium 2.0 WebDriver API。這是特別設計用來進行Ajax元素的測試的，在測試Ajax元素方面，Selenium 1.0 有一些限制。
在Selenium 2.0，你使用waitFor（）方法，等待一個頁面元素變成可得到的。這參數是一個WebDriver實現的定位器By對象。這個被詳細地解釋在WebDriver一章。
要使用Selenium 1.0（Selenium RC）完成這個，涉及更多的代碼，但也不困難。方法是去檢查這個元素，如果它是不可得到的，則等待一個預定的時間段，然後再一次檢查它。用一個帶有預定義的超時，如果元素仍然沒有發現就終止這個循環的，循環執行這個。
讓我們考慮一個帶有一個鏈接（link=ajaxLink）的頁面，在點擊一個頁面上的按鈕時（沒有刷新頁面）。這可以使用一個for循環，用Selenium來處理。
// 循環初始
for (int second = 0;; second++) {// 如果循環到達60秒，則中斷這個循環
if (second >= 60) break;// 搜索元素"link=ajaxLink" ，如果可得到則中斷循環
try { if (selenium.isElementPresent("link=ajaxLink")) break; } catch (Exception e) {}// 暫停1秒
Thread.sleep(1000);}
這肯定不是惟一的解決方案。Ajax在用戶論壇是一個公共的主題，我們推薦搜索一下以前的討論，看看其他人已經做了那些事情。
© Copyright 2008-2012, Selenium Project. Last updated on Feb 02, 2012.