最早，我們發覺，由開發人員重構造成的腳本失敗占大多數，而測試人員每次拿到的上一個版本是沒有錯誤的。所以會出現自動化腳本本地跑得過，服務器上跑不開的情況發生。二是我們修改了發布的邏輯，在后臺單元測試通過、flash編譯完成的情況下打的那個war包，復制一份，放到某待定目錄指定為currentbuild。供測試人員寫測腳本使用。

　　過程改進之后，測試人員可以快速的修正腳本了，雖然對于開發人員重構造成測試人員工作的返工無疑是一種浪費，但是畢竟自動化的測試省了回歸測試的不少時間，還是可以接受。

　　腳本的修正速度解決之后，工作似乎有了些起色，但很快，問題的本質就暴露了出來build的時間太長了，修得速度還是跟不上問題產生的速度。尤其是中間缺少當build失敗時強制阻止代碼提交的環節。這之后依然是周一和周五兩頭綠，中間都是紅的。于是，我們覺得問題還是出在build速度上。我們人工的將功能測試腳本分到四個suite里去，然后以多線程的方式進行。速度被提高了4倍。于是又消停了兩天。

　　好景不長，多線程的測試似乎不太穩定。很多本地可以跑通的測試用例，到了服務器上就失敗。險些一個禮拜都沒有build出一個版本。最后不得不改回單線程。這時，build一次已經占到了100分鐘。第一期的產品Backlog還沒有完成1/3。

　　持續集成走到這里已經進入一個困境，有必要做一些更深一步的改進。經過多次討論，歸納出了幾套方案：

　　分冒煙測試和all test兩套測試用例集是我們當中呼聲最高的一種方案，當我的代碼提交之后在跑完所有單元測試和基本的冒煙測試之后就發布beta版，由測試人員接到beta版，進行更細致的自動化測試并帶一些人肉測試。但是反對的聲音認為，不跑完全部的測試用例就失去了持續集成的意義。而且會更降低開發人員修正Bug的積極性。于是作為修正，支持的聲音則提出，在Check-InGate處把關，恢復每個人提交代碼之前跑測試用例的實踐。可這明顯會給開發人員帶來更大的工作負擔，估計以此時的進度壓力，開發人員的安全感肯定會大幅下降。很可能會推行不下去。