如何實(shí)現(xiàn)工具無關(guān)化？關(guān)于自動化測試腳本的設(shè)計(jì)

1.問題的提出

最近幾年來，我的自動化測試工具之旅大致是這樣的，最早用的是QTP,然后是RFT(IBM的功能測試自動化產(chǎn)品),之后也經(jīng)歷了Selenium, Watir等，再后還是一些商業(yè)工具主要是偏web自動化及移動自動化，如sahi, appnium, Keynote DeviceAnywhere, SeeTest, HP UFT等，這一系列的變化，讓人痛苦的不是學(xué)習(xí)的過程，也不是各種編程語言的轉(zhuǎn)換，最痛苦的是我們的自動化測試腳本要因?yàn)楣ぞ叩淖兓枰貙懀驗(yàn)闊o法重用，我們或是維護(hù)多種自動化工具腳本，或是將自動化測試腳本為最近使用的工具進(jìn)行重寫編寫，有太多的effort花在這些事情上。

我們怎么解決這類問題呢？試想，如果我們能夠有這樣一個(gè)平臺，如果提供統(tǒng)一的自動化編程API,而且獨(dú)立于某種工具，那該 有多好。所以本文的目的要設(shè)計(jì) 這樣一個(gè)平臺，能夠?qū)ψ詣踊瘻y試人員提供統(tǒng)一的編程接口，能夠適應(yīng)測試工具的變化，而無須修改已經(jīng)基于此平臺編程好的自動化測試腳本。

2. 如何實(shí)現(xiàn)工具無關(guān)化

首先，我們要考慮工具無關(guān)化，如果要實(shí)現(xiàn)工具無關(guān)化，那么對于使用者（自動化測試腳本實(shí)現(xiàn)者）一定是使用一致的api，一致的測試元素，一致的數(shù)據(jù)訪問方式。那么我們先要考慮一下測試元素的一致性。

這里我們先假設(shè)我們未來的待測試應(yīng)用都是web應(yīng)用或是mobile應(yīng)用，而mobile應(yīng)用我們使用的都是hybrid應(yīng)用。對于測試元素來講，最重要的是如何能夠識別它，我們在識別元素的時(shí)候，都會找到一個(gè)唯一id或?qū)傩詠順?biāo)識它。來看我們上邊假設(shè)的應(yīng)用，我們可以使用xpath來做為唯一id來識別元素。你可能根據(jù)自已實(shí)際場景來設(shè)計(jì)來定義它。除此之外，為了能夠操作元素，我們需要知道它的名字，因?yàn)槲覀冞€需要為它命名。除此之外，我們還需要使用一個(gè)類型字段來區(qū)別不同工具之間可能對測試元素有些特別的要求，我們通常使用type字段來標(biāo)識它。所以我們從邏輯上來看，一個(gè)工具無關(guān)的測試元素大致看起來是這樣的。

對于測試數(shù)據(jù)來講，我認(rèn)為，每個(gè)數(shù)據(jù)都是有一個(gè)列和一個(gè)值組成，所有數(shù)據(jù)看起來比較簡單。

數(shù)據(jù)有一點(diǎn)需要注意一下，如果我們要實(shí)現(xiàn)數(shù)據(jù)驅(qū)動的自動化測試，我們就需要在此平臺提供處理多行數(shù)據(jù)能力。

有了測試對象和測試數(shù)據(jù)之后，我們需要了解我們的待測試應(yīng)用，我們的平臺需要對待測試應(yīng)用使用之前進(jìn)行一些配置，使用時(shí)還要進(jìn)行一些初始化等工作，使用完我們還會對些進(jìn)行一些清理銷毀等工作。。如此一來，我們的平臺需要考慮如何進(jìn)行測試設(shè)置工作，因?yàn)槲磥砦覀兤脚_面對可能各種不同的測試工具，那么在這里我們也需要在些考慮好一致的接口。所以此部分看來如下所示：

