最近參加了乙個公司內部關於devops的培訓。簡單了解了什麼是devops以及自動化測試在devops這種新的開發模式中的重要性。簡單來說devops提倡的是加強開發團隊與運維團隊之間的合作，從而加快產品開發周期以及上線頻率。快速的產品發布導致的必然結果就是加強自動化測試的覆蓋率，因為傳統的手動測試很難跟上高速產品發布的腳步。但是與此同時，頻繁的發布產品也會導致自動化測試的開發成本加大。在沒有以自動化測試為開發驅動的專案當中，任何的產品元件的公升級都可能導致寄存的自動化指令碼失效。這就導致自動化測試的開發人員需要不停地維護原有的測試指令碼，從而延長自動化測試專案的生命週期。而維護成本的不斷增加是當今自導致自動化專案失敗的乙個主要原因。另一方面，在傳統的手動測試無法滿足高速產品更新的同時，自動化測試是否就一定能滿足這一需求？我們知道自動化測試也是一種開發，如果開發的自動化測試指令碼所對應的測試用例只需要檢測一次，而測試指令碼的開發（或者更新）時間要遠大於手動測試時，自動化測試就沒有真正的提高測試效率。自動化測試的roi也必然走向負面。如何在開發自動化測試的同時減少維護成本甚至開發成本，必然是自動化測試人員不可迴避的乙個話題。
相對於產品開發，自動化測試的開發模式以及框架都相對較少，畢竟自動化測試的起步要遠遠晚於產品開發。簡單談一下我所知道的自動化測試專案的模式：
1.現有的自動化測試專案往往是借助自動化測試工具來錄製回放測試指令碼，再加上大量的人力來執行。這樣做所帶來的最大弊端就是當產品公升級時，原有通過工具錄製的自動化指令碼重用率極低，自動化測試人員不得不重新進行一輪新的指令碼錄製。乙個簡單的ui公升級都可能給這樣的自動化專案帶來毀滅性的打擊。
2.根據sa提供的產品設計，由自動化測試人員自主開發自動化測試指令碼。相對於上一種模式，這種由具有開發能力的自動化測試人員來編寫測試**的模式明顯要高階很多。有經驗的自動化測試人員往往會基於專案來開發一些共用庫，從而大大提高開發效率。在產品更新的時候也可以通過簡單的修改外圍**來維護自動化指令碼。
在產品更新發布頻率低於兩周一次的時候，上述的第二種模式已經基本可以滿足使用者的需求。但是在當今的業界裡，某些宮色的產品的更新發布頻率要遠遠高於此，有時甚至是以分鐘為單位。在如此快速的頻率下，在保證產品「質」的同時，必然會降低產品的「量」。也就是說每次更新的產品原始**會相對減少，產品功能變化不大（改變產品核心功能的情況除外）。如果可以將自動化測試指令碼與產品本身建立起關聯關係，從而使自動化指令碼在產品更新時自動更新，那必然會再次大大降低自動化專案的維護成本。
想要達到這一目的，講自動化測試與持續整合緊密聯絡在一起是乙個必然的前提。這裡的持續整合，指的不僅僅是將自動化測試的**放入持續整合工具，而是將產品**，測試**，以及產品模組與測試用例的對應關係全部結合起來並作為可持續性整合的一種新的模式。自動化測試人員不僅需要得到產品功能的規定，還需要得到開發部門的整套開發文件（api, swagger等等）。讓自動化指令碼先可以「讀」懂產品的源**，然後將自動化測試指令碼與產品**中的業務邏輯鏈結起來。
自動化測試 web自動化測試
自動化 由機器裝置代替人為完成制定目標的過程 優點 提高工作效率 減少勞動力 產品規格同一標準 批量生產 自動化測試 讓程式代替人為去驗證程式功能的過程，即在預設條件下執行程式系統 流程確定 搭建自動化框架 編寫測試用例，將其轉化為soupui 介面 自動化測試指令碼 執行自動化測試指令碼 輸出執行...
自動化測試與手工測試
軟體測試早已不是單純的點點點了，很多場景都可以使用自動化測試的方式來代替手工，但手工測試也有著自動化測試不可代替的優勢。自動化是釋放雙手的過程 自動化 web測試 web自動化測試 自動化測試的先決條件 產品需求變更較少 專案周期長，測試用例執行頻繁，人工無法勝任，有充足的人力物力 a 自動化測試不...
測試自動化 自動化測試的定義
相關術語 automated testing test tool,automated testing test suite,automated testing test script等.具體參見 http en.wikipedia.org wiki test automation 推薦書籍 1 軟體...