軟體測試自動化

作者: derekhsu (華麗的天下無雙) 看板: Soft_Job
標題: [心得] 軟體測試自動化
時間: Tue May 29 00:07:38 2012

既然談到Automation Test，分享一下在下的經驗好了，

Test Case：
文件化後的測試描述，相對於Use Case從使用者角度出發，Test Case從
測試角度出發。至少有輸入(Input)、預期輸出(Expected Output)、步驟(Test Step)
等三項要素，其他像是測試編號(Test Id)，測試方法(Test Method)、前置條件(
Precodtion)，這些依照不同公司、環境的測試規範而定。

自動測試：Automation Test，採用電腦自動執行Test Case中的Step。
人工測試：Manual Test，採用人力執行Test Case中的Step
隨意測試：Ad-hoc Test，在沒有Test Case的情況下人工亂打。
單元測試：Unit Test，程式碼層級的測試，主要透過Unit Test Program自動完成。
          理想的Unit Test應該能夠去除類別之間的Dependency.

除單元測試外，其他的測試若沒有主動提到都是指在整合測試階段的測試。
這裡的單元測試是指透過xUnit家族之類的Unit test automation framework來
進行的單元測試。

其他還有一堆有的沒有的測試像是Monkey Test、Randomness Test、Load Test、
Stress Test的ROI就不在這裡討論的範圍之內的。

有人說Automation Test一定勝過Manual Test或Ad-hoc Test，我的答案是：
從ROI的角度來看，並非100%贊同，特別是GUI Automation。

Ref:
http://www.testingmentor.com/imtesty/2009/11/18/gui-automation-and-roi/

Dan Mosley and Bruce Posey (Just Enough Software Test Automation) suggest
that on average an automated test must run approximately 17 times in order to
break even. But, this doesn’t imply that we break even if we simply run the
same test on a daily build for the next 17 days.

這一段引用了一篇來自於Dan Mosley與Bruse Posey的書，這本書告訴我們自動化測試
「夠用就好」，原本這裡面的數據是某位我以前的同事告訴我的，我最近才找到來源，
它說「一個平均的自動化測試要打平它的開發成本，至少要可執行約17次。」「而且
這17次不是說執行每日建構17天，而是要在17次版本改變裡面被正確執行。」

我們說一個自動化測試不是對的，並不是說被測試的程式是錯的，而是自動化測試程式
本身無法依照測試腳本(案例，Test Script/Test Case)上面的定義去驗證程式。

這一點是自動化測試一個非常嚴重的迷思：
錯在哪裡？

如果一個自動化測試不能夠被穩定的執行多次，而每次錯誤都必須找出自動化錯誤程式
錯在哪裡，最後卻發現原來都是自動化測試程式的錯而不斷去修改自動測試程式，那麼
若是由Developer開發自動化程式，這樣的程序浪費了他用在Feature開發的時間；若是
由QA開發自動化測試，那麼這樣的程序浪費了他執行其他更重要的測試的時間，於是這
個自動化測試案例就失去了他原本的價值。

更嚴重的是，他會使整個團隊不再信任自動化測試的結果，而這就是絕大部分專案執行
自動化測試失敗的原因。

「被測試程式的穩定性」是評估自動化測試ROI的第一項指標。

那麼，哪種被測試程式的穩定性最差？
GUI。

因為GUI是最容易因為需求改變而被改變的程式，因此GUI Test(通常GUI Test是
Integration Test層級)的Automation的爭議性一直是最高的，甚至有台灣大神
vgod開發的sikuli都做到用Screenshot來Test了但還是有很多問題在。

用Screenshot的Test，假設圖改了呢？(Sikuli)
用座標的Test假設位置變了呢？(AutoIt, PyAuto...)
用Id/xpath的Test假設Id換了，或是...沒有Id(動態元件，如Ext3)呢？
(Selenium, HP QuickTest ...)

有太多因素可以影響GUI，造成自動化測試程式不是依照預期的正確、或是錯誤。
一般而言，穩定性最低的GUI Test最不適合做Automation。如果你的團隊要做自動化
測試，請將GUI Test的投資順序挪後。如你能很神奇的維持GUI的穩定，那請您一定要
分享給我們您是怎麼做到的。

穩定性最差的情況是連需求都不穩定，需求一旦變化，Test Case要跟著動，主程式要
跟著動，當然Automation Test也要跟著動。這也是幾乎所有專案公司執行Automation
Test都會失敗的原因，因為台灣的專案公司在驗收時都還可能在改需求在改Code。

所以很多人對於自動化測試的經驗相當兩極化，原因就是在你是不是在做一個穩定的
產品或專案，一個好的Unit Test可以增加Automation Test的穩定性，但一個亂七八
糟的需求變更流程可以讓Unit Test毀Automation Test更厲害。

--
所有我的作品，請到.....
～四十八個德瑞克～http://blog.derekhsu.homeip.net
馬皇本紀：http://blog.derekhsu.homeip.net/2009/08/821
上官先生傳：http://blog.derekhsu.homeip.net/2009/08/825

