一個實際案例
N年前某大型通信設備公司的測試部門發起一場轟轟烈烈的測試轉型運動，驅動轉型的動力非常簡單：人手太緊了，要釋放人力，當時該部門有95%以上的測試精力都投入系統測試上，導致其它測試，比如組網測試、協議測試一致性測試、性能測試，還有白盒測試根本顧不上。部門經理賈XX決心很大，先部門總動員，歷經艱難，后來終于從各產品測試組抽調20多位骨干來研發自動測試工具。
半年過去，終于有一兩個自動工具的初始版本做出來了，選測試組進行試驗，為讓自動測試跑起來，測試組額外多投了20%的精力飼候這個脆弱系統，后來工具研發人員幾經努力，又用了半年時間，自動系統終于能穩定的跑起來了。大家舒了一口氣，都指著這個系統能幫他們節約出幾個人來，結果，兩個版本測試周期過去了，人力沒節省，反倒多搭進50%的人力寫測試腳本，維護測試腳本。部門經理賈XX并不因此灰心，他認為這是測試自動化推行初期必然要經歷的。
這次，他們調整策略，只從所有產品中選擇1/3容易做自動化的測試組，給每個測試組指定一個測試自動化率指標，拿這個指標考核測試經理。如此又堅持了一年半，最后統計發現，這1/3測試組中又只有1/3是出效果，自動化測試有助于減少測試工作量，而見到顯著效果的，卻只是個別產品。
問題到底出在哪兒呢？
不適合自動化測試的產品領域
業務自動化測試是個香孛孛，看起來很誘人，嘗一口苦澀得很。并不是所有產品都適合推行自動化測試，尤其是具有如下特點的產品。
1. 一次性產品
這類產品生命周期不長，客戶需求比較確定，做出產品測穩定后，就很少升級，不會一個接一個的升級版本。
此類產品不宜做自動化的主要原因是，首次自動化的成本遠高過投入，實現自動化后重用性差，自動測試是不大可能在前一兩輪測試就產生效益的。
2. 接口原型或業務模式尚不穩定的產品
當產品業務的模型還不成熟，經常會變，或者子系統之間接口不穩定，經常變來變去。這樣的系統不大適合做自動化。
3. 涉及過過物理設備交互
測試自動化的基礎是設備仿真，如果被測產品與眾多物理設備打交道，而又缺乏恰當的軟件仿真或硬件工具仿真（缺少測試儀表或模擬器）時，自動化測試是難以為繼的。
4. 項目周期很短的項目
自動化測試是一項長期投入，項目周期短往往只看到為自動化做投入，而等不到它產生效益。
5. 在用戶界面操作表現復雜業務的產品
業務復雜意味著針對界面操作實現自動測試的代價很高，業務越復雜涉及的界面元素就越多，業務越復雜也意味它越容易變化，這對于自動測試，實現一次測試的自動化尚不輕松，更別說長期維護它了。
解決此類產品的業務自動測試，只一條途徑：優化產品結構，進行抽象分層，讓復雜的業務邏輯集中某幾個規格化的接口（比如命令行接口、MML接口，數據驅動或表格驅動接口）來處理。
6. 涉及過多界面美觀，圖像質量、音頻質量等可用性與易用性的產品
文章來源于領測軟件測試網 http://www.kjueaiud.com/
