初次接觸自動化測試：基本架構設計的能力

作為新員工時，做的自動化測試是捕捉系統的窗口句柄然后往里面發送字符串，連測試結果都不能自動檢查，還要自己去看日志或者截屏。盡管那時的自動化做得非常粗糙，但也極大地鼓勵了自己。每天跑著這樣的腳本，想象著這些腳本接下來一定會變得很強，于是樂此不疲。

開始主動向公司的自動化測試前輩（本部門、外部門）學習。滿懷信心，利用加班時間來學習腳本語言和工具的使用。但很快就發現，自動化測試并不像我想象中那么美：

·一個非常簡單的功能，寫好再調通，花費的時間并不少。很多時候手工測試5分鐘就能做好的事情，調好腳本要花1個小時。

·腳本執行時一旦發現問題，排查起來花費的時間也不少。一旦腳本報錯，會再反復跑幾次，先確認是不是真的有問題，再在腳本中加各種打印或者等待來定位問題。

由于測試的產品定制多、版本分支也很多，我發現如何把這些腳本管理起來，以便在不同的版本中運行也是個問題。

這些問題讓我有些沮喪——大家都說自動化測試可以提高效率，怎么到我這里就不靈了呢？

我開始意識到，自動化測試不是有了工具，有一腔熱情，然后通過加班就可以完成的事情。這需要有基本的架構設計能力，能有手段和方法檢查腳本的運行結果，并能有效管理這些腳本。每一件事情背后都工程方法，需要有策略有規劃，一步步來完成。

第二次自動化測試：自動化的意義

認為第一次自動化測試失敗的問題，主要出在缺乏規劃和設計上。既然找到了問題，我決定和我的小伙伴一起，再來做一次自動化。

既然是要做規劃，第一步肯定是定目標。由于團隊也是第一次做自動化，那從簡單內容入手是比較靠譜的；另外回歸測試中有大量重復測試工作，測試的內容也比較基礎，很適合使用自動化。這樣我們團隊的自動化目標就變成了從簡單的內容開始，將自動化腳本用于回歸測試，達到100%自動化回歸測試。

這個目標看起來沒毛病，但實際執行起來卻變了味。在“簡單的內容先自動化”的思想下，大家心照不宣地做了很多非常簡單的測試界面配置的邊界值腳本。

由于希望把自動化腳本用于回歸測試，這些測試配置的極簡腳本就順理成章地成為回歸測試用例集。

但這樣的回歸測試自動化，大家打心底都不認同，覺得這些腳本的測試內容執行起來沒有任何意義，就是說出去好聽而已（我們實現了100%回歸自動化測試）。運行幾次之后，大家就很自然地不想再繼續了。

這次經歷讓我對自動化測試有了新的思考——自動化測試要從解決煩瑣工作入手，而不是從簡單工作入手，要讓團隊看到自動化測試切實的效果。只有這樣，自動化才能真正被團隊接受，而不是變成勞民傷財的花架子。

第三次自動化測試：自動化腳本的誤判

認真總結第二次自動化測試的經驗教訓后，準備再發起一次自動化測試實踐活動。

為了保證自動化測試的有效性，我專門組織大家，從手工測試中選出那些需要反復執行的測試用例，作為自動化測試用例，然后從當前自動化測試技術的角度，對這些測試用例是否具備自動化的條件仔細梳理了一遍。我們對自動化測試平臺底層技術進行討論，并做了一些優化，還討論制定了團隊的自動化開發規程，討論了腳本的組織和管理形式。領導也開始更加關心自動化測試，大家的激情都被重新點燃，干勁十足。

就當一切都在向著好的方向發展的時候，新的問題又出現了：自動化腳本出現了誤判！換句話說，我們無法相信自動化測試的結果，自動化腳本運行結果是失敗的測試用例，可能僅是自動化環境的問題；自動化腳本運行結果是通過的測試用例，實際功能卻可能有問題。

我們想了很多辦法去解決問題，比如每一輪自動化測試，同一個腳本都反復執行幾次（如執行5次），然后設置一個腳本執行失敗的容錯值（比如設置容錯值為2，即執行5次這個腳本，腳本失敗只要不超過2次就算通過）；想辦法保存所有的測試執行記錄，然后再手工抽驗測試記錄，確認是否有腳本判斷漏掉的異常。

其實這些問題，歸根到底還是腳本的檢查部分，或者說斷言寫得有問題。

