如何實現工具無關化？關於自動化測試指令碼的設計

1.問題的提出

最近幾年來，我的自動化測試工具之旅大致是這樣的，最早用的是QTP,然後是RFT(IBM的功能測試自動化產品),之後也經歷了Selenium, Watir等，再後還是一些商業工具主要是偏web自動化及移動自動化，如sahi, appnium, Keynote DeviceAnywhere, SeeTest, HP UFT等，這一系列的變化，讓人痛苦的不是學習的過程，也不是各種程式語言的轉換，最痛苦的是我們的自動化測試指令碼要因為工具的變化而需要重寫，因為無法重用，我們或是維護多種自動化工具指令碼，或是將自動化測試指令碼為最近使用的工具進行重寫編寫，有太多的effort花在這些事情上。 進入》    軟體測試社群學習交流   加我VX：atstudy-js 回覆“測試”，進入 自動化測試學習交流群~~

我們怎麼解決這類問題呢？試想，如果我們能夠有這樣一個平臺，如果提供統一的自動化程式設計API,而且獨立於某種工具，那該 有多好。所以本文的目的要設計 這樣一個平臺，能夠對自動化測試人員提供統一的程式設計介面，能夠適應測試工具的變化，而無須修改已經基於此平臺程式設計好的自動化測試指令碼。

2. 如何實現工具無關化

首先，我們要考慮工具無關化，如果要實現工具無關化，那麼對於使用者（自動化測試指令碼實現者）一定是使用一致的api，一致的測試元素，一致的資料訪問方式。那麼我們先要考慮一下測試元素的一致性。

這裡我們先假設我們未來的待測試應用都是web應用或是mobile應用，而mobile應用我們使用的都是hybrid應用。對於測試元素來講，最重要的是如何能夠識別它，我們在識別元素的時候，都會找到一個唯一id或屬性來標識它。來看我們上邊假設的應用，我們可以使用xpath來做為唯一id來識別元素。你可能根據自已實際場景來設計來定義它。除此之外，為了能夠操作元素，我們需要知道它的名字，因為我們還需要為它命名。除此之外，我們還需要使用一個型別欄位來區別不同工具之間可能對測試元素有些特別的要求，我們通常使用type欄位來標識它。所以我們從邏輯上來看，一個工具無關的測試元素大致看起來是這樣的。

對於測試資料來講，我認為，每個資料都是有一個列和一個值組成，所有資料看起來比較簡單。

資料有一點需要注意一下，如果我們要實現資料驅動的自動化測試，我們就需要在此平臺提供處理多行資料能力。

有了測試物件和測試資料之後，我們需要了解我們的待測試應用，我們的平臺需要對待測試應用使用之前進行一些配置，使用時還要進行一些初始化等工作，使用完我們還會對些進行一些清理銷燬等工作。。如此一來，我們的平臺需要考慮如何進行測試設定工作，因為未來我們平臺面對可能各種不同的測試工具，那麼在這裡我們也需要在些考慮好一致的介面。所以此部分看來如下所示：

對於測試元素的操作，我們通常會使用類似 click, setValue 等一些點選，填值的操作，我們同時還會檢查一些測試元素是否在頁面中存在，也會檢測一個測試元素是否展示在螢幕上。我們可以將些部分統一歸結為 action. 所以物件的 action 看起來如下所示：

除了 action 之外，我們的平臺還要提供 checkpoint 功能，此功能是為了能夠讓我們指令碼有能力判斷最近測試結果是透過還是失敗。即有一個 checkpoint 失敗了，整個測試指令碼就是失敗狀態。Checkpoint 的功能使用起來極其簡單，我們需要為其輸入兩個引數，一個為 expect,一個為 actual,二者進行比較並返回比較結果。這裡需要強調的一點是，我們設計 checkpoint 時，要使其能夠為其二個引數可以自適應到各種資料型別，因為我們實際應用時，有時會使用兩個布林值進行判斷，有時可能會使用兩個字串進行判斷，也可能我們可能直接將兩個物件傳過來進行比較。所以這裡我們要讓其能夠自適應。

講到這裡，我們的平臺還需要至少要有的一個功能是 report, 我們的 report 要能夠展示測試指令碼最終是透過了還是失敗了。同時能夠記錄每個步驟的狀態，能夠截圖。當然，如果 report 能夠提供更多的 metric 資料就更好了。方便未來計算 ROI.

講到這裡我們都是講的都是對外提供的統一的 API，從使用都角度，這些已經基本夠用了。但是對於工具來講，我們要實現工具無關化，我們要講起來可能會簡單一些，但是實際做的時候還是比較麻煩的。因為我們需要針對我們平臺支援的每一套測試工具編寫介面，使其在外邊看起來是一樣的。所以平臺這邊說起來是簡單的，但實現工作量還是比較大的，因為每套工具都有其複雜性，再次封裝後並提供統一的簡單易用介面並非總是那麼容易。所以編寫介面的人，必須 是對其封裝的工具是極其熟悉的，並且有豐富的實際應用經驗，因為這種你們才能為使用者寫出他們真正所需的介面。

3. 總結

在上面我大致講解了要實現一個工具無關的自動化測試平臺所應該具有最少元素集合。在實際應用中，我們所做的工作遠遠大於這個集合。但是有了這個平臺之後，我們自動化指令碼的重用率有了很大的提升。對於團隊中的自動化實現者來說，它們不需要再痛苦了學習和掌握每一種新的工具，或是因為工具的變化而重寫自動化測試指令碼了。

最後：

可以到我的個人V：atstudy-js，免費領取一份10G軟體測試工程師面試寶典文件資料。以及相對應的影片學習教程免費分享！其中包括了有基礎知識、Linux必備、Mysql資料庫、抓包工具、介面測試工具、測試進階-Python程式設計、Web自動化測試、APP自動化測試、介面自動化測試、測試高階持續整合、測試架構開發測試框架、效能測試等。

這些測試資料，對於做【軟體測試】的朋友來說應該是最全面最完整的備戰倉庫，這個倉庫也陪伴我走過了最艱難的路程，希望也能幫助到你！