1.4 如何進行自動化測試

在討論這一話題之前，我們先來看看兩名測試人員的故事。

小簡和小琪是同一個測試團隊的成員，他們各自負責某個產品模塊的測試。日常工作包括理解與確認需求、準備測試用例、執行測試、提交和復測Bugs等。隨著業務的發展，小簡覺得工作量越來越大，壓得他喘不過氣來，而小琪仿佛游刃有余，工作效率明顯高于小簡，還發現了一些容易忽略的回歸測試過程中的Bugs。小簡很苦惱，自己已經非常認真了，為什么有些問題還是容易漏掉，沒發現呢？小琪的高效到底高明在何處？

于是，小簡帶著滿心困惑去“取經”。兩人展開以下對話。

小簡：“小琪，上次那幾個bugs你是怎么發現的？開發又沒說他們動了那幾個地方，你怎么連這么小的細節都留意到了呀？”

小琪：“哈哈，其實不是我留意到了，是我的腳本幫助我發現了那里的問題。”

小簡：“噢？什么腳本？”

小琪：“我最近在學一個叫Selenium的自動化測試框架。咱們在瀏覽器頁面上做的那些操作都可以用腳本來實現的。有幾個重要的功能，咱們不是每次上線之前都要做回歸測試嗎？我就干脆用腳本實現了，要測的時候先跑跑腳本。上次那幾個bugs，是因為我的腳本里正好有那幾個檢查點，腳本報錯了，我才注意到那個頁面有點問題。”

小簡：“噢，原來如此，既然這腳本這么好用，你就分享出來，讓大伙兒都用起來唄。”

小琪：“以后會分享的，現在還不是時候呢。現在只是零碎的腳本，我想搭個框架出來再分享。有了框架，也方便大家去補充和維護用例了。”

小簡：“好的，太期待了！我也得學學Selenium，好多在頁面上點擊的活兒就不用那么費勁了。不過平時那么忙，你是怎么擠時間學的呀？”

小琪：“我最近不怎么看劇、打游戲了，反正想學總能擠出時間。其實你有編程基礎，Selenium上手挺容易的，只是用到咱們項目里還有一堆問題要考慮。咱們以后多多交流吧！”

就這樣，小簡從小琪那里聽說了Selenium這門利器，開始了自動化測試的學習之路。

故事講完了，不知道上面的對話是否喚起了你的共鳴？執行測試是一個迭代的過程，充滿了重復煩瑣的勞動。反復地操作，反復地確認，對于喜歡挑戰未知的人而言，這樣的工作是在透支工作激情。從另一個角度來說，大量反復確認的工作往往會帶來很強的疲勞感，容易熟視無睹，就這樣放過了Bugs。如何跳出這種“溫水煮青蛙”的局面？顯然應當減少重復勞動，提高測試執行的效率，節省時間去做更有價值的事情。

作為一個測試人員，追求功能測試的自動化，用技術提升工作效率，是一種本能的行為。故事中的小琪就主動使用了Selenium這款UI自動化測試工具，將自己從某些枯燥煩瑣的工作中解脫出來，并交付更好的工作成果，這正是測試人員自我學習的原動力。

以產品或者團隊的角度而言，何時進行自動化，如何有效地實施自動化測試，需要考慮方方面面的因素。比如，測試人員是否有技術背景，編碼能力如何，是否有時間編寫和維護測試腳本，是否有合適的工具或框架滿足自動化測試的需求等。

編寫自動化腳本，有人稱為“測試開發”。因為它確實需要測試人員具備很多開發技能，如環境部署、代碼能力、深入理解產品的技術細節、代碼版本控制、持續集成等。不同的人有不同的背景、不同的目標、不同的測試內容，自動化測試的實施方式自然不同。這里簡單陳述兩種不同的組織形式。

由獨立的團隊去做自動化。對于復雜的產品，尤其是銀行系統、醫療軟件等特別領域，任何人都不可能掌握所有的細節和使用場景，產品復雜度涉及技術、業務知識、交互設計等多個方面。它們的研發人數多，跨部門溝通多，產品功能在開發階段的變更不會很大，除了有功能測試人員之外，還有獨立的自動化測試團隊、性能測試團隊等。大多是把集成測試或驗收測試的用例在評審之后交由自動化團隊。

把自動化作為每個測試團隊成員的日常工作。有些公司會把掌握自動化寫入測試人員的招聘啟事中，甚至與從業年限掛鉤，作為是否入職和績效考核的標準之一。測試人員在設計用例的時候就開始考慮是否能夠自動化，大概在什么時間點補充自動化腳本。這種團隊的任務分配形式可以更加豐富，比如在版本1.0時，甲負責A模塊的手動測試，乙負責B模塊，此時大家都沒有時間寫自動化腳本，產品就上線了；而在版本2.0的開發過程中，測試人員可以編寫1.0的腳本，甲寫B模塊，乙寫A模塊，他們寫腳本的過程也是對用例評審的過程。