一、 什么是自動化測試？
1. 定義
自動化測試是把以人為驅動的測試行為轉化為機器執行的一種過程，也可以說是軟件測試的一種技術手段。
2. 常見工具
-
- Appium： AppUI自動化測試，一個移動端自動化測試開源工具。
-
- Selenium： WebUI自動化測試 ，一個用於Web應用程序測試的工具。
-
- QTP ： WebUI自動化測試，提供符合所有主要應用軟件環境的功能測試和回歸測試的自動化。
-
- Robot： 多功能自動化測試，是一款python編寫的功能自動化測試框架。
-
- Loadrunner： 性能測試，一種預測系統行為和性能的負載測試工具。
-
- Jmeter： 接口性能測試，用於測試靜態或者動態資源的性能。
-
- GT： App性能測試，一個直接運行在手機上的“集成調測環境”，可對APP進行快速的性能測試。
-
- Monkey： 穩定性測試， 適用於android和ios，通過adb shell，生成用戶或系統的偽隨機事件，
-
- Appscan： 安全測試，一個適合安全專家的 Web 應用程序和 Web 服務滲透測試解決方案。
-
- Jenkins： 持續集成 ，用於自動化構建，編譯，部署，任務執行，測試報告，郵件通知等。
3. 常見誤區
-
- 自動化測試找不到bug？
自動化測試不直接找bug，而是通過自動化測試解放出測試人員的時間和精力，來間接地找到更多、更深層次的新bug，將產品質量再提高一個檔次，還有就是用於快速迭代中的回歸測試。
-
- 自動化測試一定會馬上大量減少測試人員數量？
自動化測試不會馬上大量減少測試人員數量。因為開展自動化測試初期需要投入一定的人力進行自動化測試腳本開發，並逐漸將自動化測試腳本用於日常的測試中，逐步減少手工測試人員從事重復勞動的時間和人數。
-
- 自動化測試能提供百分百的測試覆蓋率？
並非所有內容都可以被自動化地測試到。不可能覆蓋所有可能的輸入，所有可能的組合和路徑。自動化測試可以增加測試的廣度和深度，但是仍然無法達到100%的測試覆蓋率，因為沒有足夠的時間或資源。
二、 什么項目適合自動化？
通常，以查詢報表為主的系統，就是以插入，查詢，刪除，編輯為主的xx管理系統，這種系統不適合做web自動化。why？ 因為這種系統一般定位起來也比較麻煩，主要以嵌入式表格為主，層次較深，沒有特定屬性，很難准確定位，要寫又臭又長的xpath。最主要的是不太好斷言結果，因為你的數據是查詢出來的，今天查詢出來“張三”在第一頁，后面這個查詢數據增加，“張三”跑后第五頁了，再后來跑到第170頁，你說怎么用固定的信息斷言？ 沒有斷言，你怎么知道查詢的結果對不對？
這種系統的核心就是數據，其后台實現就是各種增刪改查詢接口。功能可用就好，一般這種系統不講究用戶體驗之類的，關鍵是數據得正確。尤其是針對金融領域相關的系統，那少算一個數、一個零、一個小數點，事可就大了。所以在我看來做web自動化的實際意義並不大，或者說這類系統做web自動化的並不是系統最重要的部分。但是，這類系統非常適合做接口自動化測試，why？因為接口測試關注的就是數據，我們可以通過改變傳參，然后斷言接口的返回，以及數據入庫結果。最后只要數據正確了，功能就做成大半，剩下的無非是如何把這些數據展示在頁面上。
三、 Robot Framework
1. 簡介
Robot Framework是用於驗收測試和驗收測試驅動開發（ATDD）的通用測試自動化框架。 它具有易於使用的表格測試數據語法，並使用關鍵字驅動的測試方法。 它的測試功能可以通過使用Python或Java實現的測試庫進行擴展，用戶可以使用與創建測試用例相同的語法，從現有的關鍵字創建新的更高級別的關鍵字。
2. 特點
- 使用簡單
當你真的要向項目中推廣一個技術或工具的時候，其實這點非常重要。對於大多測試團隊的測試人員來說，開發技術還是很薄弱的。RF使用非常簡單，只要告訴你是這些關鍵字是做什么用的，你去“填表格”就好的。
- 支持開發系統關鍵字
RF可不是只能寫一些死板的操作過程，定義變量，數組、字典，寫if判斷，for循環都不在話下，甚至調用python所提供的方法。
- 可以像編程一樣寫測試用例
開發系統關鍵字，或者自己寫個自定義庫也很簡單，用工具，但又不會受制於人工具。
- 非常豐富的庫
詳情參考以下內置庫和擴展庫說明。
3. 內置庫
-
-
Builtin：提供一組經常需要的通用關鍵字（默認自動引入）。
-
Collections：提供一組用於處理Python列表和詞典的關鍵字。
-
DateTime：用於日期和時間轉換的庫。
-
Dialogs：提供暫停測試執行和從用戶獲取輸入的方法。
-
OperatingSystem：用於執行各種與操作系統相關的任務。
-
Process：用於在系統中運行進程的庫。
-
Remote：可以連接到Telnet服務器並在打開的連接上執行命令。
-
String：用於生成，修改和驗證字符串的庫。
-
Screenshot：提供關鍵字以捕獲桌面的屏幕截圖。
-
Telnet：可以連接到Telnet服務器並在打開的連接上執行命令。
-
XML：用於生成，修改和驗證XML文件的庫。
-
4. 擴展庫
-
-
WEB自動化測試：Selenium2Library(Python)、Selenium2Library(Java) 等。
-
HTTP自動化測試：HTTP library (livetest)、HTTP library (Requests) 等。
-
移動自動化測試：Android library、IOS library、AppiumLibrary等 。
-
數據庫測試：Database Library、MongoDB library 等。
-
文件對比測試：Diff Library。
-
Windows-GUI測試：AutoItLibrary。
-
.
四、 環境搭建
1. 開發語言
Python2.7，對RIDE版本兼容性較好。
2. 自動化框架
Robot Framework，不再多說。
3. 編輯器
RIDE，用於測試數據的輕量級直觀編輯器。
4. 引用庫
HttpLibrary.HTTP，用於接口測試。
DatabaseLibrary，用於數據庫查詢驗證。
5. 必要插件
wxPython，編輯器RIDE的 GUI開發庫。
6. 安裝說明
個人建議：Python2.7 + wxPython2.8 + RF3.0 + RIDE1.5
詳情參考附件及文檔說明：
鏈接: https://pan.baidu.com/s/1KKVTqLzbtMciHINMqc6ELA 提取碼: 59de
五、 工程架構
1. 項目主目錄
CRJM，用於存放系統各模塊的測試用例集，測試用例。
2. 基礎關鍵字
BasicResoure.txt，用於存放公共關鍵字。
3. 配置文件
config.ini，用於存放系統地址，數據地址，用戶信息等。
4. 數據文件
cr_api_info，用於存放接口url和請求體。
5. 自定義庫
MyLibrary，存放我們自己開發的一些關鍵字。
六、 用例編寫
1. 預制/清理數據
測試前的數據預制，以及數據清理。
比如，測試建卡成功，那么就要確保數據庫不存在這條數據，需要提前清理數據；
反之，測試建卡重復，那么就要確保數據庫已存在這條數據，需要提前預制數據。
2. 設置請求體
根據測試點的不同，設置不同的請求體，達到測試的覆蓋。
3. 發送請求
根據接口的不同（如post、get），調用不同關鍵字。
4. 驗證響應體
獲取響應體進行校驗，如果響應體固定不變，可以整體校驗；反之動態變化，請拆分進行校驗。
5. 驗證數據庫
根據數據實際入庫情況，編寫不同SQL語句進行校驗。
6. 數據清理
為了防止數據庫太多冗余數據，測試完最好清理掉。
7. 用例設計思路
七、 執行查看
-
左側是用例條目，可以添加刪除，以及勾選執行。
-
上方是常用操作，可以進行執行/停止/暫停等操作，執行完畢可以查看報告和日志。
-
中間是結果版塊，打印用例執行情況，以及報告日志文件存放路徑。
-
下方是日志版塊，打印用例實時執行日志。
八、 結果分析
- 首先是測試報告，可以查看執行日期時間，以及執行條目，成功條目，失敗條目，耗時等
2. 再者是執行日志，可以查看到測試用例詳細執行情況，並且可以根據失敗用例集>>失敗用例>>失敗步驟>>錯誤日志，最終定位到具體問題。
九、 更多資料
https://www.cnblogs.com/leozhanggg/p/9675263.html
Reference: https://www.cnblogs.com/fnng/p/5370433.html, https://www.cnblogs.com/fnng/p/4333977.html