自動化工具測試講解

1、精選優(yōu)質(zhì)文檔-傾情為你奉上如何做自動化測試什么叫做自動化測試工程師首先，會使用自動化測試工具的測試人員不能夠稱之為完全的自動化測試人員，這類測試人員被稱為工具小子(Script Kid)。這個階段還是處于自動化測試的一個比較低級的階段，因?yàn)檫@些工具都不是測試人員開發(fā)的。對于高手來說，要能寫一些獨(dú)立的測試腳本甚至測試工具。更高的高手則是能腳本和工具和實(shí)際工作緊密結(jié)合起來，解決工作中遇到的問題。自動化測試工程師應(yīng)該具有開發(fā)能力嗎通過上述內(nèi)容，應(yīng)該可以看得出來，自動化測試人員一定要有開發(fā)能力，而這恰恰是測試人員目前所欠缺的。沒有開發(fā)能力的測試人員雖然也可以做一些所謂的自動化，但是僅僅是一些皮毛，沒有

2、辦法做到活學(xué)活用。根據(jù)某機(jī)構(gòu)的調(diào)查數(shù)據(jù)，目前所有從事測試工作的人中，90%的人都沒有任何開發(fā)能力。根據(jù)目前的市場行情，如果在精通一門開發(fā)語言，能夠從純手工測試轉(zhuǎn)型為自動化測試工程師，月薪至少增加35k。自動化測試的層級一般來說，自動化測試分為三個層級：單元測試、接口測試和UI測試，這三層成一個金字塔形狀分布。最底層是單元測試，接口測試在中間，UI測試在最上層。下面通過一個表格來對比著三層測試。層級所處位置受益測試對象運(yùn)行速度定位問題難度維護(hù)成本單元測試底層70%類或者方法極快十分容易低接口測試中間20%服務(wù)接口快一般低UI測試上層10%UI慢較難非常高從表格中我們可以看到，最適合做自動化的是單

3、元測試層，而UI層則不是十分適合進(jìn)行自動化。測試人員應(yīng)該怎么辦單元測試單元測試無疑是最適合做自動化的，但是，大多數(shù)單元測試都是由研發(fā)人員自己完成。單元測試的代碼行覆蓋率能夠達(dá)到70%，就是一個非常不錯的程度了。測試人員不做單元測試，但是可以嘗試推動研發(fā)人員來編寫單元測試用例。單元測試框架 單元測試常用的框架XUnit，比如Java的JUnit，PHP的PHPUnit，Python的unittest等等； 一個測試用例通常由三部分組成setUp，測試邏輯，tearDown。setUp用于準(zhǔn)備測試數(shù)據(jù)，tearDown用于清理數(shù)據(jù)； 一般單元測試框架都支持裝飾器設(shè)計模式的注解，比如跳過執(zhí)行，測試套

4、件的組織，測試用例依賴管理等等單元測試框架可以無縫地在UI測試和接口測試中使用，它們的基本思想都是相通的。UI測試目前，大眾眼中關(guān)注的比較多的是UI的自動化測試，這是由大家的思維慣性導(dǎo)致的。傳統(tǒng)的測試行業(yè)，測試工程師都是從UI下手，來完成所有的測試工作，所以到自動化領(lǐng)域，大家也理所當(dāng)然的喜歡從UI層來進(jìn)行自動化。做UI自動化，最重要的是要能有一個好的自動化測試框架，這里有一些框架的基本設(shè)計思路供大家參考： 分布式case增加到一定程度后，如何快速的運(yùn)行所有的case，這就涉及到分布式的概念。對于Selenium，官方提供了一個Grid，感興趣的同學(xué)可以研究一下； 行為驅(qū)動也就是常說的Cucum

5、ber，這個領(lǐng)域筆者沒有太多的涉足，不誤導(dǎo)大家 關(guān)鍵字驅(qū)動由操作對象、操作、數(shù)據(jù)關(guān)鍵字組合成測試用例，框架來把關(guān)鍵字解析為腳本并執(zhí)行。這種框架最大的優(yōu)點(diǎn)就是可以提供給不懂代碼的測試人員使用，典型的代表是Robot framwork 數(shù)據(jù)驅(qū)動同一段代碼的業(yè)務(wù)邏輯通過更換數(shù)據(jù)輸入來生成多個測試用例，我們只需維護(hù)測試數(shù)據(jù)就可以維護(hù)case，這種框架思想在很多測試工具中都有實(shí)現(xiàn) 關(guān)鍵字和數(shù)據(jù)混合驅(qū)動目前最高級的框架，將上述兩種框架結(jié)合起來當(dāng)然，這些思路不僅僅能用在UI層的自動化。對于UI自動化，我個人的建議是只做冒煙測試用例的自動化，這樣既可以從UI的角度來重復(fù)性的驗(yàn)證主業(yè)務(wù)主流程沒有問題，又可以降低

6、維護(hù)成本。接口測試接口的自動化是目前最適合測試工程師進(jìn)行自動化的一層。接口不但變化小，運(yùn)行速度快，受益高，還有著出現(xiàn)問題后能夠很快定位的優(yōu)點(diǎn)。什么時候最適合做自動化首先，自動化測試從來都不是用來發(fā)現(xiàn)新的bug的，它更多的是用來驗(yàn)證原有功能是沒問題的，新的修改對原有代碼邏輯沒有影響。所以，當(dāng)一個項目相對穩(wěn)定之后，以后的項目都是基于原有代碼進(jìn)行迭代，這個時候自動化的介入是非常有效的。另外，如果某個用例需要有大量的輸入項，做手工測試比較繁瑣，我們也可以引入自動化的手段做局部的自動化。比如，驗(yàn)證某個用戶登錄1000次是否能夠登錄成功，這種情況使用手工的方式基本是不可能的?？偨Y(jié)服務(wù)端灰盒測試是一個很好的自動化測試的方向，從功能測試向服務(wù)端自動化測試轉(zhuǎn)型，需要自己學(xué)習(xí)充足的編程知識