學(xué)習(xí) 總結(jié) 記錄=成長(zhǎng)！
自動(dòng)化測(cè)試(Automated Testing)，是指把以人為驅(qū)動(dòng)的測(cè)試行為轉(zhuǎn)化為機(jī)器執(zhí)行的過(guò)程。實(shí)際上自動(dòng)化測(cè)試往往通過(guò)一些測(cè)試工具或框架，編寫自動(dòng)化測(cè)試用例，來(lái)模擬手工測(cè)試過(guò)程。比如說(shuō)，在項(xiàng)目迭代過(guò)程中，持續(xù)的回歸測(cè)試是一項(xiàng)非?？菰锴抑貜?fù)的任務(wù)，并且測(cè)試人員在每天重復(fù)勞動(dòng)的工作之下，也絲毫得不到成長(zhǎng)。此時(shí)開展自動(dòng)化測(cè)試就能夠幫助測(cè)試人員從重復(fù)、枯燥的手工測(cè)試中解放出來(lái)，提高測(cè)試效率，縮短回歸測(cè)試時(shí)間。一般來(lái)說(shuō)，自動(dòng)化測(cè)試通常都會(huì)跟持續(xù)集成系統(tǒng)（比如Jenkins）配合使用。
但在自動(dòng)化實(shí)踐過(guò)程中，往往會(huì)發(fā)現(xiàn)理想和現(xiàn)實(shí)之間的差距很大。自動(dòng)化測(cè)試的劣勢(shì)，主要體現(xiàn)在以下幾方面：
項(xiàng)目周期長(zhǎng)，需求變動(dòng)不頻繁
測(cè)試用例的穩(wěn)定性決定了自動(dòng)化測(cè)試的維護(hù)成本。如果軟件需求變動(dòng)過(guò)于頻繁，測(cè)試人員需要根據(jù)變動(dòng)的需求來(lái)更新測(cè)試用例以及相關(guān)的測(cè)試腳本，而腳本的維護(hù)本身就是一個(gè)代碼開發(fā)的過(guò)程，需要修改、調(diào)試。如果所花費(fèi)的成本不低于利用其節(jié)省的測(cè)試成本，那么自動(dòng)化測(cè)試便是失敗的。
項(xiàng)目中的某些模塊相對(duì)穩(wěn)定，而某些模塊需求變動(dòng)性很大。我們便可對(duì)相對(duì)穩(wěn)定的模塊進(jìn)行自動(dòng)化測(cè)試，而變動(dòng)較大的仍是用手工測(cè)試。
自動(dòng)化測(cè)試腳本可重復(fù)使用
如果費(fèi)盡心思開發(fā)了一套近乎完美的自動(dòng)化測(cè)試腳本，但是腳本的重復(fù)使用率很低，致使其間所耗費(fèi)的成本大于所創(chuàng)造的經(jīng)濟(jì)價(jià)值，自動(dòng)化測(cè)試便毫無(wú)意義。
測(cè)試任務(wù)手工測(cè)試難以實(shí)現(xiàn)
比如壓力測(cè)試，大數(shù)據(jù)或者大量重復(fù)數(shù)據(jù)測(cè)試，必須有自動(dòng)化工具的支持。
一般落后于新功能的手工測(cè)試階段，可以在手工用例執(zhí)行完成或功能上線后，再去補(bǔ)充自動(dòng)化的用例。
自動(dòng)化不是跟著新需求走，而是測(cè)變化的東西對(duì)不變東西的影響，一定不要做為了自動(dòng)化而自動(dòng)化的工作。
在理解分層自動(dòng)化之前，我們先看一下經(jīng)典的測(cè)試金字塔。
UI層：界面自動(dòng)化測(cè)試?？梢钥闯鏊膬r(jià)值最小，它最接近用戶真實(shí)場(chǎng)景，也容易發(fā)現(xiàn)問(wèn)題，但它的實(shí)現(xiàn)成本最高且太容易受外部依賴，容易影響腳本成功率?？傮w來(lái)說(shuō)，適當(dāng)?shù)慕缑孀詣?dòng)化測(cè)試是有必要的，但是沒(méi)有必要在UI層投入太多；
Service層：接口自動(dòng)化測(cè)試。它的價(jià)值居中，覆蓋大多數(shù)主要的接口是比較合適的。這一層要求測(cè)試人員對(duì)系統(tǒng)的結(jié)構(gòu)和系統(tǒng)間的調(diào)度非常清楚，同時(shí)要了解接口邏輯關(guān)系，否則接口測(cè)試代碼很容易遺漏一些異常場(chǎng)景；
Unit層：?jiǎn)卧獪y(cè)試。最有價(jià)值的測(cè)試，但是對(duì)測(cè)試人員要求比較高，一般由開發(fā)人員完成，否則只能采用結(jié)對(duì)編程。
通常來(lái)說(shuō)，手工測(cè)試是最基本的，可以做到接近100%,而對(duì)于自動(dòng)化測(cè)試來(lái)說(shuō)，它更像是一件'防彈衣'，用來(lái)防護(hù)身體的主要部位。有人認(rèn)為自動(dòng)化率提高了，就可以節(jié)省人力，這實(shí)際是非常片面的，因?yàn)樘岣咦詣?dòng)化率，意味著需要投入更大的人力在維護(hù)的成本上。因?yàn)橄到y(tǒng)的需求是在不斷變化的，每一個(gè)變化都會(huì)導(dǎo)致自動(dòng)化測(cè)試用例需要更新調(diào)整。
所以，自動(dòng)化測(cè)試做到什么樣才算好，也要結(jié)合上面的測(cè)試金字塔來(lái)分析。對(duì)于UI層面的自動(dòng)化測(cè)試，保證少量必要的主流程即可，切勿在這一層面將自動(dòng)化測(cè)試的'防彈衣'變成臃腫的'宇航服'；Service層面的接口自動(dòng)化測(cè)試，可以考慮覆蓋大部分的流程；Unit層面的單測(cè)，做到100%是最好的，即使有需求變化，一般也很少影響到已有的用例。一般來(lái)說(shuō)，單元測(cè)試可以發(fā)現(xiàn)80%的缺陷。
通常來(lái)說(shuō)，一個(gè)Test Suite下包含了一組相近的或者有關(guān)聯(lián)的Test Cases。而每一個(gè) Test Case 應(yīng)該只測(cè)試一種場(chǎng)景，根據(jù)case復(fù)雜程度，不同場(chǎng)景同樣可大可，可以是某個(gè)單元的測(cè)試，也可以是端到端的測(cè)試(E2E)，當(dāng)然也有特殊的寫法比如工作流測(cè)試和數(shù)據(jù)驅(qū)動(dòng)。
Case的獨(dú)立性有哪些需要關(guān)注的點(diǎn)呢?
首先Test Suite內(nèi)的Cases在執(zhí)行時(shí)不應(yīng)該相互影響，意思是說(shuō)當(dāng)我們有隨機(jī)的跑其中某個(gè)Case或亂序的跑這些Cases時(shí)，測(cè)試的結(jié)果都應(yīng)該是準(zhǔn)確的。Suite level和Directory level同樣要注意獨(dú)立性的問(wèn)題。系統(tǒng)較為龐雜時(shí)，可能會(huì)將數(shù)百上千的Cases放在一起跑，Robot本身不會(huì)規(guī)定Case執(zhí)行的順序，所以從某種程度上來(lái)說(shuō)同一層級(jí)的Cases是隨機(jī)執(zhí)行的。很典型的情況就是，測(cè)試用例在本地調(diào)試時(shí)怎么跑怎么過(guò)，放到Server上所有Cases一起跑的時(shí)候就會(huì)Fail,還可能是偶發(fā)的，這種情況下就很可能是由于其他Case的痕跡影響到了它，查找問(wèn)題的根源往往比較耗時(shí)。
Case的可遷移性主要考慮三點(diǎn) : Case對(duì)執(zhí)行環(huán)境的依賴 ; Case對(duì)外部設(shè)備的依賴;Case對(duì)測(cè)試對(duì)象的依賴。
Case對(duì)執(zhí)行環(huán)境的依賴
盡量減少對(duì)執(zhí)行環(huán)境的依賴。舉一個(gè)例子，你在本地PC上使用rf框架編寫、調(diào)試用例后，上傳到Git，然后你的領(lǐng)導(dǎo)可能會(huì)拉取你的用例在他的本地運(yùn)行，隨后又被部署到持續(xù)集成服務(wù)器上。所以你編寫的用例時(shí)就要盡量避免使用不同平臺(tái)的庫(kù)或者shell命令。
再舉個(gè)例子，如果你因?yàn)闃I(yè)務(wù)需要而修改了測(cè)試庫(kù)源碼的話，此時(shí)不管是組內(nèi)其他人還是CI服務(wù)器，肯定都會(huì)運(yùn)行失敗，這種情況該怎么解決呢？這里提供兩個(gè)解決方法：
Case對(duì)外部設(shè)備的依賴
有時(shí)為了業(yè)務(wù)測(cè)試需要，我們會(huì)引入一些外部設(shè)備來(lái)輔助測(cè)試，外部設(shè)備可能會(huì)持續(xù)升級(jí)或者更換，在編寫用例時(shí)我們就需要考慮如何用一套Case更好的兼容這些測(cè)試設(shè)備。比如可以將外部設(shè)備的操作從測(cè)試用例中抽離出去，封裝成測(cè)試庫(kù)或關(guān)鍵字；
Case對(duì)測(cè)試對(duì)象的依賴
如果測(cè)試對(duì)象是一個(gè)軟件平臺(tái)，軟件平臺(tái)通常需要適配多種的設(shè)備，而設(shè)備的硬件配置可能是多種多樣的：CPU、內(nèi)存、組件的性能和數(shù)量都可能不同。對(duì)測(cè)試對(duì)象的依賴不僅要考慮在不同設(shè)備上的可執(zhí)行性，重點(diǎn)還要考慮測(cè)試覆蓋率。由于設(shè)備組件的增多你的用例可能無(wú)法覆蓋到這些組件，或者捕捉不到某個(gè)性能瓶頸，這樣測(cè)試結(jié)果的可靠性也大打折扣。
不同的case執(zhí)行時(shí)間相距甚遠(yuǎn)，短則數(shù)秒長(zhǎng)則持續(xù)數(shù)天。數(shù)秒鐘的簡(jiǎn)單功能測(cè)試用例和耗時(shí)數(shù)天的穩(wěn)定性測(cè)試用例本身是沒(méi)有什么可比性的。但是我當(dāng)我們放眼某一個(gè)或者某一組case時(shí)，我們就需要重視Case的執(zhí)行效率。不論是敏捷流程還是持續(xù)集成都講究快速的反饋，開發(fā)人員能在提交代碼后快速的獲得測(cè)試結(jié)果反饋，測(cè)試人員能在最短的時(shí)間內(nèi)執(zhí)行更大范圍的測(cè)試覆蓋，不僅能提高團(tuán)隊(duì)的工作效率，也可增強(qiáng)團(tuán)隊(duì)的信心。
以使用rf為例，在編寫用例時(shí)可以通過(guò)以下方面來(lái)提高用例的執(zhí)行效率。
1.如果有對(duì)執(zhí)行條件的檢查，若檢查失敗，則盡快退出執(zhí)行；
2.將數(shù)據(jù)準(zhǔn)備或環(huán)境清除等工作抽取成關(guān)鍵字放到更高的層級(jí)中,，抽取時(shí)可能需要做一些組合, 但不允許出現(xiàn)重復(fù)的建刪操作；
3. 用例中盡量少的出現(xiàn)sleep，建議用'wait until ...'來(lái)代替；
4. 可以采用并發(fā)執(zhí)行用例的方法來(lái)提升效；
第一個(gè)單詞應(yīng)以小寫字母作為開頭，后面的單詞則用大寫字母開頭。 如：getProjectId, connectDB
常量的名字應(yīng)該都使用大寫字母，并且指出該常量完整含義。如果一個(gè)常量名稱由多個(gè)單詞組成，則應(yīng)該用下劃線來(lái)分割這些單詞。 如：MAX_CHAR_LENGTH
參數(shù)的命名規(guī)范和方法的命名規(guī)范相同，請(qǐng)?jiān)诒M量保證參數(shù)名稱為一個(gè)單詞的情況下使參數(shù)的命名盡可能明確。如：${account} , ${investorName}
RF提供了通過(guò)在Settings中設(shè)置tags來(lái)管理用例的方法。Tag的應(yīng)用非常的廣泛和靈活，比如可以用來(lái)做用例篩選、版本管理、統(tǒng)計(jì)策略等。
怎么打tag看起來(lái)會(huì)更便捷？
在考慮Coding Style時(shí)我們可以設(shè)置一些固定的規(guī)則,大家只要按照這個(gè)規(guī)則來(lái)做,實(shí)踐幾次之后Coding Style就會(huì)趨于統(tǒng)一. 而考慮將Case寫的如同文檔一般則需要更多的主觀能動(dòng)性。
敏捷開發(fā)(Agile Development)在國(guó)內(nèi)的發(fā)展已經(jīng)越完善，伴隨之而來(lái)的便是敏捷測(cè)試(Agile Testing)。敏捷思想強(qiáng)調(diào)以人為核心，在整個(gè)開發(fā)流程中，只寫有必要的文檔或盡量少寫文檔，這也是它與傳統(tǒng)的瀑布模型的差別。
為了不造成誤解，這里有必要插入的說(shuō)一下敏捷測(cè)試的幾個(gè)特點(diǎn)：
- 敏捷測(cè)試應(yīng)該是敏捷開發(fā)的一部分；
- 敏捷測(cè)試具有鮮明的敏捷開發(fā)的特征，如測(cè)試驅(qū)動(dòng)開發(fā)(TDD),驗(yàn)收測(cè)試驅(qū)動(dòng)開發(fā)(ATDD)。也就是說(shuō)，單元測(cè)試是敏捷測(cè)試的基礎(chǔ)，如果沒(méi)有足夠的單元測(cè)試，就無(wú)法應(yīng)對(duì)將來(lái)需求的快速迭代，也無(wú)法實(shí)現(xiàn)快速而穩(wěn)定的持續(xù)交付；
- 優(yōu)秀的敏捷測(cè)試是基于自動(dòng)化測(cè)試的；
- 敏捷測(cè)試無(wú)時(shí)不在，無(wú)處不在。
需求設(shè)計(jì)不斷的更新，而文檔往往不能被很及時(shí)的更新，那這樣的話怎么才能讓測(cè)試人員如何快速的掌握某個(gè)功能或者產(chǎn)品的需求和當(dāng)前狀態(tài)呢?
'Tests as Documentation.'
在實(shí)際的工程中，我們可能會(huì)新建一個(gè)目錄來(lái)存儲(chǔ)測(cè)試點(diǎn)相近的測(cè)試用例。每一個(gè)Case都對(duì)應(yīng)一個(gè)測(cè)試點(diǎn)，而用例名則應(yīng)該概括總結(jié)對(duì)應(yīng)測(cè)試點(diǎn)的核心內(nèi)容，這樣當(dāng)我們?cè)跒g覽一組用例時(shí),僅僅通過(guò)用例名就能大致了解里面的測(cè)試內(nèi)容,也方便尋找某個(gè)Case。
在實(shí)際的工程中，我們可能會(huì)新建一個(gè)目錄來(lái)存儲(chǔ)測(cè)試點(diǎn)相近的測(cè)試用例。每一個(gè)Case都對(duì)應(yīng)一個(gè)測(cè)試點(diǎn)，而用例名則應(yīng)該概括總結(jié)對(duì)應(yīng)測(cè)試點(diǎn)的核心內(nèi)容，這樣當(dāng)我們?cè)跒g覽一組用例時(shí),僅僅通過(guò)用例名就能大致了解里面的測(cè)試內(nèi)容,也方便尋找某個(gè)Case。
聯(lián)系客服
