作者：陳曄 螞蟻金服測試主管

首先說明，測試包括很多領(lǐng)域，這次談測試的未來，我只談移動互聯(lián)網(wǎng)測試的未來。這些年我和很多公司的同學(xué)都做過交流，經(jīng)過了長時(shí)間的交流，基本上對現(xiàn)狀有一個(gè)清楚的了解，這里就大膽的對未來進(jìn)行一個(gè)預(yù)測。

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

過去：從極易到極難

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

我自己是從09年底開始接觸Android無線應(yīng)用的功能測試，那么就從那個(gè)時(shí)間開始說起吧。

09年到11年底屬于移動互聯(lián)網(wǎng)測試在中國的第一個(gè)階段，那個(gè)階段幾乎網(wǎng)絡(luò)上除了Android、iOS的官方文檔，不存在其它任何相關(guān)的測試技術(shù)博客或者文檔，這對當(dāng)初接觸這個(gè)行業(yè)的我們是一個(gè)非常大的挑戰(zhàn)。

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

09年到11年的時(shí)候，整個(gè)行業(yè)的大部分互聯(lián)網(wǎng)公司都感覺到了移動互聯(lián)網(wǎng)的到來，這個(gè)時(shí)候，很多大企業(yè)也覺得應(yīng)該開始儲備移動團(tuán)隊(duì)和技術(shù)基礎(chǔ)了，所以開始大范圍招人。

初創(chuàng)企業(yè)招入的測試肯定是One Man One Team，一個(gè)人就相當(dāng)于一個(gè)團(tuán)隊(duì)，而大公司的話，會將自己公司內(nèi)以往做服務(wù)端測試，或者Web測試經(jīng)驗(yàn)豐富的人，拉過來做移動測試團(tuán)隊(duì)的leader，然后開始招兵買馬。

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

在移動互聯(lián)網(wǎng)早期，功能測試就被放在了一個(gè)很低的位置，直到現(xiàn)在依然沒有什么一個(gè)很好的改觀。

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

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

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

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

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

其實(shí)在這兩年里，還有一個(gè)事情讓所有人都感覺到非常大的變化，那就是開源的測試技術(shù)越來越多。現(xiàn)在很多剛進(jìn)入移動互聯(lián)網(wǎng)的測試人會發(fā)現(xiàn)單是UI自動化測試就會有幾十個(gè)框架，根本就不知道選什么。

現(xiàn)狀：業(yè)務(wù)與工具無法兼得

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

從我了解的情況看，各個(gè)公司的關(guān)注點(diǎn)慢慢從功能測試轉(zhuǎn)到專項(xiàng)測試，又從以往單純?nèi)プ鯱I自動化框架的開發(fā)發(fā)展到了測試平臺化，發(fā)展到了線上監(jiān)控。

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

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

? 業(yè)務(wù)方的同學(xué)抱怨工具組做的工具不落地，不能觸及到業(yè)務(wù)功能測試的痛點(diǎn)

? 工具方的同學(xué)不停的輸出工具，更多的從架構(gòu)層代碼層去改進(jìn)工具，卻忽略了業(yè)務(wù)的實(shí)際真正的用途

? 業(yè)務(wù)方和工具方的同學(xué)互相不服對方，這點(diǎn)很實(shí)際。業(yè)務(wù)同學(xué)大多拼體力，工具方大多拼技術(shù)，兩者薪資會有一定的差別，公司的重視程度也會有一定的差異，這其中不見得一定哪方好哪方不好，得看公司。

? 工具組的同學(xué)難過的一點(diǎn)就是他們大多并沒有自己實(shí)際的KPI，更多的是看多少能在業(yè)務(wù)方落地，也就是說KPI其實(shí)是依附于業(yè)務(wù)方，那么合作就變的尤其重要，但從上面的現(xiàn)狀我們看得出來這并非易事。

第二點(diǎn)可能很多人就未必知道了。在移動互聯(lián)網(wǎng)，工具組的同學(xué)無非做兩樣?xùn)|西————二次開發(fā)自動化測試框架和測試平臺（兼容性，自動化，監(jiān)控等）。

