移動測試人員的未來：測試開發技術的融合

首先說明，測試包括很多領域，這次談測試的未來，我只談移動互聯網測試的未來。這些年我和很多公司的同學都做過交流，經過了長時間的交流，基本上對現狀有一個清楚的了解，這里就大膽的對未來進行一個預測。

另外我還想說，測試行業還是一個不成熟的行業，學術界和工業界都存在著大量看不清客觀事實的人，同樣的也存在大量的扯淡的人，本篇文章希望大家都能夠認清楚現在的局勢，以便更好的認清方向去學習，從而將行業整體推向一個正確的道路上。

過去：從極易到極難

要預測未來，我們首先必須對過去和現狀有一個清晰的了解，所以，下面首先介紹一下移動測試過去是什么樣的。

我自己是從09年底開始接觸Android無線應用的功能測試，那么就從那個時間開始說起吧。

09年到11年底屬于移動互聯網測試在中國的第一個階段，那個階段幾乎網絡上除了Android、iOS的官方文檔，不存在其它任何相關的測試技術博客或者文檔，這對當初接觸這個行業的我們是一個非常大的挑戰。

對于一個未知的領域，為了保證產品質量，測試必然是從功能方面切入進行。不過好在那個時期的App大多都是純Native的邏輯，并不像現在那么的復雜。但由于開發整體技術的不成熟以及硬件上不充分的支持，我們最常見的其實就是OOM（Out Of Memory），那個時期真的算是習以為常了。

09年到11年的時候，整個行業的大部分互聯網公司都感覺到了移動互聯網的到來，這個時候，很多大企業也覺得應該開始儲備移動團隊和技術基礎了，所以開始大范圍招人。

初創企業招入的測試肯定是One Man One Team，一個人就相當于一個團隊，而大公司的話，會將自己公司內以往做服務端測試，或者Web測試經驗豐富的人，拉過來做移動測試團隊的leader，然后開始招兵買馬。

但無論是哪一類公司，測試工作肯定集中在功能測試用例的設計、執行測試用例上，而且非常的累。所以當時如果你會或者說掌握Android Monkey測試以及iOS的Monkey測試的話，那么已經是神一樣的人物了，很多公司會爭先恐后的搶著要的。（這里我不得不提一句，我面試了那么多的人，大部分人就是知道基礎的命令，也不知道Monkey執行的策略包括實現，這些人就不要說掌握或者熟練了。）

在移動互聯網早期，功能測試就被放在了一個很低的位置，直到現在依然沒有什么一個很好的改觀。

然后過了快2年，各個公司發現，移動互聯網不如自己設想中的賺錢，反而燒錢很快。于是11年下半年部分公司就開始裁員了，而首當其沖的就是測試工程師。在這個階段中，幾乎所有公司都不知道自己要招什么樣的人，JD（崗位描述）都會很模糊，會寫上要移動互聯網測試經驗，但不知道具體要什么經驗。整整2年就處于這樣一個階段，我稱之為移動測試第一階段。

接著12年開始到13年底基本上又是兩年，進入了第二階段。

這個階段，移動互聯網的項目迭代周期也基本定型了，1～2月內一次大迭代，小版本可能每天都有。此時的公司對移動測試的要求也開始具體化——當然，中國是一個跟風嚴重的國家，比如當初BAT或者各個大公司寫出來具體的測試JD，行業的其它公司紛紛開始抄襲，所以這階段的移動測試的要求基本是從 BAT和大公司出來的。

12年開始，行業對測試人員的招聘要求來了一個180度的轉變，Robotium，Monkey，Monkeyrunner，Instrumentation，Objective-C，Java，Python等各種詳細的要求接踵而來，整個12年的面試會給測試人員一個感覺———面試測試崗位比面試一個CTO崗位都要累。記得某些公司在面試測試人員之前，首先先要筆試，做各種卷子，包括軟件工程，測試，算法，代碼，智力題等，從我看來簡直變態的可以。

另一方面，移動互聯網的產品本身從Native開始慢慢的轉變成部分Native，部分WebView。Native主要用來實現一些類似于設置、本地界面框架的功能，而WebView更多的會做一些活動界面、廣告投放的功能。之后Hybrid混合式應用就變成了移動互聯網應用的主流實現方式。測試工作也從以往的純功能性測試，增加到現在的自動化測試、持續集成、碎片化測試等等。移動測試的技術在這段時間也得到了非常大的進步和提升。

