如何讓自動化測試產生價值？這是一個恒古不變的話題！只有將自動化切入日常測試中，才能將飄于空中的技術產生實際的價值，無論是DevOps、CICD等其他的一些融合開發(fā)的概念，質量的自動化保障都是基礎設施。本次主要講一下現有團隊在自動化方面的一些探索和落地。
自動化優(yōu)先，既在QA人員介入測試時，就需要考慮需求自動化測試動作。需求中需要哪種程度的自動化介入，需要哪些自動化測試動作的介入，自動化測試需要哪些前置資源，自動化測試所花費成本，自動化測試在本次需求中的收益點；了解清楚了這些內容，就能夠確定自動化是否要做，怎么做。
根據實際的項目經驗，自動化優(yōu)先具有以下優(yōu)點：
節(jié)約自動化編寫時間（項目熟悉成本）、在測試過程中自動化的用例能夠支持測試、加快定版回歸效率、外部聯(lián)調測試中支持測試。
材料：外部接口文檔、web接口契約
在實際的自動化測試過程中，主要涉及以下的流程&動作：
1.需求分析：
前面有提到，我們的自動化手段有很多，在實際項目中，無論是基于UI、WEB場景、SRV服務代碼邏輯覆蓋；針對需求的大小、涉及面、復雜度、類型（UI、接口），都有使用場景，不同工具方法使用在不同的場景發(fā)揮恰到好處的價值。
具體來講：
接口請求返回調整的需求，僅需要針對歷史腳本文檔進行維護即可。
新增完整小模塊的需求，針對模塊功能，上線模塊功能自動化覆蓋。
調整/重構核心系統(tǒng)的需求，具體分析本次需求對核心系統(tǒng)影響，了解變更設計的歷史腳本維護，了解需要對哪些歷史腳本進行維護，并了解需要新增的邏輯/接口。
全新系統(tǒng)開發(fā)類的需求，了解本次需求涉及測試類型，針對UI、WEB接口、srv服務等類型，考慮需要采用的合適測試類型。
2.腳本設計
根據需求分析中得到的需求類型和涉及的測試類型，涉及對應的測試用例，此處只討論接口測試相關內容。
一個接口測試用例應包含以下幾個模塊：初始化（數據初始化、配置初始化）、業(yè)務邏輯模塊（內包含基礎的接口）、工具類（conditionSleep、加密加簽、解密等）、數據校驗、數據輸出。
很多時候完整自動化用例并不適用小版本迭代，在進行小版本功能迭代時，更多是進行部分接口或邏輯的變更。針對小的邏輯變更時，可以參考開發(fā)代碼進行代碼行邏輯覆蓋，結合jacoco工具，做到對開發(fā)有效代碼的邏輯覆蓋。通過這種方式的測試，無需上層復雜場景高成本覆蓋，僅通過底層接口的自動化測試，來保證底層提供功能的符合性。
以下示例為一個完整的場景測試用例。
3.基礎配置
在開始編寫腳本之前，需要準備好所需要的資料（如：外部接口文檔、WEB接口文檔、相關規(guī)約說明）。
在進行基礎配置準備中需要遵循一些基本原則，即可維護性，通用性，原子性。通常這類配置都是能夠被不同業(yè)務場景，甚至業(yè)務線共用的，保持其通用性將會對后續(xù)的腳本開發(fā)、維護有極大的便利性。
根據實際系統(tǒng)的需求，針對外部接口文檔配置所需要的MOCK（通常情況下為保證自動化的通過率，外部系統(tǒng)的接口采用MOCK方式支持）；依據WEB接口文檔，配置基礎的WEB接口參數等。
PS：MOCK系統(tǒng)的支持需要基礎設施的支持，這個不在本次討論范圍內，后續(xù)有機會討論。
MOCK配置：MOCK開關初始化、MOCK路由配置、 MOCK請求數據準備、MOCK返回數據準備。
WEB接口配置：服務、公共路徑（功能模塊）、方法配置（請求參數、返回參數）。
MicService接口配置：服務、服務組標識（ServiceGroup）、接口（InterfaceInfo）、方法（Method）
不過在沒有經驗的情況下，這些可能無法一次就做的比較好，那么就一步一步迭代即可，初步保持基本原則，在遇到具體的多元化引用時進行優(yōu)化。
4.腳本編寫
在開始腳本編寫的時候，要根據腳本設計實施，針對不同的模塊類型有具體差異性。
常見的模塊類型有：公共工具模塊、數據初始化、數據校驗模塊、腳本場景支撐模塊。
公共工具類模塊主要提供一些工具屬的支撐，如：條件等待（有些場景異步返回結果或返回結果是非實時，需要根據某一個條件（通常是數據庫數據）判斷是否進行下一步操作）、加簽加密（某些外部接口請求需要對請求參數進行加密加簽處理，通常這類操作是通用的）、解密（有些外部請求的返回已被加密，在進行后續(xù)操作是需要進行解密；有些數據檢查需要進行解密后才能校驗）。
數據初始化模塊包含場景用例運行所需的初始數據，這類數據來源有：數據庫現有數據（現有可進行場景執(zhí)行的賬戶）、根據規(guī)則實時生成的數據（如：身份證、手機號、訂單號）、由其他用例執(zhí)行后輸出的數據（如開通腳本輸出的開通用戶數據、借款腳本生成的借款單數據）
數據校驗模塊用來對數據落地進行邏輯符合性校驗，通過對場景運行中涉及到的數據落地表數據進行邏輯符合性校驗，保證自動化用例的有效性。數據校驗也可以分層分級進行配置，針對不同用途的腳本（冒煙、回歸、功能測試），選擇覆蓋不同的表、字段檢查項。
腳本場景支撐模塊是場景用例組裝的基礎，腳本設計中包含此模塊詳細設計。具體來講，通過對需求業(yè)務、接口各個功能分析，劃分出場景中相對固定的一些模塊（此處劃分有以下原則可以遵循：接口上下文在場景多元化時無需增減調整、無參數變化、無異步調用出，則可以劃分為一個模塊。在模塊劃分清楚后，依據已經實現的原則層用例，將各個子用例打包成一些固化的模塊，組織好各個原子接口的參數輸入和輸出以及一些基本的校驗。
自動化測試中很大一部分的工作都在此時完成，腳本的效率、合理性、魯棒性都是在此時通過具體實施來落地。腳本的優(yōu)化性都有一個相對度，不必過于追求對腳本進行優(yōu)化，如同開發(fā)代碼一樣，優(yōu)化是沒有極限的，只要滿足當前使用要求，遵循一些必要原則即可。
5.場景組裝
自動化想要實現的覆蓋都會通過場景組裝來實現，需要覆蓋多少場景是根據每個團隊業(yè)務需要來確定，有些需要做盡可能多場景覆蓋，有些僅需要做核心邏輯覆蓋即可。
場景組裝需要控制覆蓋場景的粒度，一旦過于追求場景覆蓋度，維護成本就會失控。
在進行場景組裝時，會發(fā)現有些前置的實現存在不合理，此時及時優(yōu)化不合理的地方并做記錄，方面后續(xù)腳本優(yōu)化時有的放矢。
場景組裝示例
6.調試優(yōu)化
腳本編寫完成后，通過不斷的運行，會發(fā)現腳本中一些不合理的地方。這些不合理的地方主要有：耗時較久、不穩(wěn)定（偶爾失敗）、腳本間互斥（配置初始化不合理）、通過率較低等一些問題。
針對這些問題，其實上面已經講過方法，在腳本編寫的階段未嚴格遵循一些原則或沒有意識到這些問題，此時對應做優(yōu)化即可。
耗時較久的問題，需要做下取舍或通過技術手段來彌補腳本的等待時間，針對某些需要等待過久的腳本，單獨拆出做自動化。
用例執(zhí)行耗時
不穩(wěn)定的問題，一般都是檢查點不合理導致的，某些檢查點未做好，會出現偶爾失敗的場景。有些檢查點不必做過于強的校驗，抓住自動化的目的。
腳本間互斥的問題，此類問題就是腳本設計問題了，在考慮好腳本場景要求后，對每個腳本都要做一些配置校驗或初始化，保證腳本運行期間業(yè)務、系統(tǒng)配置是預期的。另，在不同腳本運行期間由于運行順序不合理業(yè)務有此類問題，此時可以調整用例的線性運行順序。
通過率較低的問題，在腳本初步調試完成后，運行一段時間發(fā)現通過率較低，這個在自動化初期階段較常見，一般都是外部系統(tǒng)不穩(wěn)定導致的問題。此時需要針對不穩(wěn)定的外部系統(tǒng)，做些MOCK，必要時，可以要求研發(fā)提供必要的接口支持業(yè)務數據順利流轉。
自動化是一個持續(xù)化的過程，任何團隊在落地自動化的過程中都會遇到很多問題，甚至是長期無法產生價值，產生價值無法量化，這些都需要質量團隊的管理人員去思考，去想辦法解決。
作者：諸葛
出處：http://www.360doc.com/edit/editdraftnew.aspx?draftid=898
歡迎轉載，但未經作者同意請保留此段聲明，并在文章頁面明顯位置給出原文鏈接。
聯(lián)系客服
