引子 自動化測試用例設(shè)計(jì)及原則

? ? ? 最近在查看同事寫的robot自動化用例時候秧倾，發(fā)現(xiàn)一些問題。沒有搞清楚一個完整自動化用例的標(biāo)準(zhǔn)是什么傀缩。把自動化用例前置準(zhǔn)備工作也算作一個自動化case那先。根據(jù)自己理解談?wù)勛詣踊美O(shè)計(jì)和開展自動化測試的一些原則。

原則一：每個自動化用例可以獨(dú)立運(yùn)行

? ? ? 每個自動化用例應(yīng)該是沒有依賴關(guān)系的赡艰，可以獨(dú)立運(yùn)行的售淡，比如測試一個電商網(wǎng)站，第一個測試用例是用戶登錄慷垮，第二個例子是添加商品到購物車揖闸，需要用戶登錄，并且依賴第一個測試用例料身，這樣的用例設(shè)計(jì)是有問題楔壤，因?yàn)檫`反了我們說的獨(dú)立運(yùn)行原則。那如果我的測試用例重點(diǎn)不是測試登錄惯驼，而是添加商品到購物車蹲嚣，需要先登錄，這個登陸的前置條件應(yīng)該放在哪里呢祟牲？這個時候需要講解一下自動化框架基本都會自帶的一個功能模塊隙畜，setup和teardown。接下來我們借助自動化測試框架RF（Robot Framework）來進(jìn)行講解说贝。

RF框架的三種 set up/teardown

第一種：Suite setup and teardown 測試套件層面议惰。所謂測試套件（suite）就是一組測試用例集合，在RF里面就是一個Robot文件乡恕。也就是說這個層面的setup和teardown只發(fā)生在一組測試的開始前和結(jié)束后言询。并且RF最終teardown的log也是在最前面的。所以根據(jù)log沒法看出關(guān)鍵字執(zhí)行順序傲宜。

Suite Setup? ? ? ? ? Open Browser To Login Page

Suite Teardown? ? Close All Browsers

第二種：Testcase setup/teardown 測試用例層面运杭。每一個case的開始和結(jié)束都會去執(zhí)行的步驟。一般預(yù)置條件和數(shù)據(jù)準(zhǔn)備放在setup函卒，數(shù)據(jù)銷毀放在teardown辆憔。

先來看一個組用例:

針對這組測試用例，我們發(fā)現(xiàn)每組測試用例前置條件都是用戶登錄，于是我們可以把用戶登錄這個關(guān)鍵字抽出來虱咧，放到Testcase setup的地方熊榛，這樣減少我們用例代碼的冗余.

Test Setup? ? ? ? Open Browser To Main Page

Test Teardown? ? Close All Browsers? ? ? ? ? ? ? ? ? ? ? #測試結(jié)束之后執(zhí)行關(guān)鍵字

這時候我們發(fā)現(xiàn)setup和teardown是按照執(zhí)行順序出現(xiàn)的了。

第三種： Testcase setup/teardown腕巡。 和第二種類似玄坦，只是針對單個case作用，而不是一組case绘沉。當(dāng)case中出現(xiàn)這個setup會覆蓋寫在setting處的setup

Overridden setup [Documentation] Own setup, teardown from setting table [Setup] Open Application App B Do Something

原則二：測試用例之間不應(yīng)該有包涵關(guān)系

如果A用例包含B用例营搅，那么B用例已經(jīng)冗余了，不需要重復(fù)執(zhí)行梆砸，冒煙測試用例除外转质。

原則三：測試數(shù)據(jù)應(yīng)該自動創(chuàng)建和銷毀

自動化測試需要的測試數(shù)據(jù)包括測試壞境也應(yīng)該盡可能的自動創(chuàng)建和銷毀。有條件話可以嘗試采用docker容器化的方式運(yùn)行自動化用例帖世。

（有興趣的小伙伴可以加扣扣裙164549428或者加威dingyu-003免費(fèi)領(lǐng)取各種測試資料）

原則四：自動化應(yīng)該優(yōu)先覆蓋需要重復(fù)測試的核心功能

一般情況下休蟹，新功能是來不及做自動化測試和覆蓋的。需求變化快的模塊也是不適合做自動化的日矫。覆蓋產(chǎn)品的核心功能赂弓，也就是優(yōu)先從冒煙測試開始做自動化測試。

原則五：自動化開展順序應(yīng)該是自底而上

項(xiàng)目的自動化開展順序應(yīng)該是從單元測試開始哪轿，然后才是API測試盈魁，模塊測試，最后才是UI自動化窃诉。很多團(tuán)隊(duì)本末倒置了杨耙，一上來就搞UI自動化，然后發(fā)現(xiàn)成本太高飘痛，進(jìn)度太慢珊膜，然后下個結(jié)論，我們項(xiàng)目不適合做自動化宣脉。殊不知單元測試的自動化才是效率最高收益最高的车柠，UI自動化應(yīng)該是最后一步了。這里借用網(wǎng)上一個圖來說明自動化測試的經(jīng)典的金字塔模型塑猖。越往上竹祷，越接近用戶，自動化測試效率越低羊苟，成本越高塑陵，反之，越往下践险，越接近開發(fā)猿妈，自動化測試效率越高，成本越低巍虫。

原則六：不要一開始就想所有東西自動化

自動化測試的本質(zhì)是減少回歸測試的重復(fù)勞動彭则，提高測試效率，對于大部分中小公司來說占遥，一上來就想吃成個胖子俯抖，全部自動化是不可能的，剛開始開展自動化可以分析每次測試流程的時間瓶頸瓦胎，到底是環(huán)境安裝配置芬萍，還是數(shù)據(jù)準(zhǔn)備，還是執(zhí)行用例最花時間搔啊，從最能提高效率或者受益最大的部分開始柬祠，簡而言之就是手動+自動化的方式。同時還要考慮團(tuán)隊(duì)人員的技術(shù)水平负芋，而不是花大量時間精力為了自動化而搞自動化漫蛔，結(jié)果最后發(fā)現(xiàn)比手動測試成本還高，就很尷尬了旧蛾。