如果沒有用到自動(dòng)化測(cè)試，顯得那么不與時(shí)俱進(jìn)，但引入自動(dòng)化測(cè)試，卻是一件不是那么容易的事，在引入自動(dòng)化測(cè)試后，可能需要面臨一些問題，包括但不限于以下幾點(diǎn)：
1， 具備腳本開發(fā)的測(cè)試人員少
2， 培訓(xùn)成本大，但成效不明顯
3， 面臨工具及開發(fā)技術(shù)的選
4， UI，需求，功能發(fā)生變化后，基于UI的腳本維護(hù)大非常大
5， 線性腳本造成海量腳本，開發(fā)及維護(hù)工作量大
6， 沒有自己的測(cè)試框，擴(kuò)展性及移植性差
那么如果解決這些問題，有沒有成功案例可借鑒呢，如何設(shè)計(jì)開發(fā)一套自動(dòng)化測(cè)試平臺(tái)或框架才能在測(cè)試團(tuán)隊(duì)快速高效的推廣使用起來呢?；趥€(gè)人經(jīng)驗(yàn)，大概一套比較好的平臺(tái)或框架需要以下這些必要的基礎(chǔ)功能模塊：
1， 一套框架管理多個(gè)被測(cè)系統(tǒng)，而不是為多個(gè)項(xiàng)目設(shè)計(jì)多個(gè)框架
這樣做可以避免不同的項(xiàng)目系統(tǒng)采用的自動(dòng)化測(cè)試技術(shù)不同，而造成技術(shù)成本。
2， 自動(dòng)提交缺陷到缺陷管理系統(tǒng)
3， 連接被測(cè)系統(tǒng)的數(shù)據(jù)庫，以方便做數(shù)據(jù)驗(yàn)證
4， 測(cè)試腳本與測(cè)試用例（數(shù)據(jù)）分離
測(cè)試用例可以獨(dú)立完成（如果有專職設(shè)計(jì)測(cè)試用例，將會(huì)有更高的覆蓋率）
5， 高復(fù)用性測(cè)試腳本
這可能包括兩個(gè)部分，既然可以管理多個(gè)被測(cè)系統(tǒng)，那么每個(gè)被測(cè)系統(tǒng)具有獨(dú)立的共享類和方法，而平臺(tái)框架本身有自己的核心模塊，也有提供給每個(gè)被測(cè)系統(tǒng)共享的類和方法。
6， 易維護(hù)性腳本
特別是基于UI的腳本，更是要將UI操作封裝設(shè)計(jì)，這樣可以最大限度減少UI變化引起的維護(hù)量，而測(cè)試腳本可以更關(guān)注于業(yè)務(wù)邏輯，而不是UI元素操作。
7， 一目了然的測(cè)試報(bào)告
管理人員可能希望看到某次測(cè)試的結(jié)果是測(cè)試了多少個(gè)用例場(chǎng)景，通過多少個(gè)，不通過多少個(gè)，通過率多少等這些數(shù)據(jù)。而測(cè)試人員或開發(fā)人員看到報(bào)錯(cuò)截圖外，希望可以快速定位到當(dāng)時(shí)的測(cè)試場(chǎng)景和數(shù)據(jù)，以便分析具體的問題。
So，有什么合適的自動(dòng)化測(cè)試平臺(tái)嗎？我之前用的是Postman，但是因?yàn)楣居袊a(chǎn)化要求就換了Eolinker，用得還不錯(cuò)。
聯(lián)系客服
