三年自動化測試經驗分享
來自專欄 自動化測試
微軟外包自動化測試兩年,而後轉入互聯網公司做移動端自動化測試一年,經歷了入行時的迷茫,而後的篤定,轉入移動後對自身定位和價值的懷疑,繼而對自動化測試的重新認識,職場三年,終於敢對自動化測試有所論述了。
先說說測試吧,測試本身有其自己的價值嗎?我覺著這個得看公司對自身的定位,倘若公司本身定位就是一個小作坊,出一款產品就打算小撈一筆,受眾較小,那測試真就是累贅,對於測試的投入是毫無道理可言的,但如果公司打算長久規劃,想樹立自己的品牌價值,那麼還是一開始就儘可能的投入吧,畢竟口碑這種東西,失去了一次,想要挽回來那可不是陣痛那麼簡單,想想xxxxx,紅會,還有那麼多那啥的中國產業和企業吧,在今天技術無法形成壁壘,產品同質化嚴重,競爭日益激烈的大環境下,國內環境越來越重視測試是明智的。測試毫無技術含量嗎?就我從業這幾年,聽到過無數這樣的論述,搞技術的看不起搞測試的,這裡我不想反駁什麼,我只想說說就我來看一個出色的測試人員所具備的素質:測試人員是塊磚,哪裡需要哪裡搬,幾乎所有的測試框架都只是提供一個通用底層的解(更傾向於叫這種自動化測試框架叫自動化測試技術),自動化測試人員需要有架構方面的知識去根據自身產品特點,組織代碼結構形成自己的框架;針對一個平台的測試會有多種框架可選,測試也需要兼顧性能方面的考慮,這一切都需要你去學習掌握不同的語言,或者不同種類的語言及配套的一系列平台框架內的知識;
自動化測試工作中仍需要開發及擴展一些工具,各種類型的工具去滿足自動化測試的需求,所以網頁開發,桌面程序開發,移動端開發這些是必會的;自動化測試有時也需要去讀產品代碼去分析問題,定位問題,快速理解所有產品代碼邏輯是必須的;測試人員不只要關注產品bug,產品體驗也是工作很重要的一部分,所以一個好的測試人員可以看成半個產品;測試本身的職業特點要求測試人員溝通技巧要像銷售一樣剛剛的(這點我做的不是很好);測試對工作流程,項目進度掌控,團隊配合等管理技巧不必其他團隊差;雖然各個方面都不算是最專業的,但測試需要的是全才,全才也算人才的一種。測試對於軟體開發的上游來講,是你們前進的鞭策而不是你們成功的障礙,通過一個個bug,你才能認識到自己的不足啊,孩子!收起你那可笑的傲慢吧,你們的代碼我見過,而我們的代碼你們並沒機會見到。這時候一般我會強調一句話:將代碼寫得優雅是每個工程師的義務。給微軟做外包兩年,除了學習了一堆微軟測試技術及通過內部資源了解的其他東西外,最主要的印象在於其軟體測試這麼多年積累起來的流程規範,對於測試來講,強與不強永遠不會體現在技術積累上,更多體現在流程管理,許可權管理,文檔(代碼也在文檔範疇)規範上。微軟產品較為封閉,版本迭代較慢,UI等風格也較為統一,其測試可以減少cost最大的點在於增加測試用例,文檔的復用,他在測試管理上所有的細節也在儘可能的增加復用,WTT,PS等測試平台軟體的設計上這點非常突出,在其管理模式上也很有很大的體現,這就是微軟的測試取得成功的重要原因。
來到移動互聯網後,剛開始也一直沿著這種思路在做,大家的重心仍然放在增加復用,做了一整套測試用例執行平台以增加用例復用,對各種測試框架擴展以增加代碼復用,想盡一起辦法實現代碼錄製以減少代碼編寫,這一切的一切貌似總趕不上版本更新的速度,自動化測試總是測試中最拖後腿的一環,所以一段時間內對自動化測試定位產生了嚴重的懷疑,沒有存在感。其實仔細想想,這一切並沒有錯,那究竟問題在哪呢?產品!移動互聯網的發展速度太快了,其產品更新也快,尤其是新產品,版本之間UI變化特別大,基於UI的自動化測試在有限的cost下很難跟上這種速度,你大部分的測試代碼只有執行一次的命運,無法迭代復用,有這時間手動就點完了,包括代碼錄製,就目前來講,極端的說對於Android這種開放性特彆強的系統來說一切的代碼錄製都是耍流氓,你錄製一次出來的代碼很難達到其他設備上不經修改就可以回放,基於UI的自動化測試驅動UI操作從來都不是難點,難點在於各種對結果的Verify,錄製完逐行去添加這些東西簡直是噩夢,而且就目前的代碼錄製實現手段來講,限制性太多,想要達到別說完美就是能滿足測試百分之五十的需求都很難,花大量時間和精力去弄這個是很不明智的。
那麼自動化測試的出路在哪?應該是輔助手動測試,自動化測試終極目的在於增加復用,減少重複性動作,其cost相對於手動測試來講是巨大的,所以有限的人力應該去投入到更有效的地方去,測試人員都知道一句話,全覆蓋的測試是不存在的,所謂測試就是拿有限的cost去儘可能覆蓋更多的測試點,其注重於投入產出。回過來講自動化測試,在移動端它的價值更多體現在性能監控,非必現bug復現,適配測試,健壯性測試等復用較多的點,舉個健壯性測試的例子,涉及到圖片操作分享的應用都會關注在重複發送及接收大量圖片的時候,這對手動測試簡直是噩夢,交給自動化測試,或調取伺服器介面,或客戶端ui自動化這很容易解決,而且自動化測試還有個很大的好處,不需要佔用太多的資源,手動提出相關需求後,白天寫代碼,晚上或者節假日把手機借過來跑case,第二天直接拿報告,這簡直是完美的配合。我想這也是自動化測試在移動端的出路吧。推薦閱讀:
※核心實驗:Selenium IDE->測試Agileone的公告管理
※工具應用:Robot Framework-安裝配置與基礎使用
※Selenium Grid 兼容性測試(Python版)
※Xebium詳解07-操作DB
※matplotlib繪圖和可視化