前言
手工測試用例與自動化測試用例對比如下。
1、手工測試用例特點：
① 較好的異常處理能力，能通過人為的邏輯判斷校驗當前步驟的功能是否正確實現
② 人工執行用例具有一定的步驟跳躍性
③ 人工測試步步跟蹤，能夠細致地定位問題
④ 主要用來發現功能缺陷
1、 自動化測試用例特點：
① 執行對象是腳本，任何一個判斷都需要編碼定義
② 用例步驟之間關聯性強
③ 主要用來保證產品主體功能正確和完整，讓測試人員從煩瑣重復的工作中解脫出來
④ 目前自動化測試階段定位在冒煙測試和回歸測試
通過對比我們可以看到，手工測試用例與自動化測試用例之間存在較大的差異，所以，不能直接把手工測試用例“翻譯”成自動化測試腳本。
通過它們之間的特點對比也可清晰地認識到，自動化測試不能完全地替代手工測試，自動化測試的目的僅僅在於讓測試人員從煩瑣重復的測試過程中解脫出來，把更多的時間和精力放到更有價值的測試中，例如探索性測試。而自動化測試更多的是用來進行冒煙測試和回歸測試。
1、 自動化測試用例選型注意事項：
① 不是所有的手工用例都要轉為自動化測試用例。
② 考慮到腳本幵發的成本，不要選擇流程太復雜的用例。如果有必要，可以考慮把流程拆分成多個用例來實現腳本。
③ 選擇的用例最好可以構建成場景。例如，一個功能模塊，分多個用例，多個用例使用同一個場景。這樣的好處在於方便構建關鍵字測試模型。
④ 選擇的用例可以帶有目的性。例如，這部分用例作冒煙測試，那部分用例作回歸測試等，當然，會存在重疊的關系。如果當前用例不能滿足需求，那么唯有修改用例來適應腳本和需求。
⑤ 選取的用例可以是你認為是重復執行，很煩瑣的部分。例如，字段驗證、提示信息驗證這類，這部分適用於回歸測試。
⑥ 選取的用例可以是主體流程，這部分適用於冒煙測試。
⑦ 自動化測試也可以用來做配置檢查、數據庫檢查。這些可能超越了手工用例，但也算用例拓展的一部分，項目負責人可以有選擇地增加。
⑧ 平時在手工測試時，如果需要構造一些復雜的數據或重復一些簡單的機械式動作, 則告訴自動化腳本，讓它來幫你，或許你的效率會因此而得到提高。
1.2 測試類型
1、測試靜態內容
靜態內容測試是最簡單的測試，用於驗證靜態的、不變化的UI元素的存在性。例如：
① 每個頁面都有其預期的頁面標題？這可以用來驗證鏈接指向一個預期的頁面。
② 應用程序的主頁包含一個應該在頁面頂部的圖片嗎？
③ 網站的每一個頁面是否都包含一個頁腳區域來顯示公司的聯系方式、隱私政策以及商標信息？
④ 每一頁的標題文本都使用<h1>標簽嗎？每個頁面都有正確的頭部文本嗎？
你可能需要（也可能不需要）對頁面內容進行自動化測試。如果你的網頁內容是不易受到影響，則手工對內容進行測試就足夠了。
2、測試鏈接
Web站點的一個常見錯誤為失效的鏈接或鏈接指向無效頁。鏈接測試涉及各個鏈接和驗證預期的頁面是否存在。如果靜態鏈接不經常更改，則手動測試就足夠了。但是，如果你的網頁設計師經常改變鏈接，或者文件不時被重定向，則鏈接測試應該實現自動化。
3、功能測試
在你的應用程序中，需要測試應用的特定功能，需要一些類型的用戶輸入，並返回某種類型的結果。通常一個功能測試將涉及多個頁面，一個基於表單的輸入頁面，其中包含若干輸入字段、提交和取消操作，以及一個或多個響應頁面。用戶輸入可以通過文本輸入域、復選框、下拉列表，或任何其他瀏覽器所支持的輸入。
功能測試通常是需要自動化測試的最復雜的測試類型，但通常也是最重要的。典型的測試是登錄、注冊網站賬戶、用戶賬戶操作、賬戶設置變化、復雜的數據檢索操作，等等。功能測試通常對應着你的應用程序的描述應用特性或設計的使用場景。
2、 測試動態元素
通常一個網頁元素都有一個唯一的標識符，用於唯一地定位該網頁中的元素。通常情況下，唯一標識符用HTML標記的“id”屬性或“name”屬性來實現。
這些標識符可以是一個靜態的（即不變的）字符串常量，也可以是動態生成值，在每個頁面實例上都是變化的。例如，有些Web服務器可能在一個頁面實例上命名所顯示的文件為doc3861，而在其他頁面實例上顯示為doc6148，這取決於用戶在檢索的“文檔”。通常情況下，具有變化的標識符的動態元素基於用戶操作的結果頁面上，然而，顯然這取決於Web 應用程序。
1.3 自動化測試用例編寫原則
在編寫自動化測試用例過程中應該遵循以下原則：
1) 一個用例為一個完整的場景，從用戶登錄系統到最終退出並關閉瀏覽器。
2) —個用例只驗證一個功能點，不要試圖在用戶登錄系統后把所有的功能都驗證一遍。
3) 盡可能少的編寫負面邏輯用例。一方面因為負面邏輯的用例很多（例如，手機號輸錯有幾十種情況）；另一方面自動化腳本本身比較脆弱，復雜的負面邏輯用例實現起來較為麻煩且容易出錯。
4) 用例與用例之間盡量避免產生依賴。
5) 一條用例完成測試之后需要對測試場景進行還原，以免影響其他用例的執行。