自動化測試的成本高效果差嗎？那麼自動化測試的意義又何在？

“自動化測試的成本高效果差”是真的嗎？當然不是。而且我始終相信，回答問題的最好方式是把問題本身弄清楚。也就是問關于問題的問題。這個問題換而言之就是：如果有的項目的自動化測試，我們發現成本高于預期，效果不符合預期，那麼問題可能出在哪裡？怎麼判斷自動化測試是否有效？

關于錯誤的預期

我一點都不奇怪有人會告訴我說：

我都不知道我或者我的老闆對自動化測試有什麼預期，沒人跟我說過。

或者：

自動化不就是不用手工測試了嗎？用例用代碼實作都能自己跑，測試人員就可以去幹别的了，可以少招幾個不産生價值的測試攻城獅了。老闆就是這樣計劃的。

這是兩種非常典型的關于自動化測試的預期問題：

1.根本就不清楚自動化測試的目标，以及為達到目标所計劃的投入

2.對自動化測試（通常是總監以上的老闆，開發人員或者手動測試人員）抱有不切實際的幻想型期望，認為自動化測試能夠幹很多活同時省很多錢。

自動化測試的第一目标從來都不是節省測試的人力成本。成功的自動化測試，作為軟體測試的一種工具，從業務最終效果來看，應該是能夠節省成本和提高産品品質的。但是把節省測試的人力成本作為自動化測試的直接目标是錯誤的，而且是緻命的。

每個人對自動化測試了解都不一樣，每個項目組做自動化的方式都不一樣。我講個故事，是我認識之前一個印度自動化項目的真執行個體子。這個項目95%以上的測試場景都是比較複雜的UI測試（Web +Windows Application）他們的自動化是這樣做的：

1.手工測試人員把測試用例錄入到用例管理系統，精确到每一步的描述和每一個資料

2.自動化測試人員用代碼（java，python等）實作自動化用例，儲存到SCM

3.準備好測試環境

4.打開Eclipse

5.定位到要執行的用例的源代碼

6.Run As Junit （因為統一用JUnit做封裝）

7.兩眼直視顯示器，目不轉睛

8.如果有步驟執行不成功，比如某個按鈕點選不成功，手動幫助點選，繼續

9.一個用例執行完畢，重複步驟5到9

你覺得這個自動化做的怎麼樣？我當時的感覺是幾乎要吐血了，因為這個項目是我要接手的。更加吐血的還在後面，這個部門的QA的VP對自動化測試的效果很不滿意（絕對的），他的設想包括：

1.自動化應該是一種Service（Automation As A Service)，所有的測試人員和開發人員都應該可以自己很友善的去跑自動化

2.自動化測試的運作結果應該是可以自動分析的，占用很少的時間

3.自動化測試的成功率應該是要很高的（比如95%以上）

4.自動化應該是寫一次，運作很多次，為什麼你們花那麼多時間還要去改自動化代碼？

這個就是一個典型的不懂自動化的團隊+期望脫離現實的老闆。

關于什麼是自動化

James Bach 曾經在一篇博文提到，自動化測試這個名字是非常有誤導性的。它讓一般的人誤以為就是測試完全被自動化了，就像一個自動的咖啡機一樣，我隻需要把杯子放在那裡，按一個button就夠了。James說更加準确的叫法應該是“工具輔助的測試”。當然他還有另一層意思，就是好的測試用例是沒有辦法100%被自動化的，測試人員的經驗，邏輯判斷和探索性的測試方法都不能被有效自動化。我非常同意這個觀點。作為這個論斷的補充和擴充，自動化應該是審視軟體研發活動的每一個環節，去發現那些可以被工具化自動化的重複性活動，然後去實作。廣義的自動化應該包括但不限于以下環節：

測試環境的搭建和管理

測試環境的檢查，監控和報警

測試代碼的編譯和測試建構

測試代碼的靜态檢查和報警

測試用例的分發和執行

測試結果的儲存與管理

測試報告的生成

測試優先級的建議

自動化的成本與收益（ROI）

一個過于簡化的公式可以這樣寫：

自動化的收益 = 疊代次數 * 全手動執行成本 - 首次自動化成本 - 維護次數 * 維護成本

或者如果假設疊代次數和維護次數近視相等，這個在某些情況下可以成立，比如一個比較新的産品：

自動化的收益 = 疊代次數 * (全手動執行成本 - 維護成本) - 首次自動化成本

解讀：

自動化的收益與疊代次數成正比

自動化收益可能為負數：即當自動化成本和維護成本比手動執行成本還高時

