1. 程式人生 > >自動化測試最佳實踐(一):從紡錘模型到金字塔模型

自動化測試最佳實踐(一):從紡錘模型到金字塔模型

一、當前軟體開發的趨勢

開篇我們先簡要介紹一些近幾年在企業開發中出現的重要概念,以便引入持續測試的主旨。這些概念中最重要的兩個便是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。如何控制成本、降低成本是對自動化測試工具以及人員能力的挑戰。

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

作者:魏建軍

來源:宜信技術