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