很多時候自動化成本并不比手動成本高，但是維護成本很高

為什麼強調過于簡化，因為這裡的自動化收益僅僅考慮時間和資源成本的節省。好的自動化帶來的疊代周期的縮短，是可以縮短項目周期，在某些時候能變不能做為能做，進而帶來的機會收益是巨大的，也是很難量化的。這個就要求決策者對軟體工程和自動化有比較正确的直覺和了解。片面追求自動化的資源節省，或者要求精确量化自動化的收益，本人覺得都不可取。

推論1：什麼項目适合自動化

從ROI的簡化公式可以看出，下面幾中情況比較适合自動化：

1.回歸測試為主的Support Engineering項目，即需要長期做支援維護的産品。或者有過去版本需要長期做支援維護的産品。這種産品（比如企業軟體，作業系統等）一個版本在釋出之後往往需要支援好多年，做bug fix和patch。這個時候每次小版本的開發都會增加疊代次數，并且每次産品變動都非常有限，維護成本相對偏低，自動化收益就非常好。這也是很多企業級軟體或者硬體産品有專門自動化團隊的原因。因為産品的支援維護開發的回歸測試基本靠自動化

2.接口比較穩定的産品，同上

3.手動測試特别費時費力，甚至無法達到測試目的的項目。比如壓力測試，大資料或者大量重複資料測試，必須有自動化工具的支援。

推論2：自動化的介入時間點

同樣從ROI的簡化公式推斷出，一個項目的初期可能不太适合自動化。因為項目初期使用者界面和接口沒有穩定，自動化代碼會被動的被要求頻繁改變，維護成本非常高。自動化收益不好。而反而手動測試能夠快速發現問題，回報給開發人員。而到了項目後期和維護期，自動化再介入為回歸測試做準備，可以最大化自動化收益。

推論3：自動化的程度和自動化率

這裡自動化的程度是指整個軟體研發活動中引入自動化的程度。推論2中說，有些項目早期可能不太适合高度自動化，但是項目早期仍然可以標明某些環節進行自動化。比如穩定的公用接口，軟體的編譯和部署，環境的搭建等從一開始就比較穩定的部分。

自動化率同樣也要看産品和項目的特性，對于産品的UI部分如果會頻繁改動，可以做比較低的自動化。對于接口比較穩定的服務元件可以提高自動化率。

你有什麼樣的團隊，工具和基礎設施

其實這個因素是做所有事情都必須考慮的。自動化測試本身就是軟體開發。好的自動化測試架構，架構設計很重要。這些會決定自動化的開發成本和維護成本。這些都要求很強的開發能力。如果你的團隊隻有很有限的開發能力，那麼怎麼去做自動化，是做最原始的錄制回放，還是資料驅動。複雜自動化也需要良好的基礎設施支援。比如你有很好的DevOps的虛機管理系統，就不用自己去開發，省下的資源和人力也是很可觀的。

工具是另外一塊，如果公司有實力支援商業測試軟體和管理軟體，就可以降低程式設計要求（當然這會帶來一些其他問題）。如果沒有辦法用商業工具，隻能考慮開源和自己開發，這個對自動化測試開發的能力要求就高。總之必須選擇和團隊，技能儲備，基礎設施與工具比對的自動化政策。

管理層的了解程度和支援

這個就不再展開。我見過很糟糕的情況，一個帶好幾百人兼顧産品技術的VP，越3到4級直接給測試團隊提技術需求和建議。你說是做還是不做，怎麼做？還有一個團隊，自動化測試人員從來沒有寫過Java或者其他OO語言的程式，被要求從頭設計自動化架構，那就是一場災難。還有一個團隊，管理層幾次要求更換自動化工具，相當于整體重寫自動化腳本。

總結

自動化測試是一個很專門化的領域，自動化測試又是對工程師的技術廣度深度要求很高的工作。對于團隊管理和決策者來講，請不要簡單化和孤立看待自動測試。最重要的是確定聽取真正了解産品，團隊和自動化測試的技術人員的判斷。

更多軟體測試資源分享微信公衆号：【軟體測試小dao】

軟體測試技術交流群：1033482984

不要隻做收藏從未停止，行動從未開始的人，很多事情，做着做着就無師自通了。如果在做的過程中還能稍微加點思考，稍微看一些别人的經驗和做法，成長會更快，效果也會更好！加油吧，測試人！路就在腳下，成功就在明天！

一個用心碼了這麼多文字的人，往往渴望得到大家的認可。如果你覺得這篇文章對你有幫助，輕按兩下螢幕，給我點個贊呀！