引子
最近在查看同事寫的robot自動化用例時候，發現一些問題。沒有搞清楚一個完整自動化用例的標準是什麼。把自動化用例前置準備工作也算作一個自動化case。根據自己理解談談自動化用例設計和開展自動化測試的一些原則。
原則一：每個自動化用例可以獨立運行
每個自動化用例應該是沒有依賴關係的，可以獨立運行的，比如測試一個電商網站，第一個測試用例是用戶登錄，第二個例子是添加商品到購物車，需要用戶登錄，並且依賴第一個測試用例，這樣的用例設計是有問題，因為違反了我們說的獨立運行原則。那如果我的測試用例重點不是測試登錄，而是添加商品到購物車，需要先登錄，這個登陸的前置條件應該放在哪裡呢？這個時候需要講解一下自動化框架基本都會自帶的一個功能模塊，setup和teardown。接下來我們藉助自動化測試框架RF（Robot Framework）來進行講解。
RF框架的三種 set up/teardown
- 第一種：Suite setup and teardown 測試套件層面。所謂測試套件（suite）就是一組測試用例集合，在RF裡面就是一個Robot文件。也就是說這個層面的setup和teardown只發生在一組測試的開始前和結束後。並且RF最終teardown的log也是在最前面的。所以根據log沒法看出關鍵字執行順序。
<code>Suite
Setup Open Browser To Login Page
Suite
Teardown Close All Browsers
/<code>
先來看一個組用例:
針對這組測試用例，我們發現每組測試用例前置條件都是用戶登錄，於是我們可以把用戶登錄這個關鍵字抽出來，放到Testcase setup的地方，這樣減少我們用例代碼的冗餘.
<code>Test
Setup Open Browser To Main Page Test Teardown Close All Browsers /<code>
這時候我們發現setup和teardown是按照執行順序出現的了。
- 第三種： Testcase setup/teardown。 和第二種類似，只是針對單個case作用，而不是一組case。當case中出現這個setup會覆蓋寫在setting處的setup
<code>Overridden
setup
[Documentation]
Own
setup
,teardown
from
setting
table
[Setup]
Open
Application
App
B
Do
Something
/<code>
原則二：測試用例之間不應該有包涵關係
如果A用例包含B用例，那麼B用例已經冗餘了，不需要重複執行，冒煙測試用例除外。
原則三：測試數據應該自動創建和銷燬
自動化測試需要的測試數據包括測試壞境也應該儘可能的自動創建和銷燬。有條件話可以嘗試採用docker容器化的方式運行自動化用例。
原則四：自動化應該優先覆蓋需要重複測試的核心功能
一般情況下，新功能是來不及做自動化測試和覆蓋的。需求變化快的模塊也是不適合做自動化的。覆蓋產品的核心功能，也就是優先從冒煙測試開始做自動化測試。
原則五：自動化開展順序應該是自底而上
項目的自動化開展順序應該是從單元測試開始，然後才是API測試，模塊測試，最後才是UI自動化。很多團隊本末倒置了，一上來就搞UI自動化，然後發現成本太高，進度太慢，然後下個結論，我們項目不適合做自動化。殊不知單元測試的自動化才是效率最高收益最高的，UI自動化應該是最後一步了。這裡借用網上一個圖來說明自動化測試的經典的金字塔模型。越往上，越接近用戶，自動化測試效率越低，成本越高，反之，越往下，越接近開發，自動化測試效率越高，成本越低。
原則六：不要一開始就想所有東西自動化
自動化測試的本質是減少迴歸測試的重複勞動，提高測試效率，對於大部分中小公司來說，一上來就想吃成個胖子，全部自動化是不可能的，剛開始開展自動化可以分析每次測試流程的時間瓶頸，到底是環境安裝配置，還是數據準備，還是執行用例最花時間，從最能提高效率或者受益最大的部分開始，簡而言之就是手動+自動化的方式。同時還要考慮團隊人員的技術水平，而不是花大量時間精力為了自動化而搞自動化，結果最後發現比手動測試成本還高，就很尷尬了。
*本文來源於網絡，如有侵權，請及時聯繫刪除
https://testerhome.com/topics/20396
