寫在前面的話
自動化測試是什么時候開始火的？已經記不清了，只記得08年畢業(yè)的時候，QTP和load runner就已經成為了各大民間測試培訓組織的必備課，學員們裝著盜版的QTP，LoadRunner，在課堂上一遍又一遍虐待著百度的搜索框，然后感覺自己棒棒噠，出了學校，發(fā)現(xiàn)實際用到自動化測試的公司并不多。說這話可能有人要撿磚頭開拍，北上廣深杭這些大地方筆者真的沒去工作過，不敢說人家那邊自動化測試在行業(yè)內的推廣最早是什么時候，當時又到了何種程度，只是在作者工作的這個地方，自動化測試時至今日依舊是一個尷尬的存在，抱怨幾句，大家都在一股腦的推自動化，可是什么樣的項目適用自動化，要用在測試哪個階段，用到何種程度，卻依舊沒有個行業(yè)標準。大多數(shù)的人只看到了自動化測試可以減少人工，就吵著嚷著說自己也要用自動化，說我們是敏捷團隊，能讓項目加速的都是我們要做的，何其可笑，還是暫且打住這個話題。
閑來看了看當前測試工程師招聘的JD，發(fā)現(xiàn)很多公司已經把“能獨立搭建并應用自動化測試框架”作為招聘需求。墻里墻外扒拉了一下，發(fā)現(xiàn)了RobotFrameWork這個東西，看了一個禮拜大概弄清楚了一點，尋思著就把弄清楚的這一點點先寫出來，給同樣是菜鳥的少年們看看，也是給自己留個記錄。
翻了翻網上關于RobotFrameWork的文章，大部分內容套路都差不多，根據(jù)我這幾天的研究成果，這次我們直接寫個基于測試實例代碼分析的RobotFrameWork學習。這個系列的文章我不打算按照正常的套路從安裝講起到如何應用結束，相反，咱們先來看看測試實例，再分析代碼，最后看看安裝過程。如果看完第一篇，感覺有興趣，再往下看，沒有興趣就直接看別的就好啦。
閑話不多說了，我們開始。
Robot Framework 是一款由Nokia公司開發(fā)，使用Python編寫的功能自動化測試框架。憑借其良好的可擴展性，在引入各種資源包后，可用于web功能自動化測試，接口測試，手機app自動化測試，windows app測試以及數(shù)據(jù)庫自動化測試等。相較于其他自動化測試框架，Robot Framework 的最大優(yōu)勢在于：
完美地將底層大部分操作代碼封裝成關鍵字，最重要的是支持使用變量，循環(huán)，以及if else邏輯判斷。同時，在依舊無法滿足測試需求的情況下，支持將多個系統(tǒng)內建的關鍵字再次封裝為用戶自定義關鍵字。
語法類似自然語言，對于code要求極低，直接使用文本文件作為測試用例。使測試人員將更多地精力放在測試邏輯上。
良好的測試文檔管理結構，包括測試用例管理（分類，有選擇地執(zhí)行），資源統(tǒng)一存放等。同時HTML格式的測試報告具有良好的可讀性。
本文一改其他框架介紹文章的結構，不從安裝開始，而是借助一個簡單的測試實例，通過對測試用例的分析來對robot framwork+selenium2library框架在測試中的應用進行一個初步介紹，在讀者感覺此框架真正有用之后，再進行安裝，使用的具體介紹。
測試實例的介紹
“…一次一次地折磨Baidu的id=kw,su,你考慮過它們的感受么？”
我們這次的待測系統(tǒng)是Orelly 在線圖書館
業(yè)務需求如下：
注冊頁面的input box未填寫時，點擊注冊按鈕，每個文本框下方會出現(xiàn)錯誤提示信息
當輸入任何信息后，紅色的錯誤提示信息會消失
Email地址欄輸入的驗證
a. 單獨字母數(shù)字特殊符號無法通過
b. 字符+@無法通過驗證
c. @+字符無法通過驗證
d. 字符+除@外其他特殊字符+字符無法通過驗證
e. 正常的郵件地址可通過驗證通過何種渠道了解到本站”的拉列表值符合預定義值
成功注冊的happy flow
下面讓我們來看一下要實現(xiàn)對上述5點需求的功能自動化測試，RFS的代碼量是多少。
首先來看編寫RFS自動化測試代碼的UI IDE工具 –RIDE，使用RIDE可以極大的增加代碼編寫效率，同時也可以避免使用命令行的形式來運行測試用例。
由圖中我們可以看出，整個Demo由一個包括4條測試用例的testsuite以及一個資源管理文件 resource.robot組成。
首先我們看測試用例的代碼。在RIDE中，Test Suite是一個虛擬的套件，切換到測試代碼Tab后我們發(fā)現(xiàn)，所有功能的測試代碼只有區(qū)區(qū)60行出頭：
我們再來看resource資源管理文件的代碼量
我們在資源文件中，引入了幾個常用的測試庫及工具庫，并且對待測網址，測試瀏覽器，無效的Email Address地址以及下拉列表期待值進行了變量化的封裝，全部代碼也只有15行。
結束~
的確，如果是一個剛剛接觸自動化測試的新手，通過這簡單的不到100行代碼，就可以完成多個需求的測試，如果使用原始的selenium+python代碼，即使有一定的經驗，提前把webdriver.Chrome(),driver.get(“Http://www.xxxxx.com”)， driver.getElementBy()等方法進行封裝，然后再在測試用例中進行調用，代碼量也會遠超100行，更別提這其中涉及到的下拉列表取值和對比。
最后我們來看一下全部執(zhí)行完成后的測試報告以及自定義關鍵步驟的截圖：
- 測試運行Log
隨著測試用例的執(zhí)行，RIDE本身會在控制臺打印出各個用例的log情況，方便追蹤報錯以及測試失敗情況。在控制臺log的最下方，打印出了測試報告，測試long存放的地方。
- 測試報告
測試運行完成后，由于我們沒有設置制定的報告存放地址，報告默認存在[User]/AppData/Local/Temp/路徑下。打開文件夾，我們發(fā)現(xiàn)里面有5個文件：
a. geckodriver.log， 這個是selenium以及瀏覽器運行時的log，與我們這次要介紹的內容沒有關系，暫時忽略
b. argfile.txt，儲存了log文件夾的存放的地址，暫時忽略
c. Output.xml – RFS運行完成后，將整個測試的詳細流程，包括具體的操作以及使用的變量等和對應操作的結果，在這個XML文件中展現(xiàn)。當測試體量不斷增大，需要使用分布式執(zhí)行測試的模式時，可以采用工具將每個子節(jié)點測試機器的output.xml合并起來，得到一個總體，詳細的測試結果，這樣的文檔型測試結果也方便用戶保存及使用版本控制工具來管理測試結果。
d. report.html | log.html – 這兩個HTML文件就是整個測試最終的報告。在report.html中，對當前測試進行了總結，并給出了各種統(tǒng)計結果。
在這里我們可以按照用例的分類，標簽的分類， 套件的分類等進行篩選，然后通過點擊鏈接進入對應的詳細log查看
e. 最后，我們來看一下測試的截圖。在代碼中，我們指定了截圖保存的地址是測試代碼文件夾，打開對應的文件夾，我們可以看到2張截圖已經成功保存到這里，對應的文件名分別為：
name = input_all_info_3.jpg / signup_successful_2.jpg
本次介紹的第一部分就結束了，在接下來的部分我們會具體分析這個測試實例的代碼，來展示RFS在自動化測試過程中的高效，便捷。
