昨天給開發的同事講我們正在做的自動化測試，同事問了句：為什麼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，那麼後面的測試的開發就會越來越快了啊。
UI自動化測試框架
python selenium unittest ddt htmlreport分布式資料驅動自動化測試框架結構 1 business 公共業務模組，如登入模組，可以把登入模組進行封裝供呼叫 login business.py from page object.common page.login pa...
UI自動化測試 介面測試等自動化測試策略
今天跟大家介紹ui測試 介面測試 單元測試主要內容，以及每種測試花費時間討論。ui測試 selenium ui測試是最接近軟體真實使用者使用行為的測試型別。通常是模擬真實使用者使用軟體的行為，即模擬使用者在軟體介面上的各種操作，並驗證這些操作對應的結果是否正確。介面測試 api測試 api測試，主要...
UI 介面自動化測試策略
今天跟大家介紹ui測試 介面測試 單元測試主要內容，以及每種測試花費時間討論。ui測試 selenium ui測試是最接近軟體真實使用者使用行為的測試型別。通常是模擬真實使用者使用軟體的行為，即模擬使用者在軟體介面上的各種操作，並驗證這些操作對應的結果是否正確。介面測試 api測試 api測試，主要...