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