其實在這兩年里，還有一個事情讓所有人都感覺到非常大的變化，那就是開源的測試技術越來越多。現在很多剛進入移動互聯網的測試人會發現單是UI自動化測試就會有幾十個框架，根本就不知道選什么。

現狀：業務與工具無法兼得

最近的一年又有了什么變化呢？

從我了解的情況看，各個公司的關注點慢慢從功能測試轉到專項測試，又從以往單純去做UI自動化框架的開發發展到了測試平臺化，發展到了線上監控。

前幾年，行業大部分公司都在大量招聘業務測試人員，以及所謂的自動化測試工程師。在某些大公司里，整個測試團隊分成兩部分—————業務團隊和工具團隊（這里不得不吐槽，其實實際情況是工具組的大部分所謂的測試開發工程師其實就是開發，并沒有太多測試的積累）。從2011年開始，百度等公司就開始陸續這樣去分團隊工作，幾年下來的確有著不錯的積累，比如各個公司屬于自己的框架和平臺都搭建起來了，但這樣的分工就如雙刃劍，讓我來和大家說下另外一面吧。

第一點相信很多人心里也都知道，也就是兩個組總是不能非常融洽的合作，總有互相的抱怨。所謂一個巴掌拍不響，雙方都存在問題：

• 業務方的同學抱怨工具組做的工具不落地，不能觸及到業務功能測試的痛點
• 工具方的同學不停的輸出工具，更多的從架構層代碼層去改進工具，卻忽略了業務的實際真正的用途
• 業務方和工具方的同學互相不服對方，這點很實際。業務同學大多拼體力，工具方大多拼技術，兩者薪資會有一定的差別，公司的重視程度也會有一定的差異，這其中不見得一定哪方好哪方不好，得看公司。
• 工具組的同學難過的一點就是他們大多并沒有自己實際的KPI，更多的是看多少能在業務方落地，也就是說KPI其實是依附于業務方，那么合作就變的尤其重要，但從上面的現狀我們看得出來這并非易事。

第二點可能很多人就未必知道了。在移動互聯網，工具組的同學無非做兩樣東西————二次開發自動化測試框架和測試平臺（兼容性，自動化，監控等）。先說框架這個東西，如果僅僅是API層面的框架，那么的確能夠長期有效的使用下去。但移動互聯網中工具組大多做的是什么類型的框架呢？你猜對了，正是UIAutomation Framework，過程很黃很暴力，我就不多說了，我們來說結果吧。結果就是大多數業務方用著也不是很爽，所以不停的給工具組提需求，而工具組服務的不止一個業務方，為了KPI只能不停的去接需求，加班修改，最后不僅沒有滿足業務方，工具組團隊先跪了，原因是需求根本來不及滿足，Bug也根本就修不完，不停的惡性循環。

所以說，經過這段時間之后，行業里的公司在功能測試上基本都有了一定的積累，然后開始關注應用的性能，因為性能直接關系到用戶體驗。

同時，行業也意識到功能測試和自動化應該是測試人員的基本能力，而不是一個加分項。

所以到了14年，其實很少看到再有公司要招單純的自動化測試工程師了，就算有，招入進去的也會承擔更多的職責。雖然我很難確認這到底是不是一個進步，但是國內測試行業之前一直很混亂，伸手黨橫行，大多數人屬于自己根本不能自理的狀態，所以從這個角度來看，整個行業的技術能力要求提升，算是一個非常不錯的趨勢了。關于測試行業到底有哪一些搗亂的人，可以移步 測試行業感謝有你 。

行業現狀也能說明這種情況，我能夠透露的是，螞蟻金服從title上面來講的話，已經不存在“測試工程師”了，全部是“測試開發工程師”，這其實隱約的在暗示點了什么。今年我去了360、百度、JD、OneAPM等公司，同時也和手Q、趕集等同學有了深入的交流。交流下來來看，大家也都隱約的有一種轉型。

未來：找出問題還不夠，要定位問題

了解了移動測試的過去和現狀，現在可以大膽的預測未來了，不過，這里也僅僅是未來三年內的情況。

首先，測試人員肯定是朝著全棧的方向去發展了，這點毫無疑問。而功能（業務）測試，專項測試，自動化測試等都會變成一個測試人員基本的能力，而非加分項。

而隨著網商的發展，各類互聯網＋金融的崛起，移動安全的測試將會變成專項測試之后的一個新的關注點。

