轉載自：Dev Club 技術分享

導語：

在移動網際網路越來越快的迭代專案中，很多測試人員和測試團隊都開始覺得力不從心。很多團隊和公司都開始討論怎麼保證質量，事實是單純的從測試和測試團隊出發都無法保證產品的質量了。是時候從技術以及思想上開始轉變了。

正文：

1. 測試已死，關注質量才是王道

首先先看下今年我到各個公司交流的時候，大家最常問的一些問題吧。

其實總體來講測試行業現在還是有很大進步的，既關注了整體策略也關注了技術細節。但其實比較奇怪的是其實大部分人關注的還是別人怎麼做，就是特別的缺少的從自己公司的產品業務和團隊情況去思考問題。這不得不讓我想到“別人家的xxx”這樣一個場景。當初我在做這個“測試到質量”轉變的時候我就是希望貼近主題儘量從全面的去闡述測試到質量的變化。 總體來講，還是測試行業太過焦躁，我們總是偶爾的很積極的想去了解，想去學習，但這不可持續發展，這就好像我們會去存很多pdf和網站，但從來不看是一個道理。

今天在群裡的都是開發同學，其實就我的瞭解，大部分的開發同學都知道測試的重要性，但其實本質上並不知道測試具體要做什麼或者說怎麼做，再比如測試工程師到底應該具備什麼樣的能力也不清楚，反正就是是一個模糊的概念。

所以我想先強調下，今天我和大家說的並不是一種測試的理想狀態，而是現在移動網際網路，這樣一個快速發展，變化的行業測試應該有的姿態。以前國內網際網路行業中的測試相對不是很規範，流程也好，技術也罷。但近幾年越來越走向正軌，所以也希望各位開發同學能夠一起努力把產品的質量做好。

就如我這邊說的，現在快速的發展依靠傳統的測試已經不可能完成了。那麼什麼是傳統的測試方式呢？傳統的測試方法就是隻關注“ui自動化，單元測試，介面測試，持續整合，迴歸測試，冒煙測試等等”。

這些可以說是測試行業不變的關注點，但在現今的移動網際網路，單純的關注這些已經遠遠不可能保證我們的產品質量了，希望很多開發和測試都有這樣的感覺。所以這就是今天我們要來講述的測試到質量的轉變。只關注測試的測試已經死了，我們所有人都需要把關注點放在質量上

2. 一專多能

切入點有這樣兩個：

• 一個是人，這裡的人先還是比較關注在測試身上。

• 另外一個就是流程，流程中的每個細節都是質量保證的關鍵點。

由於今天的時間關係，無論人還是質量上面，我都會挑選部分來說，如果大家感興趣所有的點，以後可以再挑時間來分享哈。

之前有很多文章討論過所謂的“全棧”，其實至少從現在來看，“全棧”真正的意義隨著時間的推移也開始浮出水面——快速學習的能力和驅動持續學習的興趣。

第二點其實想表述的就是如果我們走出測試來看質量的話，幾乎所有事情都不是單純的測試個體或團隊能夠完成的。我們需要走出那個“你提需求，別人實現”的時代，取而代之的是“你提需求，你牽頭來實現”。我們需要去利用合適的資源去做合適的事情，而不是什麼都自己來做。

在我參加的很多大會上都會有這樣的問題，一個團隊是否都應該是這樣一專多能，全棧的人。在我的理解裡，一個團隊中其實肯定不能沒有全棧的人，也不可能都是全棧的工程師。但這裡其實特別的去強調了“定位問題”。舉個例子來講，我們在平時測試的過程中發現了一個問題，我們需要有能力去判斷這個問題是前端還是後端的，如果是後端的，那麼通過各個系統日誌和呼叫關係需要去明白問題出在什麼系統上。如果是前端，那麼我們需要去發現是框架層的，還是組建層的，還是業務方等等。也就是說其實無論你是功能測試、自動化測試或者架構，定位問題都是通用的要求。

其實之所以要求測試能夠有定位問題的能力，本質就是為了提升整個專案流程的效率。因為當我們發現一個問題的時候，以前的方式是測試直接報一個bug。這個bug會描述清楚問題的上下文和現象。但其實開發還是需要去排查問題，然後再fix。也就是說排查問題這個過程是免不了的，而且往往測試並不知道這個問題是哪個開發的頭上，容易出現A踢皮球到B，B再踢給A的情況。所以在現在的測試行業中，大部分的公司索性就要求測試需要有定位問題的能力，這也是一項基礎的能力。

