基于以上面臨的問題，一種“開后門”的方法引起了我們的注意，“后門”是指RD在程序中專門為了某些目的開設(shè)的訪問通道，通過這些隱秘不為人知的數(shù)據(jù)訪問通道，可以實現(xiàn)特殊的產(chǎn)品功能。對于自動化來說，我們可以通過這種方式將程序的一些界面信息暴露，當然也不局限于UI的信息，我們也可以將任意測試程序需要的信息通過后門的方式暴露給我們自己的測試程序即可以實現(xiàn)自動化相關(guān)的需求。
這個想法在后期的實踐中逐步優(yōu)化，最終形成了一套基于Proxy架構(gòu)的自動化解決方案。當被測程序啟動時，加載Proxy，并將皮膚引擎的指針（全局變量）傳入Proxy中，自動化腳本通過與Proxy通信，實時獲取UI的各種信息該框架包含兩大部分：
1、一部分是以Pywinauto（Pywinauto是一些用于自動化測試Windows標準圖形界面的模塊的集合。它可以允許你很容易的發(fā)送鼠標、鍵盤動作給Windows的對話框和控件）為操作基礎(chǔ)，pyunittest為case組織框架的python腳本部分，這部分包含了關(guān)鍵字的封裝，case的實現(xiàn)。
2、另一部分是植入到被測程序內(nèi)部的Proxy，當被測程序啟動時，加載Proxy，并將皮膚引擎的指針（單例）傳入Proxy中，自動化腳本通過與Proxy通信，實時獲取UI的各種信息，從而達到自動化的操作以及驗證的目的。
整個自動化框架圖如下：
執(zhí)行
穩(wěn)定性測試不同于功能測試的自動化，它屬于一種概率性的測試，需要長期運行過后才能得出最后的測試結(jié)論，即使穩(wěn)定性測試通過，也不能保證系統(tǒng)實際運行的時候不出問題。所以要盡可能的提高測試的可靠性，我們可以通過多次測試，延長測試時間，增大測試壓力來提高測試的可靠性。
當穩(wěn)定性場景存在多組時，為了保證運行的及時性與可靠性，同時也為了滿足測試環(huán)境的豐富性，穩(wěn)定性測試的執(zhí)行需要多臺機器才行。如果條件允許，可以使用不同環(huán)境及配置的物理機進行測試，也可以使用虛擬機，構(gòu)建豐富的環(huán)境中心來滿足穩(wěn)定性測試的需求。
當存在多個運行環(huán)境和多組case時，為了保證測試場景組合的多樣性，各組case要階段性的循環(huán)在每個運行環(huán)境中執(zhí)行，因此需要一個清晰明確的執(zhí)行計劃和記錄：
客戶端穩(wěn)定性測試
穩(wěn)定性測試是在保證功能完整正確的前提下，必不可少的一項測試內(nèi)容，通過對軟件穩(wěn)定性的測試可以觀察在一個運行周期內(nèi)、一定的壓力條件下，軟件的出錯機率、性能劣化趨勢等。進而大大減少軟件上線后的崩潰卡死等現(xiàn)象，為軟件的逐步優(yōu)化提供方向及驗證。
無論是服務(wù)器端還是客戶端，對穩(wěn)定性的測試無非是就是測試系統(tǒng)的長期穩(wěn)定運行能力。在系統(tǒng)運行過程中，對系統(tǒng)施壓，觀察系統(tǒng)的各種性能指標，以及服務(wù)器的指標。不同于服務(wù)器端的穩(wěn)定性測試的是，客戶端軟件是運行在單機環(huán)境下，所以不存在并發(fā)用戶數(shù)的概念，取而代之的是一些多進程長時間的操作，以及各種復雜的并發(fā)場景的組合。一款客戶端軟件，它的穩(wěn)定性測試需求基本包括：
1、長時間運行及各種操作下，軟件的穩(wěn)定性以及各種性能指標的劣化趨勢。
2、多進程或多線程運行時的穩(wěn)定性。
3、不同操作系統(tǒng)，在不同宿主軟件下運行的穩(wěn)定性。
穩(wěn)定性測試實施
整個穩(wěn)定性測試的包括三大部分：
1、場景的設(shè)計及實現(xiàn)
2、穩(wěn)定性測試的執(zhí)行
3、最后結(jié)果的校驗
場景設(shè)計
測試場景一般是指模擬平常的壓力，以及模擬實際中用戶的日常操作，如果包含數(shù)據(jù)庫，那么數(shù)據(jù)庫要存有一定的數(shù)據(jù)。一般來說客戶端產(chǎn)品的穩(wěn)定性測試包括：
自動化腳本
自動化測試是穩(wěn)定性測試的基礎(chǔ)，對于使用標準控件的客戶端軟件來說，可以使用市面上較為通用的自動化及性能測試軟件QTP或LoadRunner，這些軟件對標準控件支持較好，可以很方便快速的搭建起自動化測試的框架，為穩(wěn)定性測試提供基礎(chǔ)。
但由于目前客戶端軟件的界面開發(fā)為了更加快速，同時融入業(yè)界前沿的皮膚技術(shù)，為用戶創(chuàng)建更加高效，專業(yè)的界面，大多數(shù)都采用了DirectUI的技術(shù)，這種方式是直接在父窗口上繪圖。即子窗口不以窗口句柄的形式創(chuàng)建，只是邏輯上的窗口，繪制在父窗口之上。對于這種非標準控件如果使用QTP等自動化測試工具就會顯得力不從心了。
結(jié)果
從穩(wěn)定性的測試目的中可以得出在對穩(wěn)定性結(jié)果的判斷需要從以下幾個方面進行：
1、判斷是否崩潰
a）對于能夠被崩潰上報進程捕獲的的崩潰比較好辦，可以通過判斷是否有崩潰上報進程來進行判斷。
b）在測試機上安裝任意的debugger工具（例如windbg）就可以檢測各種類型的崩潰情況（只要有崩潰就會觸發(fā)debugger的調(diào)用，檢測是否出現(xiàn)debugger進程就ok）
c）對于那種運行在宿主程序中的插件，單獨插件的崩潰有時不會導致宿主程序的整個崩潰，所以對插件崩潰的檢測需要記錄運行正常時的pid或tid，發(fā)現(xiàn)其消失就判斷為崩潰，因為插件運行在宿主程序中不是一個進程就是一個線程。
2、判斷是否假死
a）對于單進程程序，只要主窗口發(fā)消息即可，找對主窗口是關(guān)鍵，通過枚舉某個進程的全部窗口句柄，找parent為null，visible 為true，不是托盤程序的那個窗口句柄。
b）強制主窗口重繪（這個重繪方式各產(chǎn)品可能不一樣，有的發(fā)消息就可以，有的需要移動位置），然后截圖，白色的就是假死（判斷白色的已有現(xiàn)成的代碼）
3、判斷是否存在性能劣化的趨勢
a）這點也屬于性能測試中資源占用情況的測試，可以再穩(wěn)定性測試的同時使用性能檢測工具進行檢測。
待改進點
1、自動化判斷，定位異常信息。目前一些偶現(xiàn)的卡死和崩潰無法捕獲到堆棧信息，對定位意義的不大，需要在崩潰或卡死時保留住現(xiàn)場，不能連續(xù)的執(zhí)行后續(xù)的case。
2、操作步驟及數(shù)據(jù)選取的隨機性?？梢钥紤]引入Fuzzy以及解析用戶日志的方式增加操作步驟及測試數(shù)據(jù)選取的隨機性。
3、測試case在各個執(zhí)行環(huán)境中循環(huán)切換的自動化。目前這種循環(huán)還是靠手工保證，后續(xù)可以考慮從在每臺測試機器上動態(tài)調(diào)用測試腳本，代替手工的切換及運行。
4、測試腳本的穩(wěn)定性：穩(wěn)定性的測試不僅是對被測程序穩(wěn)定性的驗證，同時也考驗我們自動化測試腳本運行的是否穩(wěn)定，而且在長時間的運行過程中可能會出現(xiàn)各種阻礙腳本運行的但卻是正常的情況，所以需要增加各種判斷和輪詢的機制，另外為了保證場景的多樣性都需要我們的腳本更加通用和周密，一不小心，被測程序還沒掛呢，我們自己先停了……對于腳本的穩(wěn)定性一直在測試的過程中不斷完善，積累經(jīng)驗。