前 言
伴隨著業務的飛速發展， 美團點評的用戶端研發團隊的規模從初期的 20 餘人的發展為數百人， 且分散在不同的業務團隊。 擁有如此大規模的研發團隊， 他們是如何保證高效的內外部協同效率？美團與大眾點評原本是兩家獨立運營的大型互聯網公司， 分別有著不同的積累和儲備。 兩家的合併為業務帶來巨大的好處的同時也為技術團隊帶來了巨大的挑戰——如何能夠同時高效地在美團和大眾點評兩個 App 上實施業務開發？
在突破了這些難題之後， 美團希望繼續提高自身的研發效率， 經過系統性地分析，
本文就帶你揭曉美團點評技術團隊背後的故事， 分享一些美團點評用戶端團隊的技術架構及其設計思路， 幫助團隊技術負責人設計有利於提升研發效率的業務架構。 以下全文來自美團技術研究員梁士興在 2017 北京 ArchSummit 全球架構師峰會上的演講內容。
為什麼要建設用戶端架構？
用戶端架構與用戶端或 APP 的發展經歷是相關的。 早些年 APP 通常是由個人開發者或者小團隊來實施， 那時候它往往是作為一個業務創新或某一個實踐去做的。
APP 從小型變成了巨無霸， 代碼動輒上百萬行， 美團移動支付的占比也早就超過 90%， 開發團隊也從小變大， 美團點評現已有數百人專門從事 APP 開發。 反覆運算週期主要和業務的重要性相關， 如果是核心的業務載體， 反覆運算週期就需要做得越來越頻繁、越來越迅速。
美團點評使用戶端架構統一是希望得到這方面的收益， 通過標準化， 就可以實現三個統一：統一的基礎設施、統一的邏輯分層、統一的開發範式。 然後會帶來四個明確的好處：
讓一線開發人員聚焦在業務開發上；
可以實施靈活的人力調配；
可以用標準化的方式介入一個新的業務以支持其快速啟動；，
一旦實現了標準化， 必然可以基於它做一些自動化的實現， 可以把一些相對機械重複的事通過自動化去取代人工。
最終帶來的好處是：可以更好地服務業務。
美團用戶端的演變歷程
上圖是針對美團用戶端整理的技術研發體系。
美團用戶端架構發展分為三個階段：
蠻荒階段：這個階段並沒有什麼體系化的架構設計；
標準化的階段：內部細分了三個小階段，實現了業務隔離、基礎設施複用、開發範式等。
自動化是正在建設中的階段，希望通過使用工程自動化的手段去持續提升效率。
蠻荒階段
蠻荒階段也就是最初的 APP 形態，眾所周知，美團是做團購起家的，萬物都是團購，在這個階段美團並沒有針對性地設計任何架構相關的東西。但是團購有一個好處就是可以以很低的成本把業務觸達到各個領域，在這個階段中，美團實現了業務遍地開花，很輕鬆地觸達到不同的品類，比如酒店、電影等。於此同時，美團也讓移動 APP 成為了核心業務載體，移動支付的占比超過了 90%。
面臨的挑戰
那這個階段能繼續下去嗎？挑戰很快就接踵而至。挑戰主要來源於兩個方面：業務差異化和業務間的協同效率，從業務層面上來講，雖然美團實現了業務的遍地開花，用團購方式觸達到各個業務領域，但還不足以把業務做深。例如：團購這種形式並不適用於所有的領域，如酒店一定要預定，它和美食的團購行為是不一樣的，這個時候要有訴求地去深耕業務，把不同業務特點的東西做出來，就是所謂的垂直化。因為業務這邊已經有了不錯的發展，換句話說就是賺到錢了，所以團隊的規模在極速擴張，同時美團的研發團隊被拆分到各個業務去，這也是為了更好地服務業務。
標準化階段
第一階段，美團主要通過分層和隔離的方式來解決問題，首先把跟各個業務都無關的和與各個業務都相關的公共基礎設施定義為平臺的基礎設施。我們把一個平臺做強，同時在這個平臺的基礎之上去構建各個業務，而且在業務裡面進行有特色的垂直化建設，這個階段會帶來很明顯的收益。
通過這樣的平臺設施，在一定程度上實現了複用和業務的積累，解決了業務之間的耦合，各個業務在物理上會隔離開，放到不同的代碼倉庫裡面，只是在構建的時候把他們集成在一起，這種模式還有一個好處，就是為新業務的接入保持開放，任何一個新業務都可以按照規範輕鬆地接進來。
具體步驟
如果想要達成這樣的目的，首先應該開發一套標準的業務範本，所有的新業務都按照這個範本去開發，根據範本的內容去進行業務的定制，並且通過統一的方法來實現接入，誰做比較合適？顯然是新業務，讓新業務去做小白鼠，在這個階段裡，短期內是可以接受代碼拷貝的，通過解耦拷一份代碼，將其分到一個獨立的倉庫裡。為什麼說短期可以接受這種行為？用戶端有一個特點，哪怕不動彈，過一段時間頁面也會被產品改得面目全非。
在這個過程中美團的收益是什麼？總結起來有三點：
首先是在業務層面實現了業務間的隔離，解除了業務間的干擾，再也不會看到改電影模組導致酒店模組出現故障的現象，也不會把外賣的東西展示到美食區；
在工程層面上實現了工程標準化，使得新業務接入的方式是標準化的；
在技術層面上實現了獨立的編譯和二進位的集成，一旦實現了業務間的獨立編譯，就可以利用分散式的系統進行多機構建，這樣就可以極大地縮短應用的構建時間。
但梁士興認為這個階段並不完美，還有很大的改進空間。因為一線開發者的研發效率並沒有因為這次重構得到任何提高，這是為什麼呢？因為開發層面沒有標準化，代碼複用是非常困難的一件事，所以需要實現開發範式，通過定制開發範式，將開發過程統一化，開發產物也是標準化的，可以被更好地複用起來。
統一開發範式
從上圖來看，茴字有五種寫法，而 USB 介面的實現方式更多。也就是說用戶端開發的實現方式有很多種，這就使得複用變得非常困難，因為大家做事的方式都不一樣，業務模組介面也是不統一的，想用統一的方式把所有模組調度起來就會非常困難。
這個問題讓開發範式的目標明確了起來，開發範式實現的是書同文、車同軌，即開發方式統一化，業務介面標準化。
在這裡以一個實際頁面為例，這是一個複雜的頁面，這個頁面天然地劃分成若干塊，從這幾個角度上來講，頁面本身並不存在什麼東西，所有東西都被放到模組裡，經過這樣的抽象，我們把頁面上的每一塊定義為一個模組，同時頁面會退化成模組容器的概念。
進一步來說，模組之間通常存在著通信的需要，這種通訊包括 UI 上的聯動、資料的共用等，模組之間如果需要強依賴去獲取資料，則模組之間也存在著依賴，這個是不能接受的，我們設計的目標是希望能實現模組級別的複用。
為此，梁士興說他們團隊引入了一個消息匯流排的概念，可以允許模組在上面訂閱或發佈消息，通過這種方式也能實現模組之間的耦合。他們還進一步對模組的內部也進行了約束，要求模組統一，按照這樣的方式去組織，能夠更好地實現自動化測試。經過這樣的設計，美團主要頁面的實現方式得到了統一，最直接的好處就是模組可以跨業務複用了。
按梁士興的說法，他們在設計統一開發範式的時候就設定了目標，他們希望對高級工程師的依賴能夠降低，以及開發效率能夠得到提升，提升的邏輯在於代碼可以複用。對此他給出了以下案例：將 2014 年 7 月、2016 年 12 月以及 2017 年夏天開發獨立 APP 時做的需求進行對比，前兩者比較，發現 2016 年效率提升了 33%，而 2017 年獨立 APP 只用了 2 倍的人力實現了 8 倍工作量，效率提升了 400%，這種提升是非常值得開發人員自豪的。同時他們團隊參與這些項目的高級工程師的比例也在持續降低，到最後做獨立 APP 時，一個高工帶著一群小弟就能把事情搞定了。
想實現統一開發範式也會存在一些困難，這裡的困難和上文是一樣的，主要有兩點，第一，整體重構一遍成本極高，第二，業務永遠不會等著技術，所以開發的同時要進行重構。他們只對新需求涉及的頁面進行重構，用戶端的代碼總是很快地反覆運算到，借著產品反覆運算這樣的時機把對應的架構重構做完。
做到這個程度，梁士興認為他們已經進入了相對理想的狀態，但有些事情是不受他們控制的。由於公司戰略的原因，美團和點評進行了合併，眾所周知，這兩家公司一直以來是獨立運營的，各自都有不一樣的積累，合併會帶來大量的不統一：兩邊的 APP 技術棧不統一，後端服務不統一，交互樣式也不統一。對產品經理來說相當於多了一個 APP，再加上大量的基礎設施不統一，想把某功能整體從美團遷移到點評，這幾乎比登天還難。但是技術人員就是解決問題的，所以針對這三個不統一，他們做了兩層抽象。
首先，針對基礎服務層的差異，他們做了一層抽象介面，這個介面不做具體功能的實現，它的具體實現是由兩個平臺真正的基礎設施來實施的。第二個方案是針對差異進行了設計，在一套代碼倉庫裡利用構建過程，把一些差異化的地方讓它產生不同的構建產物。
通過這樣的方式，可以在 APP 裡寫不一樣的代碼，同時去支持美團和點評兩個 APP 的業務開發，這套方案其實是一個通用的方案，它並不僅限於對這兩個 APP 的支持。美團在開發獨立 APP 的時候，也是直接利用這樣一套模式，就把美團的東西複用到美團獨立的 APP 中，在三端之間實現了代碼複用，而且這套模式本身對自動化測試也是極好的，可以直接利用二進位構建的結果接入到自動化測試的工程，這樣自動化測試的構建效率是非常高的。
解決了多應用複用的問題，帶來的收益更加明顯。統一架構優化之後遷移成本整體控制在 30% 以下，其實平均是低於 20% 的，在這個階段下，美團多應用同時支援需求反覆運算的情況就變得可行了，而且是一個常態化的過程，代碼複用率也從一開始不復用，到後面整體複用率在 95% 以上。
自動化階段
經過了這樣幾輪架構方面的反覆運算，還有沒有辦法進一步提升研發效率呢？在這裡，美團用了一個方法論：既然已經實現了標準化，是否可以進行自動化了呢？因為有了自動化的工具做保障，反過來可以促成標準化的達成，殺掉非標準化的行為。
那我們應該針對什麼事情做自動化？梁士興表示，根據一個反覆運算週期的各個環節的實際人力投入，可以發現測試的成本很高，測試和開發的時間比例是 4：5，同時把測試和開發的若干個環節再去做拆解，會發現測試裡面有一個很可怕的東西叫做回歸測試，占的比重非常大，而且回歸測試還有一個特點：回歸測試的規模只與 APP 的規模有關，並不與反覆運算的新功能有關，這也是一件很可怕的事情。某個版本做了很小的需求想快速上線，同時還要為了保證線上的品質進行完整的回歸，回歸的規模並不因為需求小而變小，應該優化回歸測試的過程，從這個角度上來說，自動化測試就是解決回歸測試最有效的手段。
從開發階段上來講，美團在這幾個環節中的投入基本相當，他們希望通過代碼腳手架的方式減少開發階段的成本，如涉及網路的開發與後端進行 API 聯調的工作，如果使用聯合腳手架的話就會變得非常輕鬆。
如何進行自動化測試？
通過這樣的業務流程對各個頁面進行分析，可以得到一個結論：現在只有兩種類型的頁面，資訊展示頁面和交互邏輯型頁面，前者占比超過了 80%，如果對這類頁面進行測試，只關注它的展示行為，會發現它並沒有很複雜的邏輯；後者的情況正好相反，它的占比很少，但是它的交互邏輯會變得非常複雜，同時它內部的各種細節都會對品質有至關重要的影響，對它的測試要做得比較重，而且它的測試更多關注的是程式邏輯的實現。
然後再針對這些頁面去做測試技術的選型，上圖中的三角是通用的模型，涉及測試的各個場景，中間是分界線，分成黑盒和白盒兩種方式，美團選擇了靠近分界線的這一塊，從 UI 自動化測試和集成測試裡選取一個子集，一個子集是 UI 的截屏測試，應用在資訊展示型頁面，一個子集是面向 UI 介面應用於交互邏輯型頁面。
首先是 UI 截屏測試方案，一份截屏測試需要參考圖、實際效果圖、Diff 分析，還包括後端返回的資料，即資料樁，還有類比登錄層出、設置時間等，同時需要把上下文的所有資訊都設置成可控的，展示結果也是可控的。
面向 UI 介面的集成測試類比了視圖該有的結果，可以供開發者執行測試，套用到三部曲裡，第一步，設置上下文環境，設置測試資料；第二步模擬用戶操作，就是用測試用例調用 VM 上的命令；第三步校驗結果，即監測 VM 上的資料狀態。有些測試用例資料一直在端上，我們要把最終發起的請求攔截住，在請求那一層檢查，比如選擇了下單資訊，最終去發出請求看這些是否正確。
自動化測試的挑戰
實施自動化測試也有很大的挑戰，主要有兩點：一是實施測試的成本，二是自動化測試的執行效率。成本方面主要體現在開發測試用例的人力投入和測試用例本身失效帶來的額外成本（也可以說是維護的成本）。
在執行效率方面，前面介紹過通過複用二進位構建方式，把構建 + 執行時間從 30 分鐘優化到 6 分鐘，然後另一個是執行成功率，因為有 15% 的概率會失敗，所以需要引入重試的機制，把失敗率降低到 5% 以下。
自動化測試的收益
自動化測試帶來的收益，首先最明顯是線上品質的提升。另一個是對研發效率有很大的提升，這主要體現在對反覆運算頻率的影響，因為一旦對應的模組實施了自動化測試，就只需要抽查 2% 的測試用例。
未來之路
對於未來，梁士興表示他們希望把前面測試用例通過平臺化的方式統一管理起來，同時會在這些場景裡面對日常開發有很大的效率提升。另一個是代碼腳手架，從上文反覆運算週期可以看到這塊也是值得去做的。
免責聲明：轉載自網路 不用於商業宣傳 版權歸原作者所有 侵權刪
美團用戶端架構發展分為三個階段：
蠻荒階段：這個階段並沒有什麼體系化的架構設計；
標準化的階段：內部細分了三個小階段，實現了業務隔離、基礎設施複用、開發範式等。
自動化是正在建設中的階段，希望通過使用工程自動化的手段去持續提升效率。
蠻荒階段
蠻荒階段也就是最初的 APP 形態，眾所周知，美團是做團購起家的，萬物都是團購，在這個階段美團並沒有針對性地設計任何架構相關的東西。但是團購有一個好處就是可以以很低的成本把業務觸達到各個領域，在這個階段中，美團實現了業務遍地開花，很輕鬆地觸達到不同的品類，比如酒店、電影等。於此同時，美團也讓移動 APP 成為了核心業務載體，移動支付的占比超過了 90%。
面臨的挑戰
那這個階段能繼續下去嗎？挑戰很快就接踵而至。挑戰主要來源於兩個方面：業務差異化和業務間的協同效率，從業務層面上來講，雖然美團實現了業務的遍地開花，用團購方式觸達到各個業務領域，但還不足以把業務做深。例如：團購這種形式並不適用於所有的領域，如酒店一定要預定，它和美食的團購行為是不一樣的，這個時候要有訴求地去深耕業務，把不同業務特點的東西做出來，就是所謂的垂直化。因為業務這邊已經有了不錯的發展，換句話說就是賺到錢了，所以團隊的規模在極速擴張，同時美團的研發團隊被拆分到各個業務去，這也是為了更好地服務業務。
標準化階段
第一階段，美團主要通過分層和隔離的方式來解決問題，首先把跟各個業務都無關的和與各個業務都相關的公共基礎設施定義為平臺的基礎設施。我們把一個平臺做強，同時在這個平臺的基礎之上去構建各個業務，而且在業務裡面進行有特色的垂直化建設，這個階段會帶來很明顯的收益。
通過這樣的平臺設施，在一定程度上實現了複用和業務的積累，解決了業務之間的耦合，各個業務在物理上會隔離開，放到不同的代碼倉庫裡面，只是在構建的時候把他們集成在一起，這種模式還有一個好處，就是為新業務的接入保持開放，任何一個新業務都可以按照規範輕鬆地接進來。
具體步驟
如果想要達成這樣的目的，首先應該開發一套標準的業務範本，所有的新業務都按照這個範本去開發，根據範本的內容去進行業務的定制，並且通過統一的方法來實現接入，誰做比較合適？顯然是新業務，讓新業務去做小白鼠，在這個階段裡，短期內是可以接受代碼拷貝的，通過解耦拷一份代碼，將其分到一個獨立的倉庫裡。為什麼說短期可以接受這種行為？用戶端有一個特點，哪怕不動彈，過一段時間頁面也會被產品改得面目全非。
在這個過程中美團的收益是什麼？總結起來有三點：
首先是在業務層面實現了業務間的隔離，解除了業務間的干擾，再也不會看到改電影模組導致酒店模組出現故障的現象，也不會把外賣的東西展示到美食區；
在工程層面上實現了工程標準化，使得新業務接入的方式是標準化的；
在技術層面上實現了獨立的編譯和二進位的集成，一旦實現了業務間的獨立編譯，就可以利用分散式的系統進行多機構建，這樣就可以極大地縮短應用的構建時間。
但梁士興認為這個階段並不完美，還有很大的改進空間。因為一線開發者的研發效率並沒有因為這次重構得到任何提高，這是為什麼呢？因為開發層面沒有標準化，代碼複用是非常困難的一件事，所以需要實現開發範式，通過定制開發範式，將開發過程統一化，開發產物也是標準化的，可以被更好地複用起來。
統一開發範式
從上圖來看，茴字有五種寫法，而 USB 介面的實現方式更多。也就是說用戶端開發的實現方式有很多種，這就使得複用變得非常困難，因為大家做事的方式都不一樣，業務模組介面也是不統一的，想用統一的方式把所有模組調度起來就會非常困難。
這個問題讓開發範式的目標明確了起來，開發範式實現的是書同文、車同軌，即開發方式統一化，業務介面標準化。
在這裡以一個實際頁面為例，這是一個複雜的頁面，這個頁面天然地劃分成若干塊，從這幾個角度上來講，頁面本身並不存在什麼東西，所有東西都被放到模組裡，經過這樣的抽象，我們把頁面上的每一塊定義為一個模組，同時頁面會退化成模組容器的概念。
進一步來說，模組之間通常存在著通信的需要，這種通訊包括 UI 上的聯動、資料的共用等，模組之間如果需要強依賴去獲取資料，則模組之間也存在著依賴，這個是不能接受的，我們設計的目標是希望能實現模組級別的複用。
為此，梁士興說他們團隊引入了一個消息匯流排的概念，可以允許模組在上面訂閱或發佈消息，通過這種方式也能實現模組之間的耦合。他們還進一步對模組的內部也進行了約束，要求模組統一，按照這樣的方式去組織，能夠更好地實現自動化測試。經過這樣的設計，美團主要頁面的實現方式得到了統一，最直接的好處就是模組可以跨業務複用了。
按梁士興的說法，他們在設計統一開發範式的時候就設定了目標，他們希望對高級工程師的依賴能夠降低，以及開發效率能夠得到提升，提升的邏輯在於代碼可以複用。對此他給出了以下案例：將 2014 年 7 月、2016 年 12 月以及 2017 年夏天開發獨立 APP 時做的需求進行對比，前兩者比較，發現 2016 年效率提升了 33%，而 2017 年獨立 APP 只用了 2 倍的人力實現了 8 倍工作量，效率提升了 400%，這種提升是非常值得開發人員自豪的。同時他們團隊參與這些項目的高級工程師的比例也在持續降低，到最後做獨立 APP 時，一個高工帶著一群小弟就能把事情搞定了。
想實現統一開發範式也會存在一些困難，這裡的困難和上文是一樣的，主要有兩點，第一，整體重構一遍成本極高，第二，業務永遠不會等著技術，所以開發的同時要進行重構。他們只對新需求涉及的頁面進行重構，用戶端的代碼總是很快地反覆運算到，借著產品反覆運算這樣的時機把對應的架構重構做完。
做到這個程度，梁士興認為他們已經進入了相對理想的狀態，但有些事情是不受他們控制的。由於公司戰略的原因，美團和點評進行了合併，眾所周知，這兩家公司一直以來是獨立運營的，各自都有不一樣的積累，合併會帶來大量的不統一：兩邊的 APP 技術棧不統一，後端服務不統一，交互樣式也不統一。對產品經理來說相當於多了一個 APP，再加上大量的基礎設施不統一，想把某功能整體從美團遷移到點評，這幾乎比登天還難。但是技術人員就是解決問題的，所以針對這三個不統一，他們做了兩層抽象。
首先，針對基礎服務層的差異，他們做了一層抽象介面，這個介面不做具體功能的實現，它的具體實現是由兩個平臺真正的基礎設施來實施的。第二個方案是針對差異進行了設計，在一套代碼倉庫裡利用構建過程，把一些差異化的地方讓它產生不同的構建產物。
通過這樣的方式，可以在 APP 裡寫不一樣的代碼，同時去支持美團和點評兩個 APP 的業務開發，這套方案其實是一個通用的方案，它並不僅限於對這兩個 APP 的支持。美團在開發獨立 APP 的時候，也是直接利用這樣一套模式，就把美團的東西複用到美團獨立的 APP 中，在三端之間實現了代碼複用，而且這套模式本身對自動化測試也是極好的，可以直接利用二進位構建的結果接入到自動化測試的工程，這樣自動化測試的構建效率是非常高的。
解決了多應用複用的問題，帶來的收益更加明顯。統一架構優化之後遷移成本整體控制在 30% 以下，其實平均是低於 20% 的，在這個階段下，美團多應用同時支援需求反覆運算的情況就變得可行了，而且是一個常態化的過程，代碼複用率也從一開始不復用，到後面整體複用率在 95% 以上。
自動化階段
經過了這樣幾輪架構方面的反覆運算，還有沒有辦法進一步提升研發效率呢？在這裡，美團用了一個方法論：既然已經實現了標準化，是否可以進行自動化了呢？因為有了自動化的工具做保障，反過來可以促成標準化的達成，殺掉非標準化的行為。
那我們應該針對什麼事情做自動化？梁士興表示，根據一個反覆運算週期的各個環節的實際人力投入，可以發現測試的成本很高，測試和開發的時間比例是 4：5，同時把測試和開發的若干個環節再去做拆解，會發現測試裡面有一個很可怕的東西叫做回歸測試，占的比重非常大，而且回歸測試還有一個特點：回歸測試的規模只與 APP 的規模有關，並不與反覆運算的新功能有關，這也是一件很可怕的事情。某個版本做了很小的需求想快速上線，同時還要為了保證線上的品質進行完整的回歸，回歸的規模並不因為需求小而變小，應該優化回歸測試的過程，從這個角度上來說，自動化測試就是解決回歸測試最有效的手段。
從開發階段上來講，美團在這幾個環節中的投入基本相當，他們希望通過代碼腳手架的方式減少開發階段的成本，如涉及網路的開發與後端進行 API 聯調的工作，如果使用聯合腳手架的話就會變得非常輕鬆。
如何進行自動化測試？
通過這樣的業務流程對各個頁面進行分析，可以得到一個結論：現在只有兩種類型的頁面，資訊展示頁面和交互邏輯型頁面，前者占比超過了 80%，如果對這類頁面進行測試，只關注它的展示行為，會發現它並沒有很複雜的邏輯；後者的情況正好相反，它的占比很少，但是它的交互邏輯會變得非常複雜，同時它內部的各種細節都會對品質有至關重要的影響，對它的測試要做得比較重，而且它的測試更多關注的是程式邏輯的實現。
然後再針對這些頁面去做測試技術的選型，上圖中的三角是通用的模型，涉及測試的各個場景，中間是分界線，分成黑盒和白盒兩種方式，美團選擇了靠近分界線的這一塊，從 UI 自動化測試和集成測試裡選取一個子集，一個子集是 UI 的截屏測試，應用在資訊展示型頁面，一個子集是面向 UI 介面應用於交互邏輯型頁面。
首先是 UI 截屏測試方案，一份截屏測試需要參考圖、實際效果圖、Diff 分析，還包括後端返回的資料，即資料樁，還有類比登錄層出、設置時間等，同時需要把上下文的所有資訊都設置成可控的，展示結果也是可控的。
面向 UI 介面的集成測試類比了視圖該有的結果，可以供開發者執行測試，套用到三部曲裡，第一步，設置上下文環境，設置測試資料；第二步模擬用戶操作，就是用測試用例調用 VM 上的命令；第三步校驗結果，即監測 VM 上的資料狀態。有些測試用例資料一直在端上，我們要把最終發起的請求攔截住，在請求那一層檢查，比如選擇了下單資訊，最終去發出請求看這些是否正確。
自動化測試的挑戰
實施自動化測試也有很大的挑戰，主要有兩點：一是實施測試的成本，二是自動化測試的執行效率。成本方面主要體現在開發測試用例的人力投入和測試用例本身失效帶來的額外成本（也可以說是維護的成本）。
在執行效率方面，前面介紹過通過複用二進位構建方式，把構建 + 執行時間從 30 分鐘優化到 6 分鐘，然後另一個是執行成功率，因為有 15% 的概率會失敗，所以需要引入重試的機制，把失敗率降低到 5% 以下。
自動化測試的收益
自動化測試帶來的收益，首先最明顯是線上品質的提升。另一個是對研發效率有很大的提升，這主要體現在對反覆運算頻率的影響，因為一旦對應的模組實施了自動化測試，就只需要抽查 2% 的測試用例。
未來之路
對於未來，梁士興表示他們希望把前面測試用例通過平臺化的方式統一管理起來，同時會在這些場景裡面對日常開發有很大的效率提升。另一個是代碼腳手架，從上文反覆運算週期可以看到這塊也是值得去做的。
免責聲明：轉載自網路 不用於商業宣傳 版權歸原作者所有 侵權刪