這點我特別的強調下，因為現在整個行業都在追求技術。我們在很多網站可以看到這裡很牛的hook技術，那邊有很牛的遍歷技術等等。但行業卻慢慢的弱化了測試原本需要有的技術能力。比如測試策略的制定，比如測試的方式，測試用例設計的方式等等。我很擔心再過10年，測試行業都是一群技術很牛卻不懂測試的人。就好像我已經聽到很多測試同學和我說，很多公司的測試總監不知道ab test 和灰度釋出有什麼區別，竟然認為兩個是一個東西。讓我也是很擔心測試行業的發展。

好了。以上我就挑了關於“人”這個方面的幾個點和大家闡述下。關於測試流程來講的話，其實測試本身還有很大的挖掘點。

3. 質量體系的建設

我給大家舉個例子：

其實網際網路發展到現在，測試大部分的技術，無論是自動化，還是動態AOP的hook等，其實我們想想，這些技術都是存在於“測試中”或者“測試執行”過程。但我們的流程中還有兩個很大的空缺。一個就是測試前，我們叫做測試準備，一個就是測試後，也就是我們的測試結束後。這兩個階段可以說是非常空白的。

測試準備這裡其實包括比如說“測試用例的自動生成”，“資料的自動化生成”。我相信很多人聽說過“MBT”，就是基於模型的測試，這就是一個比較成熟的case自動化生成的方式。

在移動網際網路中，BAT中一些公司會使用線上導流的方式，從而能夠直接回放線上使用者的行為，這樣既能夠自動的準備測試資料，也可以省下編寫自動化測試用例的時間。但這裡要注意的是和使用者相關的敏感資訊的脫敏。

而在測試結束，也就是我們的灰度以及我們釋出之後的話，那就是我們之後說的質量大盤的事情了。讓我們接著往下看吧。

由於時間關係，所以我就挑選幾個點來講。首先是自動化，這個可以說是測試比較注重的一塊。

UI自動化其實在幾年前，整個行業都還是在搭建自己的框架或者自動化團隊，包括積累很多的自動化用例。但經過這幾年發現基本上是不可行的。最大的原因就是UI自動化的ROI太低了。在現在這樣一個快速發展的移動網際網路下根本是沒有辦法可持續發展的。

那麼現在的大部分公司為了更好的支援hybrid（混合式應用）的模式，那麼選用了開源的Appium。當然這些公司並不會直接使用appium，而是拉出appium比較穩定的一個branch，然後自己來開發，並將appium根據自己的頁面封裝成適合自己的框架。

而UI自動化不在會是每次迭代都會去增加case了。也就是說會將那些很核心，不怎麼變化的流程編寫成我們的冒煙case和迴歸case。而在冒煙的時候，根據提交的程式碼屬於哪個bundle，然後會去呼叫對應的case，並不會每次打包都跑全量。同時regression的話也是一樣的，會有一套穩定的用例。這是基本上現在大部分公司選擇的方案。

而自動化中的API會要求比較高，比如API的程式碼覆蓋率，業務鏈路的覆蓋率，本次feature涉及到的API的數量的覆蓋率等等。這些資料會完完全全的去影響這個系統是否會發布。因為現在移動網際網路的app大部分的邏輯都會在後端，包括現在的hotfix都是依賴服務端的能力，所以對於後端的測試基本上會有一套完整的准入準出標準。但對於app前端就相對會弱點。

我們在App的專項測試中，自動化也會扮演非常重要的角色。如果對於專項測試不瞭解的朋友，我們以後可以專門開一個專項測試的課，專項測試可以講2個小時了。自動化在專項中的角色其實主要是為了獲取長時間的app效能資料。

比如說我們要獲取一個連續支付3000次，或者某個功能連續使用6小時下的耗電量。那麼這種情況我們就需要那種能夠脫離usb的自動化框架的支援，例如android的uiautomator。

所以總結下，UI自動化其實就是為了保證我們的核心功能是正確的，不會出現很大的regression的問題。我們不可能依賴UI自動化去提升質量。最多也就是保證核心的質量。

