國內互聯網巨頭們軟體開發過程中測試自動化程度如何？

01-20

我在一家提供銀行IT解決方案的公司工作，產品完全依靠測試人員人力測試，沒有任何自動化測試。測試人員苦不堪言，代碼質量令人堪憂。
近年讀了不少技術書，內容包括TDD(測試驅動開發)、ATDD(驗收測試驅動開發)、BDD(行為驅動開發)、CI(持續集成)和CD(持續交付)等。了解到軟體系統開發應該有完備的自動化的單元測試、集成測試和驗收測試，代碼覆蓋率應該在70%以上。系統在交給測試人員之前，自動化測試套件應該能夠捕捉到絕大多數低級Bug，而測試人員應該集中精力於發現深層次的Bug和影響用戶體驗的不良設計。
和一位在唯品會工作過的前同事聊過，他說唯品會也幾乎沒有自動化的測試，軟體質量全靠龐大的測試人員團隊來保證。不知道其他諸如BAT之類的大型互聯網公司是什麼狀況？(有誰關注了相關大牛的麻煩幫忙邀請一下。)

先來說下自己的情況，騰訊IEG研發部wetest平台的（專註質量的一個平台），同時也是騰訊Unity手游自動化測試框架wpyscripts的作者。

騰訊對手游的質量非常重視，如果有必現的嚴重bug，或者手游性能不達到騰訊內部的標準，均是不允許上線的。公司內部對遊戲品質的要求越來越高，但是測試人力缺不太能增加，所以自動化測試必然以後發展的重要方向。

不同於Web應用和Android原生應用，手游的自動化測試的難點要高的多。1、遊戲更為複雜；2、更新迭代，版本周期更短；3、Bug種類更多，流暢、音效等；4、沒有一款成熟的UI自動化測試框架；5、難以以用例的形式進行測試，遊戲往往是一擼到底的。

騰訊推出了一套Unity手游自動化框架，幾乎能夠模擬人的一切行為，在部分手游中有非常好的應用。我們現在搭建的平台進行自動化不僅會發現crash、無響應、UI問題，也會記錄CPU、內存、FPS、流量等性能數據，自動化測試過程中會保留說有的日誌、操作截圖。

通常我們平時的自動化測試時這樣的（項目組自己對待測試的方式各不相同，我只說UI自動化）：

1、持續集成。每日都會自動構建一個可用版本，構建系統能夠自動把這個apk提交到http://wetest.qq.com。平台這邊會在top100的手機上，執行安裝、拉起、登錄、monkey點擊。通常10分鐘之內出報告。

2、case自動化測試。開發一個新版本後，針對該新功能，使用腳本在平台上Top100的Android手機上執行。主要是兼容性測試和性能測試，附帶一定的功能性測試。通常30分鐘之內出報告。

3、提測版本測試。每一個提測版本，均需要做回歸測試，可以利用平台進行自動化測試。

4、PVP類手游測試。MOBA多人對戰遊戲，往往需要找10個外包一起測試，耗費人力巨大。因此，部分項目組使用9個自動化腳本+1個人測試人員的模式進行測試，能夠極大的節省人力成本。

5、探索性兼容測試。就測試效果而言，人工測試也並不全部優於自動化測試，人在測試的時候一定是具有定向思維的，部分按鈕很難被測到。我們使用自動探索的方式進行測試，對遊戲進行無意識的操作覆蓋儘可能多的場景，更加容易發現兼容性問題。

6、大版本發布。wetest內部還有一個團隊叫ATC，適配兼容測試團隊。大版本上線之前，會使用人工對遊戲進行最後一次測試，發現自動化發現不了的問題。

微信在http://wetest.qq.com上的測試最為嚴格，每天晚上都會在180多種Android手機，超過300台手機上，自動化測試超過8個小時。樓主提到自己是在一家提供銀行解決方案的公司工作的，我們最近也幫一個及知名的銀行進行自動化測試。

自動化測試一次性投入很大，學習門檻較高，部分測試人員和開發人員對自動化測試有一定的排斥。最重要的，自動化測試在可見的未來難以替代人工測試。這幾個原因，可能導致國內自動化測試普及程度沒有國外高。

=====================

對自動化測試感興趣的，可以私信我。

我來說一下我們公司吧,,做P2P產品的,基本完全依靠功能測試

不過你說的CI,CD大部分都能做,至於TDD,BDD來說,對團隊整體,和測試人員技術要求很高, 又要懂開發和測試的人來說很少

首先要明確的是目前的自動化測試，還不能做到取代手工測試去發現缺陷。只能說越底層越靠近代碼的測試，自動化測試存在的價值越大。理論上講，手工測試的所有步驟和明確的檢查點，都可以通過代碼實現自動化測試，但一方面需要考慮成本問題，另一方面手工測試中人對於整體功能正確性的把握，是肯定超過代碼的，最關鍵的是，自動化測試的代碼也是人寫的，如何保證自動化測試代碼的正確性，目前還沒看到好的解決方案。

