關鍵字驅動
> 被測系統/功能還處於開發階段時，就能開始著手寫測試指令碼。
> 模組化的指令碼設計和資料集的使用可減少冗餘的指令碼 被測系統功能有變化時，只需修改與此業務功能相關的特定指令碼。
> 輸入，期望結果等資料可儲存成很容易獲取的記錄。
> 測試指令碼可以設計得很健壯，幾乎能做到無人值守。
> 需要對自動化工具所要求的指令碼語言非常熟悉。
> 測試範圍的擴大，會導致測試資料的數量和類別都非常多，維護這些資料成本會增大。
> 測試工程師維護具體測試計畫時需要重新設定資料檔案，以符合計畫要求。
> 維護資料檔案時需要格外注意資料的格式，因為往往沒有比較智慧型的編輯工具。否則需要在指令碼中處理各種格式問題（千萬別這麼做，很難維護，容易挖坑）。
> 可以在具體測試計畫中包含簡潔明瞭的測試資料。
> 測試工程師可以不用關心自動化工具所需的指令碼語言，而是直接呼叫由專業人員用這些指令碼語言編寫的業務通用的指令碼塊。
> 因為只需了解一些特定的關鍵字以及如何使用這些關鍵字的格式，測試工程師的生產效率會非常高。快速上手的特性可以延緩詳細的工具使用培訓。
> 和其它模式一樣，如果測試人員想要建立自定義的測試功能，就必須對測試工具所要求的指令碼語言非常了解。（當然，同時也要了解其它已有的關鍵字和各種可能的使用格式）。不過這只是在初期會遇到的困難。一旦測試工程師的學會了這些，建立維護測試用例就會容易得多。
一般的測試框架都結合了資料驅動和關鍵字驅動。
深入了解自動化 對自動化測試的誤解
這邊文章是寫給沒有接觸過自動化測試，包括剛學自動化測試或者專案管理人員。在工作中常常會有這種人，專案剛開始才出設計稿就要求先將自動化測試用例寫出來 既然有自動化測試，那麼就不要手工測試了，全部使用自動化。最常出現的誤解，既然有自動化測試就不需要手工測試。我在世界排名前幾位的公司專案文件上看到過這樣的...
自動化測試之六 自動化測試模型
from selenium import webdriver chrome driver path r c users administrator envs selenuimautotest lib site packages selenium webdriver chrome chromedriv...
《自動化測試》之
不知道之前的selenium api 用法1，有沒有去練習，個人認為線性 還是要靠敲的，後面的模組化除了多敲還需要一定的程式設計思想去理解，今天下午不是很忙就給來這兒補充點selenium api 的例子，之所以選擇例項是因為直觀，容易理解，而不是理論去解釋具體的關鍵字用法。題外話，最近越發覺得ui...