自動化測試的意義

有人問：自動化測試的成本高效果差，那么自動化測試的意義在哪呢？

我覺得這個問題帶有很強的誤導性，是典型的邏輯陷阱之一。“自動化測試的成本高效果差”是真的嗎？當然不是。而且我始終相信，回答問題的最好方式是把問題本身弄清楚。也就是問關於問題的問題。樓主也學可以進一步 說明下面幾個問題，有助於自己理解自己的問題，更有助於問題得到准確的回答：

1. 請定義“自動化測試”的范疇。自動化測試簡單來講，包括用例的撰寫，代碼的實現，環境的搭建，用例的執行，報表的生成，結果的分析，缺陷報告等等。每個項目自動化程度不一樣，測試人員對自動化的理解有偏差，實際實行自動化的范疇差別很大
2. 請定義“成本“包括哪些
3. 請定義什么是“高”。高是相對的。比較對象可以是另外的項目或者項目組，也可以是他人的期望
4. 請定義什么是”效果“
5. 請定義什么是”差“。差也是相對的，可以是同手工測試比較，也可以是同老板的期望比較

如果樓主仔細思考並且回答了以上的問題，我有七成的把握樓主要么不想問這個問題，要么想換個問題。

換一種問法

好吧，為了避免灌水嫌疑，我且以最大的善意揣摩樓主的意圖。樓主是想問：

如果有的項目的自動化測試，我們發現成本高於預期，效果不符合預期，那么問題可能出在哪里？怎么判斷自動化測試是否有效？

-----------------這里是正文開始--------------

關於錯誤的預期

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

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

或者：

自動化不就是不用手工測試了嗎？用例用代碼實現都能自己跑，測試人員就可以去干別的了，可以少招幾個不產生價值的測試攻城獅了。老板就是這樣計划的。

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

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語言的程序，被要求從頭設計自動化框架，那就是一場災難。還有一個團隊，管理層幾次要求更換自動化工具，相當於整體重寫自動化腳本。

總結

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