[心得] 軟體測試自動化
既然談到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)
推
05/29 00:16, , 1F
05/29 00:16, 1F
※ 編輯: derekhsu 來自: 175.182.34.146 (05/29 00:19)
推
05/29 00:30, , 2F
05/29 00:30, 2F
※ 編輯: derekhsu 來自: 175.182.34.146 (05/29 01:01)
→
05/29 01:26, , 3F
05/29 01:26, 3F
→
05/29 01:27, , 4F
05/29 01:27, 4F
→
05/29 01:27, , 5F
05/29 01:27, 5F
→
05/29 01:27, , 6F
05/29 01:27, 6F
→
05/29 01:28, , 7F
05/29 01:28, 7F
→
05/29 01:31, , 8F
05/29 01:31, 8F
→
05/29 01:31, , 9F
05/29 01:31, 9F
→
05/29 01:32, , 10F
05/29 01:32, 10F
→
05/29 01:34, , 11F
05/29 01:34, 11F
→
05/29 01:35, , 12F
05/29 01:35, 12F
→
05/29 01:36, , 13F
05/29 01:36, 13F
→
05/29 01:38, , 14F
05/29 01:38, 14F
→
05/29 01:38, , 15F
05/29 01:38, 15F
→
05/29 01:38, , 16F
05/29 01:38, 16F
推
05/29 01:39, , 17F
05/29 01:39, 17F
→
05/29 01:39, , 18F
05/29 01:39, 18F
→
05/29 01:39, , 19F
05/29 01:39, 19F
→
05/29 01:39, , 20F
05/29 01:39, 20F
→
05/29 01:39, , 21F
05/29 01:39, 21F
→
05/29 01:40, , 22F
05/29 01:40, 22F
→
05/29 01:41, , 23F
05/29 01:41, 23F
→
05/29 01:41, , 24F
05/29 01:41, 24F
→
05/29 01:41, , 25F
05/29 01:41, 25F
→
05/29 01:42, , 26F
05/29 01:42, 26F
推
05/29 01:42, , 27F
05/29 01:42, 27F
推
05/29 01:43, , 28F
05/29 01:43, 28F
→
05/29 01:43, , 29F
05/29 01:43, 29F
推
05/29 01:44, , 30F
05/29 01:44, 30F
→
05/29 01:44, , 31F
05/29 01:44, 31F
→
05/29 01:45, , 32F
05/29 01:45, 32F
→
05/29 01:45, , 33F
05/29 01:45, 33F
→
05/29 01:45, , 34F
05/29 01:45, 34F
→
05/29 01:47, , 35F
05/29 01:47, 35F
→
05/29 01:47, , 36F
05/29 01:47, 36F
→
05/29 01:47, , 37F
05/29 01:47, 37F
→
05/29 01:47, , 38F
05/29 01:47, 38F
→
05/29 01:48, , 39F
05/29 01:48, 39F
→
05/29 01:48, , 40F
05/29 01:48, 40F
→
05/29 01:48, , 41F
05/29 01:48, 41F
→
05/29 01:48, , 42F
05/29 01:48, 42F
→
05/29 01:52, , 43F
05/29 01:52, 43F
→
05/29 01:52, , 44F
05/29 01:52, 44F
→
05/29 01:52, , 45F
05/29 01:52, 45F
→
05/29 01:52, , 46F
05/29 01:52, 46F
→
05/29 01:53, , 47F
05/29 01:53, 47F
→
05/29 01:53, , 48F
05/29 01:53, 48F
→
05/29 01:54, , 49F
05/29 01:54, 49F
→
05/29 01:54, , 50F
05/29 01:54, 50F
推
05/29 07:26, , 51F
05/29 07:26, 51F
推
05/29 08:09, , 52F
05/29 08:09, 52F
→
05/29 08:10, , 53F
05/29 08:10, 53F
→
05/29 08:14, , 54F
05/29 08:14, 54F
→
05/29 08:14, , 55F
05/29 08:14, 55F
推
05/29 09:14, , 56F
05/29 09:14, 56F
推
05/29 10:19, , 57F
05/29 10:19, 57F
推
05/29 13:54, , 58F
05/29 13:54, 58F
→
05/29 13:56, , 59F
05/29 13:56, 59F
推
05/29 17:12, , 60F
05/29 17:12, 60F
推
05/29 17:59, , 61F
05/29 17:59, 61F
推
05/29 23:57, , 62F
05/29 23:57, 62F
推
06/05 22:48, , 63F
06/05 22:48, 63F
推
07/17 21:06, , 64F
07/17 21:06, 64F