4. 測試技術還只是剛剛起步，將來是資料的天下

然後出現了這樣的一個問題。

我相信任何一個人面臨這個問題的時候，都是右邊的這個臉。我其實很想回答，臣妾做不到啊。

我們的測試人員是有限的，我們的測試環境也和線上環境不同。我們的測試機也不可能有線上使用者那麼多。你讓我說資料要一樣，我肯定說不一樣，但如果我說不一樣，那麼老闆肯定會想，我投入那麼多人力，資金等於沒有用啊。所以就會面臨兩難的境地。

所以就這個問題之後出現了“質量大盤”這個概念

我這裡大概的列了質量大盤的一個製作流程，這裡我無法和大家說細節了。大家如果有什麼問題私下可以諮詢我哈。

我說下質量大盤的目的：

1. 為了讓所有的人明白現在產品的質量，因為質量大盤上面是會根據一定的公式算出分數。這樣無論是不是技術人員都能夠一目瞭然這個產品每天的分數到底怎麼樣，以及長時間的趨勢是怎麼樣的。

2. 質量大盤會在每個樓層的辦公室裡public出來，這樣也會被動的讓那些PM，PD，Dev，Tester去知道自己和別人產品的分數。被動的可以push大家去提升自己負責模組的質量。

3. 能夠減少一定的測試工作。因為質量大盤的資料都是通過線上大資料總結得出的。更貼近使用者的痛點，這樣團隊能夠第一時間去著手解決使用者的痛點問題。而不是僅僅通過測試環境裡的資料。

這是我通過百度的echart做的模擬圖，基本上就是分成這樣兩塊。一個是每個模組，每個業務的分數（左邊的），一種就是總體的分數趨勢（右邊）。T+1會在質量大盤上顯示。

我們再來看下每個公司都會有的這個工具組的境地，基本上每個公司的工具組都會出現這樣的問題。做工具的這些同學其實也很苦惱。

之後改變成了，這個工具組會變成一個平臺建設組。這個平臺建設組就是輸出通用的sdk，資料的儲存以及前端的展現。至於每個BU自己的需求，每個BU 基於這個sdk和平臺的功能自己去封裝和實現。雖然我覺得這並不是一個最終的解決方案，但至少比之前的方案來的好，也更容易落地。

5. 從思想本質上改變對質量的認識

所以我們回到這個問題上來，我們怎麼很快的迭代下保證產品質量呢？

從本質上我們需要認清，無論是誰，無論什麼架構都不可能在移動網際網路下去保證產品的質量，這是絕對不可能的。我們只能保證產品核心和很重要的模組的質量，但不可能說我們保證產品的完整的質量。

從思想上，我們需要轉變的是，以前我們認為在專案流程中我們通過測試，通過bug bash，通過各種方式在上線前保證我們產品的質量。但現在我們需要轉變，我們需要利用線上，利用使用者，幫助我們一起去保證產品質量。我們不要擔心線上出問題。所以我們需要一套質量體系，當出現問題的時候，第一時間能夠預警，能夠hotfix，能夠動態的更新，能夠及時應對。這就是我們在移動網際網路下應該有的質量思維。

就如剛剛的這張圖。這裡所有都是質量體系的一部分。

這張圖是電影中的，很多人都知道吧。“楚門的世界”，其實測試就如同楚門，那麼多年都在測試這個圈子裡走來走去，就好像我一開始說的，關注UI自動化，功能測試，api測試，持續整合等等。其實本質上，關注這些根本無法從本質去保證質量，更不要說提升質量。所以我們只有跳出測試這個圈子，站在質量的這個角度，才能夠真正的看到更全面的東西。比如產品的架構，程式碼的規範，每個milestone的准入準出，怎麼灰度，怎麼利用大資料等等。這些都是測試需要關注的。也是每個關注質量的人應該關注的。

好了。由於時間關係，今天就是到這裡。其實很多擴充套件的，可以放在以後的課程哈。

謝謝大家！

問答環節

問：請問單元測試應該由誰來做，是自動化測試的重中之重嗎？

你好～單元測試從軟體測試的定義上來講是由Dev來做的，無論測試多麼的瞭解程式碼都不應該由測試來講。在以前微軟的流程中，有一種測試叫做bvt。也就是每個開發的模組如果要check in，需要程式碼跑過自己的bvt的單元測試，才能夠check in。

