題外：新年Flag
大年初一，立個Flag。19年希望能夠持續關注測試及相關行業的發展，不斷加深對測試的理解，專注於測試技術在測試左移與測試右移的應用與創新。
測試技術的應用不僅限於功能測試、自動化測試、性能測試、可用性（用戶體驗）測試隨著測試左移與右移的發展，還引入了數據分析（用戶行為）、線上質量運營等方向，相信還會衍生出更多的方向，比如正在逐步發展壯大的算法測試。
自動化測試的認知
一些錯誤的認知：
- 使用自動化完全替代手工測試。
- 使用自動化測試發現更多的新BUG。
應該形成怎樣的認知：
- 自動化測試的目的不單純是為了減少或者替代手工測試，而是為了測試人員能夠做更多更有意義的測試，比如更深入的需求分析、測試設計或者對測試右移的投入；減少或抽調人力投入；適應開發模式的轉變，比如類敏捷、devops模式下的頻繁迭代、持續部署。
- 自動化測試是用來驗證以前能夠正常工作的功能是否依舊可以正常工作。
為何自動化測試
要清楚不是為了自動化而自動化，是為了實現一套解決方案來解決某些問題而開展某種自動化 ，肯定是解決某些測試過程中的問題而引入自動化測試。既然選擇自動化解決某些問題，首先要清楚自動化測試的利與弊，如下：
利
- 關於成本，機器資源成本代替人力成本，一定程度解決了重複性的測試執行成本問題。
- 關於效率，提高測試執行效率，縮短測試周期，一定程度解決了測試周期隨版本迭代次數的增加(功能點增加)而增長的問題。
- 關於測試覆蓋，通過自動化測試工具的錄製回放及數據驅動來測試功能，可以提高測試覆蓋率，一定程度解決了迴歸測試中測試覆蓋率低的問題。
- 關於發現問題，自動化測試具有較好的一致性和可重複性， 一定程度解決了手工反覆執行過程中的一致性的問題。
- 關於流程，自動化測試工具作為一種角色引入到整個測試流程中，提高測試執行流暢性。
弊
- 關於人員，額外要求測試人員具備定測試開發能力，引入了對測試人員能力要求較高的問題。
- 關於成本，自動化測試開發成本因選擇自動化框架(或工具)而異，但都具有較高的開發成本，引入了開發成本的問題。
- 關於維護， 隨著版本迭代和功能變更，引入了自動化代碼的開發維護的問題。
- 關於發現問題，受其本身的侷限性(大多應用在迴歸測試、穩定版本場景中)， 自動化測試發現問題較少。
工欲善其事必先利其器
IT行業甚至其它行業的產品都是能夠做到自動化的，所以是否自動化不是能與不能的問題，而是是否存在合適的時間或階段以及合適方式去做的問題，實施自動化測試之前需要對產品開發過程進行分析，同時自動化測試是一把雙刃劍， 所以通常自動化的開展需要同時滿足以下條件：
- 軟件需求變動不頻繁(超過10%的變動是頻繁變動，當然10%不是一個定值)
- 項目週期足夠長
- 自動化測試用例可重複使用
通常適合於軟件測試自動化開展的場景如下：
- 迴歸測試，重複單一的測試操作造成了不必要的浪費
上文中也提到肯定是解決某些測試過程中的問題而引入自動化測試，如果是為了自動化而自動化，無疑它將是失敗的。
何為自動化測試
自動化測試是把以人為驅動的測試行為轉化為機器執行代碼的一種過程。
通常，在設計測試用例並完成評審之後 ，由測試人員根據測試用例一步步執行側試，得到實際結果與期望結果的比較。
在此過程中，為了降低人力、時間或硬件資源的投入，提高測試執行效率，便引入了自動化測試的概念。
飛機還是大炮
框架、工具的選擇是我們確認開展自動化後首先面臨的問題。之前網上有個梗，泡麵煮著吃是沒有靈魂的，當然這是一種調侃。自動化測試開展一定要結合被測系統的特點進行選擇，不顧被測系統（系統框架）特性、場景而盲目選擇自動化測試框架(或工具)， 它是沒有靈魂的，自動化失敗概率會相對高很多。
下面我們先簡單的介紹一下自動化開展的幾種自動化測試驅動框架。
首先我們需要明白自動化測試框架更傾向於一種設計思想 ，這種思想指導工具的使用或者自研開發，並且不是隻能使用僅僅一種框架，結合被測系統本身特性一般是選擇多種測試框架的組合，來滿足測試和設計需求(開發、維護角度)。
錄製回放測試框架
錄製回放測試框架所採用的原理是通過錄制應用程序產生的線性腳本進行回放從而達到自動化測試的目的。
- 優點：對測試人員測試開發能力要求最低，通過錄制就可以得到所需腳本。
- 缺點：一般不具有邏輯判斷的能力 ，可維護性差 ，效率低。
- 適應場景：不推薦，傳統的UI自動化測試逐步弱化。關於U自動化，一定要清楚 被測系統是否滿足開展自動化的條件，在被測系統變動頻繁的項目中，開展UI自動化無疑是挖了一個很大的坑，其後期維護工作足以讓大心疲憊，被迫放棄自動化測試。
測試庫構架框架
測試庫構架框架的核心思想可以概括為系統功能操作和業務邏輯的解耦。將所有的針對測試系統支持的功能操作封裝在測試庫中，測試腳本調用測試庫的同時傳遞外部的測試數據，測試庫的編寫由自動化測試發工程編寫(可以不懂業務)，負責控件的變更和維護， 測試腳本的編寫可由對業務比較掌握的自動化測試開發工程編寫，負責業務邏輯、測試數據的變更和維護。
- 優點：被測試系統無論是哪層發生變化(代碼層或業務層等)，只需要相應的人員進行變更維護即可。
- 缺點：變更引起的維護工作同時附加在自動化測試開發工程師與業務測試人員身上，維護代碼建級大。
- 適應場景：基於各種自動化開展方式(基於工具如Jemet或不基於工具的自研研發+持續集成)一般都會應用該框架。
數據驅動的自動化測試框架
數據驅動的核心思想可以概括為數據(測試數據、配置數據)與代碼解耦。該種框架的原理是採用了數據驅動腳本進行測試，數據驅動腳本是將數據輸入存儲在獨立的數據文件中，腳本只存代碼，運行時腳本的輸入直接從文件中讀取，如此相同的腳本(代碼模版)可以運行於不同的測試用例中，實現了代碼與數據的分離。
- 優點：對於業務人員由面向代碼的開發轉換為面向配置的設計(參數組合設計)， 降低了開發難度與開發成本，同時提高了測試用例的易擴展性，可以快速擴展相似測試，實現了自動化代碼不隨用例的增長而增
- 缺點：測試腳本的維護由自動化測試開發工程師負責，要求懂自動化編程和業務邏輯，初始測試腳本設計成本較大，具有一定侷限性 (針對相同的測試內容並具有相同的測試邏輯).
- 適用場景：更適應於測試內容測試邏相重複度高，被測對象對測試用例易擴展性、可複用性要求較高的場景。
關鍵字驅動的自動化測試框架
關鍵字驅動是對數據驅動的邏相擴展，它的核心思想可以概括為數據代碼流程(邏輯)解耦，同時完成了代碼與測試描述(針對被測對象的測試描述)的映射。該框架的原理是基於數據驅動的基礎上，完成了對被測對象的拆分、抽象、 封裝使之映射成一個“關鍵詞” (測試描述)，編寫測試用例時，僅需要對關鍵詞進行組合 ，即可完成不同場景的測試用例開發。
- 優點:對於業務手工測試人員，由面向代碼或配置的開發轉化為面向自然語言(測試描述)的開發，最大程度的降低了開發難度與維護成本，同時提高了測試用例的易擴展性、易組織性，實現了自動化代碼不隨用例的增長而增多。
- 缺點:對測試人員的測試開發能力以及業務瞭解程度要求很高。
- 適用場景:被測對象包含複雜業務流程(邏輯)，當然複雜的能做簡單的更ok。
僅僅從實現上講，很多種自動化測試框架(或工具)都可以開展自動化，或者說任意一種也不是很勉強， 所以在自動化框架(或工具)的選擇上，不是人為核心的(我會什麼， 或有哪種框架比較好掌握)，而是以被測對象為本來選擇自動化框架(或工具)。
以目標為導向
著重考慮自動化覆蓋率、效率提升率、投資回報率(ROI)、效率轉換等指標，按季度或產品版本為週期，進行持續性的評估，以便感知落地後的自動化測試是否持續性的發揮著原定作用，通常我們會收集一下數據並依據此設定不同等級進行評定，以便區分優劣，具體如下：
- 自動化覆蓋率 = 當前版本該項目自動化測試點/當前版本該項目所有測試點。
- 效率提升率 = 1- 單輪次自動化執行時間/單輪次手動執行時間（針對被自動化測試所覆蓋的用例而言）
- 標準盈餘時間 = （單輪次手工執行時間-單輪次自動化執行時間）*自動化執行次數
- 實際盈餘時間 = 結合標準盈餘時間估算
- 投資回報率(ROI) = （標準盈餘時間/自動化測試開發投入時間）*100%
- 效率轉換 = 對實際盈餘時間的分配及相關產出
自動化測試前移
隨著敏捷、devops等開發模式的引入，軟件交付週期逐漸縮短，相對傳統的自動化測試准入原則，已不能滿足現有的發展要求，比如“版本功能相對穩定後開展自動化測試”。此時，我們提出了自動化測試前移的設想，基於這個設想我們首先要解決哪些問題？
- 開發成本，由於自動化前移，會影響前期對測試設計、分析的時間投入。
- 維護成本，由於自動化前移，由於接口或設計調整而引入的自動化用例變更維護的可能性更大。
因此自動化測試前移是否具備可行性，取決於開發成本和維護成本的是否在可以縮減到一定範圍內，這同樣也涉及到自動化測試的可持續性問題。
自動化測試策略
依託合適的自動化測試框架，進行自動化測試設計來解決。這裡我們主要基於關鍵字驅動的自動化測試框架進行自動化測試設計，其中有幾個設計細節可以借鑑一下，比如：
將接口自動化測試分解為請求響應關鍵字、響應體特定內容提取關鍵字、數據校驗關鍵字等幾個模塊：
- 其中請求響應關鍵字支持http、https協議的多種請求方式，同時支持JSON、xml等響應體的校驗（如，接口響應體為JSON類型時，針對特定Key進行校驗或跳過特定Key進行校驗），請求響應關鍵字的參數包含，URL、請求方式、請求體、期望結果，此時通過該關鍵字可以實現所有類似接口的自動化測試；
- 特定內容提取關鍵字支持特定內容的提取，以便在集成接口自動化測試場景下，提取上游接口響應體特定內容，作為下游接口參數輸入；
- 數據庫校驗關鍵字支持多種類型數據庫的增刪改查，以及查詢結果與期望結果比對等功能；
- 基於關鍵字驅動的自動化測試框架一定程度解決了隨著用例數量的增加維護代碼量也越來越多的問題。
如何實現不輸入期望的自動化測試用例開發模式？，
- 比如針對冪等性接口，我們在初次運行的時候，重複調用接口10次，然後區分響應體不發生變化的內容和發生變化的內容，再根據不發生變化的內容自動生成期望，回填到用例中，這樣大大就提高了自動化的開發效率。
除此之外，關鍵字驅動的自動化測試，還解決了測試人員與測試開發人員的解耦問題，即測試人員負責用例設計，對產品質量負責。測試開發人員負責框架和關鍵字維護，對測試效率負責。
閱讀更多 測試開發技術棧 的文章
