十年測試經驗悟出的測試心得

壹佰案例發表於2016-06-03

enter image description here 許奔,聯想集團研發主管工程師,資深自動化測試工程師,《深入瞭解Android自動化測試》作者。曾帶領聯想手機單元測試團隊、聯想手機自動化測試團隊為公司開發出多款實用的Android自動化測試工具。同時,他還是聯想集團年度發明人,MBG專利大師。

論壇「罵戰」讓我快速提升測試技能

做黑盒/功能測試的同學總想嘗試一下自動化測試或單元測試,或者說,自動化測試或單元測試對於從事軟體測試的童鞋而言具有一種不可名狀的吸引力。 多年後,有的同學已經成功跨過這道坎進入到自動化測試或單元測試領域,但大多數同學仍在觀望著,繼續抱著那種期待和恐懼——期待自動化測試或單元測試的魔力,恐懼於他們對技術上的要求。

作為一隻從事軟體自動化測試和單元測試將近10年的老鳥,我是如何一步步踏上這條路的?十年一回頭,對我而言,從事軟體自動化測試和單元測試最重要的技能又是什麼呢?

十年前,作為一名毫無程式設計經驗的初學者,抱著一本Paul C.Jorgensen的《軟體測試》,無所畏懼地踏上這條路。當時負責一個Windows平臺的財務系統專案測試,由於公司經費有限,每個專案只有一名測試,自己寫測試用例,自己測試,自己出測試報告,自己報bug,沒有人管你是如何測試,甚至沒人審查你的用例,專案經理只看bug,以及最後客戶是否滿意。

為了減少自己的工作量,開始逛測試論壇,開始知道有QTP這麼個玩意兒,可以錄製回放,如果稍微引數化一下,可以大大減少測試錄入的工作量——就這樣,懵懵懂懂地開始了第一款自動化軟體的學習和使用。

隨著對QTP越來越深入的瞭解,隨著指令碼錄製/回放過程中諸多不滿意,開始自己試著修改指令碼,當時的指令碼應該是VBScript指令碼,然後試著描述性程式設計,學了一些必須掌握的語法,開始自己寫更為穩定的指令碼——畢竟是為了自己用起來方便,而不是為了秀demo,所以一切以實用為目的。就這樣做了一兩年,這期間由於對VBScript的熟練,順便學習了C#和Java的基礎知識,發現都不是很難,也更便於自己發現研發的bug。

除此之外就是,在論壇上掀起很多「罵戰」,一方面是自己出來嘚瑟的帖子被人罵,一方面是去罵其他出來嘚瑟的帖子——這種「罵戰」的好處就是,可以快速發現自己知識和實踐中的不足和錯漏,還可以結識到相關技術的大牛。記得當時和我「對罵」最厲害的一位QTP大牛,為了證明他的確比我牛,把他總結的《QTP難點及解答》發給我,這篇長達數十頁的word文件讓我在QTP自動化測試的疑難雜症面前攻無不克,還幫助他順利進入夢想中的HP,繼續鑽研QTP,當然,這是後話。

現在很多童鞋問我,學習自動化,我該看什麼書?我該從哪開始?我該問誰?我的回答是:找個當下就能幫你減輕負擔的工具,從這裡開始,玩轉它,併到論壇上去分享,去掀起「罵戰」,讓自己快速提升。

最基礎的指令碼為什麼是「大牛」來寫

兩年後,專案結束,我跳槽到一個外包公司,將我外包到微軟嵌入式團隊,做「嵌入式自動化測試」。這裡所謂的「嵌入式自動化測試」,是指在只安裝Windows core以及某個元件(component)的基礎上對其進行自動化測試。比如自動取款機就是Windows core+IE結構。

要知道,如此簡化的系統是執行不起QTP這樣的工具的,因為沒有.net framework,也執行不起市面上大部分成熟的自動化框架或工具,只能通過最原始的命令列執行。所以當時我們寫的都是批處理(batch)和Javascript指令碼,然後通過微軟的WTT,將指令碼和測試資源匯入到測試機後通過命令列執行指令碼。

在此之前我通過批處理寫過一些簡單的批量執行或檔案檢查的指令碼,但在這裡,需要通過批處理寫出大量複雜的、相互呼叫的指令碼,這讓我對批處理刮目相看,也逼著自己把指令碼管理和指令碼聯調的能力修煉得更好。

但我認為,這個階段真正學到的,並不是指令碼管理和聯調能力,而是什麼人應該編寫最基礎的指令碼。為什麼這樣說?

我剛進公司最困惑的一件事是:IE所有最簡單的開啟、關閉,以及最基本的每個下拉選單的開啟,這類最最基礎的指令碼,居然是由美國一位大牛負責。而作為菜鳥的我,卻需要編寫非常複雜的指令碼,比如:開啟IE後在位址列輸入某個連結,確認跳轉後截圖對比,然後將該連結儲存收藏夾,將IE關閉後再開啟,去收藏夾確認該連結已被成功儲存。

我非常鬱悶和不服,因為在國內,都是菜鳥寫最簡單和最基礎的指令碼,越牛的人寫的指令碼越複雜,為什麼在外企反而倒過來——牛人寫簡單指令碼,每天喝咖啡游泳曬太陽。菜鳥寫複雜指令碼,每天苦逼累個半死。這還有天理嗎?還有王法嗎?

結果我領導反問我一句話:你那條複雜指令碼有多少人呼叫?如果出了問題需要緊急停止會造成多大的損失?換句話說,你需要承擔多大的責任?我想了想道:好像就我自己呼叫,如果緊急停止不會造成太大損失…我領導繼續問:那他那條基礎指令碼有多少人呼叫?出了問題會造成多大損失?我徹底反應過來:他那條指令碼全世界不知道多少人在呼叫,出了問題那還真是蝴蝶效應,估計直接受影響的用例就高達幾千條!

