有人問:自動化測試的成本高效果差,那么自動化測試的意義在哪呢?
- 請定義“自動化測試”的范疇。自動化測試簡單來講,包括用例的撰寫,代碼的實現,環境的搭建,用例的執行,報表的生成,結果的分析,缺陷報告等等。每個項目自動化程度不一樣,測試人員對自動化的理解有偏差,實際實行自動化的范疇差別很大
- 請定義“成本“包括哪些
- 請定義什么是“高”。高是相對的。比較對象可以是另外的項目或者項目組,也可以是他人的期望
- 請定義什么是”效果“
- 請定義什么是”差“。差也是相對的,可以是同手工測試比較,也可以是同老板的期望比較
如果樓主仔細思考並且回答了以上的問題,我有七成的把握樓主要么不想問這個問題,要么想換個問題。
換一種問法
好吧,為了避免灌水嫌疑,我且以最大的善意揣摩樓主的意圖。樓主是想問:
如果有的項目的自動化測試,我們發現成本高於預期,效果不符合預期,那么問題可能出在哪里?怎么判斷自動化測試是否有效?
-----------------這里是正文開始--------------
關於錯誤的預期
我一點都不奇怪有人會告訴我說:
我都不知道我或者我的老板對自動化測試有什么預期,沒人跟我說過。
或者:
自動化不就是不用手工測試了嗎?用例用代碼實現都能自己跑,測試人員就可以去干別的了,可以少招幾個不產生價值的測試攻城獅了。老板就是這樣計划的。這是兩種非常典型的關於自動化測試的預期問題:
- 根本就不清楚自動化測試的目標,以及為達到目標所計划的投入
- 對自動化測試(通常是總監以上的老板,開發人員或者手動測試人員)抱有不切實際的幻想型期望,認為自動化測試能夠干很多活同時省很多錢
自動化測試的第一目標從來都不是節省測試的人力成本。成功的自動化測試,作為軟件測試的一種工具,從業務最終效果來看,應該是能夠節省成本和提高產品質量的。但是把節省測試的人力成本作為自動化測試的直接目標是錯誤的,而且是致命的。
每個人對自動化測試理解都不一樣,每個項目組做自動化的方式都不一樣。我講個故事,是我認識之前一個印度自動化項目的真實例子。這個項目95%以上的測試場景都是比較復雜的UI測試(Web +Windows Application)他們的自動化是這樣做的:- 手工測試人員把測試用例錄入到用例管理系統,精確到每一步的描述和每一個數據
- 自動化測試人員用代碼(java,python等)實現自動化用例,保存到SCM
- 准備好測試環境
- 打開Eclipse
- 定位到要執行的用例的源代碼
- Run As Junit (因為統一用JUnit做封裝)
- 兩眼直視顯示器,目不轉睛
- 如果有步驟執行不成功,比如某個按鈕點擊不成功,手動幫助點擊,繼續
- 一個用例執行完畢,重復步驟5到9
- 自動化應該是一種Service(Automation As A Service),所有的測試人員和開發人員都應該可以自己很方便的去跑自動化
- 自動化測試的運行結果應該是可以自動分析的,占用很少的時間
- 自動化測試的成功率應該是要很高的(比如95%以上)
- 自動化應該是寫一次,運行很多次,為什么你們花那么多時間還要去改自動化代碼?
這個就是一個典型的不懂自動化的團隊+期望脫離現實的老板。
關於什么是自動化
James Bach 曾經在一篇博文提到,自動化測試這個名字是非常有誤導性的。它讓一般的人誤以為就是測試完全被自動化了,就像一個自動的咖啡機一樣,我只需要把杯子放在那里,按一個button就夠了。James說更加准確的叫法應該是“工具輔助的測試”。當然他還有另一層意思,就是好的測試用例是沒有辦法100%被自動化的,測試人員的經驗,邏輯判斷和探索性的測試方法都不能被有效自動化。我非常同意這個觀點。作為這個論斷的補充和擴展,自動化應該是審視軟件研發活動的每一個環節,去發現那些可以被工具化自動化的重復性活動,然后去實現。廣義的自動化應該包括但不限於以下環節:- 測試環境的搭建和管理
- 測試環境的檢查,監控和報警
- 測試代碼的編譯和測試構建
- 測試代碼的靜態檢查和報警
- 測試用例的分發和執行
- 測試結果的保存與管理
- 測試報告的生成
- 測試優先級的建議
自動化的成本與收益(ROI)
一個過於簡化的公式可以這樣寫:
自動化的收益 = 迭代次數 * 全手動執行成本 - 首次自動化成本 - 維護次數 * 維護成本
或者如果假設迭代次數和維護次數近視相等,這個在某些情況下可以成立,比如一個比較新的產品:
自動化的收益 = 迭代次數 * (全手動執行成本 - 維護成本) - 首次自動化成本
解讀:
- 自動化的收益與迭代次數成正比
- 自動化收益可能為負數:即當自動化成本和維護成本比手動執行成本還高時
- 很多時候自動化成本並不比手動成本高,但是維護成本很高
為什么強調過於簡化,因為這里的自動化收益僅僅考慮時間和資源成本的節省。好的自動化帶來的迭代周期的縮短,是可以縮短項目周期,在某些時候能變不能做為能做,進而帶來的機會收益是巨大的,也是很難量化的。這個就要求決策者對軟件工程和自動化有比較正確的直覺和理解。片面追求自動化的資源節省,或者要求精確量化自動化的收益,本人覺得都不可取。
推論1:什么項目適合自動化
從ROI的簡化公式可以看出,下面幾中情況比較適合自動化:- 回歸測試為主的Support Engineering項目,即需要長期做支持維護的產品。或者有過去版本需要長期做支持維護的產品。這種產品(比如企業軟件,操作系統等)一個版本在發布之后往往需要支持好多年,做bug fix和patch。這個時候每次小版本的開發都會增加迭代次數,並且每次產品變動都非常有限,維護成本相對偏低,自動化收益就非常好。這也是很多企業級軟件或者硬件產品有專門自動化團隊的原因。因為產品的支持維護開發的回歸測試基本靠自動化
- 接口比較穩定的產品,同上
- 手動測試特別費時費力,甚至無法達到測試目的的項目。比如壓力測試,大數據或者大量重復數據測試,必須有自動化工具的支持
推論2:自動化的介入時間點
同樣從ROI的簡化公式推斷出,一個項目的初期可能不太適合自動化。因為項目初期用戶界面和接口沒有穩定,自動化代碼會被動的被要求頻繁改變,維護成本非常高。自動化收益不好。而反而手動測試能夠快速發現問題,反饋給開發人員。而到了項目后期和維護期,自動化再介入為回歸測試做准備,可以最大化自動化收益。推論3:自動化的程度和自動化率
這里自動化的程度是指整個軟件研發活動中引入自動化的程度。推論2中說,有些項目早期可能不太適合高度自動化,但是項目早期仍然可以選定某些環節進行自動化。比如穩定的公用接口,軟件的編譯和部署,環境的搭建等從一開始就比較穩定的部分。
自動化率同樣也要看產品和項目的特性,對於產品的UI部分如果會頻繁改動,可以做比較低的自動化。對於接口比較穩定的服務組件可以提高自動化率。
你有什么樣的團隊,工具和基礎設施
其實這個因素是做所有事情都必須考慮的。自動化測試本身就是軟件開發。好的自動化測試框架,架構設計很重要。這些會決定自動化的開發成本和維護成本。這些都要求很強的開發能力。如果你的團隊只有很有限的開發能力,那么怎么去做自動化,是做最原始的錄制回放,還是數據驅動。復雜自動化也需要良好的基礎設施支持。比如你有很好的DevOps的虛機管理系統,就不用自己去開發,省下的資源和人力也是很可觀的。工具是另外一塊,如果公司有實力支持商業測試軟件和管理軟件,就可以降低編程要求(當然這會帶來一些其他問題)。如果沒有辦法用商業工具,只能考慮開源和自己開發,這個對自動化測試開發的能力要求就高。總之必須選擇和團隊,技能儲備,基礎設施與工具匹配的自動化策略。
管理層的理解程度和支持
這個就不再展開。我見過很糟糕的情況,一個帶好幾百人兼顧產品技術的VP,越3到4級直接給測試團隊提技術需求和建議。你說是做還是不做,怎么做?還有一個團隊,自動化測試人員從來沒有寫過Java或者其他OO語言的程序,被要求從頭設計自動化框架,那就是一場災難。還有一個團隊,管理層幾次要求更換自動化工具,相當於整體重寫自動化腳本。總結
以上應該是一個很粗淺的回答。自動化測試是一個很專門化的領域,自動化測試又是對工程師的技術廣度深度要求很高的工作。對於團隊管理和決策者來講,請不要簡單化和孤立看待自動測試。最重要的是確保聽取真正理解產品,團隊和自動化測試的技術人員的判斷