我們日常實現系統級別自動化測試的時候,一個用例需要執行多種類型的測試步驟,包括:數據庫、日志、 Web 和一些模擬工具的操作。 Sikuli 實現界面類型的測試步驟是其長處。本文研究了如何將 Sikuli 融合到系統級別的自動化測試流程中,解決系統測試用例中界面測試步驟無法實現的問題。
在實際做某平臺項目自動化測試的過程中,發現平臺的自動化測試一直無法有效開展。平臺項目本身系統及其復雜,造成測試難度就比較高。因為
1、 項目的模塊眾多;
2、 版本類型多;
3、 功能多;
4、 流程狀態鏈長,導致狀態路徑多,任何一個出錯都會導致失敗。
除了系統復雜,導致自動化測試比例不高的另外一個重要的原因是原來的自動化測試方案:通過完全的消息收發來實現流程的方案,有很多弊端。
1、 消息都是私有協議封裝的消息,消息都是二進制類型的。導致測試用例的配置繁瑣,工作量大(大量的資源都用于配置消息字段級的值),且容易出錯。
2、 采用消息流的方式導致測試過程不直觀,無法對正常的手動測試產生幫助
3、 工具復雜,維護難度大,現在已經沒人維護,導致新功能無法實現自動化測試。
原文轉自:https://mp.weixin.qq.com/s/XMsmK6kaysG7Y_DUZjnx-Q