iT邦幫忙

2018 iT 邦幫忙鐵人賽
DAY 27
1
自我挑戰組

再戰軟體工程系列 第 26

『我覺得這樣已經很方便了』 -- 測試要做到多自動化才夠?

自動化測試、自動化測試,一樣的話不知道聽多少遍了,大家都知道要做自動化測試,但是真正能做到的有幾個?首先,『趕進度都沒時間了,沒時間寫測試』是我聽過最多的原因。我沒有辦法解決你沒時間寫測試的問題,因為,這代表你的工作環境不把測試當成你的工作,而且,加班寫測試也不就失去了本意。除非你把這件事當成興趣,或是學習技術,以side project的方式來在閒暇時間做,那還勉強OK。

在敏捷開發的洪流中,比較麻煩的是一種『我覺得我已經很敏捷了』的人。他不願意改變,他覺得這樣已經『夠敏捷』了。這種人,你很難動搖他的心智,因為他認為,『這麼敏捷了,還要改善什麼?』-- Well, 你發現這句話的矛盾了吧!

敏捷開發的重要精神就是持續改善,有敏捷精神的人,會在任何時刻有不需改善的想法嗎?

自動化測試也是一樣,如果你認為『這麼自動化了,還要改善什麼?』那你就是犯了跟上面抗拒敏捷的人一樣的錯了。我舉個例子吧:

我的產品中,有一個『客戶單筆消費明細』功能,我寫完了,也寫了測試。這個測試很簡單,我們有一個RD共同開發的環境,於是我在該類別中埋下一個main,我每次想驗證此類別有沒有被改壞,就去執行那個main,他會去讀取一批我事先在該環境準備好的資料,並且秀在螢幕上。

『只要這個測試用的main正常跑完,我只要一眼就能看出這個報表功能壞了沒,因為這個結果是固定的。』

這樣做算是自動測試嗎?嗯...well,...這要看你有沒有付我顧問費來回答你這個問題...

哈!開玩笑的啦,當然不算啊!
這樣充其量只能算是『跑個結果出來,並檢查一下對不對』
這種事連QA都懶得手動做了,你都動手寫程式了,怎麼才寫成這樣?
(請原諒我說話就是這麼直)

如果你所謂的『自動測試』長得像上述故事這樣,我們來看看你至少有哪些可以更好的做法

不要跟別人共用資料庫

資料自己準備是好事,但是一旦用了共用資料庫,難保你的測試資料不會被別人不小心竄改。最好的做法,是有一個自己的空白資料庫,管你要架在自己電腦還是偷偷在公司伺服器裝一個。反正裡面只能有你的資料,而這個資料庫最好是隨時保持全空狀態(只有Schema),在每個測試案例要開始前,才去創一些這個案例專用的資料,並且在測試完後刪除,留下乾淨的資料庫給別的測試案例用。

關於這點,也許你有存疑,但因篇幅有限,歡迎參考拙作『談測試的資料』,裡面有比較詳細的論述、原因、與建議做法。

不要另寫main來測試你的功能(就算寫了也不要跟別人講)

現在已經是2017年了,不管你是前端還是後端,甚至是網頁,都有不只一種的自動化測試框架,即便是worst case,都可以按一個鍵,就跑完此專案內所有測試。因此,像『寫一個只有自己知道在哪裡的main來慢慢測』這種大學時代的做法,我們就盡量不要用了。(就算用了也不要跟別人講)

我絕對不是說舊方法不好
我絕對不是說舊方法不好
我絕對不是說舊方法不好

舊方法很好。因為,舊方法會存在,肯定是因為在那個年代,他是最適合的做法,我們必須給予肯定。但是同樣的精神留著,可以拿來套用在比較方便又全面的技術上,何樂而不為呢?

請記住,測試,尤其是功能性測試,是跑再多次也不會嫌煩的。如果不能至少做到一鍵執行所有測試案例,在21世紀的今天,就不太被認為是『自動化』的測試方式。

能夠用肉眼比對的『值』,就一定可以叫程式幫忙比對

沒有什麼是不能比較的。如果你的物件欄位有10個,那就叫程式幫你比對這10個欄位。如果你預期某行Log會出現10次,那就叫程式去屬看看是否真的印了10次。如果你預期這樣跑完資料庫會新增20筆資料,每筆資料5個欄位,那你就叫程式去整張table取出來,先數數看是不是真的有20筆,再一筆一筆對看這5個欄位是不是預期的值。

當然,除了一些圖案顯示性的功能比較難用程式比對以外,舉凡是資料正確性、特定method被呼叫次數、連線建立數等,只要是你用眼睛看得出pass或fail的值,都可以讓程式用同樣標準去檢視。你說你肉眼看一下很快,問題,你有比電腦替你看還要快嗎?一次努力,永久受惠,多划算啊?

可以想到時手動驅動一下,但是至少你要每天『自動』驅動一次全部測試案例

半自動測試另一個有可能引發問題的地方,就是你必須時不時地想到,然後去跑一下。問題就在,你跑了30次都pass,然後隔了一周才想到,再去跑第31次,問題就往往出在這一周的空檔。

理想狀態下,我們會希望每次commit,或至少每次push,就能自動觸發此專案中的所有已存在test case。如果這件事很難,那麼你至少要排程,讓他每天自動地跑一次。既然是排程,時間就可以訂在大家都下班後的深夜了。而排程的好處很明顯:『你會忘,但電腦不會。』

至少,你每天一進公司打開email,就知道昨天我們團隊做的所有更動,把哪些其他功能搞壞了。記得我們前文說的嗎?痛苦的是要讓他提早發生。debug夠痛苦了吧?那就讓bug一旦被製造出來,就馬上被抓到吧!

隨時思考有沒有更『懶』的空間

以上只是一些基本步驟,還有更多更深的理論在背後,但是身為工程師,如果我們沒有要追求極致完美,至少我們要做到有信心。譬如:

我的主線上的程式,老闆隨時有需要,我都有信心他可以馬上讓測試人員檢測,測完馬上上線。

你如果初期能做到這種程度,其實也就夠了。

接下來就是在開發過程中,持續補強,持續讓流程更自動化 (aka更懶),並持續改善你的工作流程,當然也包含你的『自動化腳本』本身。請記住:

在敏捷的世界裡,唯一不變的事情,就是『改變』這件事本身。


上一篇
『你們敏捷都不寫文件的啊』 -- 真相究竟是...?
下一篇
『我覺得自己來比較保險,我超有經驗』 -- 自動化部署的謬誤
系列文
再戰軟體工程30

尚未有邦友留言

立即登入留言