【分析】自動化測試解決方案

若是沒有用到自動化測試,顯得那麼不與時俱進,但引入自動化測試,倒是一件不是那麼容易的事,在引入自動化測試後,可能須要面臨一些問題,包括但不限於如下幾點:
1, 具有腳本開發的測試人員少
2, 培訓成本大,但成效不明顯
3, 面臨工具及開發技術的選
4, UI,需求,功能發生變化後,基於UI的腳本維護大很是大
5, 線性腳本形成海量腳本,開發及維護工做量大
6, 沒有本身的測試框,擴展性及移植性差數據庫

那麼若是解決這些問題,有沒有成功案例可借鑑呢,如何設計開發一套自動化測試平臺或框架才能在測試團隊快速高效的推廣使用起來呢。基於我的經驗,大概一套比較好的平臺或框架須要如下這些必要的基礎功能模塊:
1, 一套框架管理多個被測系統,而不是爲多個項目設計多個框架
這樣作能夠避免不一樣的項目系統採用的自動化測試技術不一樣,而形成技術成本。
2, 自動提交缺陷到缺陷管理系統
3, 鏈接被測系統的數據庫,以方便作數據驗證
4, 測試腳本與測試用例(數據)分離
測試用例能夠獨立完成(若是有專職設計測試用例,將會有更高的覆蓋率)
5, 高複用性測試腳本
這可能包括兩個部分,既然能夠管理多個被測系統,那麼每一個被測系統具備獨立的共享類和方法,而平臺框架自己有本身的核心模塊,也有提供給每一個被測系統共享的類和方法。
6, 易維護性腳本
特別是基於UI的腳本,更是要將UI操做封裝設計,這樣能夠最大限度減小UI變化引發的維護量,而測試腳本能夠更關注於業務邏輯,而不是UI元素操做。
7, 一目瞭然的測試報告
管理人員可能但願看到某次測試的結果是測試了多少個用例場景,經過多少個,不經過多少個,經過率多少等這些數據。而測試人員或開發人員看到報錯截圖外,但願能夠快速定位到當時的測試場景和數據,以便分析具體的問題。框架

So,有什麼合適的自動化測試平臺嗎?我以前用的是Postman,可是由於公司有國產化要求就換了Eolinker,用得還不錯。

使用地址:www.eolinker.com工具

相關文章
相關標籤/搜索