從自動化測試到持續部署，你須要瞭解這些

在互聯網的產品開發時代，產品迭代愈來愈頻繁，「從功能開發完成直到成功部署」這一階段被稱爲軟件開發「最後一千米」。不少開發團隊也愈來愈認識到，自動化測試和持續部署可幫助開發團隊提升迭代效率和質量。

那麼，如何更好地解決「最後一千米」這一問題呢?

一切從自動化測試開始，讓自動化測試貫穿在整個項目開發-集成-部署-交付的-開發流程中。

若是你的團隊尚未開始自動化測試，推薦從經典的測試金字塔開始。

自動化測試

在這個分層自動化測試金字塔中，Unit 表明單元測試，Service 表明服務集成測試，UI 表明頁面級的功能測試。不一樣的產品層次都須要自動化測試，投入的精力和工做量會有所不一樣。下面咱們仔細看下每一個層次的測試：

1.1 Unit 單元測試

「凡是不能量化的工做都是不可考量的」

目前不少公司已經意識到了單元測試的重要性，但國內堅持寫單元測試的團隊並很少，其中一個難點在於沒有考量，沒有很好地執行單元測試覆蓋率檢測。

想一想，若是沒有單元測試覆蓋率檢測，單純的只寫單元測試，時間長了也許開發人員會產生惰性，好比：今天任務太緊了，就不寫單元測試了，之後再補，反正寫不寫也沒有人知道。引入單元測試覆蓋率檢測以後，開發人員會更主動地寫單元測試，就算補寫單元測試也更有成就感。單元測試覆蓋率檢測有現成的第三方工具，好比 code climate 、 Coveralls 等等，針對不一樣的語言也有還有一些定製化的檢測工具， 好比前端經常使用的 Eslint , Python 經常使用的PEP8 等等。整個項目的單元測試覆蓋狀況百分比，看上去一目瞭然。

相比其餘層級的測試，單元測試發現並解決問題付出的成本相對來講最低，而投入產出比最高。單元測試的責任主體通常來講是開發人員，寫單元測試也是開發人員對本身的代碼進行檢查的過程。

1.2 Service 集成測試

「多數應用和產品都須要與外部資源交互，有時候多數 Bug 並不來源於程序自己，而是由從外部輸入的數據所引發的。」

這時候，就更須要集成測試。

集成測試是在單元測試的基礎上，將全部模塊按照設計要求（如根據結構圖）組裝成爲子系統或系統，進行集成測試。這個集成測試階段主要解決的是檢查各個軟件組成單元代碼是否符合開發規範、接口是否存在問題、總體功能有無錯誤、界面是否符合設計規範、性能是否知足用戶需求等等。

集成測試與單元測試最大的區別在於，它須要儘量地測試整個功能及相關環境。若是不通過單元測試，那麼集成測試的效果將會受到很大影響，大幅增長單元代碼糾錯的代價。

這一層的被測對象是抽離了展示層的代碼(前端以及部分後端展示層邏輯)，主要是由測試人員進行，是測試人員大展身手的地方。

1.3 UI 系統測試

「一份永遠都運行成功的自動化測試用例是沒有價值的。一切都在變化中。」

在作好上面兩層的測試覆蓋以後，最頂端的是 UI 層的自動化測試。目前，UI 層的自動化覆蓋正在逐漸轉變爲頁面展現邏輯及界面前端與服務展示層交互的集成驗證。UI層自動化作的方式不少，根據不一樣的系統，不一樣的架構可能會用到不一樣的框架或者工具，比較主流的有QTP，Robot Framework、watir、selenium 等。

怎麼選擇合適的工具？每一個測試工具都有它的優缺點，每一個被測試的項目也有本身自己的特色。好比，項目是用什麼語言編寫的，C, C++, Java, PHP , Python or C#? 項目是什麼類型，Desktop , Web or Mobile Application? 很難說一種工具就能夠搞定全部或者大部分的項目，也很難說一個項目就能單純的靠一種工具來搞定。

UI 層是直接面向用戶的，須要測試人員放入更多的時間和精力。現在的互聯網公司大多需求變化大而快，迭代頻繁，因此不少團隊作 UI 自動化測試投入較大精力，卻遲遲見不到效果，自動化測試人員天天奔命於維護腳本，追趕進度。有 2 點 UI層自動化覆蓋的原則很是有必要提下：

• 能在底層作自動化覆蓋，就儘可能不在UI層作自動化覆蓋；

• 只作最核心功能的自動化覆蓋，腳本可維護性儘量提升。

