自動化測試的優勢
能夠極大地提公升測試的效率，測試人員可以迅速地在指定平台部署測試指令碼且對相應功能進行測試。
「弱化」了軟體測試人員個體差異對測試結果的影響。
提高整個測試團隊的技能水平。
自動化測試的缺陷
自動化測試的缺陷在於：總是按照既定的流程往下走，不能像人一樣隨機應變。一旦功能發生變動，就需要重新維護測試指令碼。
自動化指令碼的關鍵
要開發一套高質量的測試指令碼，並不是簡單的錄製/回放，而是需要滿足以下特點：
能夠有效發現產品缺陷
有良好的可讀性和錯誤日誌，能夠方便測試人員快速定位問題所在
能夠穩定、重複、獨立地執行，經過嚴格的審查流程
經過充分的指令碼驗收流程
在開發測試指令碼的時候，需要時刻記得指令碼的目的是暴露問題，任何在執行指令碼時丟擲的異常都有可能是產品問題產生的，因此需要避免在**中隱藏問題。
乙個好的自動化指令碼的開發人員首先必須是乙個好的測試人員，只有對需要測試的產品非常熟悉，才能夠開發出真正有效的測試指令碼。
如何提高測試指令碼的可維護性？這就要求指令碼有詳細的錯誤日誌和可讀性。
如何提高測試指令碼的穩定性？這就要求測試指令碼能夠具備執行獨立性和可重複性。
當乙個指令碼執行失敗後，可能的原因有如下幾個方面：
由於產品本身的缺陷導致指令碼執行失敗
由於測試指令碼本身存在的缺陷導致誤報
由於測試環境搭建產生的問題導致失敗
不幸的是，在乙個專案中，真正由於產品缺陷導致的指令碼執行失敗所佔的比率並不高，測試人員往往花費大量的時間去解決指令碼缺陷和測試環境導致的失敗。
因此，在開發測試指令碼的時候，需要注意：
環境搭建和資料載入後，需要有明確驗證步驟，如果資料載入失敗，及時中斷指令碼執行且提示出錯原因
對於每乙個驗證點，需要在日誌裡輸出實際值和期望值，若驗證失敗，在日誌裡詳細描述
盡量不要在程式裡捕捉有可能出現的異常，應該將異常暴露給使用者，使測試人員能夠清楚地知道異常產生的位置
如何有效提高指令碼的可讀性？
通用的**程式設計規範
充分利用測試**中的注釋
將測試描述和測試**分離
如果沒***測試用例執行的獨立性，就可能產生如下問題：
由於所有用例之間的關係緊密，某乙個用例執行失敗導致了後續一系列用例的執行失敗
增加了測試人員解決指令碼問題的難度，用例失敗，測試人員難快速定位問題原因
測試人員無法從中選取部分測試用例單獨執行
自動化測試框架
乙個設計良好的自動化測試框架，能夠很方便地幫助測試人員開發高質量的自動化測試用例。
在開發乙個自動化框架之前，首先需要考慮該框架需要滿足什麼樣的要求。
一套自動化指令碼的執行週期中主要完成了以下工作：
測試環境配置
執行待測試的用例
測試結果的記錄
測試環境清除
測試報告生成
這些過程也構成了設計乙個自動化框架的最原始的功能需求。
乙個設計良好的自動化測試框架應該具備：
提高測試用例指令碼開發效率--如何能夠方便測試人員開發測試用例，能夠做到資料和執行過程分離
具有完善的環境搭建的支援--讓測試人員更加關注測試業務邏輯部分**的開發
具有完善的測試結果匯報功能--讓測試人員更好地測試業務邏輯
我們需要將環境準備的工作在測試自動化框架的層面進行實現，具體來說，需要實現以下功能：
測試環境的搭建和測試資料的清除
測試用例指令碼的執行呼叫
執行結果報告的生成
在設計這樣的自動化測試執行引擎時，首先需要考慮的是平台無關性。
制定自動化開發時間點時需要考慮的因素
不要在產品不穩定的時候開發自動化：初期缺陷較多，手動測試也可以熟悉產品，發現原有測試計畫的不足和覆蓋率缺失問題。
將測試指令碼用於回歸測試中：功能相對穩定，且計畫也得到了較好的優化。
首先開發通用task：前期重點
測試自動化指令碼應該基於乙個相對穩定的測試環境下，且依照成熟的測試計畫進行開發。如果初期開發大量自動化指令碼，往往會導致後期大量的指令碼返工量，反而降低了效率。
自動化測試的選取
自動化測試分為ui測試和api測試兩大類，api測試屬於更高層的測試方式，和單元測試相比，它更貼近使用者的操作。
gui測試往往採用錄製/回放的方法，最大程度模擬使用者操作，站在使用者的角度去發現問題，和終端使用者的行為聯絡緊密。但往往比預期要困難，因為ui設計變更會增加自動化測試複雜度，因此，gui測試適用於當ui介面趨向於穩定的時候。
api測試通過直接呼叫軟體產品的外部介面來驗證返回是否符合預期，但無法覆蓋到介面ui的顯示正確性。api介面往往不會有頻繁的變化，能夠減少後期測試指令碼維護的工作量。
根據產品特點，可以採取不同方式去實施api測試，既可以直接呼叫產品暴露的api，也可以通過模擬使用者的http請求來呼叫伺服器端的service。
測試指令碼的驗收
當完成指令碼開發之後，為了保證指令碼的高質量交付，需要制定高效的指令碼評審流程和驗收流程。
產品**清晰描述了某個功能點，能夠通過直觀的檢查確定功能是否完成。
自動化指令碼明確描述了測試流程、需要檢查的功能點，以及期望結果。
一套能夠永遠毫無差錯執行的指令碼不一定是高質量的指令碼，因為這也有可能是由於指令碼沒有發現產品的問題。
自動化指令碼評審分成**評審和功能點評審兩大方面。
**評審：
**是否符合**規範
**的擴充套件性如何
閱讀**是否能清楚知道每個測試用例的測試步驟
是否能很好地暴露指令碼執行時發現的問題
功能點評審：
關注**是否涵蓋了所有的功能驗證點，測試步驟和驗證點是否和測試計畫保持一致
測試指令碼的驗收就是為了確保指令碼的使用者能夠順利地執行這套指令碼。
如果說評審是為了保證**的質量和功能點的涵蓋，驗收流程確保了自動化指令碼的執行穩定性和可重複性。
自動化指令碼驗收：
應當由非指令碼開發者且具備中等技能的測試人員實施
支援跨平台的產品應覆蓋到不同平台
不僅僅關注指令碼的執行是否順利，也要關注日誌是否詳細，是否有助於定位問題
驗收中發現的任何問題應該由指令碼開發者負責解決
自動化測試的穩定性
測試自動化指令碼的穩定性直接決定了測試的效率。
影響自動化測試指令碼的穩定性因素：
指令碼中對某些輸入引數的硬編碼：這是影響指令碼穩定性最重要的因素。
指令碼等待時間硬編碼：在開發指令碼時機路的等待時間未必就是將來測試環境中的執行時間
跨平台問題：不同的作業系統或者資料庫可能存在不同，因此必須在多個平台上進行測試。
如何權衡手動測試和自動化指令碼開發的關係
對於比較穩定的測試專案，可以考慮在編寫測試計畫的時候同步編寫指令碼，測試計畫的作者同時也是測試指令碼的開發者，這將極大提高自動化開發的效率，但前提是每乙個測試人員都具有自動化指令碼開發的能力。
環境搭建和資料準備工作不會有頻繁的變更，可以考慮在專案初期先完成這部分的自動化工作。
把握測試自動化的度。
用公式平谷自動化指令碼開發的必要性
指令碼開發執行成本=指令碼開發工作量+(平均除錯指令碼工作量+平均執行指令碼工作量)*每產品週期執行次數
手工執行成本=平均手工執行工作量*每產品週期執行次數
roi=指令碼開發執行成本/手工執行成本
如果這個roi比例在5以內，則說明需要用5倍的工作量去開發自動化指令碼。換句話說，這套指令碼如果未來執行了5次，我們就把成本賺回來了，以後每執行一次，我們就能盈利一次。而如果某功能點的手動測試需要半天時間，而我們需要花費1個多月的時間去開發自動化指令碼，這個比例就在60以上了，也就是說以後要執行60次以上才能收回成本。
自動化測試之軟體測試和測試環境
二 軟體測試和測試環境 三 資料的形式與數制 軟體是程式 資料 文件的集合。程式 由程式語言 c c c python等高階語言程式設計而成 資料 使用檔案或者資料庫來儲存檔案 文件 安裝文件 說明文件等等。按照軟體的功能可以分為三大類 支援軟體 按照軟體的功能可以分為兩大類 b s軟體 brows...
軟體測試自動化
只有當系統的介面元素不會頻繁的變化 系統功能基本穩定，已經通過一至兩輪的手工測試，確定系統不會存在重大缺陷時，才可以考慮自動化的實施。使用自動化測試工具代替手工完成一些測試任務，現在國內主流的測試工具是loadrunner 和qtp。lr 效能測試工具 和qtp 自動化測試工具 的區別 1 lr 基...
軟體測試 自動化測試 回歸測試
軟體測試可分為以下幾類 1.單元測試。單元測試是針對程式中最小的可以測試的 塊進行驗證，比如中的乙個類。由此可見單元測試是和開發很接近的測試，其測試用例一般由開發人員編寫。敏捷開發模式中有一種開發模式叫做測試驅動開發模式，其主體思想即在 實現之前先實現單元測試用例。而程式編寫目的以程式功能通過單元測...