Test特性表示這一部分是測試代碼主體，可以看到都是基于驅(qū)動器的實例在操作瀏覽器進行點擊和輸入

　　1、導(dǎo)航到百度

　　2、找到id為kw的元素，并且清空它

　　3、找到id為kw的元素，并且鍵入“暴走漫畫”

　　4、找到id為su的元素，并且點擊它

　　這和我們錄制的操作基本一致

　　TearDown，眼淚落下，你說測試結(jié)束的時候有特么這么煽情么？

　　1、試圖關(guān)閉瀏覽器，如果出錯也不?它，這里至今我也沒搞清楚為什么不做處理，希望神人解答。

　　2、然后看看上面創(chuàng)建的記錄錯誤的S—B有沒有內(nèi)容，如果有內(nèi)容則測試失敗。

　　運行我們可以發(fā)現(xiàn)回放正常，重復(fù)執(zhí)行了我們所錄制的操作。至此，基本的測試框架搭建完成。

　　其實一路下來我們發(fā)現(xiàn)其實很簡單的，博主的智商也不過如此，這還需要寫個什么鳥博客來JJYY一大串？

　　這個工程還只能供剛剛?cè)腴T的測試人員參考，在這個工程中，我們其實從表面上可以發(fā)現(xiàn)很多的問題：

　　1、代碼過于專業(yè)化，不自然，可讀性不高

　　2、錄制的腳本太過于機械化，例如Test中的第二句，其實在我們這次情況下是可有可無的。

　　3、重復(fù)代碼過多，不光是找元素的代碼driver.FindElement(By.Id("XX"))，還有一些我沒有列出來的自動生成的IsElementPresent、CloseAlertAndGetItsText，不得不說這些方法是很有用的，但是如果你再錄制一個自動生成的腳本，這些方法又會出現(xiàn)，并且完全相同。在程序設(shè)計中，這些方法在維護的時候會非常令人頭疼，尤其是多起來了以后。

　　上面這些都是需要解決的問題，真正的項目中的代碼如果寫成這樣會被接你的班的程序員噴死的。那么，在下一次博客中，我們再來一起探討相關(guān)問題，接下來是觀眾提問時間謝謝~