自動化

這幾年工業(yè)4.0的概念很火。若要來總結四次工業(yè)革命的話，我會說這是一個通過不斷深入自動化來解放人類的過程。

• 第一次工業(yè)革命，人類利用水力和蒸汽的力量解決了出力過程的自動化。
• 第二次工業(yè)革命，人類使用電力解偶能源采集和能源使用，從而讓出力過程自動化擴散開來。
• 第三次工業(yè)革命，人類使用電子設備和信息技術解決了調度過程的自動化。
• 第四次工業(yè)革命，人類想要解決分析，編排過程的自動化。

程序員是一個很自負的群體，他們號稱要把一切能自動化的東西都自動化掉，其結果就是：當把編程也自動化之后，就不再需要程序員了。如果這是什么壞事的話，那也是他們自食其果。因為在那之前，他們已經(jīng)把很多東西都自動化掉了，也消滅了很多行業(yè)。

測試在開發(fā)之前

不管是從工業(yè)革命的歷史來看，還是從邏輯上推理，調度過程的自動化總是先于分析和編排過程的自動化。而測試其實就是一種調度的過程。開發(fā)則涉及到一些分析和編排的過程。所以可以得出測試的自動化應該在開發(fā)自動化之前。

測試幾時會被干掉

馬克思分析了資本主義的種種問題，預言中了出現(xiàn)的種種惡果，然后說共產(chǎn)主義是未來。然而已經(jīng)過去多少年了，共產(chǎn)主義卻遲遲不來。不管是基于歷史推斷，還是純粹理性邏輯，一個事物應該是怎么樣不等于它實際是怎么樣。

人類有能力正確預言一個簡單事物的發(fā)展結果，但如果一個結果是基于其它未確定或穩(wěn)定的結果，那么人類預言正確的概率通常都不高。所以這里要討論的不是測試應不應該或者能不能自動化。而是現(xiàn)在自動化測試的條件成熟了沒有。

自動化測試的前提

所謂自動化，無非就是讓原本需要人來完成的工作由機器來完成。而軟件其中一類的功能就是讓電腦來完成原本需要人才能完成的工作。所以自動化測試并不存在技術上的不可實現(xiàn)點。

1936年圖靈提出了一個抽象計算模型：圖靈機。而第一臺圖靈完全的通用數(shù)字計算機出現(xiàn)在8，9年后。而人類建造通天塔的傳說更是告訴我們，技術上沒有不可實現(xiàn)點，不等于實際上可實現(xiàn)。

軟件工程最大的問題在于復雜度的問題，我們假設我們開發(fā)的系統(tǒng)是可實現(xiàn)的，那么我們只要論證開發(fā)一個自動化測試我們目標系統(tǒng)的測試系統(tǒng)，復雜性不高與我們的目標系統(tǒng)，那么這個自動化測試系統(tǒng)就是可實現(xiàn)的。

系統(tǒng)的復雜度主要有兩種，一種是概念上的復雜性，一種是表述上的復雜性。測試系統(tǒng)與目標系統(tǒng)在概念復雜性上是一致的。不管是測試一種行為還是實現(xiàn)一種行為，對行為的概念應該是一致的。在表述復雜性上，測試系統(tǒng)是低于目標系統(tǒng)的。因為目標系統(tǒng)表述的是實現(xiàn)一種行為的過程，而測試系統(tǒng)表述的是對比目標系統(tǒng)的執(zhí)行結果和預期的結果。所以可以得出測試系統(tǒng)的復雜性低于目標系統(tǒng)。所以對于一個可實現(xiàn)的目標系統(tǒng)來說，它的自動化測試系統(tǒng)也是可以實現(xiàn)的。

上面說的是技術上可以實現(xiàn)，現(xiàn)實中我們要不要做一件事通?？紤]的是成本與收益。我們不可能在開發(fā)一個系統(tǒng)時（或之前或之后），還要開發(fā)一個自動化測試系統(tǒng)，成本不允許。但針對整個軟件領域開發(fā)一套自動化測試框架是收益大于成本的。所以是值得做的事，所以才有了那么多的測試框架。而自動化測試的前提就是對一個系統(tǒng)進行自動化測試的成本小于自動化測試帶來的收益。

如何去做自動化測試

任何有用的系統(tǒng)，都會有輸入和輸出，但輸入輸出的表現(xiàn)形式各不相同。所以并不一定所有的系統(tǒng)都適合在目前來做自動化測試。接下來我們討論的是幾種軟件系統(tǒng)的自動化測試方案。

web 系統(tǒng)

如果 web 系統(tǒng)是采用比較老的技術棧開發(fā)的，那么可以使用一些目前比較成熟的 web 應用程序測試框架。但這些框架通常使用起來不是很方便。成本不低，因為要編寫和維護比較復雜的測試腳本。收益不高，因為腳本檢測不到很多人一眼就能看到的問題。

如果使用的是現(xiàn)在比較新的技術棧，那么很多組件化框架本身就帶了測試框架，使用這些框架可以方便的達到自動化測試的效果。只是需要額外多寫一些測試代碼，關于值不值的寫這些測試代碼以及寫到什么樣的程度，業(yè)界一直存在爭議。就目前的情況來說，完全有可能使用自動化測試覆蓋所有功能性測試。成本不低，也不算高，但收益高。

使用接口訪問的系統(tǒng)

使用接口訪問的系統(tǒng)是一類比較容易進行自動化測試的系統(tǒng)，無論是通過 webservice 還是 restful 接口，都有比較成熟的測試框架，測試效果甚至優(yōu)與人工測試，因為人出現(xiàn)失誤的機率比電腦高，而且人對時間的敏感性會帶有主觀因素。

壓力測試

不同于功能性測試，壓力測試除了測試正確性之外，還需要測試系統(tǒng)的負載，響應時間，可用性等?，F(xiàn)在壓測的框架不少，問題只在于自動化壓測環(huán)境的搭建，而這是運維方面的內容，而去運維的自動化目前是走在測試自動化前面的，所以這塊并沒有什么多說的。

外部條件

軟件行業(yè)日新月異，新技術，新概念不斷涌現(xiàn)，這些年來微服務也是特別火，網(wǎng)上隨便搜索一下最近很火的技術文章，不是在說微服務就是在說容器化。

對于微服務產(chǎn)生的原因，以及帶來的好處，網(wǎng)上已經(jīng)討論的比較多了，但是我?guī)缀鯖]有看見有人說過微服務同時也降低了系統(tǒng)自動化測試的成本。一個好的架構常常就是這樣，它在實現(xiàn)自身架構意圖的情況下也讓別的方面變的更合理了。

點題

自動化運維也是近來比較火的概念，也處于發(fā)展飛快的階段。而測試的全自動化卻是被提及的比較少的。比較不火導致了推行上會遇到一些阻力，領導會問：為什么要做，能不能做，值不值得做，有沒有成功的案例。下屬會問：怎么做，有沒有參照系統(tǒng)。

這里我基本描述了為什么要做，能不能做，值不值得做的問題，簡單描述了一下怎么做的問題。限于篇幅，很多實現(xiàn)案例只能等有機會時再做介紹。