讓自動化腳本按照測試者的意愿執行測試操作其實并不難，難的是讓自動化腳本可以像測試者那樣檢查預期。比如，對預期內的結果，自動化腳本要保證效率，要避免誤判，除此之外，還要注意捕捉預期外的各種異常。

第四次自動化測試：規模化自動化

慢慢地，我們團隊有了較多的腳本，但這些腳本都是基于用戶接口設計的腳本，執行一個腳本需要做不少配置，我們的產品部署都很復雜，有時候需要多個產品才能完成一個功能。為了避免不同腳本之間配置干擾，每執行一個腳本我們就要初始化一遍，以清除掉當前的配置，恢復環境。盡管我們實現了并行化，但是自動化腳本的執行效率依然很低。當自動化率到10%左右的時候，團隊好多同學都認為我們的自動化已經到頭了，因為我們維護這些腳本已經很難了，再繼續下去，自動化測試的復雜度會超過手工測試。自動化測試進程再次進入僵局，徘徊不前。

這再次刺痛了我，我發現我做了這么久的自動化，并沒有真正感受到過自動化的便捷，相反它成為一個負擔，我不知道接下來該怎么走。

這時又出現一個轉機，公司的高層開始非常重視自動化，成立專門的自動化測試小組。高層領導直接定了一個很高的自動化目標，自動化率要達到80%。我們覺得這是不可能完成的任務。但是自動化測試小組的負責人卻在領導的支持下，做了一系列的改革：

1）要求開發人員進行單元測試。

2）增加接口自動化測試。

3）對用戶層面的自動化測試，在需求確定后，就要求開發人員確定用戶層面的輸入輸出，且一經確定不能隨意修改，然后自動化測試團隊開始封裝關鍵字。我們可以在測試用例設計完成后直接使用封裝好的關鍵字編寫測試腳本。這樣我們真的做到了可以用自動化來做新功能的測試。

對那些自動化中的困難點，例如前面提到的每個腳本要恢復配置，自動化測試團隊基于此給產品開發團隊提交了自動化可測試性需求。我們通過腳本執行起來費時費力的操作，產品開發團隊通過內部設計很容易就搞好了。

由于這個自動化測試團隊是一個拉通了所有產品的資源部門，他們還將腳本按照場景做成了測試套，供不同產品團隊在有類似需求時選用，大大加強了腳本的復用率，促進了自動化測試規模化發展，也讓我第一次切實感到了自動化測試的威力。

這次自動化的經歷給了我很大的啟發。我感到自動化測試，并不是測試人員單方面能夠搞定的事情，要想做好自動化，需要領導的支持，需要產品、架構、開發等全流程的支持。

自動化建設同樣需要分層，可分為單元測試和接口測試，這樣用戶層面的測試就可以減少，版本質量也會更好，自動化測試的效率會更高。

從自動化測試技術的角度來說，第三次和第四次并沒有本質區別，差別在于流程中各個角色的配合方式，也就是工程方法。我們需要全局看整個產品的狀況，制定合適的自動化策略，以此來推動自動化測試發展。

講完故事，我們再回過頭來討論一些與自動化測試相關的觀點。聊了那么多，我認為自動化測試最基本的要求其實就是兩點：

1）測試者能夠充分信任自動化的結果。

2）自動化腳本可穩定連續運行，可維護，可移植。

自動化測試是值得每個測試者去探索和實踐的，但我們也需要知道自動化測試的真相。

真相1：自動化測試并不廉價，其實自動化很貴。

自動化測試是用一段程序去測試另外一段程序，這中間需要花費的成本并不少。

真相2：自動化測試的意義首先在于固化能力，其次才是提升效率。

自動化測試的意義，首先在于固化能力——把原來測試人員的能力，通過腳本執行固化下來，形成標準的組織資產；其次是效率提升。從另一個角度來說，效率提升是反復執行帶來的，是能力固化后的副產物。

理解了這一點后，我們可以更加理性地看待自動化，認識自動化的價值。我們應該本著固化能力的原則去設計自動化架構，發展自動化。通過腳本自動執行相關步驟只是自動化進程中的第一步，可靠的檢查點設計、腳本的穩定性、腳本的組合和連跑、腳本的可維護性和可移植性，才是自動化架構需要不斷打磨精進的內容。

真相3：自動化測試不是單靠測試人員就能搞定的。

自動化測試聽起來像僅是測試人員的事情，但是想要真正做好自動化測試，達到規模化自動化的效果，并不是測試人員單方面就能搞定的。

摘取自劉琛梅老師的《測試架構師修煉之道：從測試工程師到測試架構師 第2版》