昨天給開發的同事講我們正在做的自動化測試，同事問了句：為什么API的測試不需要寫代碼了，而UI的測試還需要寫那么多代碼呢？ 能不寫代碼么？
目前我們的自動化測試的現狀：
目前主要覆蓋兩個部分：API的測試和UI的測試。對於API的測試經過框架的封裝，基本上只需要編寫一個xml描述的test case就可以了，xml里描述了輸入，調用和斷言。框架就根據這個xml來測試具體的API，基本上(99%)不需要寫代碼了。而UI的測試在這方面框架封裝的卻比較少(力所能及的封裝一些通用控件)，更多的是制定一些分層的規范。
我當時回答：
因為API的輸入和輸出比較明確，而且目前的API的測試還僅僅是關注在單個API上，而UI這方面輸入輸出不明確，變化也較多，而且主要關注業務流程，用戶場景。
同事又問：
API也會變化啊，UI也可以做到明確啊。
顯然我的回答，同事並不滿意。后來我也在思索，為什么UI測試就不能像API測試那樣不寫任何代碼，只用一個類似xml的case文件描述一下即可呢？
下班回家在地鐵里突然想到，其實對於UI來講，UI上的每一個可輸入的最小的可復用單元都算是一個“接口”，這個接口等價於API測試中的那個接口(REST, RPC等)。如果我們要給UI中的最小輸入單元編寫測試基本上是可以做到不寫代碼的(測試人員可以不寫代碼，由測試框架提供)。而復雜的UI其實也是這些最小接口組合而成的。通過將這些最小”接口“組合成大一些的”接口“，最后組合成頁面級的”接口“，其實也可以做到不寫程序代碼測試UI。后來自己都笑了，這不就是Keyword Driven么。
聯想到昨天吳老師 @吳穹 講到：DSL不僅僅是針對某個領域的，每個項目也可以有自己的DSL。
那么如果我們能夠在項目的前一兩個迭代，利用Keyword Driven總結出這個項目的DSL，那么后面的測試的開發就會越來越快了啊。