--
※ 發信站: 批踢踢實業坊(ptt.cc)
◆ From: 175.182.34.146
※ 編輯: derekhsu        來自: 175.182.34.146       (05/29 00:10)
推 atpx:相當清楚~~                                                 05/29 00:16
※ 編輯: derekhsu        來自: 175.182.34.146       (05/29 00:19)
推 Ting1024:相當清楚...感謝                                        05/29 00:30
※ 編輯: derekhsu        來自: 175.182.34.146       (05/29 01:01)
→ TonyQ:一般來講，我作過的 UI 測試，底線會是 vision test 。       05/29 01:26
→ TonyQ:vision test 在大多的 UI 元件上都還可以取得相對穩定的品質  05/29 01:27
→ TonyQ:當然，假設原本的穩定性是 5% , vision test 大概是 30%      05/29 01:27
→ TonyQ:這是我們自己作 UI 測試的方法論跟經驗談。                  05/29 01:27
→ TonyQ:另外其實大多 ui 元件，都會提供生 ID 給你的方案啦。:P      05/29 01:28
→ superpai:所以Test同時也是在測試公司的品質..                     05/29 01:31
→ derekhsu:哪有Ext哪有生ID給我                                    05/29 01:31
→ derekhsu:我是沒用過Zk，會吐固定的Id嗎？                         05/29 01:32
→ derekhsu:還有我沒聽過vision test，也Google不到，願聞其詳        05/29 01:34
→ TonyQ:ZK 是有個 API 可以讓你實作，實作完之後就會吐固定 id。     05/29 01:35
→ TonyQ:vision test 簡言之，截圖比對...                           05/29 01:36
→ TonyQ:extJS 可以自己設定ID 或用 selenium selector 去作。        05/29 01:38
→ TonyQ:selenium seelctor 基本上蠻夠用了，再不然還可以 customize  05/29 01:38
→ TonyQ:locator 去作。不過這還是要看你要測什麼就是了。            05/29 01:38
推 ohb:重點還是在穩定性...UI Component相較於其他的模組，改版時會   05/29 01:39
→ derekhsu:沒有用，動態生出來一堆元件，Id很難預期                 05/29 01:39
→ ohb:改動的機率就是比較高...如果你的UI可以盡量都不改，那自動化   05/29 01:39
→ ohb:UI test就有價值在了                                         05/29 01:39
→ derekhsu:selenium selector那要用狗屎般長的xpath...              05/29 01:39
→ TonyQ:剛查了一下 vision test 是只有我們自己講的非正式名詞XD     05/29 01:40
→ TonyQ:@derekhsu 沒吧，他有 css selector 啊 比xpath好用多了      05/29 01:41
→ TonyQ:我也很賭爛 xpath XD                                       05/29 01:41
→ TonyQ:http://goo.gl/9VDbG                                       05/29 01:41
→ TonyQ:這是 0.8.0 版的文件，但這個基本上後來改變不大             05/29 01:42
推 ohb:非不得以的話請不要用xpath XD                                05/29 01:42
推 LetDogDay:zk有用到extjs??                                       05/29 01:43
→ TonyQ:沒啊，當然沒有，他們是自己刻的。XD                        05/29 01:43
推 lovdkkkk:visual testing http://goo.gl/uK5Pz                     05/29 01:44
→ TonyQ:btw 閒聊，我對元件覺得有點瓶頸所以離開 ZK 了，XD          05/29 01:44
→ TonyQ:所以大家不要太把我的話跟 ZK 連上等號。雖然我還是很喜歡這  05/29 01:45
→ TonyQ:家公司。:P                                                05/29 01:45
→ TonyQ:但是我不太希望因為這樣造成前東家困擾。                    05/29 01:45
→ derekhsu:如果tag上面沒有css class的話，一樣，而且ext的事件都在  05/29 01:47
→ derekhsu:奇怪的地方...                                          05/29 01:47
→ derekhsu:你根據文字找到了要點的按鈕，卻發現事件不是綁在那附近   05/29 01:47
→ TonyQ:我記得 ext-js 跟我們一樣在不同元件有不同 css class 識別   05/29 01:47
→ TonyQ:應該夠用才對。不過可能大多都是要手工作，不太能倚賴        05/29 01:48
→ TonyQ:selenium IDE 這類的工具就是了 :x                          05/29 01:48
→ TonyQ:@derekhsu 我們家的東西也是一樣，那個是有歷史因素的...     05/29 01:48
→ TonyQ:一切都是向下相容造成的...                                 05/29 01:48
→ TonyQ:@ohb 發現忘了回到你，所以 vision test 很重要，            05/29 01:52
→ TonyQ:     拍張圖很快，用這種作法比起傳統一一判斷狀態來得實際   05/29 01:52
→ TonyQ:     不過當然，有些東西就是沒辦法拍圖作，像是位置會浮動   05/29 01:52
→ TonyQ:     對話框...                                            05/29 01:52
→ TonyQ:反正 UI testing 就是能作多少算多少，我是也有看過一種狀況  05/29 01:53
→ TonyQ:是挑幾個特定節點去跑程式截圖，然後人工看看有沒有問題的。  05/29 01:53
→ TonyQ:不過 UI Testing 來講，幾乎不可能沒有 false alarm 是最討   05/29 01:54
→ TonyQ:驗的事情...:x 一定要有人讀 report ...                     05/29 01:54
推 ppHomer:感謝分享!!                                              05/29 07:26
推 ccpz:ext-js 真的很難測, id 亂數的問題還好解決(另外指定一個      05/29 08:09
→ ccpz:獨一無二的關鍵字就好), 還有很多標準元件他都自己重新設計    05/29 08:10
→ ccpz:變成測試時也要一個一個處理,不然就是event亂綁,自動測試      05/29 08:14
→ ccpz:無法觸發 event 時就只能瞎子摸象 orz                        05/29 08:14
推 musie:這篇就真的是好文，給推~                                   05/29 09:14
推 littlebau:這篇真的是難得的好文,對軟體測試不熟。不然也想討論     05/29 10:19
推 marcusmiller:清楚的好文，還是希望樓上寶哥來分享，畢竟           05/29 13:54
→ marcusmiller:測試不分軟韌體，test logic都會很像                 05/29 13:56
推 littlebau:覺的軟體測試 比韌體測試難多了..                       05/29 17:12
推 andreli:德瑞克好帥                                              05/29 17:59