【轉載】自動化測試最佳實踐（一）：從紡錘模型到金字塔模型

來自：https://www.cnblogs.com/yixinjishu/p/11119212.html

1、當前軟件開發的趨勢

開篇咱們先簡要介紹一些近幾年在企業開發中出現的重要概念，以便引入持續測試的主旨。這些概念中最重要的兩個即是DevOps和微服務。二者都是目前軟件開發中的最佳實踐和方法論，旨在爲企業提供更高的靈活性，提高運營效率。

1.1 DevOps

DevOps是一套實踐方法論和文化，提倡打破原有組織和限制，職能團隊開始擁抱和接受DevOps所倡導的高度協同，研發、測試、運維及交付一體化的思惟。隨着DevOps和敏捷熱度的不斷提高，不管是互聯網企業仍是傳統軟件企業都開始擁抱敏捷，實踐DevOps。持續集成CI（Continuous integration）、持續交付CD（Continuous delivery ）做爲DevOps的最佳實踐，愈來愈受到重視。

1.2 微服務架構 Microservice Architecture

微服務架構源起於DevOps意識形態和實踐中，是一種軟件架構風格。微服務架構帶來了一系列好處，例如可部署性、可靠性、可用性等等。雖然原則上可使用任何架構來實踐DevOps，但微服務架構正在成爲構建持續部署 (CD)系統的標準架構風格。因爲每項服務的規模都很小，它容許經過連續重構來實現單個服務的體系結構，所以減小了對大型項目前期設計的需求，容許儘早發佈軟件而且持續交付。微服務和DevOps是自然的共同體，結合起來共同實現軟件開發行業的變革。

2、自動化測試 Test Automation

隨着敏捷和微服務架構的引入，CI/CD成爲構建和部署的標準，即便在沒有采用微服務架構的項目中也是如此。爲了保證已定義的流程和事務按照預期運行，測試必不可少。而在應對現代軟件產品頻繁的變化和發佈上，傳統的手工測試方式在人員和效率上都存在嚴重不足，所以自動化測試已經成爲現代軟件研發過程當中一個關鍵組成部分。自動化測試是打通持續集成和持續交付的核心，沒有有效的自動化測試保證，持續集成和持續交付就僅僅是一個沒有靈魂的軀殼。

2.1 測試分類

測試按照不一樣的維度能夠進行多種分類。

• 按測試手段是否手工，可劃分爲自動化測試和人工測試；
• 按照測試目的劃分，可分爲功能測試、性能測試、負載測試等。

本文采用Martin Fowler按照層級分類的方式對測試進行分類。

Martin Fowler描述測試金字塔分爲單元、服務和UI三個層級。儘管你們對此的具體描述各不相同（有人將三層分別定義爲單元、接口、集成測試；也有人將整個金字塔劃分爲4-5個層級），但金字塔自底向上的結構是你們公認和遵循的。

1)單元測試

單元測試是針對代碼單元（一般是類/方法）的測試，單元測試的價值在於能提供最快的反饋，在開發過程當中就能夠對邏輯單元進行驗證。好的單元測試能夠幫助改善既有設計，在團隊掌握 TDD的前提下，單元測試能輔助重構，幫助提高代碼整潔度。

2)接口（服務/API）測試

接口測試是針對業務接口進行的測試，主要測試內部接口功能實現是否完整。好比內部邏輯是否正常、異常處理是否正確。接口測試的主要價值在於接口定義相對穩定，不像界面或底層代碼會常常發生變化，因此接口測試比較容易編寫，用例的維護成本也相對較低。在接口層面準備測試的性價比相對較高。

3)集成（UI）測試

集成測試從用戶的角度驗證產品功能的正確性，測的是端到端的流程，而且加入用戶場景和數據，驗證整個過程是否健康流暢。集成測試的業務價值最高，它驗證的是一個完整的流程，但由於須要驗證完整流程，在環境部署、準備用例及實施等方面成本較高，實施起來並不容易。

2.2 微服務架構爲測試帶來的挑戰

微服務架構在解決了應用大小、應用開發規模等問題以後也帶來了一些新的問題，比較突出的有微服務數量增多、服務間調用關係複雜等等。複雜的依賴致使即便項目資深開發人員也不能一會兒梳理出全部關係。

微服務和傳統的單體應用相比，在測試策略上會有一些不太同樣的地方。簡單來講，在微服務架構中，測試的層次變得更多，須要測試的服務和應用也會變得更多。手動執行全部的測試是低效的，沒法跟上互聯網快速迭代的要求。這時有必要引入自動化測試來減輕測試團隊的壓力，提升測試效率和測試質量。

2.3 自動化測試

提及自動化測試，功能測試人員可能會將其想得很高端複雜。

先來看通常的功能測試如何進行：設計並編寫用例文檔，描述測試步驟和預期結果；測試人員根據測試用例描述按步驟操做，而後判斷實際結果與預期是否一致。若是一致，測試經過；若是不符，測試失敗。

自動化測試要作的事情與功能測試是一致的。分層理論和自動化測試方法結合，出現了三個層面的自動化：單元測試自動化、接口測試自動化和UI測試自動化。固然，不一樣層面的自動化關注點是不同的。因此，從測試的行爲本質上來看，功能測試與單元自動化測試、接口自動化測試和UI自動化測試並無區別。惟一的區別是，一個由人來執行，一個由代碼或工具執行。

2.4 自動化測試分層

1)單元自動化測試

單元測試自動化，指對軟件中最小的可測試單元進行檢查和驗證，調用被測服務的類或方法，根據類或方法的參數，傳入相應的數據，獲得一個返回結果，最終斷言返回的結果是否符合預期。若是相等，測試經過；若是不相等，測試失敗。

