我們的自動化測試為什么這么難？

　　筆者在別的貼子里面曾提過，自己所在部門的自動化測試經歷了幾次步進式的建設，都具有階段性的成果，但是總的看來卻不是一個成功的案例。因為趕進度，倉促的投入讓一大堆的腳本質量比較低下，有幾個測試組由于沒有人力投入自動化開發而又不得不完成自動化的KPI，只好聘請外包來幫忙完成自動化。理智地想一想，咱們花的那點錢請到過真正精通自動化技術又肯主動深入考察我們公司業務系統特征的外包么?況且外包終究還是要離開的，所以我們不得不接收一堆沒有經過精心設計、沒有組織性的腳本——尤其是在沒有通用測試框架的情況下。且不說UI測試的自動化腳本本身就運行不了多久就會面臨界面變更，單單是要讓我們接收別人迥然不同的設計風格就是一件很難的事情。結果呢?要么延續這種無組織性，讓腳本數量更加龐大、更加雜亂無章，要么就是放棄對這些腳本的維護，任其自生自滅，最終變成一堆廢材。

　　再想一想如今我們有幾個人在利用自動化腳本幫助自己的測試?高通過率的腳本是否就一定有它存在的意義呢?會不會出現為了應付指標數據，我們讓我們的腳本設計和驗證得盡可能地簡單、盡可能地能運行通過的情況呢?他們可能即便不放心自動化測試結果，也可以手工再回歸測試一遍……這種滑稽的現象表明自動化測試已經徹底的成了包袱!雖然我們公司崇尚結果導向，但是我覺得我們應該首先從根本上弄清楚什么目標才是我們最終想達到的。KPI考核的導向性作用很強，但是如果KPI并沒有能夠幫助我們得到我們想要的結果，那么KPI的設定就不是SMART的，持續改進意識不僅僅是流程規范，還有我們的KPI，對于自動化測試來說尤其重要。

　　我們有一部分同事宣稱：“我知道自動化能給我帶來便利，但是我實在沒有時間投入腳本開發”，其實就是骨子里抵觸自動化測試，抵觸工作方式的改變。另一部分人則很狂熱，看到自動化的些許好處就開始盲目崇拜自動化測試，也正是由于這種急功近利的心態，讓他們在“看到”一些失敗之后就將矛頭直指測試工具，而并不去反思自己在整個實施過程中采用的方法。攻擊某種工具是如何的不好，另一種工具如何的優秀，但是不去分析其中的差異，武斷地對大家宣稱換一種測試工具能夠節省成本、提高測試有效性。其實各種測試工具各有優點側重，其應用范圍和方法都有所不同，還是要理性地去看待這些問題。我本可以把別的測試工具數落一番，但我又不敢，因為我著實還沒有精通它們的使用方法，所以也不是非常明了它們的弱點，單就大家常說的QTP的弱點來說：

　　需要付出昂貴的工具許可費用，的確是很大一筆費用。但是買都買了，莫非我們還要找廠商去退貨?再者，我們省掉的可能是工具許可費用，但是要付出的則是培訓人員新技能的費用、開發測試管理工具和新測試工具接口的費用和為仍然可能出現的失敗買單的代價;

　　需要大批的運行客戶端，情況的確是這樣，但是做真實的頁面模擬測試，并且不能繞開我們系統的SSO認證，用什么工具都是一樣的，不信的話可以自己去驗證一下;

　　對象經常不能識別，凡以此為由貶低QTP的人都可以回去面壁了，那么簡單的技術都用不好又何必再言其他?我相信也有一些QTP粉絲們在對開源測試工具的易用性不斷地腹誹，論壇上甚至還有謾罵聲;

　　運行經常莫名其妙的失敗，這是測試環境問題、運行客戶端問題、腳本健壯性問題，這些問題可以得到解決，我們也可以通過解決這些問題來更加深入的了解我們的測試工具。

　　這些現象從根本上反映了人在出發點的心態和對工具的認知水平才是決定自動化測試實施成敗的關鍵。對自動化測試工具的使用來說，我很慶幸自己選擇了一個由簡單到復雜的學習過程;如果先學習了較為復雜的，再去使用這些所謂“簡單”的商業工具，很容易產生剛入門就輕視的情緒。正是為了避免自己“半瓶水瞎晃蕩”，我們試圖努力地去學習、了解別人的所思所想，可結果是，越學越迷茫、越學越恐慌——以前眼中的小小領域竟然包含如此之多的知識，學海無涯一說實誠不我欺也!而在學習的同時也深深的為我所看到的一些現狀擔憂，正是由于這種擔憂，即便知道自己只是半瓶水，但還是忍不住站出來，東一榔頭、西一棒槌的“晃蕩”幾下，繼續扮演領導眼中一個不明真相的圍觀群眾的角色。

　　別試圖用底層測試取代頁面測試

　　測試基礎理論告訴我們：缺陷發現的越早，修復所花的成本越低;所以對于自動化測試來說，如果應用的越早，它的收益就應該越多。所以現在很多公司都在推行集成測試、單元測試的自動化建設，我們也不例外。我們把這些自動化測試工作納入測試部門的日常工作中來，試圖在每日回歸自動化中使用這些測試，而同時測試環境和版本管理非常嚴格，那么這部分的自動化測試執行還是要等到版本一板一眼的把流程走完，部署到測試環境之后才能開始。如此一來，這部分集成測試和單元測試的自動化的執行時間并沒有被提前，和敏捷更是掛不上邊。我們的版本流程清晰的從時間上分開了單元測試、集成和系統測試，也從流程上基本上消滅了在測試環境做非系統功能、性能測試的可能性。所以，如果說要開展以贏得更多效益為目的的底層的自動化測試，還是需要推動編碼人員去實施這部分測試內容或者變革版本流程，做到將底層的自動化測試在開發環境進行運行，達到測試出口之后再進入系統測試階段。

　　單元測試和集成測試全部通過完成之后是否就意味著本次構建測試就是通過的呢?當然不是。在很多夾雜著復雜業務邏輯的軟件中，復雜的操作場景和數據邏輯的正確性驗證還是要依賴大量的UI層面上的驗證測試。所以對于有些形態(例如金融類)的軟件產品的自動化測試來說，有足夠強大的UI層自動化測試支持也是必需的。早已有很多人已經給底層測試覆蓋的作用蓋棺定論：并不是每一個功能點和每一個分支測試通過就意味著軟件質量是合格的，因為對于不同結構的系統來說，有些程序邏輯很依賴前端，有些程序邏輯更偏向于倚重核心，加上數據的復雜業務特性也不允許我們忽略復雜場景組合帶來的一些新問題。也就是網友所說的“代碼覆蓋只能告訴你什么沒有測試，卻不能告訴你軟件是否通過了有效測試”，正是基于這點，如果傾向于用單元測試或者集成用例測試來豐富自動化回歸測試范圍的話，我們能夠理解;但是如果想用單元測試或者集成測試用例來替代回歸測試中對應的內容，那么就沒有什么意義了。而且筆者提倡如果某個功能如果同時能夠通過頁面和底層去驗證的話，就盡量不要去做底層的測試，至少在非敏捷的項目中或者在測試部門的系統測試工作中，不要去這么做。不知道這種說法是不是顛覆了一些人心中的觀念，且不要急著拍磚，下面我們繼續討論。

原文轉自：http://www.anti-gravitydesign.com