自動化測試框架 設計的重構

2021-04-18 06:31:26 字數 2803 閱讀 7614

最近對測試框架進行了重構,也對其中原有的一些設計進行了反思。其中不免有一些自我感覺得意之處,因此寫出來和大家分享。這是乙個重構的過程,所以將以重構的思路來講述。

重構對於乙個系統來說,往往是必要的。他的必要性往往不在於重構的好處,而在於系統的成長的趨勢。乙個好的系統在初步階段,在很多方面都會存在成長的空間,就如人在小時候長身體一樣,如果補充的營養跟不上,一生都可能會受到影響。

對於我們這個系統來講,目前也正是初步使用驗證階段,所以重構的可能性非常大。當然了,如果從成本角度來看,在系統重構的時候,必須對系統的使用做嚴格的管理。幸好我們在早期對這方面比較謹慎,使用範圍沒有盲目擴充套件。因此重構所帶來的影響會被縮小到最小範圍。

那麼先來說說這次重構的目的。在原先的框架系統中,設計思路是在delphi中編寫自動化測試,**通過呼叫控制項的適配介面,最終完成對介面的操作。而這些**,也被編譯到dll中。這裡面就有一些問題:

每一次修改,都必須重新編譯。

由於dll被程式load,不可直接覆蓋(替換),所以必須重新啟動目標測試系統。

基本上不可以部分執行指令碼。

自動化**和自動化框架**同時暴露給使用者

再一次說明一下原先的設計。原先的設計中,自動化**將作為dll的一部分被編譯進去,而這個dll會作為程式系統的一部分被裝載。本來我想用圖形來表示,突然感覺其實可以多多用表示式來表示,我想做乙個嘗試,這樣可以免去的麻煩。下面是系統的表示:

被測試系統(自動化框架(自動化**))

其中括號表示包含關係。可以看到,最終只有乙個系統在執行。

在這裡關注一下列出的問題重點,這在重構過程中非常重要。因為重構並不是盲目的。需要做到目標準確不偏移。簡單點說就是將好刀用在刀刃上。並且要保障重構的結果能呼應最初的目的。並且這次重構屬於系統級別的重構,重點不是一些類的調整,而是整天解決方案的革新。

為了解決這些問題,我們思考從指令碼入手,進行自動化測試框架的重構。但在做之前,必須考慮好重構系統的穩定性如何保障。系統級別的重構和單元級別的重構的保障機制應該是不一樣的。這不得不提到單元測試,但僅僅是單元測試是無法保障的。

第一、系統中大部分類可能都有所改變。針對原先的單元測試必須重新編寫。

第二、系統級別的測試不能被單元測試替代。因此非常有必要持續進行。

這裡,我並沒有做方法上深入**,但是測試這件事必須做。電腦暫時做不了的事,人來做。我們在單元測試的基礎上,持續迭代地對重構後的系統進行系統測試,這樣能盡量快速地發現重構中失誤所在。

後來發現,在重構過程中,對新的方法編寫測試用例更加有效。因為重構往往是在時間緊急的情況下進行的,所犯錯誤可能比初期編碼階段更容易。這個階段,舊的單元測試**和新的單元測試**能夠很好提公升系統的穩定性。

現在講一下重構的過程。重構的目標是,將自動化**的編寫改變為xml的配置。自動化框架通過讀取配置,並解析每一段指令碼,自動執行。我們先不談其中的實現技術細節,而是先來談談這樣的好處。

指令碼是解釋性的,因此框架dll不需要重新編譯。

指令碼由於成為配置,那麼其管理也就變得更加容易和簡單。

可以讓測試人員,完全只是關心業務上的指令碼。

從配置中,可以方便地記錄每一步的執行內容。原先的編譯方式,失去了很多資訊。

配置可以動態組織,這樣有可能實現部分指令碼的執行。

重構,就是發現問題到解決問題的過程。相對於設計的不同,在於重構是在現有設計的基礎上發現問題。

下面說說實現過程中的細節。在這個過程中,最關鍵的是指令碼的解析。由於之前,針對所有控制項,都已經有了封裝的介面,因此在這個基礎上,我們考慮到採用soap的實現思想,通過對介面方法的invoke,來實現最終的指令碼執行。

要實現這個invoke的過程,就必須深入了解一下delphi是如何實現soap的。這當然是另外乙個話題了。有興趣的可以看一下invoker.pas中的**。要實現invoke的過程,可以有兩個選擇:

完全參考soap的呼叫約束

自己定義結構,自己解析轉換引數,實現invoke

我實際是選擇了後者,雖然說對於我理解invoke原理有了很大幫助,但後來還是證實我的選擇不是最好的。先不管這個了。

完成了invoke的過程,下面就是指令碼的設計了。我為指令碼的設計,增加了幾方面的內容:

定義testwindow的概念,表示每乙個被測試和編碼的窗體。

定義teststep的概念,表示對使用者介面發出的每一次命令。

定義testpackage概念,表示多個teststep的組合。

定義testwindow和teststep之間的關係。testwindow包含多個teststep。每乙個teststep包含多個testwindow,表示這個命令可能觸發的新的測試窗體。

定義這些概念是非常有意義的。可以幫助我們清晰地理解系統,也非常便於以後的技術交流。這也說明了自動化測試框架本身設計的完善和進步。

在定義完成這些概念後,就是完成乙個指令碼的配置工具。並在這個編輯器上實現指令碼的除錯和日誌功能。除錯方面,我們選擇了http的呼叫方式。其實可以選擇很多其他方式。一來http的方式,實現起來很簡單。二來支援http後,呼叫自動化測試,只需要通過http就可以了。finalbuilder和一些shell都支援這種方式。這對於以後的自動化呼叫是非常有意義的。

現在系統的架構變了。不再是原先的乙個系統了,因為這裡引入了乙個輔助系統,可以稱之為自動化的ide。再使用上面的方式,我們描述以下系統:

被測試系統(自動化框架)= ide(自動化指令碼)

等號表示系統互動是雙方向的。ide向系統傳送指令碼,系統向ide傳送log。

好了,這次重構基本都完成了。整個過程的中心在於指令碼的結構遷移。而重構的前因和結果也都進行了對比。雖然說很多方面的細節也許並沒有考慮清楚。但是這次框架設計的重構,還是非常有價值的!而且整個重構的過程,更是框架本身的完善過程。

希望自動化測試框架越來越好!

自動化測試框架 設計的重構

最近對測試框架進行了重構,也對其中原有的一些設計進行了反思。其中不免有一些自我感覺得意之處,因此寫出來和大家分享。這是乙個重構的過程,所以將以重構的思路來講述。重構對於乙個系統來說,往往是必要的。他的必要性往往不在於重構的好處,而在於系統的成長的趨勢。乙個好的系統在初步階段,在很多方面都會存在成長的...

自動化測試框架 設計的重構

最近對測試框架進行了重構,也對其中原有的一些設計進行了反思。其中不免有一些自我感覺得意之處,因此寫出來和大家分享。這是乙個重構的過程,所以將以重構的思路來講述。先來說說為什麼會重構。原先的框架系統,思路是將自動化 通過呼叫控制項的適配介面,最終完成對介面的操作。而這些 也被編譯到dll中。這裡面就有...

demo的自動化測試框架設計

準備環境 pycharm 思路 python request unittest htmltestrunner 框架 框架的可讀性需要強 公共方法提取 可變引數需要提取放入配置檔案 做好日誌記錄 單個指令碼能執行成功,前後指令碼資料無依賴 結構是 結構說明 config 配置資訊 data 存放資料資...