對于剛開始做自動化測試的新手，一個很大的煩惱就是如何開始的問題。面對心中澎湃的激情和老板殷切的希望，很容易陷入兩個極端。
第一個極端是“over design”，就是試圖在一個framework里解決所有的問題。這樣的后果一是framework必然要引入更多的抽象層導致framework變得復雜而丑陋，第二個是前期工作量非常大，可能很長時間連一個可以跑的demo都拿不出來。
另一個極端是不講設計，沒有任何framework，一個script就是一個case。這樣快倒是快，但很多重復的代碼分布在各個script里完成類似的功能，后期維護簡直就是災難。。
這里問題的核心是，你如何來界定一個自動化測試程序的范圍呢？一個程序解決所有case不行，一個case一個程序也不行。你必須要確定一個自動化測試程序要解決的范圍。在這個范圍里，既能設計一個framework能兼容所有的testcase，取得最大的代碼重用效果，又不至于把framework搞成一個復雜難懂的怪物。
其實這里有一個很簡單好用又有效的方法。那就是根據“數據驅動”的testcase來定義你的自動化測試程序。如果你發現了一套testcase可以用，或者已經用，數據驅動的形式定義的，那么就把它作為你自動化的對象。
說這個方法簡單好用是因為它一點也不復雜，testcase是已經現成設計好的，不用花心思來決定“留”和“舍“那些testcase的問題。說它有效是因為
1） 一套testcase既然能設計成使用數據驅動的形式，那么他們必然有類似的測試邏輯。因此framework也不會很復雜，那么做出來第一個能跑demo也相應會比較快。
2） 第二個好處是有大量的testcase能自動化起來。因為有類似的測試邏輯，如果自動化了1個case，那么剩下的9個case差別相當小。自動化10個case顯然比自動化1個case更能獲得老板的認可。。。
3） 第三個好處是，一般來說越是核心的功能，測試越徹底，那么數據驅動集也會越大。如果你首先挑上這樣的一套testcase，那么自動化程序的價值也相應的更大。
不僅僅是對于新手。任何時候當出現“狗咬烏龜，無從下口“的時候，都可以應用這個方法。我在前段時間做的一個項目，也采用了這種方法。原因是測試的需求不清楚。我得到的任務是對某個包含多個子功能的功能開發自動化測試程序，但具體要自動化哪些case，有什么樣的milestone根本不清楚。這個時候，我就選擇了一個用data driven的最大的一個testcase集合。我能確定這一套testcase肯定是要自動化的，所以我不會花時間在錯誤的地方；然后我能很快拿出一個可以跑的demo給客戶看看，讓他對自動化測試的效果有了實際的認識，幫助他更好的提出自己的需求。
文章來源于領測軟件測試網 http://www.kjueaiud.com/