這一篇我的偶像Jackei 致敬：
（關於偶像的問題，發表一下自己的看法，我覺得每個人都應該有“偶像”，偶像是標桿和奮斗目標。關於有些人拿比爾蓋茨 和 自己當偶像的，要么活在夢里，要么活在自己的世界，我只能 呵呵 了。）
其實，從剛開始做測試就有學習自動化（基於UI 的web自動動化測試），理解上一直處於非常皮毛的狀態。再次的深入學習並實踐自動化大概從半年前開始。邊學習邊總結是我的一貫學習方式。
Jackei 的這篇文章我了好幾遍，雖然將的內容並不高深，但隨着自己自動化水平的提高，每次看完也會一新體會。基於這篇文章，擴展的來談一下自己對幾種自動化測試模型的理解。
線性測試
通過錄制或編寫腳本，一個腳本完成用戶一套完整的操作，通過對腳本的回放來進行自動化測試。
這是早期進行自動化測試的一種形式。
腳本一
from selenium import webdriver import time driver = webdriver.Firefox() driver.get("http://passport.cnblogs.com/login.aspx?ReturnUrl=http://www.cnblogs.com/fnng/admin/EditPosts.aspx") driver.find_element_by_id("tbUserName").send_keys("admin") driver.find_element_by_id("tbPassword").send_keys("123456") driver.find_element_by_id("btnLogin").click() ...... driver.quit ()
腳本二
from selenium import webdriver import time driver = webdriver.Firefox() driver.get("http://passport.cnblogs.com/login.aspx?ReturnUrl=http://www.cnblogs.com/fnng/admin/EditPosts.aspx") driver.find_element_by_id("tbUserName").send_keys("user") driver.find_element_by_id("tbPassword").send_keys("456123") driver.find_element_by_id("btnLogin").click() ...... driver.quit ()
通過上面的兩個腳本，我們很明顯的發現它的問題：
一個用例對應一個腳本，假如界面發生變化，用戶名的屬性發生改變，不得不需要對每一個腳本進行修改，測試用例形成一種規模，我們可能將大量的工作用於腳本的維護，從而失去自動化的意義。
這種模式下數據和腳本是混在一起的，如果數據發生變也也需要對腳本進行修改。
這種模式下腳本的可重復使用率很低。
模塊化與庫
我們會清晰的發現在上面的腳本中，其實有不少內容是重復的；於是就有了下面的形式。
#coding=utf-8
from selenium import webdriver import time #登錄模塊
def login(): driver.find_element_by_id("tbUserName").send_keys("user") driver.find_element_by_id("tbPassword").send_keys("456123") driver.find_element_by_id("btnLogin").click() #退出模塊
def quit(): .............. driver = webdriver.Firefox() driver.get("http://passport.cnblogs.com/login.aspx?ReturnUrl=http://www.cnblogs.com/fnng/admin/EditPosts.aspx") #調用登錄模塊
login() #其它個性化操作
...... #調用退出模塊
注意，為了省事我把代碼寫在了一個文件里，真正的實施時需要把模塊放到其它文件進行調用。還有上面代碼不能完整運行。
通過上面的代碼發現，我們可以把腳本中相同的部分獨立出來，形成模塊或庫；當腳本需要進行調用。這樣做有兩個好處：
一方面提高了開發效率，不用重復的編寫相同的腳本。
另一方面提高了代碼的復用。
數據驅動
數據驅動應該是自動化的一個進步；從它的本意來講，數據的改變（更新）驅動自動化的執行，從而引起結果改變。這顯然是一個非常高級的概念和想法。
其實，我們能做到的是下面的形式。
d:\abc\data.txt
#coding=utf-8
from selenium import webdriver import os,time source = open("D:\\abc\\data.txt", "r") values = source.readlines() source.close() # 執行循環
for serch in values: browser = webdriver.Firefox() browser.get("http://www.baidu.com") browser.find_element_by_id("kw").send_keys(serch) browser.find_element_by_id("su").click() browser.quit()
好吧！不管我們讀取的是txt 文件，還是csv、excel 文件的之類，又或者是數組、字典函數。我們實現了數據與腳本的分離，換句話說，我們實現了參數化。我們仍一千條數據，通過腳本的執行，可以返回一千條結果出來。
同樣的腳本執行不同的數據從而得到了不同的結構。是不是增強的腳本的復用性呢！
其實，這對開發來說是完全沒有什么技術含量的；對於當初QTP 自動化工具來說確是一個買點，因為它面對的大多是不懂開發的測試。
關鍵字驅動
理解了數據驅動，無非是把“數據”換成“關鍵字”，關鍵字的改變引起測試結果的改變。
關鍵字驅動用編程方式就不太容易表現了。QTP 、 robot framework 等自動化工具就是典型的關鍵字驅動（填表格）
好吧！我能說selenium IDE 也是關鍵字驅動么？
轉化成表格是這樣的：
Selenium IDE 腳本分：命令（command）、對象（command）、值（value）
格式就那里不偏不移，通過這樣的格式去描述不同的對象，從而引起最終結果的改變。也就是說一切以對象為出發點。
當然，這樣的腳本，顯然對於不懂代碼的同學非常直觀！我要找誰（對象）？怎么做（命令）？做什么（值）？
更高級的關鍵字驅動，可以自己定義keyword然后“注冊”到框架；從而實現更強大的功能和擴展性。關鍵字更詳細的理解可以看我偶像的那偏文章。
本文所列出了不同自動化模型，雖然簡單闡述了他們的優缺點，但並不主觀的說評判某一模型好壞。其實他們也並非單純后者淘汰前者的關系，實施自動化更多的是以需求為出發點，混合的來使用以上模型去解決問題。