原文鏈接：http://www.bossqiang.com/article/18
1. 為什么需要設計測試框架？
首先我們需要明確一點，自動化測試工具或程序的開發與一個軟件產品的開發在本質上是沒有區別的，特別是從技術層面上來說，更是如出一轍。我們開發一套軟件產品，也是為了能夠幫助客戶解決某些層面的問題，提升效率或降低成本，正因為有客戶需要才有開發這套產品的價值。同樣的道理，我們開發一套自動化測試工具，當然是為了更好地給測試團隊使用進而提高測試團隊的執行效率，提升軟件產品的質量，所以這套工具的客戶即為測試團隊成員，因為他們有需要，因為他們不想把時間花費在一些重復的勞動上，所以這也是自動化測試工具的價值所在。
既然都是在開發軟件產品，軟件工具，那么毫無疑問，我們必須要考慮開發效率及維護成本。這個時候，一套高效的框架便很有必要。所謂框架，就是介於原生代碼和最終產品之間的一個半成品。
2. 如何評價一個框架的好壞？
我們主要可以從以下幾個方面來評估一個框架的質量：
(1) 獨立於測試工具：無論使用什么樣的測試工具或測試技術，並不影響框架本身。
(2) 測試步驟可重用：一個項目中難免會有很多操作過程是類似的，應該設計為可重用。
(3) 測試資產可重用：測試資產包括測試腳本，測試數據，測試環境等。
(4) 測試數據易定制：比如通過外部數據源定制不一樣的測試數據，完善測試用例。
(5) 異常處理機制：測試執行過程中難免會遇到各種未知異常，應該捕獲並截圖保存。
(6) 測試腳本易開發：測試框架一旦定義完成，應該使測試腳本的開發變得更加容易。
(7) 測試腳本易維護：對可能的操作均進行封裝，並且對相關操作進行分層處理。
(8) 無人干預執行：持續集成的關鍵所在，從版本構建到測試到報告甚至到發布，均自動完成。
(9) 代碼可移植性高：測試腳本當中沒有Hard-Code，同時針對不同的項目，也能順便移植。
(10) 適宜於團隊開發：自動化測試框架也需要考慮團隊開發的問題，要定義好自己的接口規范。
3. 目前流行的框架設計思路
每一個人在構思一個框架時，都會受限於自己的思維方式，實踐經驗，成功案例，甚至於所測試的產品領域和業務流程等。所以我們很難說什么框架一定是最好的，什么框架一定不好。甚至也不能簡單的評判一些通用性強的框架就一定是好的，通用性差的框架就一定不好，這都會出現以偏概全的誤解。筆者在此為大家整理了目前比較流行的一些框架設計思想，供讀者朋友參考：
(1) 數據驅動測試：即英文單詞Data-Driven Testing，簡稱DDT。
(2) 關鍵字驅動測試：即英文單詞Keyword-Driven Testing，簡稱KDT。
(3) 業務流程測試：即英文單詞Business Process Tesing，簡稱BPT。
(4) 頁面對象模式：即英文單詞Page Object Model，簡稱POM。
(5) 基於組件的測試：即英文單詞Component-Based Testing，簡稱CBT。
4. 關於框架設計中的分層思想
事實上，無論是自動化測試框架的設計還是軟件產品的研發框架的設計，在很多思想上都是完全一致的，其中很重要的一點就是“分層思想”。
那么，什么是分層思想呢，其核心就是不同的操作，應該放在不同的類和不同的方法中，層與層之前互相依賴，互相調用，每一層都有自己獨特的分工。就像我們之前學習TCP/IP模型一樣，應用層，傳輸層，網絡層和物理層，每一層都需要共同結合才能真正完成一個任務，但是每一層都有自己獨特的分工，不能亂來，一旦亂了，分層思想也就失去了其價值。
分層思想的設計指導原則如下：
(1) 上層總是依賴下層，不要跨層訪問
(2) 一切從系統需要提供的功能進行分析
(3) 每個層的接口有明確的職責范圍
(4) 只要接口規范無變化，接口的實現互不影響
5. 關於CBT框架的設計思想
強哥原創的CBT框架有兩種解釋：Component-Based Testing和Component & Business Testing，兩種解釋中的核心在於“Component”組件和“Business”業務，所以其核心是基於產品業務和基於測試組件。而這里的每一個接口，每一個業務操作，都可以認為是一個“組件”，而整個自動化測試程序，則是由諸多不同類別的組件構成，這些組件大致可以划分為以下幾類：
(1) 公共組件：用於測試框架中一些可重用的功能，提高開發效率和維護效率。
(2) 操作組件：用於對接口或GUI進行關鍵操作，但是不需要進行斷言測試。
(3) 測試組件：通過調用操作組件，並對其操作的進行進行斷言，屬於自動化測試的核心部分。
(4) 業務組件：針對不同的業務，我們可以封裝不同的組件，可以結合操作組件，測試組件等。
(5) 模塊組件：一個模塊組件應該由多個測試組件的調用構成，我們可以為此開放一個接口，專門用於將其模塊相關的測試封裝起來，可以更嚴謹地定義測試用例的調用順序，針對該模塊的測試設計模塊私有的公共組件等，同時也更方便測試執行時的調用。
6. 目前的測試框架存在的問題
目前市面上的測試框架，很難評價其好壞，更多的應該從被測試產品的產品架構，業務形態進行考量，適合自己的才是最好的。但是，通常的框架都存在一些這樣或那樣的問題，簡單總結如下：
(1) 測試框架只針對某些特定領域。比如專門針對Selenium的框架，專門針對性能測試的框架，專門針對接口測試的框架等。無法很好地覆蓋全流程測試。
(2) 測試框架試圖減少測試人員的編碼時間，而因此導致自動化測試腳本被各種操作限制得非常死，只能完成一些簡單的自動化測試，無法進行深度開發和定制。
(3) 測試框架的通用性更強，試圖適用於各類測試。比如Robot Framework，其通用性很強，可以針對PC端和移動端，可以對GUI進行測試，也可以測試接口，甚至於命令行。但是其通過關鍵字進行操作，雖然作為入門級使用非常方便，可以關注更少量的代碼，但是其靈活性也大打折扣，我們無法定制更強的功能，反而對於一個有經驗的測試開發工程師來說，是非常不習慣於被其關鍵字操作所限制，在功能組件的擴展上也顯得比較麻煩。
所以，我們更希望通過自己完全從零開始編碼來將業務的這些框架思想進行代碼實現，從而對各個環節及代碼細節有更清晰的認識。只有這樣，我們才能夠更好地應用一些成熟的框架，或者定制適合自己企業的專有框架，而不會受限於別人的框架，以致於導致自動化測試開發無法真正應用起來，產生應有的價值。
7. 附：CBT框架的階段划分圖:
版權所有，請勿盜圖。