測試自動化的最高境界是？

12-30

做測試自動化，已經有6年了。
先談談我經歷過的不同階段。
1. 先是測試用例的自動化。
用程序把人從重複的勞動里解放出來。用junit搭的框架，實際上跑的是功能測試。
也整合了selenium.

2. 後來是流程的自動化。
用hudson實現。這樣，我們可以指定測試，定時定點的開始運行，完成以後，自動推送測試報告。當然，也可以附加一些靜態代碼分析，測試覆蓋率計算等工作。
3. 自動搭建測試環境。（這步還在實現中）
比如說有個測試需求是，針對10月10號的build, 馬上搭一個window8的機器，然後在IE10上，運行所有selenium case，並報告結果。
目標是，藉助chef強大能力, 我只要下班前輸入若干參數，第二天上班看結果。
完成以上三個階段，測試自動化之路似乎也走到頭了。
更進一步的話，可能是測試代碼自動生成，但是這個現在來說太難了。
各位大拿，有什麼見解？

個人覺得豐田的「自働化」主張可以作為我們的一大目標，也即自動化就要做到「省人化」、「智能化」。前者是說自動化應該能夠將人從執行和監控工作中釋放出來，完全交由自動化系統負責；而後是在執行過程中，遇到某些可預見類型的故障或問題，可以自行解決。

再往後可以朝著所謂「雲」、「移動」的方向發展，例如：隨時隨地可以訪問自動化系統。

分散式執行、虛擬化啊啥的，一大堆東西都可以加上去，慢慢地想吧，完全有無數的想像空間。

測試代碼的自動化可以參見 基於模型的測試。

我理解的自動化測試的最高境界是：能有效地預防和發現軟體缺陷。

在你的一二三點之後，把你的成果打造成開源的，或者商業的版本，解救其他的測試人員。

自動化測試的最高境界自然是不用人工干預的完全自動化拉。

第一階段：case還是要人來寫，所以有Having Automation Cases is still a precondition.

在此基礎上，所有的工作，包括

test case selection based on code change and enviornment

build

deployment

execution (self-maintain pools and self-setup execution environment to make sure parallelly execution)

result analysis

bug report

bug tracking

test case rerun

test closure report

test case maintainance based on application change

這些工作都完全不需要人工干預，作為人而言只要最後看一下自動生成並發送的closure report，這個階段的quality情況就一目了然了。當然closure report可能還附送testing coverage情報比如code coverage and mutation coverage以供評估總體風險。

以上這些步驟最難的就是result analysis，analysis的準確度由於不太可能達到100%（話說回來就算是人來做也不可能100%，具體成功率取決於機器學習的程度和人工智慧的能力），就是整個系統的風險所在，也是最可能需要被迫人工干預的階段。當然我們可以選擇在一些敏感階段比如發布前夕的某個時間進行人工干預以交叉測試降低風險。

當然還有一個難點是如何通過降低干擾等手段以提高failure valid rate，這是另外一個話題，不多說了。

所以人做的事，除了case development，便是維護整個系統拉。

第二階段：在第一階段的基礎上，automation test case完全或者大部分自動生成。這個目前大概還在研究階段，在部分領域問題還好(比如API)，千奇百怪的E2E測試可能還是比較難以自動產生非常有效的測試場景，因為測試場景歸根結底取決於業務邏輯，而業務邏輯和其測試邏輯之間的不確定相關性以及發散相關性是有悖於程序設計的確定性的。目前的想法也只能是大量的收集信息來建立模型，但是這樣的東西存在及維護的難度使得大多時候我們更偏向於直截了當的寫case了……或者有待於更深一步的AI development，我們目前還是缺乏這樣的AI research。有人做過研究的請不吝提供點資料。

再說多就變成如果有這麼強的AI，那我們還要developer幹嘛，有個產品經理控制需求告訴AI讓他開發不行嗎？那還要產品經理幹嘛？當然AI和automation現在還是兩回事，只能說有一點點交叉的地方而已。我期待將來這交叉能更多點。

個人覺得，測試自動化的最高境界應該是最大限度的節省測試時間，壓縮測試成本，同時在代碼版本快速迭代時，能夠及時有效的發現功能或UI層面的defect或bug，從而有效提高產品質量。自動化測試的價值體現在功能龐大，迭代快速的敏捷開發類項目中，回歸測試或冒煙測試中大部分測試工作都可以通過自動化實現。

