Test特性表示這一部分是測試代碼主體,可以看到都是基于驅動器的實例在操作瀏覽器進行點擊和輸入
1、導航到百度
2、找到id為kw的元素,并且清空它
3、找到id為kw的元素,并且鍵入“暴走漫畫”
4、找到id為su的元素,并且點擊它
這和我們錄制的操作基本一致
TearDown,眼淚落下,你說測試結束的時候有特么這么煽情么?
1、試圖關閉瀏覽器,如果出錯也不?它,這里至今我也沒搞清楚為什么不做處理,希望神人解答。
2、然后看看上面創(chuàng)建的記錄錯誤的S—B有沒有內(nèi)容,如果有內(nèi)容則測試失敗。
運行我們可以發(fā)現(xiàn)回放正常,重復執(zhí)行了我們所錄制的操作。至此,基本的測試框架搭建完成。
其實一路下來我們發(fā)現(xiàn)其實很簡單的,博主的智商也不過如此,這還需要寫個什么鳥博客來JJYY一大串?
這個工程還只能供剛剛入門的測試人員參考,在這個工程中,我們其實從表面上可以發(fā)現(xiàn)很多的問題:
1、代碼過于專業(yè)化,不自然,可讀性不高
2、錄制的腳本太過于機械化,例如Test中的第二句,其實在我們這次情況下是可有可無的。
3、重復代碼過多,不光是找元素的代碼driver.FindElement(By.Id("XX")),還有一些我沒有列出來的自動生成的IsElementPresent、CloseAlertAndGetItsText,不得不說這些方法是很有用的,但是如果你再錄制一個自動生成的腳本,這些方法又會出現(xiàn),并且完全相同。在程序設計中,這些方法在維護的時候會非常令人頭疼,尤其是多起來了以后。
上面這些都是需要解決的問題,真正的項目中的代碼如果寫成這樣會被接你的班的程序員噴死的。那么,在下一次博客中,我們再來一起探討相關問題,接下來是觀眾提問時間謝謝~