測試自動化：關注服務層測試

測試發展至今已十年有余，測試的工作也越來越受到各方面的重視，對于測試人員的要求也越來越高，據不完全統計，目前測試項目自動化要求已經接近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