這件事一直影響我到現在,最基礎的指令碼誰來負責?值得大家反思。

自動化測試最重要的技能是什麼

從移動網際網路大潮興起一直到現在,我一直做著Android自動化測試。關於Android的各款測試工具,從被我稱之為「小李飛刀」的monkey,到具備錄製回放能力的monkeyrunner,再到自動化「屠龍刀」Instrumentation和「倚天劍」UIAutomator,還有那把單元測試的「手術刀」CTS,一路走來,每一款工具的使用,每一款框架的原始碼剖析,每一次對框架的二次封裝或工具開發,以及一點一滴的反思,都被我記錄在《深入理解Android自動化測試》這本書中,感興趣同學可以自行查閱。

很多同學認為,從事自動化測試或單元測試,最需要的技能是個人的程式設計能力,或是對自動化工具的駕馭能力,或是自動化相關的實踐經驗。我認為,這些都不是自動化最重要的技能!

從業十年,回頭來看,發現自動化測試或單元測試最最重要的技能,就是我當初我懷抱著進入自動化行業的那本Paul C.Jorgensen的《軟體測試》。自動化測試也好,單元測試也罷,說到底,都是軟體測試。

向谷歌學習怎麼寫用例

舉個真實的例子:我剛開始做Android單元測試時,領導讓我為媒體播放器(Media player)設計單元測試用例。 當時我想了下,設計了這麼幾條用例:

  • Priority 1:播放器正常開啟、暫停、停止;
  • Priority 2:播放器在播放時切換下一首歌、上一首歌;
  • Priority 3:播放器在播放時突然停止,幾種常用格式音訊檔案播放;

設計完後,我還專門看了一下Android官網針對播放器的狀態切換圖: enter image description here 我覺得沒什麼遺漏,測試覆蓋得很完美。就這樣,這些單元測試用例一直執行著,執行著,直到某天我突然看到CTS裡Google工程師為播放器編寫的單元測試用例,整個人一下就不好了。

首先是測試資源預置及環境清理總結,資源預置時建立了兩個播放器物件並獲取相關資原始檔,環境清理時釋放這兩個物件並刪除相關資原始檔,如下圖所示。 enter image description here

然後開始測試,先是「空檔案及音視訊播放測試」,如下圖所示。看到這裡,我發現我漏掉了空檔案播放這個邊界值,也忘記了視訊播放測試。 enter image description here

再下來是「切換下一首測試」,如下圖所示。看到這裡,我發現單純的音訊切換,我只做了基本狀態檢查,其他狀態檢查都沒有覆蓋到。 enter image description here

接下來是「頻譜測試」,如下圖所示。這裡,我發現自己完全沒考慮到這些「奇葩」檔案。 enter image description here

接下來是「無縫播放測試」,如下圖所示。不用說,這個方面就更沒考慮到。 enter image description here

然後是「視訊介面重置測試」,如下圖所示。似乎這個測試很簡單,但仍然被我無情地漏掉了。 enter image description here

再下來是「錄製視訊播放角度測試」,如下圖所示。只考慮播放,沒考慮錄製後播放,這是我的錯… enter image description here

然後是「不同格式視訊檔案測試」,該單元測試用例涵蓋了絕大部分檔案型別,如下圖所示。想想我只選擇了幾個常用音訊格式檔案,就無比汗顏,這裡不僅選擇了不同的型別、編碼格式、解析度、位元率、幀率、聲道、頻率,而且做了組合測試——請注意,是組合測試! enter image description here

再下來是「字幕選擇/取消選擇測試」,如下圖所示。當時完全沒考慮到視訊,更沒考慮到字幕,更沒考慮到內建字幕和外接字幕的不同,更沒考慮到字幕選擇和取消… enter image description here

緊接著是「字幕切換測試」,如下圖所示。 enter image description here

接下來是「播放器回撥測試」,如下圖所示。是的,我承認之前完全沒考慮到要不要測一下回撥是否正常… enter image description here

最後是「視訊錄製播放測試」,如下圖所示。 enter image description here 看完這些,我當時特別汗顏。

從普通走向優秀

一名普通自動化/單元測試工程師與一名優秀的自動化/單元測試工程師之間,最大的差別是什麼?

• 是對軟體測試理解的深刻程度。

• 是對測試理論掌握的熟悉程度。

• 是對測試技術運用的熟練程度。

一些測試員仗著程式設計能力較好,看不起基本的測試技術(如邊界值、等價類,還有諸如決策表、因果圖、狀態機等)。

事實上,優秀的測試工程師首先需要具備的就是紮實的測試技術功底。只有掌握了最最基本的測試技術後,無論做什麼測試(黑盒、白盒、自動化、效能或是單元測試),都能遊刃有餘,設計的測試用例也才能真正深入進入,進而發現隱藏的bug。

如果不打好這個基本功,哪怕程式設計能力再好,設計的用例也漏洞百出,發現不了問題的根源。以“不同格式視訊檔案測試”為例,如果要確保測試到位,就一定要設計各種不同格式的播放檔案(型別、編碼格式、解析度、位元率、幀率、音訊格式、聲道、頻率等等),所以有此測試。

大家不難看出,設計這個用例的單元測試工程師是多麼的不厭其煩,一點點地從細節上去把控。而很多同學卻認為這些瑣碎的小事情不值得花時間,或認為沒有技術含量而只是草草寫上幾個,相比Google的大牛們,難道不汗顏嗎?

想和許奔探討更多測試方面的知識?搜尋公眾號「巴哥奔」可以找到許老師,許老師將於6月25-26日在深圳MPD現場分享《Android自動化測試實踐》,給小編留言有機會獲得體驗票哦 。

相關文章