新手如何開始學習自動化測試？

　　對於測試人員來說，不管進行功能測試還是自動化測試，還是效能測試，都是需要編寫測試用例，所以我們必須先要了解清楚手工測試用例與自動化測試用例的一些特點，才能更好的開展自動化測試工作。

　　1.1手工測試用例和自動化測試用例

　　手工測試用例是針對功能測試人員的，而自動化測試用例是針對自動化測試用例框架或工具的。

　　手工測試用例特點

　　（1）較好的異常處理能力，能透過人為的邏輯判斷校驗當前步驟是否正確實現；

　　（2）人工執行用例具有一定步驟跳躍性；

　　（3）人工測試步步跟蹤，能夠細緻定位問題；

　　（4）主要用來發現功能缺陷；

　　自動化測試用例特點

　　（1）執行物件是指令碼，任何一個盤算都需要編碼定義；

　　（2）用例步驟之間關聯性強；

　　（3）主要用來保證產品主體功能正確和完整，讓測試人員從繁瑣重複的工作中解脫出來；

　　（4）目前自動化測試階段定位在冒煙測試和迴歸測試。

　　（注意

　　透過對比發現，自動化測試不能完全替代手工測試，自動化測試的目的僅僅在於讓測試人員從繁瑣重複的測試流程中解脫出來，把更多的時間和精力放在更有價值的測試中，例如探索性測試。）

　　自動化測試用例注意事項

　　1、不是所有手工測試用例都要轉為自動化測試用例。

　　2、考慮到指令碼開發成本，不要選擇流程太複雜的用例，如果有必要，可以考慮把流程拆分成多個用例來實現指令碼。

　　3、選擇的用例最好可以構建場景。例如，一個功能模組，分成多個用例，多個用例使用同一個場景，這樣的好處在於方便構建關鍵字測試模型。

　　4、選擇用例可以帶有目的性。例如，這部分用例作冒煙測試等，當然，會存在重疊關係，如果當前用例不滿足需求，那麼唯有修改用例來適應指令碼和需求。

　　5、選取的用例可以是主體流程，這部分用於冒煙測試（，如果不瞭解專業術語，下來要花費功夫哦）。

　　6、選取的測試用例可以是你認為重複執行，很猥瑣的部分。例如欄位驗證、提示資訊驗證之類，這部分適用於迴歸測試。

　　7、自動化測試也可以用來做配置檢查、資料庫檢查。這些可能超過了手工用例，但也算用例擴充的一部分，專案負責人可以有選擇的增加。

　　8、平時在手工測試時，如果需要構造一些複雜的資料或重複一些簡單的機械式動作，則告訴指令碼，讓它來幫你，或許你的效率會因此提高。

　　1.2自動化測試型別

　　測試靜態內容

　　靜態內容測試是最簡單的測試，用於驗證靜態的、不變的ui元素的存在性，例如：

　　（1）每個頁面都有預期的頁面標題，這可以用來驗證連結指向一個預期頁面；

　　（2）應用程式的主頁包含一個應該在頁面頂部的圖片；

　　（3）網站的每個頁面是否包含一個頁尾區域來顯示公司的聯絡方式、隱私政策以及商標資訊等；

　　（4）每一頁的標題文字都使用

　　標籤嗎？每個頁面是否都有正確的頭部文字？你可能需要（也可能不需要）對頁面內容進行自動化測試。如果你的網頁是不易受到影響的，則手工對內容進行測試就足夠了。假設你的應用檔案的位置移動了，則內容測是就非常有價值。

　　測試連結

　　web站點的一個常見錯誤為失效的連結或連結指向無效頁。連結測試涉及各個連結和驗證預期的頁面是否存在。如果靜態連結不經常更改，則手動測試就足夠了。但是，如果你的網頁設計師經常修改連結或者檔案不時被重定向，則連結測試應該實現自動化。

　　功能測試

　　在你的應用程式中，需要測試應用的特定功能，需要一些型別的使用者輸入，並返回某種型別的結果，通常一個功能測試涉及多個頁面，一個基於表單的輸入頁面，其中包含若干輸入欄位，提交和取消操作，以及一個或多個響應頁面。使用者輸入可以透過文字輸入域、核取方塊、下拉選單，或任何其他瀏覽器所支援輸入。

　　功能測試通常是需要自動化測試的最複雜的測試型別，但通常也是最重要的。典型的測試是登陸，註冊網站賬戶使用者賬戶操作、賬戶設定變化、複雜的資料檢索操作等等。功能測試通常對應著你的應用程式的描述應用特性或設計的使用場景。

　　測試動態元素

　　通常網頁元素都有唯一的識別符號，用於唯一的定位該網頁的元素。通常情況下，唯一識別符號用html標記的id屬性或name屬性來實現。

　　Ajax的測試

　　Ajax是一種支援以及動態改變使用者介面元素的技術。頁面元素可以動態更改，但不需要瀏覽器重新載入頁面，如動畫，RSS源、其他實時資料更新等。

　　Ajax有無數更新網頁上元素的放大，最簡單的方式是在Ajax驅動的應用程式中，資料可以從應用伺服器檢索，然後顯示在頁面上，而不需要重新載入整個頁面，只有一小部分的頁面，或者只有元素本身重新被載入。

　　1.3自動化測試用例編

　　1.3自動化測試用例編寫原則

　　最後跟大家分享一下自動化測試用例編寫原則：

　　1、一個用例為一個完整的場景，從使用者登入系統到最終退出並關閉瀏覽器；

　　2、一個用例只驗證一個功能點，不要試圖在使用者登入系統後把所有功能都驗證一遍；

　　3、儘可能少的編寫逆向邏輯用例。一方面因為逆向邏輯的用力很多（例如，手機號輸錯有幾十種情況），另一個方面自動化指令碼本身比較脆弱，複雜的逆向邏輯用例實現起來比較麻煩且容易出錯；

　　4、用例與用例之間儘量避免產生依賴；

　　5、一條用例完成測試之後需要對測試場景進行還原，以免影響其他用例的執行。