自動化測試拉開的距離

不管你跑步有多快，我一踩油門就讓你可望不可即。

---

A團隊引入了自動化測試工具
M團隊奉行手工測試

兩個團隊作同一個系統，下面是版本歷程

---

• 第1個版本

第一個版本有5個對外服務的接口。

A團隊針對每一個接口編寫了儘量全面的測試案例，並全都用代碼實現，1分鐘內能夠進行所有接口測試。

M團隊也很快實現了5個接口，而且手工測試了能想到的案例。所有接口所有案例測試一遍10分鐘。

• 第2個版本

第二個版本新增5個對外服務的接口。

A團隊針對每一個新增接口編寫了儘量全面的測試案例，並全都用代碼實現，1分鐘內能夠進行所有接口測試。

M團隊也很快實現了5個接口，而且手工測試了能想到的案例。部署前要作迴歸測試（即確保修改的代碼不會影響存量代碼），所有接口所有案例測試一遍20分鐘。

• 第3個版本

第三個版本修改3個對外服務的接口，新增3個接口，有些接口要共用一些代碼塊。

A團隊爲新增接口編寫了儘量全面的測試案例，並全都用代碼實現，1分鐘內能夠進行所有接口測試。

M團隊爲每一個改動或新增接口手工測試了能想到的案例。部署前要作迴歸測試（即確保修改的代碼不會影響存量代碼），所有接口所有案例測試一遍30分鐘。

• 第4個版本

第四個版本修改5個對外服務的接口。

A團隊修改完代碼後，1分鐘內能夠進行所有接口測試，以檢查是否有問題。

M團隊爲每一個改動接口手工測試了能想到的案例。部署前要作迴歸測試（即確保修改的代碼不會影響存量代碼），所有接口所有案例測試一遍30分鐘。

……

• 第N個版本（系統變得很複雜與很龐大了）

第N個版本修改一些地放，新增幾個接口。

A團隊修改完代碼後，15分鐘內能夠進行所有接口測試，以檢查是否有問題。（想像一下，計算機要跑15分鐘的代碼，是要幹多少活）

M團隊開發完成後，手工測試了能想到的案例。部署前要作迴歸測試（即確保修改的代碼不會影響存量代碼），所有接口所有案例測試花一天。

• 第K個版本

只用修改一個小地方。

A團隊修改完代碼後，15分鐘內能夠進行所有接口測試，以檢查是否有問題。（想像一下，計算機要跑15分鐘的代碼，是要幹多少活）

M團隊開發完成後，只測試了修改處的某些案例，沒有作迴歸測試（由於沒時間）

上線後，M團隊出現生產問題，由於修改的代碼影響了別的邏輯，測試沒有覆蓋到。花了兩天時間處理生產問題的手尾，代碼從新修改，花至少一天時間測試（怕了），上線。

---

越到後期，A團隊與M團隊花在測試上的時間相差會愈來愈大，若是加上由於測試不全面致使上線後的返工時間，相差就更加大了。

從長遠來看，A團隊擁有更多的自主時間，或者投入到產品研發中，或者投入到技術研究中，或者投入到其它能夠改善團隊績效的建設中，更容易獲得持續的進步，今後走上自動化測試這條不歸路（還沒出現嘗過自動化測試的甜頭後再變回手工測試的狀況）。

反觀M團隊，後期隨着人員更替，系統的規模變大，有效的測試工做展開的很是艱難。有效是指，每次上線前系統每一個能夠測試的地方都測試過而且都符合預期，而不是靠着「我只改了這個地方，其它地方應該沒問題」這種心態去對待測試，有個成語叫自欺欺人請了解一下。

固然，自動化測試不是要求絕對百分百的覆蓋率，90%以上沒問題，至少必定要覆蓋核心功能。

真正優秀的產品離不開自動化測試，oracle數據庫的自動化測試就要跑一個晚上。