這一篇我的偶像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 ()
腳本二
driver.find_element_by_id("tbusername").send_keys("user")
driver.find_element_by_id("tbpassword").send_keys("456123")
通過上面的兩個腳本，我們很明顯的發現它的問題：
這種模式下資料和腳本是混在一起的，如果資料發生變也也需要對腳本進行修改。
這種模式下腳本的可重複使用率很低。
子產品化與庫
我們會清晰的發現在上面的腳本中，其實有不少内容是重複的；于是就有了下面的形式。
#coding=utf-8
#登入子產品
def login():
#退出子產品
def quit():
..............
#調用登入子產品
login()
#其它個性化操作
#調用退出子產品
注意，為了省事我把代碼寫在了一個檔案裡，真正的實施時需要把子產品放到其它檔案進行調用。還有上面代碼不能完整運作。
通過上面的代碼發現，我們可以把腳本中相同的部分獨立出來，形成子產品或庫；當腳本需要進行調用。這樣做有兩個好處：
一方面提高了開發效率，不用重複的編寫相同的腳本。
另一方面提高了代碼的複用。
資料驅動
資料驅動應該是自動化的一個進步；從它的本意來講，資料的改變（更新）驅動自動化的執行，進而引起結果改變。這顯然是一個非常進階的概念和想法。
其實，我們能做到的是下面的形式。
d:\abc\data.txt
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然後“注冊”到架構；進而實作更強大的功能和擴充性。關鍵字更詳細的了解可以看我偶像的那偏文章。
本文所列出了不同自動化模型，雖然簡單闡述了他們的優缺點，但并不主觀的說評判某一模型好壞。其實他們也并非單純後者淘汰前者的關系，實施自動化更多的是以需求為出發點，混合的來使用以上模型去解決問題。
最新内容請見作者的github頁：http://qaseven.github.io/