客戶端GUI測試技術(shù)和自動化測試架構(gòu)設(shè)計簡談

客戶端GUI測試技術(shù)和自動化測試架構(gòu)設(shè)計簡談客戶端自動化特點客戶端的自動化，通常做過的人都不是很愿意深入討論。因為除了功能和邏輯之外，不得不面對各種界面變化，各種和環(huán)境交互，各種兼容問題以及想不到灰色地帶，就算這樣，也找不到太多有效的bug。然而即便如此，客戶端的自動化必須去做，尤其是GUI的。它的自動化特點是：復(fù)雜成本高不容易發(fā)現(xiàn)問題技術(shù)要求高架構(gòu)很難通用下面，從一些基本的東西開始一點點的討論客戶端GUI測試的一些問題和處理辦法，以及自動化架構(gòu)設(shè)計的一些思路。事實上就像上面說的，GUI的測試并不是為了發(fā)現(xiàn)bug，而是回歸的一種方式，作為保證而已——它過了不能說明質(zhì)量多么好，但是不過，質(zhì)量肯定不達標(biāo)。即使在微軟內(nèi)部，客戶端的GUI一樣不是個受歡迎的家伙，通常用來做BVT的測試（或一些重要性回歸，冒煙等）。客戶端自動化簡述這里并不花過多的筆墨介紹什么是客戶端，或者如何分類的種種——這些東西教材和網(wǎng)上的東西一坨一坨很多很多，這里可能“漫談”的，是實際工作中，客戶端和GUI自動化中可能遇到的一些底層技術(shù)，基本上原理，架構(gòu)設(shè)計方法以及一些項目存在困惑，這些方面的一些處理的方法。最早的自動化我個人認為所謂的計算機行業(yè)的自動化，是一直跟著這個行業(yè)的發(fā)展在走，比如下面的這些：老式計算機——CPU計算：最早自動解決手工分配穿孔的卡片問題內(nèi)存分配任務(wù)調(diào)度：操作系統(tǒng)的核心就是內(nèi)存和任務(wù)的自動管理系統(tǒng)配置Loader：操作系統(tǒng)啟動的引導(dǎo)自啟動程序注冊表：windows系統(tǒng)中自啟動程序的配置什么是自動化測試我個人認為自動化測試，就是用技術(shù)和自動化去服務(wù)測試，保證質(zhì)量，提高產(chǎn)品生產(chǎn)率（不是測試生產(chǎn)力）。無論如何這個行業(yè)需求是關(guān)鍵，脫離需求和具體環(huán)境，一切都是玩笑。傳統(tǒng)客戶端客戶端的特點是基于操作系統(tǒng)之上，它的GUI一般寄生于操作系統(tǒng)的接口。傳統(tǒng)客戶端一般采用系統(tǒng)提供的默認GUI來完成主要邏輯功能。特點是技術(shù)相對簡單，系統(tǒng)兼容性好，但是相對沒有那么炫。對于自動化來說，盡管完成起來“冗余”，但是不存在技術(shù)的難點。也就是通道都已經(jīng)鋪平了，大部分流行的GUI工具都是服務(wù)于這樣的客戶端?；ヂ?lián)網(wǎng)常用客戶端互聯(lián)網(wǎng)常用的客戶端，由于為了提供用戶體驗度，大都采用directUI，無論哪種自繪方法，都不是系統(tǒng)直接提供的。另外，由于互聯(lián)網(wǎng)客戶端的功能很雜，對注冊表的各種注入，操作系統(tǒng)的各種更改等，都會導(dǎo)致一些兼容性和安全性問題出現(xiàn)。這是互聯(lián)網(wǎng)客戶端的特點。特殊客戶端（瀏覽器）瀏覽器作為特殊的客戶端出現(xiàn)是因為它是b/s和c/s的一個界限，它本身是一個客戶端，但是卻是web的依賴著，PC上Web的主要入口。對于其他客戶端，它的特點如下：寄生jsCookies等安全各種插件W3c標(biāo)準(zhǔn)其他不同瀏覽器頁面GUI識別不同客戶端自動化特點/htm/test/newweb.htm一開始已經(jīng)提到過客戶端GUI自動化測試的特點，由于這些特點，導(dǎo)致很多沒有預(yù)算和積累的公司，會放棄客戶端GUI的自動化測試。客戶端自動化通用模型一般來說，客戶端GUI的自動化測試，大體可以分為5個部分，底層GUI技術(shù)，用例組織和開發(fā)，調(diào)度和執(zhí)行，日志以及用戶操作接口。事實上，除了底層GUI實現(xiàn)是客戶端GUI的專屬，其他的部分都屬于一般的自動化測試架構(gòu)部分，不過對客戶端測試，這些部分可以適當(dāng)調(diào)整。所以這里的重點，是GUI測試的底層。底層實現(xiàn)/limi/index.htm底層實現(xiàn)中包括GUI控件識別操作，信息hook，進程檢測，文件管理等各種底層，其中GUI控件識別是難點，其他的都可以比較輕松的完成，任何工具和編程語言都有相關(guān)部分。關(guān)于控件識別部分，包含以下內(nèi)容：基本原理控件識別是GUI的測試最核心部分，它是客戶端GUI可測與否的關(guān)鍵——底層如果走不通，其他的都是噱頭。IPC基本上操作系統(tǒng)標(biāo)準(zhǔn)控件默認使用的都是IPC的方式，實際上這個也是大多數(shù)GUI的底層技術(shù)，即進程間通信。被測程序和測試程序之間采取這種方式，達到GUI的識別和操作。內(nèi)存共享內(nèi)存共享是IPC的一種方法，這里提到只是說出了操作系統(tǒng)提供的IPC方法，一些項目和產(chǎn)品也可以自己采用內(nèi)存共享的方法進行GUI的數(shù)據(jù)共享，比如測試輸入法的時候，共享的數(shù)據(jù)可以使用windows接口hook到，但是中文輸入的分音符”’”，是私有數(shù)據(jù)，不可能搞到。通常的做法就是在測試程序中給一個帶有私有數(shù)據(jù)定義和傳出的.h文件。通信這里的通信不只是IPC中的管道通信，而是真正的通信，它的特點是安全性高，但是效率低一些。某些情況下，底層處理好，易用性很高。比如web測試中流行的webdriver，其中chrome瀏覽器對應(yīng)的是chromedriver.exe，這個驅(qū)動就是采用代理和通信的方式完成的。Chrome內(nèi)置一個服務(wù)，chormedriver.exe會開啟一個socket和chrome連接驅(qū)動瀏覽器執(zhí)行，selenium使用http和chromedriver通信，達到和其他driver使用封裝的一致。Chromedriver后門后門的方法，其實上面提到的輸入法私有數(shù)據(jù)就算一種，開發(fā)提供.h文件到測試系統(tǒng)中，只給測試程序開后面。當(dāng)然還有其他的方法，比如編譯出測試版本，進行測試，發(fā)布版本關(guān)掉這些支持；還可以開發(fā)直接提供一些hook工具，開啟的時候提供相關(guān)支持等。自繪控件自繪控件，是GUI測試的最核心問題。這個問題是這樣的——即使開發(fā)人員幫著寫自繪控件的支持，也不會每個控件都寫，每個方法都寫，如果這樣的話，用一些流行的工具，還是會錯誤百出。IAcessible實現(xiàn)最根本的自繪控件實現(xiàn)，可以參考Chrome的源代碼，windows的chrome，在UI上，都實現(xiàn)了這個東東?？偟膩碚f，需要三個步驟：繼承IAccessible相關(guān)類，然后通過LresultFromObject把IAccessible接口返回給測試程序注冊系統(tǒng)VM_GETOBJECT事件，使對外proxy可以獲取實例的變量分別實現(xiàn)IAccessible中的各個接口Chrome中原生的界面庫采用這種方式實現(xiàn)，這樣的事例在chrome中看到很多，比如：初始化：注冊：接口實現(xiàn)：hook實現(xiàn)hook的方法前面提到過一些，有些情況并不適合做控件的這些接口支持，還是用前面的輸入法為例，及時是操作系統(tǒng)自帶輸入法，在微軟內(nèi)部也沒有實現(xiàn)——最早的微軟輸入法是有IAccessbie的支持，后來的就沒有了。微軟內(nèi)部也是采用hook的方法去進行測試的。一些互聯(lián)網(wǎng)公司的輸入法，同樣也是hook去解決。坐標(biāo)計算坐標(biāo)去判斷是一種無奈之舉，但是有時候確實有用。之前我做過的一個特殊需求，就是完全的模擬用戶亂點瀏覽器頁面的鏈接，不能用任何接口和通信支持。最終打開頁面的時候，用鼠標(biāo)在整個頁面掃一下，記錄下鼠標(biāo)指針變化的位置。Win32handleWin32handle是基于句柄和消息的windowssdk中的一個工具，是windows系統(tǒng)中，GUI最基礎(chǔ)的支持。通常能獲取窗口句柄信息，類名消息等，使用相關(guān)windowsapi操作。當(dāng)然根本技術(shù)還是IPC，被測和測試之間通信完成。如下：獲取采取windowsapi的方式這種技術(shù)能處理起來比較簡單，也是很多流行工具的根本原理。但是使用的范圍極其有限。MsaaMsaa是在windowsapi的基礎(chǔ)上，專門應(yīng)對IAccessible接口而設(shè)計的，msdn上有各種相關(guān)的資料。它還是基于IPC技術(shù)的，原理如下：Msaa的核心和ole，com這些是一樣的，因為msaa的實現(xiàn)依賴于oleacc。事實上這些技術(shù)的核心，就是邊界值檢測和引用計數(shù)，但是由于不是這里的重點，所以這里不詳細討論?？梢詤⒖几鞣N教程，比如wiki。Msaa可以獲取更多hwnd的隱藏信息和一些自定義控件的信息，如下圖所示：Msaa的信息獲取，可以通過oleacc實現(xiàn)。比如在一下的python代碼（更多請參考python的msaa封裝，在之前的相關(guān)博客）：最終結(jié)果如下：Msaa的方式能夠滿足大多數(shù)需要，但是還有其局限性。UIAUIA是在.netframework之上，所以針對msaa，提供了更多有效的功能。然后由于結(jié)構(gòu)的復(fù)雜，需要更強的編程能力。UIA的原理如下：類似的，UIA可以獲取到如下信息：由于UIA的部分需要.netframework的支持，暫時沒有示例。但是畢竟是在framework之上的東西，網(wǎng)上相關(guān)的教程也是一把一把的。UIA的特點是提供了更為豐富的實現(xiàn)和功能，IPC結(jié)構(gòu)更加完善，使用便利，支持vista以上系統(tǒng)和WPF的測試。。缺點是太過于繁瑣，開發(fā)復(fù)雜。微軟內(nèi)部的GUI測試架構(gòu)Mita，也是完全重新封裝UIA的架構(gòu)，不進行二次封裝，很難快速的使用。比如msaa整個的封裝可能幾K而已，但是UIA相比之下，就是巨無霸級別了。當(dāng)然各種基于UIA的工具，性能可想而知——很多情況下我們需要測試XP和一些老式的低配機，這種情況下它并不適合?；趫D像技術(shù)嚴格來講，我本人并不推薦這種技術(shù)，一方面不穩(wěn)定，另一方面性能消耗較大。大的方面說，有一些整體都基于圖像的如ikuli，可以通過圖像去識別驅(qū)動一些程序，并且不依賴被測程序開發(fā)。但是我個人認為這東西用在自動化測試上，并不實用。小的方面說，一些用例的檢查點，和圖像有關(guān)，這時候需要做一些基于圖像的處理，比如對比圖片MD5呀，分析圖像色度之類的功能。所以基于圖像的技術(shù)，可以用在一些邊角的實現(xiàn)上，不太適合作為底層的主角——當(dāng)然這是我個人的體會。WebGUIWeb的GUI之所以放到最后，是因為它的特殊性——常用的瀏覽器中，原理是不同的。在IE上，由于有com的支持，頁面的GUI和控件是一樣的，selenium中IE的driver部分也是這樣的原理，甚至一些基于IE內(nèi)核的瀏覽器，只要內(nèi)嵌IE_frame結(jié)構(gòu)，都是一樣的，如下：對于Chrome的頁面GUI，之前已經(jīng)提到過chromedriver.exe了，它是采取了通信的手段實現(xiàn)，而不是com或Ole這種基于IPC的方式。輔助工具輔助工具，指一些輔助開發(fā)使用的GUI查看工具，這些工具比較多，包括上面使用過的spy++，inspect，當(dāng)然還包括各種UIASpy等等。當(dāng)然也可以自己開發(fā)，或者使用網(wǎng)上其他的工具，這部分工具還是很多的。Web頁面的自動化工具，如果單獨的IE情況下，可以像上面那樣按照客戶端GUI的方式完成，但是如果使用selenium這樣的架構(gòu)，最好還是像chrome一樣使用自帶的開發(fā)者工具完成web結(jié)構(gòu)定位等。好在IE也有相應(yīng)的開發(fā)者工具，而且相比真正客戶端的層級關(guān)系，web的更加規(guī)范，也穩(wěn)定。簡單示例msaa接口：如上示例UIA接口：如上示例QTP等：自行查閱用例組織和開發(fā)UnittestUnittest是兩個聰明的家伙創(chuàng)作的（名字忘了），最早在smalltalk的單元測試中，后來到JUnit和pyunit。用Pyunit舉例，大概包含如下部分：TestResult：用例結(jié)果實例，架構(gòu)自動調(diào)用TestCase：測試用例基類TestSuite：測試套件實例，用來管理測試用例TestLoader：加載測試用例，返回一個測試套件TextTestRunner：執(zhí)行實例TestProgram：執(zhí)行核心對于這個優(yōu)秀的小測試架構(gòu)，當(dāng)然不能浪費了。有些測試用例的執(zhí)行和管理，直接使用這個架構(gòu)。另外，很多大型的測試驅(qū)動架構(gòu)，和這個小架構(gòu)核心非常類似，比如微軟的MTM，用例管理的套件，思路上很像。直接使用這個框架，大部分是三種情況：第一種在uniitest框架上編寫用例，和一般的單元測試相似；第二種動態(tài)將測試用例在執(zhí)行時轉(zhuǎn)化為uniitest結(jié)構(gòu)，并且執(zhí)行；第三種借用測試套件管理測試用例；基于unittest的用例組織和管理直接，靈活，但是對于場景復(fù)雜并且測試人員編程功底不夠的情況，是不適合的。更多內(nèi)容可以參考：/pyunit_cn.html用例格式unittest中提供的，只是一種格式，事實上用例的格式千變?nèi)f化，沒有所謂的最好，只有最適合。文本文本類的用例比較適合編寫，而且不存在太多復(fù)雜的東西，定義好用例結(jié)構(gòu)，可以直接解析。Xml擴充容易，復(fù)用度高——編輯容易出錯比如網(wǎng)上的一個示例：Txt編寫容易——結(jié)構(gòu)不嚴謹，難擴展比如IBM的robot中的測試用例結(jié)構(gòu)：表格excel等excel格式的自動化用例一般都用在數(shù)據(jù)驅(qū)動的架構(gòu)中，一般底層封裝層次比較多，只留下外部數(shù)據(jù)接口，這種測試用例適合簡單但是數(shù)量多的測試情況。如下；腳本腳本的測試用例一般測試開發(fā)人員比較提倡，無縫調(diào)用，適用性強，并且重用度高。但是這種用例需要一定編程功底。Lua類似的用例如下：Java&C#Java&C#的測試用例類似于下面的情況：PythonPython的測試用例使用比較多，chrome和互聯(lián)網(wǎng)的發(fā)展，讓Python的地位越來越高，典型的用例如下：嵌套用例調(diào)用形式一些場景類的用例，需要很多重用的邏輯，也就意味著需要有很多公用的用例或者模塊，一些最終用例也很可能某一天，會成為公共用例。這樣的情況下，需要實現(xiàn)嵌套的結(jié)構(gòu)。一般來說，這樣的情況分為兩種方法。一種是腳本或者編程語言寫的測試用例，這種用例可以打包為模塊或者測試套件實現(xiàn)公用；另一種是文本類用例，這種情況下必須采取文本嵌套的模式進行調(diào)用，比如xml的：將每一個step都統(tǒng)一成一個文件，這樣就實現(xiàn)了用例的遞歸調(diào)用。管理方式無論包方式還是文件方式，都是都是以模板和功能為核心進行文件夾的管理。一般會統(tǒng)一到svn或者其他源代碼管理工具，因為測試用例也需要維護，某種程度上，這就是代碼。用例驅(qū)動用例驅(qū)動方面，我個人并不提議各種驅(qū)動什么的，這些是個名詞而已，而且大都是針對使用工具的人來介紹而已。對于架構(gòu)設(shè)計和開發(fā)人員來說，更關(guān)注的是名字后面代表的各種含義和解決方案。我個人對這些驅(qū)動的解釋是，他們沒有本質(zhì)性的差別，只是在封裝、重用和特殊需求下的粒度不同，有些極端，有些折中。關(guān)鍵字驅(qū)動這種方式是大多數(shù)流行的測試工具所提倡的，因為這些測試工具并不是為工具開發(fā)者使用，而是商業(yè)的，所以這種方式最適合，也有推廣性。這種解決方案適用在業(yè)務(wù)復(fù)雜，重復(fù)度一般的情況下。除了底層的封裝外，外層封裝和測試用例都是和業(yè)務(wù)邏輯對應(yīng)的，管理和封裝方法也取決于業(yè)務(wù)邏輯特點。一般來說將業(yè)務(wù)的最小粒度分層封裝，一直到業(yè)務(wù)頂層。執(zhí)行的時候只需要判斷關(guān)鍵字的結(jié)構(gòu)和分層順序執(zhí)行。方法驅(qū)動這種解決方案完全為由測試開發(fā)人員決定，一般來說，底層封裝完全，提供了共有的接口之后，業(yè)務(wù)很亂或者對業(yè)務(wù)不理解，都會直接保留接口封裝而不是業(yè)務(wù)邏輯，這樣的情況下，以后業(yè)務(wù)梳理完一部分，用方法順序執(zhí)行一部分。當(dāng)然，測試開發(fā)負責(zé)接口開發(fā)，手工測試進行邏輯業(yè)務(wù)用例編寫一般也是這種情況。數(shù)據(jù)驅(qū)動所謂數(shù)據(jù)驅(qū)動，是自動化測試的一個極端情況——這種情況業(yè)務(wù)邏輯相對單一，但是需要反復(fù)測試不同的數(shù)據(jù)。這種情況下，外部接口相對簡單，用例更多的是數(shù)據(jù)的編寫和組織。比如之前提到的輸入法的測試，比如我新開發(fā)一款輸入法，需要測試a開頭到z開頭的100萬個字母串輸入的首個匹配中文，并且和搜狗的輸入法做對比，這就是典型的所謂數(shù)據(jù)驅(qū)動模式。功能邏輯的接口很少，但是需要不斷重復(fù)執(zhí)行，去測試不同的數(shù)據(jù)。場景驅(qū)動場景驅(qū)動，噱頭的成分更大一些。純面向?qū)ο蟮臉I(yè)務(wù)開發(fā)都沒有什么成功的案例，面向業(yè)務(wù)和服務(wù)的開發(fā)模式，更是不實際。個人覺得所謂的場景驅(qū)動，是建立在一定粒度的關(guān)鍵字驅(qū)動封裝之上。一些穩(wěn)定回歸的，邏輯固定的場景抽象出來，作為獨立的部分，所以純面向場景的驅(qū)動不是沒有，而已意義沒有宣傳的那么大，它更多是結(jié)構(gòu)上的，但是實際工作上很少完全場景化。錄制回放錄制回放的方式，比場景驅(qū)動噱頭還要大，尤其在一些控件點擊和web元素執(zhí)行的情況下。錄制回放并不能算作一個驅(qū)動方式，只是一種輔助的手段，好處是一些技術(shù)基礎(chǔ)差的測試人員能夠參與測試用例的開發(fā)中，提高開發(fā)速度。不好的地方，是錄制后的腳本和用例一樣需要修改和調(diào)試才能實際工作，而且在自動化架構(gòu)開發(fā)的過程中，需要配套的使用hook和消息機制，做出相關(guān)的錄制功能。實際工作并不是商業(yè)軟件開發(fā)，需要合理的折中預(yù)算和人力投入，所以做不做是要看收益。但是事實上，錄制回放可以和后續(xù)的日志部分結(jié)合一起——執(zhí)行步驟，日志和錄像都可以通過索引整合到一起，定位到出錯部分，并且重現(xiàn)。這是它的另一個好處。調(diào)度和執(zhí)行前面所有的東西，包括底層和測試用例管理驅(qū)動的部分，能夠保證自動化可測，即這兩方面都完成的話，放到測試機上，就可以正常執(zhí)行和測試了。但是如果用例集很大，執(zhí)行環(huán)境復(fù)雜，人力執(zhí)行顯然不是好辦法。成熟的自動化架構(gòu)，必須考慮到測試機的執(zhí)行和調(diào)度。測試機管理測試機管理中，一般可以分為測試機執(zhí)行接口和代理——這兩個詞并不準(zhǔn)確，我臨時拿來用。命令發(fā)送命令發(fā)送這個詞同樣不準(zhǔn)確，因為在實體機的服務(wù)端和代理端，確實是以命令作為最小單元，但是如果是虛擬機，就不存在命令發(fā)送，而是虛擬機接口。虛擬機調(diào)度虛擬機，需要使用vmware提供的接口，流行語言都已經(jīng)提供，或者可以自行調(diào)用dll完成。接口在WM安裝路徑的32bit\vix.dll中。官網(wǎng)有相關(guān)信息。實體機實體機的命令發(fā)送，是我說的真正的命令發(fā)送，無論服務(wù)和代理之間采用任何形式通信，執(zhí)行一條命令是最基本的顆粒。最小顆粒之上，是定義各種需要的命令。代理通信代理是調(diào)度驅(qū)動的核心，一般情況下，實體機想要驅(qū)動，必須保持雙向聯(lián)通。一起單項的命令模式也能驅(qū)動，但是這是不完善的，沒有回執(zhí)和狀態(tài)查詢，就不能叫做調(diào)度和代理。虛擬測試機一樣需要代理通信——一個服務(wù)器資源有限，即便虛擬30多臺測試機，有時候同樣不夠用。這時候可能有很多臺服務(wù)器提供虛擬機，那么每臺服務(wù)上必須有自己的代理，服務(wù)和服務(wù)器通信，并且管理它的所有虛擬機。Socket通常，代理會選用socket進行通信，服務(wù)端管理多個代理，這是通信的最常用技術(shù)。但是一些時候也會選擇直接使用http通信，每個client端管理一個web服務(wù)，這種情況比較少。反ping對于有些特殊情況，比如需要重啟或者重裝系統(tǒng)的情況，需要代理的client端失去聯(lián)系后反Ping服務(wù)端，重新恢復(fù)session。ICE一個比較久遠的面相對象的中間件平臺，可以借助ICE定義自己的接口，最終完成代理通信和調(diào)用。GoogleProtoBuf簡單的說，googleprotoBuf是谷歌的一種數(shù)據(jù)交換格式，更確切的說，是一種可擴展的序列化結(jié)構(gòu)數(shù)據(jù)格式，可以用來存儲，RPC或者等數(shù)據(jù)通信。對于通信調(diào)用，可以借助這種格式進行傳輸和臨時存儲。MinaMina在這里，是一個重量級的東西。因為上面ICE和googleprotobug的內(nèi)容它都包含。它的根本是一個通信應(yīng)用框架，提供了協(xié)議的封裝，流和管道機制，同步和異步等。和ICE一樣也提供了server和client的封裝。在考慮寫代理的時候，可以優(yōu)先選擇。缺點是只能用java來寫。WTT&MTMWTT是微軟內(nèi)部一直使用的一個測試機任務(wù)派發(fā)調(diào)度系統(tǒng)，它是基于命令的，同時采取了反ping技術(shù)，所以一些斷網(wǎng)和刪除驅(qū)動的測試，一樣可以勝任。這是我覺得任務(wù)派發(fā)的調(diào)度的一個比較好的系統(tǒng)，并且支持定時任務(wù)和派發(fā)模板的創(chuàng)建，通過配置幾乎可以完成任何測試調(diào)度的任務(wù)。只可惜是個內(nèi)部的東東，而且太大了，一般的測試團隊很難開發(fā)和維護。相對來說，微軟的另一個主推的測試生態(tài)平臺MTM和AutoLib，并不是很好，很難和流行的QC等系統(tǒng)比較。主要愿意是它勉強和VS的搞到了一起，而且很多設(shè)計在根本上沒有考慮到擴展和模板的概念。另外，作為一個平臺，它寄生在VS的生態(tài)環(huán)境，使得性能無法提高。其他調(diào)度分配調(diào)度分配在執(zhí)行調(diào)度中，是一個可大可小的東西。一般在自動化架構(gòu)開發(fā)初期不怎么去考慮。但是如果自動化架構(gòu)穩(wěn)定之后，可能會有一些分配上的需求，包括平均，動態(tài)以及一些特殊的需求。通常分配策略使用插合的方式，可以一種策略對應(yīng)一個對象，也可以所有策略對應(yīng)工廠類，或者使用純算法的方式完成。平均平均模式一般將M個用例分到N臺機器上執(zhí)行，即使能夠監(jiān)控測試機狀態(tài)，也沒辦法對已經(jīng)分法出去的任務(wù)進行異常處理動態(tài)動態(tài)分配是一種相對較優(yōu)的辦法，它通常會輪詢測試機，有空閑則分配測試任務(wù)。它不會因為某個任務(wù)異?；蛘邷y試機異常而卡住。但是由于輪詢都需要計算，所以分發(fā)計算上效率差一些。隊列和池?zé)o論任何任務(wù)隊列也好，調(diào)度池也好，各種說法等等，在分配策略中，事實上只有任務(wù)集合和測試機集合。再沒有其他約束條件的情況下，即所有任務(wù)級別一樣，所以測試機級別一樣，它的調(diào)度會有一個折中的動態(tài)方法，在動態(tài)分配的基礎(chǔ)上，定義每次分發(fā)的最小單元。在動態(tài)的同時保證了計算效率。特殊需求這里的特殊需求，指的特殊的任務(wù)級別和特定測試機環(huán)境。這里一些有效的方法就是聚成，重排和過濾。無論是任務(wù)和測試機，都可以分成各種集合和子集合，在執(zhí)行的時候，可以才去節(jié)點為參數(shù)進行任務(wù)的下發(fā)，滿足特殊需求；如果用例和測試機的命令有約束，也可以采取過濾的方法，制定好過濾規(guī)則。另外在任務(wù)隊列里，會涉及到一些局部排序方法，這些可能要具體情況具體考慮。日志日志是一個測試架構(gòu)必須的部分，可以幾乎任何部分都要涉及到日志。當(dāng)然除了通常的一般日志，還有一些特定的日志，他們可以用來定位測試用例失敗點等等。調(diào)試日志調(diào)試日志通常放在執(zhí)行目錄下，無論調(diào)度服務(wù)還是測試用例在測試機上的執(zhí)行。一般來說，調(diào)度服務(wù)的日志只需要記錄具體關(guān)注的問題即可，但是在測試機中執(zhí)行的測試用例，其日志需要和用例執(zhí)行步驟一一對應(yīng)。這部分建議是，如果用例順序執(zhí)行，則順序記錄日志，如果遞歸執(zhí)行，則遞歸格式記錄日志。日志的內(nèi)容可以包括和用例一一對應(yīng)的信息，以及執(zhí)行的具體山下文環(huán)境，和運行時狀態(tài)。本地&數(shù)據(jù)庫通常，測試日志分為兩部分，一部分測試結(jié)果在運行時存入數(shù)據(jù)庫，這也是最終查看測試執(zhí)行結(jié)果的數(shù)據(jù)源。當(dāng)時一些調(diào)試信息日志，沒必要放在數(shù)據(jù)庫，而且也不便于調(diào)試，一般來說這部分日志在用例執(zhí)行結(jié)束后，會按照具體執(zhí)行ID放入到固定的共享文件夾。測試人員調(diào)研和調(diào)試測試用例的時候，這些都是重要的東西。另外，放到共享文件夾的調(diào)試日志，最好也包含用例執(zhí)行步驟和結(jié)果，因為一些斷網(wǎng)的情況下，無法保證數(shù)據(jù)庫的連通，但是卻希望得到執(zhí)行的正常結(jié)果。結(jié)果執(zhí)行結(jié)果執(zhí)行結(jié)果一般是以步驟為最小粒度，存放在數(shù)據(jù)庫。當(dāng)然本地日志中也最好有一份，如上面所提到的。失敗截圖失敗截圖是日志的重要組成部分，對于將截圖放在日志的共享文件夾目錄下，是沒有太多異議的，一般來說，這部分的異議是是否應(yīng)該將失敗截圖保存到數(shù)據(jù)庫中。個人建議這個看情況，但是一般保存到數(shù)據(jù)庫中也沒有什么不好，如果不需要在數(shù)據(jù)庫讀取的話，是個備份，如果讀取的話，可以整合到一些前臺頁面中。這里唯一需要注意的是，如果將失敗截圖存放到數(shù)據(jù)庫，那么，那么千萬別使用select*fromXXX的這種方式進行讀取，不然你的數(shù)據(jù)庫服務(wù)器內(nèi)存再大也承受不住。錄像錄像沒有太多爭議的放在了文件共享系統(tǒng)中進行保存，畢竟它太大了，也沒有太多頁面顯示的必要，反而不如在文件系統(tǒng)查看方便。錄像這部分需要注意的是，很多時候錄像可以和失敗日志集成到一起，通過失敗日志進行索引的定位，然后點擊錄像查看。一些流行的測試框架也提供了這類的日志和錄像的查看工具。存儲存儲主要是用來查看的，之前也提到了主要分為數(shù)據(jù)庫存儲和文件系統(tǒng)存儲，他們適合存不同