對于測試元素的操作，我們通常會使用類似 click, setValue 等一些點(diǎn)擊，填值的操作，我們同時(shí)還會檢查一些測試元素是否在頁面中存在，也會檢測一個(gè)測試元素是否展示在屏幕上。我們可以將些部分統(tǒng)一歸結(jié)為 action. 所以對象的 action 看起來如下所示：

除了 action 之外，我們的平臺還要提供 checkpoint 功能，此功能是為了能夠讓我們腳本有能力判斷最近測試結(jié)果是通過還是失敗。即有一個(gè) checkpoint 失敗了，整個(gè)測試腳本就是失敗狀態(tài)。Checkpoint 的功能使用起來極其簡單，我們需要為其輸入兩個(gè)參數(shù)，一個(gè)為 expect,一個(gè)為 actual,二者進(jìn)行比較并返回比較結(jié)果。這里需要強(qiáng)調(diào)的一點(diǎn)是，我們設(shè)計(jì) checkpoint 時(shí)，要使其能夠?yàn)槠涠€(gè)參數(shù)可以自適應(yīng)到各種數(shù)據(jù)類型，因?yàn)槲覀儗?shí)際應(yīng)用時(shí)，有時(shí)會使用兩個(gè)布爾值進(jìn)行判斷，有時(shí)可能會使用兩個(gè)字符串進(jìn)行判斷，也可能我們可能直接將兩個(gè)對象傳過來進(jìn)行比較。所以這里我們要讓其能夠自適應(yīng)。

講到這里，我們的平臺還需要至少要有的一個(gè)功能是 report, 我們的 report 要能夠展示測試腳本最終是通過了還是失敗了。同時(shí)能夠記錄每個(gè)步驟的狀態(tài)，能夠截屏。當(dāng)然，如果 report 能夠提供更多的 metric 數(shù)據(jù)就更好了。方便未來計(jì)算 ROI.

講到這里我們都是講的都是對外提供的統(tǒng)一的 API，從使用都角度，這些已經(jīng)基本夠用了。但是對于工具來講，我們要實(shí)現(xiàn)工具無關(guān)化，我們要講起來可能會簡單一些，但是實(shí)際做的時(shí)候還是比較麻煩的。因?yàn)槲覀冃枰槍ξ覀兤脚_支持的每一套測試工具編寫接口，使其在外邊看起來是一樣的。所以平臺這邊說起來是簡單的，但實(shí)現(xiàn)工作量還是比較大的，因?yàn)槊刻坠ぞ叨加衅鋸?fù)雜性，再次封裝后并提供統(tǒng)一的簡單易用接口并非總是那么容易。所以編寫接口的人，必須 是對其封裝的工具是極其熟悉的，并且有豐富的實(shí)際應(yīng)用經(jīng)驗(yàn)，因?yàn)檫@種你們才能為使用者寫出他們真正所需的接口。

3. 總結(jié)

在上面我大致講解了要實(shí)現(xiàn)一個(gè)工具無關(guān)的自動化測試平臺所應(yīng)該具有最少元素集合。在實(shí)際應(yīng)用中，我們所做的工作遠(yuǎn)遠(yuǎn)大于這個(gè)集合。但是有了這個(gè)平臺之后，我們自動化腳本的重用率有了很大的提升。對于團(tuán)隊(duì)中的自動化實(shí)現(xiàn)者來說，它們不需要再痛苦了學(xué)習(xí)和掌握每一種新的工具，或是因?yàn)楣ぞ叩淖兓貙懽詣踊瘻y試腳本了。

最后：在我的V ：atstudy-js，可以免費(fèi)領(lǐng)取一份10G軟件測試工程師面試寶典文檔資料。以及相對應(yīng)的視頻學(xué)習(xí)教程免費(fèi)分享！其中包括了有基礎(chǔ)知識、Linux必備、Shell、互聯(lián)網(wǎng)程序原理、Mysql數(shù)據(jù)庫、抓包工具專題、接口測試工具、測試進(jìn)階-Python編程、Web自動化測試、APP自動化測試、接口自動化測試、測試高級持續(xù)集成、測試架構(gòu)開發(fā)測試框架、性能測試、安全測試等。