原因有三點：
- 一個case太大，在前面部分的failure導致後面的部分沒有執行到，降低了整個test suite的覆蓋率。
- 一個case太大，會讓人花更多精力查找failure原因。
- 一個case太大，常常有許多額外的setting動作。而如果case之間類似的setting很多，將會導致一個bug就讓許多case被fail, 讓人花很多時檢查每個case失敗的原因，其實都花在同一個bug上。而且當然地，會降低整個test suite的覆蓋率。
所以case應該儘量小，且互相之間儘量少重複的動作，作爲整體的test suite覆蓋率要儘量高。
實際操作中，automate testting怎樣協助減輕manual testing 的工作呢？如果直接按照manual test case 或者bug report來寫 automation test case, 會有許多不必要的setting動作（在我的工作環境中，test case 和bug report都有相當詳細的操作步驟）。我覺得可不可以用上一層的test plan呢？ 只要說這個 automation suite已經覆蓋到了test plan的這部分，就不用再manual testing了。也就是說test plan有automation suite 和 manual testing suite兩種測試方式。其實我覺得有了test plan已經足夠， 太詳細的test case對於熟練或者有經驗的測試員反而是累贅。
一個構想：
用一組腳本創建基本狀態。這些基本狀態提供了進一步測試所需要的狀態。在建立這些基本狀態的同時也就相當於進行了基本功能的測試。而把特定的測試內容留給了腳本。問題是這一組腳本是怎麼被調用呢？放在另外的文件裏作爲測試用例？作爲測試框架的一部分？
如果這個建立基本狀態的腳本失敗，失敗信息會log到這個建立基態的腳本。case可以選擇其他的方法繞過這個失敗。
額，討厭要用幾行代碼反覆做類似的工作。
automation框架應該完成的幾樁事情：
底層：能夠支持client-agent模式，能夠得到所有被測控件的焦點，模擬鼠標和鍵盤操作。
提供能完成一定任務的控件類。模擬鼠標的移動等。提示agent的運行。
中層：當控件的id或者字符串標示符改變時，不需要更改大量測試用例。所以必須有一層封裝。
上層：同時提供一系列的方法或者模塊或者類來完成常見的操作。方便測試腳本的編寫。