其次，自動化測試存在的意義，目前看來還是在於把測試人員從重複的執行中解放出來。注意我們說的是重複的過程。好的測試人員，需要從業務需求角度，系統架構角度，功能實現角度和代碼實現等等角度，去定義可能的場景，並在系統中按照這個場景驗證系統的正確性。這樣的測試人員，對於公司和項目來講，是可遇不可求的，他們在某種程度上，是決定這個系統最終質量好壞的關鍵人物。這樣的高手，一個項目有一到兩個足矣。而重複性的勞動，既可以由自動化測試來執行，也可以手工執行，取決於測試團隊的技術能力，項目本身的特點，沒有絕對的好壞之分。

最後，也是最重要的，是我們希望通過測試來解決什麼問題。明確這個目標，再回過頭來看看，才可能對於自動化測試的上與不上，有一個理智的正確的選擇。

昨天寫的答案，再復缺一下。

重要的事先說三遍：執行好的軟體工程實踐，需要花費大量的時間和金錢！

且聽我慢慢道來，這裡我們只說兩件事: 項目和人。

項目就是一個很複雜的事，涉及到: 時間，成本，周期，技術棧等等。我們是乙方，所以我們從不考慮成本的原因。然後先說說我們在軟體工程方面的實踐，我不敢說是國內最好的，但我相信至少是數一數二的。我們採用的是敏捷的工作流程，不過我相信那些對於嘗試過敏捷的人來說可能會有些反感。

先說說我們平時是怎麼做的：

每日站會。大概會有十幾分鐘的溝通時間，主要看有沒有遇到什麼問題。
結對編程。這意味著兩個人做一件事情。我們大概兩天會換一次Pair。
測試(TDD)與測試覆蓋率。大部分公司的代碼都是沒有測試覆蓋的，即使是BAT也是一樣的。如果我們花一天寫功能代碼，那麼至少還要有半天的時間要寫測試。
持續集成。你要經常提交你的代碼，還要有測試，還要和別人的代碼集成——而且是一天多次。
進行Code Review。每天大概會有三十分鐘到一小時的Code Review時間，而且是集體Review今天的代碼。
技術債。在我們的上個項目中，由於是新的開發框架。在後期，我們發現我們積累了一些技術債——主要是代碼質量問題。然後，我們一周抽時間來一起重構代碼。
每周兩次的技術Session。技術Session的主要目的是提高團隊成員的技術水平。

我就不對上面的優點展開了。現在，讓我們來算一下我們需要多付出多小的成本。

假設，我們現在有四個人，每個人獨立工作，可以在一周內完成。即一個人需要 8*5 小時的工作時間。

如果採用上面的工程會多出來多少的成本？

一天480分鐘 - 60分鐘Code Review - 15分鐘站會 - 平均的技術債修復時間 15分鐘 - Session花費30分鐘 = 360分鐘 = 6小時。

接著，再減去寫測試的時間，就只剩下 4 小時。

然後，因為是結對編程，所以每個人只有2小時的時間。。。

這就意味著，我們可能要四周才能完成這個項目！！對於一個短期的項目來說，這簡直是不可接受的。

但是需要注意的是：

採用敏捷就意味著，生產力是固定的、代碼質量較高、技術平均水平較高！

這一點特別適合大的、長期的項目。請再聽我慢慢道來：

因為採用結對編程，所以每個人對整個項目的代碼都很熟悉。這就意味著，不用擔心有人離職要影響項目的穩定性。當有一個人離職時，整個項目的產出率也不會因此而變化。並且新人會因為採用結對編程而上手更快。因此只要不是一起離職，即使一年後，這個項目的人都已經換了一遍，項目仍然可以繼續下去。

同樣的有Code Review、測試和結對編程的存在，組內的代碼質量會達到相當高的水平。雖然這在早期可能意義不大，但是請注意一點：Bug在越後期的修復成本越大。

除了結對編程，還有技術Session可以提高組內成員的技術水平。

。。。

最後，你會發現在這裡，取主要因素的是人以及流程。

歡迎關注我的微信公眾號：phodal

it技術發展太快了，國內公司採用的技術是滯後的，很多先進的思想和技術，上面的領導根本就不知道的，也不會主動去了解，要看你的直接領導對你技術信不信任，要是信任你的日子好過很多，而且還會激發你自我進步和創新，要是不信任，你自己只有累點了，把先進技術用於實踐，通過實踐的證明說服你的領導，以後你的地位也會在團隊中提升，當然也會遇到團隊成員的阻礙，因為鶴立雞群總會被排斥，那麼你還得同步做建設團隊的任務，但是有可能會遇到白眼狼，教會徒弟餓死師傅，所以同步的你還要看哪個徒弟是你信賴的，還要學會看人。最壞的結果，這些先進的思想和技術，淪為極客的玩具，永遠投入不了生產實踐中去。

自動化不是目的。

同樣的，重話言三。除非自動化框架發展成可以自我學習的程度，不然自動化並不比人工測試高到哪裡去，只是適用的場景不一樣罷了。自動化用於簡單勞作而手工測試可以很快適應新功能。

UI Auto之前很多公司跟風做，彷彿認為UI Auto是高大上的是加分的。結果因為種種實踐問題，煙霧散去了不少。

所以我們的自動化更偏重性能，比如統計啟動時間、截圖、測試行為統計、activity覆蓋率統計，crash分析、smart monkey這些，最近在開發針對測試的類似umeng的SDK。

功能還主要靠手工，一周一個版，UI case根本寫不過來。