---

既然談到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.


這17次不是說執行每日建構17天，而是要在17次版本改變裡面被正確執行。」

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

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



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

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

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



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

有太多因素可以影響GUI，造成自動化測試程式不是依照預期的正確、或是錯誤。






--
所有我的作品，請到.....
～四十八個德瑞克～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)
※ 編輯: derekhsu        來自: 175.182.34.146       (05/29 00:19)
※ 編輯: derekhsu        來自: 175.182.34.146       (05/29 01:01)

--