移动测试人员的未来:测试开发技术的融合
作者:陳曄 螞蟻金服測試主管
首先說明,測試包括很多領(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)容,希望文章能夠幫你解決所遇到的問題。
- 上一篇: 游戏无法启动解决方案(VC环境问题无法启
- 下一篇: xenapp6.5上安装完smartau