從具體業務角度出發，測試自動化的最高境界取決於Test Case的設計，而這正是考驗一個測試者功力的地方。沒有一定的業務經驗及測試經驗的積累，很難設計出高效的Test Case，那麼即使實現的自動化腳本語言再複雜，工具再高端，對產品本身而言也不能稱為成功的測試。

自動化測試的結果判定，如樓上的朋友所言，確實是個難點。個人覺得其阻礙是判定當前的Fail結果是產品defect造成的還是自動化腳本的defect造成的。如果是自動化腳本本身造成的，那麼就有必要更新或重寫相關Test Case，並重新進行測試。這其中所花費的人力及時間將隨著功能增加及版本遞歸成正相關的線性增長。

對於有些朋友提出的「不用人工干預的完全自動化」，我認為已經超出了軟體測試的範圍，應該將其歸類於AI範疇。如果未來AI技術可以達到「非人工干預」的水平，Automation Test的「完全自動化」將有可能實現，但在可以預見的未來5年內，如沒有革命性的AI技術出現，自動化測試將仍然需要一定的人工干預，特別是業務流變更的情況下。

推薦一下自己的書測之重器-自動化測試框架開發指南圖靈社區: 合集 : 測之重器

下面是書的簡介：

自動化測試在國外已經實施了很多年，很多軟體公司都有自己的自動化測試系統，很多測試系統的建立都是在有自己的自動化測試框架的基礎上。自動化測試在一個公司能不能實行下去，自動化測試框架的優劣是其中最重要一環。

本書講述基於開源框架Fitnesse搭建自動化測試框架，在本書中，不會講解如何用xpath，如何寫SQL等知識，而是講解以下四大部分。

1. 基於筆者已經搭好的框架去講述如何寫測試案例，如何定義寫測試案列的格式，如何用scenario去組織可以被重用的測試步驟。如何組織Test suite，通過以上學習從而使讀者能對自動化測試有個清楚的認識。

2. 講解如何搭建這個自動化測試框架，如何去寫組件以滿足公司的測試需求，筆者會講解四大組件的構建（基於Selenium的頁面測試組件，基於SQL的資料庫測試組件，和最近比較火的MongoDB測試組件，以及測試Web Service的Rest組件），通過學習這四個組件的構建，讀者會掌握如何寫其他組件去滿足公司的其他測試需求。

3. 講解如何構建集成測試。筆者會講解此測試框架如何與Jenkins集成，如何用Jenkins自動去運行測試案列，如何在Jenkins上展示測試報告和發送郵件通知相關責任人。

4. 講解分散式測試系統的構建，筆者會講解如何用多個伺服器去同時執行測試案例。從而使案列運行時間大大節省。

本書讀者為Java 開發者或者有Java 基礎的測試人員。Java核心知識掌握比較牢固，筆者在搭建這個框架之前，曾把Think in Java 4 （Java編程思想）讀了一遍。在搭建框架中如果遇到技術問題，良好的Java核心知識能幫助我們快速解決問題。

配套視頻：張俊卿的課程中心_51CTO學院

問題本身對自動化測試現狀總結的基本差不多了。其實這三點串起來就是目前自動化測試技術能比較好應用的範疇了。自動構建、自動部署、自動測試，結果呈現。自動部署這部分還可以結合虛擬化，引入環境動態管理。

至於後面的趨勢，自動生成測試策略確實是趨勢，但目前還不成熟，基於模型的測試不能有效解決問題。後面應該會更多引入大數據挖掘、分析，機器學習、包括人工智慧到測試技術中，這個問題應該也會漸漸得到解決。

自動化結果的判斷是個難點，如果能像人那樣分析結果就好了

不請自來。

下一步是TaaS？

從數據的角度，自動生成測試數據，自動比對測試結果，測試數據管理

目前在第一個階段

我覺得最高境界，就是在設計的時候就考慮自動化測試。盡量減少UI層的邏輯，把所有的測試都變成API級別的自動化測試，並且在產品內建支持錄製回放腳本能力，然後消滅自動化測試人員……

最高境界是測試和開發都自動化，不需要人去分析，它自動進化。人只需要告訴它目標是要實現什麼，經過一段時間的進化，它就能實現。出現問題時，也能自動修復。

不請自來。

就一句話：為什麼要測試？