功能測試的目的是為了模擬使用者操作，從而驗證系統能按照預想的方式執行，因此自動化測試的指令碼無可避免地需要訪問軟體的使用者介面。相信很多放棄使用自動化功能測試的團隊對於自動化功能測試的態度和我剛剛接觸自動化測試時一樣，ui的易變性和測試指令碼與ui的緊密耦合，加上維護測試指令碼的團隊（測試）和ui開發的團隊（開發）往往不是同乙個團隊（或同乙個人），導致了維護測試指令碼的成本非常高。
但自動化功能測試的確能提高測試質量，並且減少人的重複勞動，這點收益足以能讓我們想辦法去解決上述的問題。和單元測試一樣，從系統設計的時候就考慮到適應自動化測試，是成本最低的解決自動化測試問題的方法。如果對乙個本來就對自動化測試不友好的系統重構，改變就可能涉及到系統的基礎架構了，這個時候投入的人力物力就會幾何級數的上公升。
既然ui的頻繁變更是影響自動化測試最重要的原因，那麼我們是否可以跳過ui來進行自動化測試呢？我是乙個很直觀的想法，而且在某些情況下是可以實現的。mvc模式告訴我們，view層是不應該包含業務處理邏輯的，因此我們可以使用系統為ui層暴露的介面（公用api）對系統進行功能測試，從而避開ui層頻繁變更的問題。
這種設計要求系統的ui層足夠的簡單，不能包含一丁點的業務邏輯，公用api的功能也需要足夠的完備，能完成系統所有的業務邏輯處理。另外值得注意的一點，測試使用的api也必須是ui層呼叫的api，否則就沒有辦法很好地模擬真實的系統行為。我們已經對系統真實情況做了妥協，就不能無底線地一直妥協下去。
web應用的情況可能相對好一點，由於web架構的特性，我們只需要直接組裝http請求傳送到web伺服器，便可以繞過ui進行功能測試。儘管這依然需要ui層足夠的薄，但這已經是大部分web開發者的共識了。
正如上面說的，使用公用api測試是一種妥協的做法，對於那些有著極高使用者體驗要求的系統，就算是ui的顯示邏輯，都可能是非常複雜的。這個時候，就算業務邏輯處理能被證明是沒有bug的，但也不能說明系統的質量就足以達到交付的要求，畢竟使用者是通過ui作業系統，而不是通過公用api與系統互動的。
在軟體設計界有一句很經典的話：「大部分的軟體耦合問題，都可以通過在中間加一層解決」。所謂的客戶端驅動模式，也是通過在中間加一層來解決測試指令碼與系統ui高耦合的問題的，我們姑且把中間的這層成為客戶端驅動層。下圖是使用客戶端驅動模式設計的自動化測試的架構圖：
可以看到，測試指令碼並不直接與系統的ui互動，而是通過客戶端驅動層互動。這樣測試用例便可以從與ui的耦合中解放出來，使用跟業務更接近的方式編寫，如下面的測試用例：
def test_testsearchengineinput(self):
setest = searchengineproxy()
setest.submittesttext('test')
result = setest.getsearchenginetitle()
self.asserttrue('test' in result)
（searchengineproxy）中。順便提乙個，我們也可以使用單元測試框架編寫自動化功能測試，比如著名的xunit系列。
我無法評價上面兩種模式的優劣，對於不同的專案，更應該根據專案的情況加以選擇。相信不少程式設計師一邊看客戶端驅動模式，一邊會皺眉頭。誰都不想多維護乙個模組的**，客戶端驅動模式也是一種對耦合的妥協，如果系統ui相對簡單，通過簡單的手工測試也可以發現ui顯示邏輯中的bug，就可以直接通過公用api進行自動化測試了。
但總有複雜的ui，需要通過自動化測試把ui層也進行測試，這個時候也別為了方便，直接讓測試指令碼與ui進行互動。畢竟測試指令碼不總是由開發人員維護，與ui緊密耦合的測試指令碼可能會讓測試用例經常失敗，嚴重打擊團隊的積極性和自動化測試結果的權威性，讓自動化測試無法有效地執行下去。
論遊戲程式設計師的自我修養（MiloYip）
定短期目標，長遠目標 程式設計師的目的就是把一些工作自動化，如果某猿僅僅只是搬磚的話，那他就不夠完美 盡量用一些技術的手段去做，包括單元測試，自動化的構建，流程，issues tracking，用基本的軟體工程的手段 最難是做技術創新，面對乙個新的問題要用更好的方法去解決這個問題。比如 愛麗絲 ip...
程式設計師的自我修養
一忌 輕易言敗，沒有自信 沒有永不放棄精神的程式設計師，只是乙個有程式設計師名號的假程式設計師。乙個真正的程式設計師，知道在程式設計的過程中，可能會遇到不計其數的困難和問題，可能有極多的挫折和失敗，而成功只有一次。就為解決乙個問題，我們可能連續十幾甚至幾十小時的坐在計算機前不停的工作。乙個問題解決了...
程式設計師的自我修養
一忌 輕易言敗，沒有自信 沒有永不放棄精神的程式設計師，只是乙個有程式設計師名號的假程式設計師。乙個真正的程式設計師，知道在程式設計的過程中，可能會遇到不計其數的困難和問題，可能有極多的挫折和失敗，而成功只有一次。就為解決乙個問題，我們可能連續十幾甚至幾十小時的坐在計算機前不停的工作。乙個問題解決了...