一、目前軟體開發的趨勢
開篇我們先簡要介紹一些近幾年在企業開發中出現的重要概念，以便引入持續測試的主旨。這些概念中最重要的兩個便是DevOps和微服務。兩者都是目前軟體開發中的最佳實踐和方法論，旨在為企業提供更高的靈活性，提升營運效率。
1.1 DevOps
DevOps是一套實踐方法論和文化，提倡打破原有組織和限制，職能團隊開始擁抱和接受DevOps所倡導的高度協同，研發、測試、運維及傳遞一體化的思維。随着DevOps和靈活熱度的不斷提升，無論是網際網路企業還是傳統軟體企業都開始擁抱靈活，實踐DevOps。持續內建CI（Continuous integration）、持續傳遞CD（Continuous delivery ）作為DevOps的最佳實踐，越來越受到重視。
1.2 微服務架構 Microservice Architecture
微服務架構源起于DevOps意識形态和實踐中，是一種軟體架構風格。微服務架構帶來了一系列好處，例如可部署性、可靠性、可用性等等。雖然原則上可以使用任何架構來實踐DevOps，但微服務架構正在成為建構持續部署 (CD)系統的标準架構風格。由于每項服務的規模都很小，它允許通過連續重構來實作單個服務的體系結構，是以減少了對大型項目前期設計的需求，允許盡早釋出軟體并且持續傳遞。微服務和DevOps是天然的共同體，結合起來共同實作軟體開發行業的變革。
二、自動化測試 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.1 紡錘型向金字塔型過渡
當項目進行一段時間以後，各層測試占比有必要向理想型的金字塔型過渡，這時需要關注以下三個方面：
- 開發與測試互相傳遞能力；
- 全員關注産品設計跟代碼的品質；
- 讓用例逐漸下沉，最後逐漸過渡到理想型。
3.2 測試品質評估
關于度量，不要用單一的名額去評估測試和産品品質，比如用例通過率、代碼覆寫率等都無法獨立地評估産品品質。
評估測試品質時要關心以下幾個方面：
- 第一是用例比例，即每一層的用例比例是多少。
- 第二是測試覆寫率。
- 第三是測試總運作時間，因為經過優化以後，總運作時間一定是越來越少。
- 第四是代碼品質名額，反映代碼的品質和整潔度。
四、自動化測試面臨的挑戰
引入自動化測試可以為團隊帶來很多好處，當然自動化測試也有其自身的缺點和挑戰。面臨的最大挑戰就是變化，因為變化會導緻測試用例運作失敗，是以需要對自動化腳本不斷debug。如何控制成本、降低成本是對自動化測試工具以及人員能力的挑戰。
另一個值得注意的是，自動化測試不能完全代替人工測試，一定的人工探索測試也是必不可少的。我們一直在不懈努力和探索，本文為自動化測試最佳實踐系列文章的第一篇，重點介紹了自動化測試的現狀和金字塔模型，接下來的系列文章中會繼續為大家介紹我們的自動化測試實踐，包括自動化測試平台的核心功能、持續測試的方法與工具等。
作者：魏建軍
來源：宜信技術學院