自動化測試的意義


有人問:自動化測試的成本高效果差,那么自動化測試的意義在哪呢?

我覺得這個問題帶有很強的誤導性,是典型的邏輯陷阱之一。“自動化測試的成本高效果差”是真的嗎?當然不是。而且我始終相信,回答問題的最好方式是把問題本身弄清楚。也就是問關於問題的問題。樓主也學可以進一步 說明下面幾個問題,有助於自己理解自己的問題,更有助於問題得到准確的回答:
  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語言的程序,被要求從頭設計自動化框架,那就是一場災難。還有一個團隊,管理層幾次要求更換自動化工具,相當於整體重寫自動化腳本。

總結

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


免責聲明!

本站轉載的文章為個人學習借鑒使用,本站對版權不負任何法律責任。如果侵犯了您的隱私權益,請聯系本站郵箱yoyou2525@163.com刪除。



 
粵ICP備18138465號   © 2018-2025 CODEPRJ.COM