移動互聯網測試到質量的轉變

導語：

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

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。所以就工具而言，一個是改造需要的投入，一個就是真正提升的效率有多少。包括維護成本多少。基本上是這樣幾個維度。

 

 

 

來自：http://mp.weixin.qq.com/s?__biz=MzAxMzYyNDkyNA==&mid=2651332554&idx=1&sn=0e8920c4abb1ebdc580ef6cce96e6bb9&chksm=80630cf9b71485ef4de253a4c43d2de101014e8eaaad45b54dcdc99ebdbc34e3167d4797dcd7&scene=4#wechat_redirect