綜上所述，分層自動化測試側重不一樣，效果不盡然完美的，而最快速高效發現 bug 的方法是將自動化測試包含到構建過程當中。謹慎周全的自動化測試能夠進一步保證持續部署的穩定與安全，提升持續部署的成功率。

持續部署

對於持續部署，@灣區日報 這樣評論：

一個團隊工程技術水平高低，直接反映在部署代碼上。我碰到其餘公司的人，都喜歡問大家怎麼部署代碼的，很是大開眼界。你很難相信，不少（有必定規模的）公司仍然是人肉 SSH 到十幾、二十臺機器上 git pull、手動重啓服務器，部署一次代碼幾個小時 -- 這麼原始，活該加班：）

持續部署（continuous deployment）是經過自動化的構建、測試和部署循環來快速交付高質量的產品。某種程度上表明瞭一個開發團隊工程化的程度，畢竟快速運轉的互聯網公司人力成本會高於機器，投資機器優化開發流程化相對也提升了人的效率，讓 engineering productivity 最大化。

2.1 持續部署的步驟

「持續部署」的痛苦源於部署時的各方面，好比須要部署到哪些環境，測試環境？灰度發佈？正式環境？還有其依賴包的版本，環境配置管理等等，都須要考慮在其中。對於一個標準的部署——安裝軟件包並啓動環境，可能的步驟將會是：

2.2 CI 工具的選擇與使用

imothy寫過一篇文章介紹了 IMVU 是如何進行持續部署。IMVU 的作法是，在持續集成構建過程當中進行大量的、覆蓋範圍廣的、很是可靠的自動化測試，保證在 10 分鐘內跑完整個測試套件。全部測試經過後，部署便開始了。

在這個過程當中，持續集成工具的選擇和系統的搭建顯得尤其重要。面對衆多的 CI 工具，咱們將其分爲 Hosted CI 和 Self Hosted CI：

• Self HostedCI 指的是將軟件部署在公司的機房或內網中，須要提供多臺服務器來完成 CI 系統的運轉，同時須要對不一樣機器之間進行環境配置。主流工具備Jenkins，其餘受歡迎的工具好比 Baboom 及 TeamCity 等。

• Hosted CI 指的是由 SaaS 型的 CI 服務，全程在線進行構建配置，不須要考慮裝機器，裝軟件，環境搭建等成本。常見的有 CircleCI，Codeship 和 TravisCI 等。

咱們對比一下這兩種 CI 服務：

• Self Hosted CI 對構建環境有徹底的控制權，可以實現徹底定製。但須要搭建環境和配置、維護成本高，須要買專門的機器，花費人力物力且更新遷移風險高；

• Hosted CI 無需額外機器，幾分鐘就能夠用起來。能夠根據你的須要動態調度資源。省時，省心，省力。

咱們作了一款 Hosted CI 產品—— flow.ci ，它是融入了 workflow 機制的持續集成（CI）服務，也能夠理解爲自動化流程平臺，除了集成代碼、編譯、測試以外，還能夠集成經常使用的工具、靈活自定義流程。1 分鐘便可完成開發測試環境搭建，開啓第一個Build。

flow.ci 更側重於工做流的設置，默認的工做流能夠自動編譯測試代碼，進行單元測試覆蓋率，代碼質量檢測等工具以插件的形式進行集成；並加入了 Webhook 功能。從自動化測試到持續部署，一切簡單靈活。

2.3 讓持續部署成功的要點

一個持續集成 & 持續部署的自動化系統並非那麼簡單的事，若是不選用其餘 CI 服務，其開發工做量和一個標準的大型互聯網業務系統沒什麼兩樣。若是沒有持續部署的經驗，要想成功地進行持續部署要注意這些:

• 充分而普遍的自動化測試覆蓋；
• 儘量短的測試反饋時間；
• 部署過程自動化；
• 部署過程要保證數據安全；
• 在穩定的前提下，儘早部署；
• 完善的風險緩解措施；
• 將一樣的產物部署到不一樣的環境中

2.4 持續部署習慣的養成

持續部署真正困難的不是技術的實現，也不是工具的選擇和使用，最難的是培養團隊持續部署的習慣以及工程文化。能夠參考下Instagram 的持續部署工程文化。

總結

不管是自動化測試，仍是持續部署，都只是一種實現手段；他們真正存在的價值在於提升代碼質量和提升產品的持續交付能力。關於如何進行更好地進行自動化測試和持續部署，能夠多參考下其餘公司的持續部署實踐案例與經驗。

若是你有更加深入的看法，歡迎留言交流！

【參考連接】

• 持續部署，並不簡單！
• 有贊分層自動化測試實踐
• Beyond Continuous Integration: Continuous Deployment
• The Product Managers’ Guide to Continuous Delivery and DevOps