測試發展至今已十年有餘，測試的工作也越來越受到各方面的重視，對於測試人員的要求也越來越高，據不完全統計，目前測試專案自動化要求已經接近5成，自動化測試已經在測試行業中佔據了相當的地位，而開展自動化測試的要求也越來越高，那麼就更加需要測試人員能力的提升，所以今天就為大家分享部分關於自動化的內容

眾所皆知，測試應該自動化。敏捷強調要實現測試自動化，但是我們往往都做的不夠多、不夠快、甚至可能根本沒有做。我認為，測試自動化不足的主要原因之一是因為我們關注錯了自動化的層次。大多數團隊都把精力集中在單元測試和UI測試上，卻忽略了服務層測試。

為了說明為何服務層測試如此有價值，讓我們仔細觀察下測試自動化金字塔的每一層。

單元測試

單元測試構成了測試自動化金字塔的基礎。因此，它應該是可靠的測試自動化策略中的最大部分。自動化的單元測試是非常棒的，因為它能夠向程式設計師提供具體的錯誤資料。

例如，自動化的單元測試報告說“在第56行有一個BUG”，那麼程式設計師可能就真的會在62行附近找到這個BUG，相對而言測試人員只能告訴“在你從資料庫中檢索成員記錄的過程中出現了BUG”，這意味著你可能需要在1000行以上的程式碼中查詢這個BUG，自動化的單元測試的優越性就在於它能夠大大縮小對缺陷存在範圍的定位。此外，由於通常採用與系統開發相同的語言編寫，所以程式設計師更適合編寫單元測試。

UI測試

相比之下，我們想盡可能少的做UI自動化測試。為什麼？因為UI自動化測試更加脆弱、昂貴和花時間。

如果要通過UI進行測試，我們需要編寫一系列的測試指令碼來驅動UI，例如往各欄位中輸入適當的資料，按動乘或除按鈕，然後比較期望數值和實際數值。這種測試有用，但是並不理想。

此外，用這種方式測試一個應用是部分冗餘的——思考一下這樣一套測試需要對UI進行多少次測試。每個測試用例都呼叫了乘除按鈕相關的程式碼和進行函式運算的程式碼，每個測試用例還會測試顯示結果的程式碼，等等。像這樣通過使用者介面進行測試，是非常昂貴的，應該儘量少。

服務層測試

然而這並不意味著我們不需要對特性進行測試。我們需要是找出一種合適的方法來避開UI執行測試，這就是測試自動化金字塔中服務層測試的由來。在我們採用的這種測試方法中，“服務”是指應用程式對某個輸入或者某一套輸入做出的響應。

在我們的計算器例子中涉及到兩個服務：乘法和除法。服務層測試就是獨立於使用者介面外對應用程式服務進行的測試。因此如果要測試十幾個乘法測試用例，我們不通過計算器的使用者介面而是通過服務層來執行這些測試用例。與在使用者層執行同樣的測試用例相比較，這樣做更加有效而不繁瑣。

自動化的單元測試是非常棒的，但它只能覆蓋應用程式的部分測試需求。UI測試通常是必須的，但是應當少量使用。服務層測試彌補了單元測試和UI測試間的空白；以更小的工作量和成本滿足了團隊的自動化測試需求。

雖然很想說希望本篇文章能對大家有所幫助，但是單一瀏覽一篇文章能獲取的知識畢竟是有限的，還請大家理性看待，可能我總結的知識存在片面性，大家有什麼好的方式方法也請在評論區中留言大家交流，最後希望大家能在測試的路上暢通無阻

好了，你們看完了文章，我也給你們分享一下資料。

介面測試相關資料

連結：https://pan.baidu.com/s/1ojpoWnpxxReR1sO2Gxy_YQ 密碼：dgfa

效能測試相關資料

連結：https://pan.baidu.com/s/1_oZhvOIRvcz0JGcCWUGT-g 密碼：d82b

軟體測試入門提升電子書

連結：https://pan.baidu.com/s/1Fp8CFE0D2p0uAZk6xcexhQ 密碼：exna

自動化測試相關資料

連結：https://pan.baidu.com/s/1yeD1EMg-HalNuRBDODGx7g 密碼：ofdg