有些人可能會擔心隨著第三方測試服務流行，測試工程師的前途在哪，我想說，測試這個崗位和測試這個工作在移動互聯網不會消亡，但綜合能力的要求提升很多，將來不會再有單純的業務測試，也不會再有單純的自動化測試，以后測試將全部是測試開發工程師，這些人可以快速的去適應各種需求，并且能夠通過業務和技術的雙向分析從而定位真正所在的問題。

測試人員自我能力的提升，也不再是單純的某一方面技術，而是這些技術如何真正的落地，以及怎么結合自己的業務，以及產品的實現框架去排查和定位問題，最終解決問題或者優化產品性能。

與此同時，開發工程師也會慢慢的被要求承擔一部分測試工作（產品自測），不僅能讓開發工程師更深入的了解業務，而且本來我們就需要自己去吃自己的狗食（Dog Food）。

舉個例子，隨著React Native和Html5的發展，很多公司為了滿足應用的需求，會開發私有的RCT和WebView容器。同時，很多業務復雜的公司的客戶端，背后對接的不僅僅是一個服務，更多的是服務群。那么這個時候問題就出現了：

我們發現了一個客戶端很卡，或者有某些安全的風險，那么，我們首先需要去從業務角度分析，可能是哪些業務鏈路上出現問題，接著我們需要去將被測產品拆開，一個一個排查和定位問題。比如

• Native Activity View啟動消耗
• RCT轉換到Natvie控件的消耗
• WebView自定義容器的消耗
• Html中的CSS，JS，PNG等流量和時間的消耗
• Native業務代碼調用RPC，http請求的方法的消耗
• 本地請求到得到返回的時間消耗
• 數據交互的Json結構是否復雜，json解析的消耗
• 本地業務邏輯是否編寫恰當
• 客戶端在智能機上的界面繪制的消耗
• 整個架構View是否存在重復繪制
• 服務群中互相交互以及透傳的邏輯是否恰當
• 服務群中的系統超時機制是否恰當
• 服務群中每個系統的消耗

我們會發現，其實我們并不能一下子就能夠找到問題在什么地方，而是需要對業務和被測應用技術了解的情況下，去慢慢排除哪些地方沒有問題，從而最終定位問題所在。此時的你光有技術，或者你光懂業務，都無法去完成這樣一個工作。測試人員很大的一部分價值會體現在這個地方。

也許看到這里，很多測試同學就要跳起來了，覺得要求怎么那么高，感覺就在扯淡，肯定不是這樣。我想說的是：

第一，目前測試圈很多人以為自己的圈子就是這個行業的全部，但其實測試的內涵比他們想象的要大的多。

第二，很多人被培訓忽悠（什么自稱xxx培訓第一），覺得單純的學習技術就可以提升價值，你們自己想想看，測試真的只是一個純技術崗位嗎？

第三，國內測試原本長時間存活在低要求環境中，導致很多人已經不知道正常的要求是什么了，當行業開始以正確的標準來要求的時候，就感覺無法接受。

大家只要拋棄成見，自然知道誰對誰錯，也會知道應該怎么去面對未來，只要勇于承認，并且快速學習，未來的測試仍然有你的一席之地。

說到這里，很多測試管理者可能會問，管理者的出路在何方。

其實對于管理者而言，現在應該已經有所感受了，就是純管理角色在移動互聯網很難存活下去。原因有兩個，其一，測試本身的技術定位要求，以及技術的更新速度會倒逼著管理者需要有一定的技術基礎，包括對一些新技術有一定的了解，否則如何將合適的人安排在合適的位置上呢？又如何去服眾呢？其二，未來的轉變不僅僅是測試技術和業務的融合，更多的是就業人員從85后轉變成了90后以及95后。以往很多管理者覺得給員工一些錢，一些股票，這些員工就會默默無聞的為公司賣命，為項目去加班。但是隨著時代的發展，現在很多的年輕人看重事情變成：工作是否開心以及是否對自己有提升。他們不是不在乎錢，但他們會變的更有自己的想法和追求。面臨這樣一群人，管理者本身的管理方式也需要有一定的改變，同時需要從公司的流程，業務發展，個人規劃，技術發展等各個角度去給出一些引導。

差不多以上就是我想表達的觀點了，也許很多人已經看到了變化，也許很多人沒有，但是無論如何，變化總在快速的，不以任何人的意志而轉移的進行下去。最后，如何想了解更多移動測試發展的話，可以關注我寫的書《大話移動App測試2.0——技術篇》，會在明年上半年出版，這會是全新的一本書。粗略的目錄可見： 大話移動App測試2.0目錄 。其中我也會將這次我全程參與錢包9.0研發過程中的一些經歷和技術寫在里面。