自動化測試能否幫助我們我們提升開發效率，關鍵在于其有效性。如果其有效性可能存在問題，那么可能是什么導致了這種問題的產生呢？對自動化測試產生作用的方式存在誤解，對自動化測試能夠產生作用所要求的條件存在誤解，自動化測試分析設計的隨意性，自動化測試開發維護的低標準，對自動化測試資產的低準出條件……本文將就自動化測試有效性簡單闡述我自己的一點見解，拋磚引玉。
觀念之一：獨木難生于漠，密植方育甘霖
沙漠中間栽下一棵樹，枯死只是遲早之事；即便有足夠的資源讓它能夠永久地生存下去，而它除了給路過的攝影師的構圖上增添一分綠色氣息，便再也沒有其它存在的意義了。如果要想它能夠長久而有生命力地活下去，并期望它能夠改善生態，那就需要將其根植在一片密林之中。自動化測試，尤其是前端自動化測試，如若離開其他層次的自動化測試和技術手段與之相互配合，便會如同這棵沙漠中間的樹一樣，不久便滅。
五一節后的周五下午和兩個開發經理一起review一個項目的性能測試需求，休息閑聊時順道提到了其中一位開發經理所負責的公網系統CI連續飄紅的問題。他坦言自己對自動化測試是不信任的，認為自動化測試發現不了任何問題，從而對CI帶來的幫助表示懷疑，因此不愿意在CI上投入過多的精力。我理解這位經理的感慨，認同他對自動化測試有效性的擔憂，但是這并不能使我認同他對CI和自動化測試的態度。而對于軟件開發來說，沒有自動化測試、沒有CI，我們可能無法期待更高效率的開發和更好的質量保證。但他這是因為沒有耐心地植下一片樹林，才導致他心目中自動化測試這棵大樹的死亡，進而卻又否認這片樹林存在的意義，是不妥的。
觀念之二：降低期望于心，提升目標于行
為什么有很多人對自動化測試的可信任程度表示懷疑呢？這源于一句看似真理的廢話：自動化不是用來發現缺陷的，而是為了驗證系統改動是否造成關聯影響并用以增加質量信心的。這話本意無非就是想告訴大家：不要對自動化測試的結果抱太高期望，對機器智能和人腦的差距要認清。這個本意本無可厚非，但是這句話現在卻逐漸成了自動化測試低質量的借口了。
首先，很多人認為自動化測試無法發現缺陷是因為測試腳本無法代替人類的自主思考，無法靈活變通。而我們之所以期望在測試執行時能夠靈活變通，是因為測試分析設計時對被測應用設計細節的不確定性。非探索式的腳本化測試設計就是要通過輸入精確的操作和數據類型，從而得到精確的輸出來和預期結果進行對比，在這種模式下，沒什么問題是需要變通才能被發現的。
其次，不得不說自動化測試分析設計的難點在于對輸入條件分支和狀態機組合的窮舉和選擇上，這需要很大的成本。不幸的是，通常在做自動化測試分析設計時，我們習慣于用經驗和主觀感覺去做，不全面和主次不分的情況常常出現。因而，自動化測試分析和設計的不嚴謹、不完整也是自動化測試不能被信任的原因之一。
此外，自動化在那些已覆蓋的測試上面表現的也不盡如人意，筆者觀察到，大多數人并不是用自動化測試腳本去做測試或質量守護工作，而只是用來讓他們運行通過，以獲得KPI的達成和成就感。自動化測試運行失敗，不習慣于或不樂于使用它的同事就會很輕易忽略潛在的問題，所以漏測和封版延期是常有的事。
最后打個比方，自動化測試就像是看門的狗，沒有它，家里進賊未必發現不了，關鍵是發現的時候是否還來得及挽回損失，而狗狗能不能在有賊光顧的時候示警，取決于我們如何馴養它。我們期望家里進賊的時候狗狗能夠示警，但并不會期望它能夠幫我們直接把小賊擒住；而且并非每次狗狗示警都意味著有賊入室，也有可能是閣下經過而已。自動化測試與此類似，凡其所致，但有一點不一致便會得到失敗的結果，而至于是不是發現了蟲子卻又是另外一碼事，想用自動化幫你解決所有問題，那你還是洗洗睡吧。
總之，我們對自動化測試有什么樣的期望，就應該有什么樣的目標和要求；設定了什么層次的測試目標，就應該有什么樣的使用效果。如果告訴你自動化測試可以朝著任意品種的狗狗去培養，目標就是看家護院，你非要以哈士奇食量大喂不起為由非要選小泰迪，那能有什么辦法呢？如果自動化測試分析設計不嚴謹，而已覆蓋的腳本也沒有嚴格編寫，而或腳本嚴格編寫卻并未善加利用，那么自動化測試自然就是一個徹底的謊言了。
我們可以期望用自動化測試來暴露所有的問題供使用者抉擇，而非用來精確定位每一個問題。即便我們不期望自動化測試發現所有的BUG，但是我們必須要用發現每一個BUG的標準去分析設計和利用我們的自動化測試用例。
方法之一：善用手動測試用例庫
如果有完整或近乎完整的手動測試用例庫，在做自動化測試的時候用它來甄別自動化測試范圍、做自動化測試需求分析和設計是非常棒的，可達事半功倍之效。因為除了SLA簽訂的關鍵功能清單，我們可以分析測試用例庫中最近X個月、Y個版本中被執行的測試用例的頻率和比例等等數字，從而很容易得出最有價值做自動化測試的范圍，而如有其他因素也可以加入綜合評估。這時候，關聯或映射手動測試用例和自動化測試腳本可以很容易地衡量自動化測試的覆蓋率等相關指標。
除此之外，手動測試用例之于自動化測試開發的意義還在于一種特定模式下的自動化測試開發：測試人員按照一種特定的規約編寫產品或項目的手動測試用例，隨后用一種模型化的轉換規則去生成自動化測試腳本，繼而再去修改和優化。這種模式的好處是，自動化測試腳本的開發者不需要懂業務知識，只需要按照業務測試人員編寫的詳盡的測試用例去實施。而不足之處卻也十分明顯，由于思維方式上的差異，編寫測試腳本過程中的溝通成本不會太低，而且對建模水平要求很高。
方法之二：搭建適應性強的框架
開源測試工具，我們組先后用過Selenium RC、WebDriver、WatiJ這幾種工具模式，框架采用JUnit和TestNG，測試調度和CI使用Jenkins管理。做起來最大的感受就是，像WebDriver這種工具，它本質上是為互聯網而生；如果要用于我們的企業ERP應用的自動化測試，如果沒有做一系列適應性的API和組件封裝，測試腳本開發對于大部分同事來說都是件頭疼的事情。
經過摸索，我們結合PAFA（PingAn Foundation Architecture）架構的前端頁面特征做了對象識別、頁面加載和處理緩沖、運行監聽、數據處理、斷言和運行容錯、報告、日志以及第三方組件（如Autoit、Cmd等）兼容的封裝操作。這種封裝屬于Bot-Style，適用于我們基于業務操作驅動的自動化測試用例編寫，能夠大大地降低我們測試腳本開發的技術成本。雖然它們看起來運行起來效率并不是十分高，但是對于被測應用的響應速度來說已經是數十倍的效率勝出了。至于使用Page Object還是Bot-Style，還請大師們不要吐我的槽，這沒什么可爭論的，因為這只是面向前端業務操作的頁面測試，二者的表現毫無優劣之分，完全在于隊員的測試腳本編寫風格偏好。
附圖1：測試中的TestCase樣例
附圖2：測試中的TestApi樣例
我們正在從瀑布開發模式下逐漸開展持續集成和敏捷轉型，不難預見，達到一定成熟度之后我們大部分團隊會使用ATDD或BDD模式。這種快速開發的基于前端的自動化驗證測試雖然在驗證測試中所占的比例會越來越小，但它們將依然有用武之地，同時對當下的系統前端的回歸測試也可以完全支持。
自動化測試框架強大與否主要在于其適應性，所以與其說自動化測試框架是選擇出來的，不如說它是被改造出來的。產品比較單一的小公司或者開發框架比較成熟的公司用一個工具、一個框架在一個測試平臺下就可以解決一個公司的自動化測試實施的絕大多數問題，而大型企業的應用繁多復雜，很難由一個簡單工具或者框架來解決。
自動化測試框架，沒有自己DIY過的永遠都不要相信不造輪子這種說法，因為只有在你做的時候，你才能夠更深入地理解你的工具、框架和你的被測應用及其所依賴的開發框架的特征，才會產出更具適應性的測試框架和特征庫。
方法之三：善用設計與重構
無論是前端自動化測試還是單元測試，腳本代碼結構的重要性是個老生長談，因為這關乎測試腳本代碼的可讀性、維護經濟性等問題。由于我們的業務系統的測試案例主要是基于操作流程的業務場景，所以我簡單說一下我們在這方面的做法與經驗，而單個功能點特性的測試分析也基本與此類同，不再獨占篇幅。
測試范圍與設計
大型企業，尤其是金融行業的ERP應用，很多系統實際上都是規則零散、流程復雜，規則引擎應用得并不是很充分。這便是前文所提及的自動化測試分析設計時對輸入條件分支和狀態機組合的窮舉和選擇困難的問題的產生原因了。對于這種情況，我們可以借鑒兩個基礎的測試設計方法：正交覆蓋和Pairwise/All-Pairs，其基本原理和用法這里不再贅述。
以正交覆蓋為例，我們需要把影響流程分支走向的因子羅列出來。一般理論認為，缺陷的產生絕大多數是因為2個因素組合產生的，所以我們先做一個正交強度為2的配對來確認最小的測試組合范圍。然后將正交強度變為最大，得到一個最大的測試組合范圍，重新審視強度為2時的子集之外的其他案例是否有必測的理由。注：正交強度最大的組合結果集并不是簡單的笛卡爾乘積，因為組合條件之間可能存在一些邏輯限制；此外，鑒于篇幅有限，本文就不再羅列下表最終正交得出的測試組合結果。
圖3：保險業務操作偽場景分析正交表樣例
通過對前端業務操作流程的分析，可以建立完整的前端的測試用例庫，當然，前端的自動化測試可能只會選擇其中的一部分去做，如上文所述，自動化測試覆蓋率也可以很輕易地度量出來。在設計評審過程中，流程設計完成者需要向評審人員展示各個業務流程的測試組合結果，并且解釋通過怎樣的組合方法得到這些結果；進一步闡述依據什么樣的原則得出自動化測試范圍的選擇結果。
特性組件抽取
完成了對測試案例場景的界定，我們便已明確我們要在被測應用上做什么樣的操作，接下來的工作就是一些通用的簡易特性抽取。雖然很多人聲稱復用不是個好東西，但它在編寫測試腳本中適度的使用，卻也可以很好地減少測試腳本開發和維護成本。
第一層的特性抽取可以通過測試框架和工具來完成，簡易的二次封裝是保證測試書寫低復雜度和保證測試腳本健壯性的好辦法，就如同圖中對click方法的簡單封裝一樣。這件事情只需要一個像筆者一樣略微熟悉測試工具和被測應用特性的測試工程師即可完成。所以這個活動的成本不會太高，而帶來的效益卻還是很不錯的，至少可以給不熟悉測試工具的腳本開發者一段很長的學習緩沖期。
圖4：STAR測試框架中的Api樣例
接下來就是被測對象的共有特性組件做抽取，仍以前端自動化測試腳本開發為例，我們可以參照被測應用本身的組件復用規律來提取測試腳本中的公用頁面組件。例如，圖3所涉及的保全操作流程中，至少包含保全申請發起、質檢、核保這三個可公用的頁面組件。假如最終需要測試的場景案例有8個，其中5個必須質檢、4個必須人工核保，那么在這三個點上就可以節省14（8+5+4-3）個測試Api的維護和開發成本。
共有特性組件既不能設計的過于粗糙，從而造成在不同的自動化測試腳本中無法統一支持；又不能過度抽象，進而導致可讀和可維護性變差。目標很簡單：任意一處純前端頁面的改動，我們只需要修改一個測試Api；任意一個分支場景的規則改動，我們只需要修改一個測試案例腳本的數據和驗證方法。
腳本重構與舍棄
雖然測試腳本應該被良好地規劃設計，但實際執行的時候可能會遇到一些問題，比如在識別公用特性組建時存在遺漏卻未在評審環節被發現，抑或被測應用的代碼重構甚至是流程再造同樣會要求我們去做這些對應的測試腳本重構的工作。
我每天都會從SVN上checkout我們組17個工程的測試腳本，之前經常會發現某些系統一次性update十數個甚至數十個文件。這時候我會問一聲為什么，最初得到的答復都是由于系統頁面發生變動，所以這部分測試腳本都需要同步修改。我的回復一律都是：重構，重新做公用組件抽取，立刻做，因為我們耗不起這個維護成本！幾次之后，再遇到這種情況，得到的答復便基本上都是：因為XX的變更影響了一些模塊的測試腳本，所以我重構了一下。這時候我的心里就比較嗨皮，比較有成就感了，因此我也樂于不斷地給大家灌輸這種從別處學來的理念，而測試腳本重構的動力也從單純的前端頁面變更驅動變得更加多樣化。
伴隨著測試腳本的開發，債務不可避免的在不斷產生，如果不加以管控，終有一天我們都會由于對之無法負擔而崩潰。所以我們如果真的重視自動化測試，我們就需要不斷地優化我們測試腳本的結構，讓它始終停留在我們可以控制的范圍之內。必要的時候我們可以放棄一些已經開發完成的但是優先級稍低的測試腳本，即便它們運行得很好。在負擔能力滿載的情況下，以放棄低優先級的部分為代價來換回我們對測試資產持續優化和維護的能力、換回我們對這種低端技術債務的負擔能力，始終都比承擔不可控甚至崩潰的風險要來得更加有價值。
方法之四：堅持定期腳本審查
在團隊里面推廣自動化測試應用，同樣也會存在很多溝通和理解上的誤差，加之不是所有人的技能都在一個層次上，所以大家可能對測試腳本開發的各種要求的理解上都會存在不同的誤區。因此，測試腳本開發完成之后第一時間要進行審查，這是測試腳本有效性驗證的第一道關，雖然這個活動將耗費不少時間。
測試腳本審查的手段分兩種：工具檢查和評審會議。一般建議在召開評審會議之前使用代碼掃描工具如sonar或者checkstyle、 findbugs等，定義一些通用的規則去檢查測試腳本書寫和設計結構上的問題。使用工具的方法本文不介紹，完成這些基礎不合規項的檢查和修復之后則可以開始后續的測試有效性評審。測試有效性評審是個技術活也是個體力活，不僅需要很強大的業務知識支撐和對系統設計模式甚至架構的理解，同時也需要足夠的時間和耐心來從事這項活動。接下來，簡單說一些實際的檢查點，通過這些檢查點，我們將識別一段測試腳本是否能夠達成測試目標，是否經濟合理。
● 經過設計評審的每一個案例是否都已經完成開發，是否存在額外的新增覆蓋，為什么；
● 預設的公用組件是否已經完全抽離實現，對于假設的被測應用修改，能否用最簡單、最經濟的測試腳本修改來支持同步；
● 測試數據的初始化和使用是否合理，是否會破壞測試環境中數據的健康度甚至帶來環境故障；
● 測試的驗證點是否精準足夠，是否存在反向的驗證方式（如，只檢查是否有錯誤發生）；
● 測試腳本中是否存在多余的結構體，是否存在非預設的隨機性分支；
● ……
子曰：腳本三月不復查，CI即便全藍——蟲子照樣遍地爬！自動化的測試有效性本就是需要通過維護去保持的，定期重新審查本就是一種測試腳本的維護手段，是非常有必要的。而頻率則需要結合團隊對測試腳本維護的力度來看，復審的主要的方法與開發完成之后的初次審查是一樣的，只是關注點會稍有不同。
兩句廢話做總結
自動化測試是達成目標的工具手段還是負擔，關鍵在于它對我們產生了什么樣的影響，要產生好的效用，就必須保證其測試有效性。保證自動化測試有效性的手段很多，筆者目前的水平只能說到這里，但愿對入門者和彷徨者有所助益，高手和噴子們便一笑而過便可。