如果沒有用到自動化測驗，顯得那么不與時俱進，但引入自動化測驗，卻是一件不是那么容易的事，在引入自動化測驗后，可能需要面臨一些問題，包括但不限于以下幾點：
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
轉載請註明出處，本文鏈接：https://www.uj5u.com/qita/266256.html
標籤：其他