先說框架這個(gè)東西，如果僅僅是API層面的框架，那么的確能夠長期有效的使用下去。但移動互聯(lián)網(wǎng)中工具組大多做的是什么類型的框架呢？你猜對了，正是UIAutomation Framework，過程很黃很暴力，我就不多說了，我們來說結(jié)果吧。結(jié)果就是大多數(shù)業(yè)務(wù)方用著也不是很爽，所以不停的給工具組提需求，而工具組服務(wù)的不止一個(gè)業(yè)務(wù)方，為了KPI只能不停的去接需求，加班修改，最后不僅沒有滿足業(yè)務(wù)方，工具組團(tuán)隊(duì)先跪了，原因是需求根本來不及滿足，Bug也根本就修不完，不停的惡性循環(huán)。
所以說，經(jīng)過這段時(shí)間之后，行業(yè)里的公司在功能測試上基本都有了一定的積累，然后開始關(guān)注應(yīng)用的性能，因?yàn)樾阅苤苯雨P(guān)系到用戶體驗(yàn)。
同時(shí)，行業(yè)也意識到功能測試和自動化應(yīng)該是測試人員的基本能力，而不是一個(gè)加分項(xiàng)。

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

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

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

了解了移動測試的過去和現(xiàn)狀，現(xiàn)在可以大膽的預(yù)測未來了，不過，這里也僅僅是未來三年內(nèi)的情況。

首先，測試人員肯定是朝著全棧的方向去發(fā)展了，這點(diǎn)毫無疑問。而功能（業(yè)務(wù)）測試，專項(xiàng)測試，自動化測試等都會變成一個(gè)測試人員基本的能力，而非加分項(xiàng)。

而隨著網(wǎng)商的發(fā)展，各類互聯(lián)網(wǎng)＋金融的崛起，移動安全的測試將會變成專項(xiàng)測試之后的一個(gè)新的關(guān)注點(diǎn)。

有些人可能會擔(dān)心隨著第三方測試服務(wù)流行，測試工程師的前途在哪，我想說，測試這個(gè)崗位和測試這個(gè)工作在移動互聯(lián)網(wǎng)不會消亡，但綜合能力的要求提升很多，將來不會再有單純的業(yè)務(wù)測試，也不會再有單純的自動化測試，以后測試將全部是測試開發(fā)工程師，這些人可以快速的去適應(yīng)各種需求，并且能夠通過業(yè)務(wù)和技術(shù)的雙向分析從而定位真正所在的問題。
測試人員自我能力的提升，也不再是單純的某一方面技術(shù)，而是這些技術(shù)如何真正的落地，以及怎么結(jié)合自己的業(yè)務(wù)，以及產(chǎn)品的實(shí)現(xiàn)框架去排查和定位問題，最終解決問題或者優(yōu)化產(chǎn)品性能。

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

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

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

? Native Activity View啟動消耗
? RCT轉(zhuǎn)換到Natvie控件的消耗
? WebView自定義容器的消耗
? Html中的CSS，JS，PNG等流量和時(shí)間的消耗
? Native業(yè)務(wù)代碼調(diào)用RPC，http請求的方法的消耗
? 本地請求到得到返回的時(shí)間消耗
? 數(shù)據(jù)交互的Json結(jié)構(gòu)是否復(fù)雜，json解析的消耗
? 本地業(yè)務(wù)邏輯是否編寫恰當(dāng)
? 客戶端在智能機(jī)上的界面繪制的消耗
? 整個(gè)架構(gòu)View是否存在重復(fù)繪制
? 服務(wù)群中互相交互以及透傳的邏輯是否恰當(dāng)
? 服務(wù)群中的系統(tǒng)超時(shí)機(jī)制是否恰當(dāng)
? 服務(wù)群中每個(gè)系統(tǒng)的消耗

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

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

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

第二，很多人被培訓(xùn)忽悠（什么自稱xxx培訓(xùn)第一），覺得單純的學(xué)習(xí)技術(shù)就可以提升價(jià)值，你們自己想想看，測試真的只是一個(gè)純技術(shù)崗位嗎？

第三，國內(nèi)測試原本長時(shí)間存活在低要求環(huán)境中，導(dǎo)致很多人已經(jīng)不知道正常的要求是什么了，當(dāng)行業(yè)開始以正確的標(biāo)準(zhǔn)來要求的時(shí)候，就感覺無法接受。

大家只要拋棄成見，自然知道誰對誰錯(cuò)，也會知道應(yīng)該怎么去面對未來，只要勇于承認(rèn)，并且快速學(xué)習(xí)，未來的測試仍然有你的一席之地。
說到這里，很多測試管理者可能會問，管理者的出路在何方。

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

差不多以上就是我想表達(dá)的觀點(diǎn)了，也許很多人已經(jīng)看到了變化，也許很多人沒有，但是無論如何，變化總在快速的，不以任何人的意志而轉(zhuǎn)移的進(jìn)行下去。

總結(jié)

以上是生活随笔為你收集整理的移动测试人员的未来：测试开发技术的融合的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。