另外說比重的話，其實要看測試的物件。不同的物件比重不同。我舉個例子，如果是app，現在整個行業的UT的比例很低。但如果是中介軟體or sdk這種，單元測試可能比重會很高。

問（接上）：非常感謝回答，不好意思因為這個問題困擾很久了所以想再問的細一點。從微信還有手機管家的經驗來看，似乎在專案初期並不需要ut，往往要到很後期產品穩定才會做，但是大部分的產品又並不會走到後期，而主流的測試模型又很推崇ut，所以是不是有點矛盾？

並不是。其實這就是我說的測試策略本身。就好像我們說吃飯是對的，喝水也是對的。但如果一天你吃10頓，吃10升的水，你也受不了。所以說本身還是有一定的上下文。首先UT本身其實是為了保證模組，單獨模組或者幾個模組耦合度比較高的情況下的質量，也就是所謂的程式碼質量。這和產品穩定不穩定關係不大。之所以會有這樣的理論是因為在不穩定的時候，大部份的開發都在忙著重構或者寫功能，沒有空去寫UT，所以才會說等穩定之後去做。

測試模型推崇UT也是對的，因為測試偏重質量，質量本身，程式碼的check in就應該有開發的測試。我們叫做自測。那麼現在移動網際網路下，大部分的公司其實是沒有UT的，所以開發就會手工的去跑一些功能測試，以保證自己模組的質量。

所以說從本質上說，這兩者並不矛盾，只不過是怎麼做效率高，怎麼做真的能落地就會怎麼做。倒不是說理論or模型說一定這樣做就一定這樣做。

問：做了幾年測試，今天講師介紹的很多觀點都很認同。想問幾個問題：
1，線上導流方式 直接回放線上行為，有哪些實現的方式，能舉例介紹一下嗎？
2，質量大盤產品不同指標也不同，如何設計認為是能全面合理體現質量標準的呢？能舉個具體事例介紹一下嗎？如何具體真實的衡量一個產品的質量打多少分？業界哪個公司哪個專案在這方面做的很好能借鑑嗎？能介紹一下嗎？

關於第一個問題，我舉個例子。比如客戶端的h5的測試。那麼無論是灰度，還是線上。我們可以通過代理伺服器直接透傳的方式，記錄訪問的h5的連結，包括req，res data等。這些資料可以通過在客戶端的webview容器直接訪問的方式進行回放。當然這個過程中細節很多，可以用的框架比如anyproxy。

第二個問題，我舉個實際的例子。比如說每個介面開啟的響應時間，那麼我們根據每個介面的PV，UV來定每個介面的權重，我們再根據不同的網路狀態，不同的手機下去定不同的公式來做計算。當然這個公式是需要大家討論的，比如Dev，Tester，PD都需要一起討論。然後最終定出來一個公式，會放入大資料的計算中間。

問：移動端的相容性自動化測試老師有好的方法成熟的案例介紹嗎？

相容性的自動化有的。如果是你是需要自己公司去搭建 ，那麼現在github最好用的就是“STF”，在TesterHome上面你可以找到我寫的二次開發“STF”框架的文章，還是很詳細的。如果你需要用第三方的話，那麼目前已有的幾個平臺也都是ok的。

問：如果是老師會怎麼去衡量一個測試人員的價值？或者怎麼去看一個工具的roi？

這個是招聘的要求，其實主要是在經驗，技術還可以的情況下，接下來就是看問題的高度和大局觀。然後說我們怎麼衡量一個人的價值。basic的話其實就是活幹的怎麼樣，其實不一定是發現了多少bug。現在行業中也有EP團隊，工程效率團隊。也就是說，只要提升了效率，就是有產出的，就是有價值的，這個提升可以是流程任何一個環節。

當然還有一點就是需要有感染力，需要帶動測試團隊，開發團隊。樂於分享，追前沿的技術，包括樂於助人等等。這些都是價值考量的一部分

所以基本上是這樣三大類。

工具的ROI，其實就是比較好評估。比如說這個工具能節省多少的人力。現在很大的情況下是用了工具，人力還是要保證一遍。這樣等於0。所以就工具而言，一個是改造需要的投入，一個就是真正提升的效率有多少。包括維護成本多少。基本上是這樣幾個維度。