因此，單元測試關注的是代碼的實現與邏輯。單元測試是最基本的測試，也是測試中的最小單元，它的對象是函數對象，也能夠包含輸入輸出，針對的是函數功能或者函數內部的代碼邏輯，並不包含業務邏輯。

該類測試通常由研發人員完成，須要藉助單元測試框架，如java的Junit、TestNG，python的unittest等。

2)接口自動化測試

接口自動化測試，主要驗證模塊間的調用返回以及不一樣系統、服務間的數據交換。接口測試自動化通常在業務邏輯層進行測試。根據接口文檔是RESTful仍是RPC？調用被測試的接口，構造相應的請求數據，獲得返回值，是成功或者失敗。無論輸入的參數是怎樣的，咱們都將獲得一個結果，最終斷言返回的結果是否等於預期結果。若是相等，測試經過；若是不相等，測試失敗。

因此，接口測試關注的是數據。只要數據正確了，功能就作成大半，剩下的無非是如何把這些數據展現在頁面上。

常見的接口測試工具備postman、jmeter、loadrunner等。

3)集成（UI）自動化測試

UI層是用戶使用產品的入口，全部功能經過這一層提供給用戶，目前測試工做大多集中在這一層，這種測試更貼近用戶的行爲，模擬用戶點擊了某個按鈕、在輸入框裏輸入了某些指令。有時可能用戶看到登陸成功了，但UI自動化並不知道它剛纔的點擊有沒有生效。因此要找「證據」，好比登陸成功後頁面右上角會顯示「歡迎，xxx」，這就是登陸成功的有力「證據」。當UI自動化登陸成功後，就去獲取這個數據進行斷言，斷言若是相等，測試經過；若是不相等，測試失敗。

因此，UI自動化的關注點用戶操做形爲，以及UI上各類組件是否可用。常見的測試工具備UFT、Robot Framework、Selenium、Appium等。

4)分層佔比最佳實踐

每種自動化測試都有本身的側重和優劣勢，在實際工做中不可能作到均分，所以咱們須要制定合理的測試策略對其進行組織和分配，包括每部分測試投入多少、測試用例比例是多少等。

測試金字塔還有另外一個維度的信息，如上圖所示。

• 越往上，越接近QA、業務/最終用戶，越往下，越接近開發；
• 越往上，測試執行越慢，越往下，測試執行越快；
• 越往上，測試成本越高（越耗時，失敗時的信息越模糊，越難跟蹤），越往下，測試成本越低。

按照測試金字塔模型以及投入/產出比，咱們得知越向下回報率越高，因此應該使用大量的單元測試和全面的接口測試來覆蓋產品提供的基本邏輯和功能，使用少許的集成（UI）測試來進行前端界面的功能驗證。

都說業內最佳實踐看Google，Google的自動化分層投入佔比是：單元測試（Unit）：佔比70%；接口測試（Service）：佔比20%；集成測試（UI）：佔比10%.

3、自動化測試最佳實踐

對現階段公司大部分團隊來講，更符合實際測試模式是紡錘模型。新項目中，可能因爲時限緣由或者開發人員習慣問題，一開始並無把單元測試準備得很完善；而某些遺留老項目，可能本來就沒有多少單元測試。

在上述狀況下，通常的作法是先將重心放在中間層的測試上，緣由有如下兩點：

• 第一，中間層投入產出比較高，能夠實現較高的自動化率；
• 第二，能夠幫助增強開發跟測試人員之間的協做，提升測試質量。這一層須要開發跟測試人員共同定義，由於開發知道內部實現的細節，測試掌握業務場景。

3.1 紡錘型向金字塔型過渡

當項目進行一段時間之後，各層測試佔比有必要向理想型的金字塔型過渡，這時須要關注如下三個方面：

• 開發與測試互相傳遞能力；
• 全員關注產品設計跟代碼的質量；
• 讓用例逐步下沉，最後逐步過渡到理想型。

3.2 測試質量評估

關於度量，不要用單一的指標去評估測試和產品質量，好比用例經過率、代碼覆蓋率等都沒法獨立地評估產品質量。

評估測試質量時要關心如下幾個方面：

• 第一是用例比例，即每一層的用例比例是多少。
• 第二是測試覆蓋率。
• 第三是測試總運行時間，由於通過優化之後，總運行時間必定是愈來愈少。
• 第四是代碼質量指標，反映代碼的質量和整潔度。

4、自動化測試面臨的挑戰

引入自動化測試能夠爲團隊帶來不少好處，固然自動化測試也有其自身的缺點和挑戰。面臨的最大挑戰就是變化，由於變化會致使測試用例運行失敗，因此須要對自動化腳本不斷debug。如何控制成本、下降成本是對自動化測試工具以及人員能力的挑戰。

另外一個值得注意的是，自動化測試不能徹底代替人工測試，必定的人工探索測試也是必不可少的。咱們一直在不懈努力和探索，本文爲自動化測試最佳實踐系列文章的第一篇，重點介紹了自動化測試的現狀和金字塔模型，接下來的系列文章中會繼續爲你們介紹咱們的自動化測試實踐，包括自動化測試平臺的核心功能、持續測試的方法與工具等。

做者：魏建軍

來源：宜信技術學院

===================================================================

接口測試主要的做用是提早下降風險，不至於等到APP端開發完成才發現問題，越日後時間成本和開發成本越高，風險越大。在多團隊協做項目工期緊張的狀況下，發現較大問題再調整產品需求幾乎是不可能的，此類問題很消耗團隊士氣，團隊被突如其來的問題影響，很容易被打亂節奏。在服務端開發完成提測，服務端測試能夠有效攔截到一半左右的問題，很大程度下降風險，提升人效。

 API測試工具推薦：postman