對自動化測試接觸不深的同學，往往會認為自動化測試只是簡單的手工測試步驟的指令碼翻譯過程，其實不然，如果真這樣操作，往往後期的維護成本會很高。在網際網路，特別是移動網際網路盛行的當下，一款受歡迎的產品，多半會部署android，ios，pc等多個版本的客戶端。本文中根據乙個真實的自動化測試專案的實現抽象出如下的測試架構圖，以此解決自動化測試會遇到的以下幾個難點問題：
1. 測試業務抽象：從業務測試需求描述（what，即做什麼）的抽象層面講，在多個客戶端上是基本一致的，比如挖財這款記帳軟體的絕大部分功能需求，在android，ios客戶端上抽象出來是一致的，不同的無非是控制項的布局，以及操作流程稍有差別。我們採用robotframework（以下簡稱rf）中文描述測試需求，然後在多個客戶端上盡可能最大粒度的復用這份測試需求，這樣在新的端接入的時候，只要實現下層的驅動層和測試邏輯層面即可。在敏捷測試領域中推崇的」活的文件「這一概念，大體上也是這個意思。
3. 業務操作的多用途復用：舉個簡單的例子，拿登入這個功能的測試來講，作為測試本體，會有常規的資料驅動測試；作為測試輔助體，它又是很多業務流程測試的準備條件，所以對於登入這個業務操作，要能滿足一處實現，多處復用。同樣我們還需要它來輔助進行基於模型的探索性測試，關於這點在下面來介紹。
4. 基於模型的探索性測試：傳統自動化測試指令碼在編寫除錯完成後，在很長的一段時間內執行的順序都是固定不變的，能發現的bug大多在除錯自動化指令碼的開始階段就已經被發現了，後期不斷執行的過程中就少有bug發現了，我們稱這類自動化指令碼為靜態自動化測試，這種自動化測試方式存在的最大問題，就是殺蟲劑效應。這種型別的自動化測試偏向用於持續整合中保證產品功能沒有被破壞的驗證。在敏捷測試中，除了這類測試之外，一般也會引入手工的探索性測試，用於發現殺蟲劑效應之外那些沒有被發現的缺陷。如果利用自動化測試來嘗試探索性測試這個領域，是自動化測試面臨的乙個挑戰，也是展現其重要價值的乙個突出的亮點。反思我們測試人員了解產品的過程就會發現，隨著對產品的不斷熟悉，業務的不斷了解，慢慢地在我們的大腦中建立起了這個產品的業務模型，這個模型就是輔助我們做手工探索性測試的基礎。如何將我們大腦中已儲存的產品業務模型用測試**來實現，是關鍵的難點。在實踐過程中，我們將此類測試分成兩類：單點功能利用有限狀態機實現探索性測試（通過這種在狀態節點間輪循的方式發現了乙個經過四五十步發現的缺陷）；整體業務邏輯的模型探索性測試，這種探索性測試的難點是構建activity/頁面節點的路徑圖、節點之間步進方路徑法實現，步進方式分為最短路徑和多路徑隨機等多種方式。
在以後的博文中，會逐漸將整個測試架構中涉及的一些關鍵點的**貼上來。
團隊專案開發 客戶端系統架構設計
進行了很長時間的設計一直沒有匯報程序進行總結，下面就客戶端的系統架構設計進行說明和介紹。客戶端共分為登入 註冊 遊戲世界3個子系統。1 登入 為了伺服器設立的子系統，負責將玩家輸入的使用者名稱和密碼與資料庫中儲存的資訊比對，從而驗證玩家身份，提取玩家人物資訊 2 註冊 為了伺服器設立的子系統，負責讓...
pywinauto客戶端自動化 模擬滑鼠操作
無論什麼自動化，都避免不了模擬一些滑鼠操作，pywinauto模組中也存在模擬滑鼠操作方法 mouse是pywinauto乙個模擬滑鼠的方法庫，可以幫助模擬滑鼠操作，直接輸入座標就可以了。座標起始是在電腦螢幕的左上角開始計算。如下圖 使用方法 from pywinauto import mouse ...
UI自動化測試POM設計之 思路結構
測試框架思路介紹 採用pageobject設計模式是將某個頁面的所有 元素 包含控制項 屬性 及 元素操作 封裝在1個類 class 裡面，目的是為了將測試 與被測頁面物件 分離，後期如果有頁面元素發生更改，只需要修改相應頁面物件的 即對應class檔案 而不需要修改測試 也是為了進一步降低後續因頁...