Selenium實戰——因測而測？因需而測！

你們好，最近實在有些忙，主要是忙着搞證，博主如今也是執證人員了。什麼證？騷年你圖樣圖森破了，趕快找個老婆告終今生吧（扯了證才知道事情多呀，不說了都是淚）。

上回說到.Net下Selenium測試環境的搭建（用力戳我進傳送門），留下一大堆的問題有待解決。你們都知道博主是個負責任的人，必定會和你們一塊兒解決這些問題，各位美女遇到博主這麼負責人的男淫就從了吧。

好了不扯了，今天要說的問題是上回提出的第一點問題：代碼過於專業化，不天然，可讀性不高。例以下面代碼中，沒法去解釋某一個方法的具體功能（方法不夠單元化），好比TheUntitledTest方法中既要作操做，又要作斷言（若是用Selenium自動錄製斷言腳本就會放到這裏面），乍看之下也晦澀難懂，徹底不知道這是要幹嗎。

NUnit爲何不合適？

上面的代碼裏使用的是NUnit做爲測試框架。NUnit是什麼？顧名思義，.Net下的「單元測試」框架，專門爲「單元測試」設計的框架。框架作的是「單元測試」，咱們作的是「系統測試」/「迴歸測試」，二者是徹底不一樣的概念。前者是從「代碼」的角度進行測試，然後者是從「業務功能」的角度進行測試（這其實才是咱們須要換掉NUnit測試框架最主要的緣由）。Selenium IDE自動生成的代碼中會使用NUnit，我以爲是出於幾個方面的考慮：首先NUnit使用普遍，理解簡單；其次NUnit勉強能夠「兼容」Selenium測試的須要。

說到這裏就要強調一下博主的強迫症了，嚴重到調音量都要調到5的整數倍有木有（中槍的自覺回覆自覺頂）。

將就向來不是個人專長。

一般來講，「兼容」的另外一面犧牲的是「特性」。咱們這裏不須要「兼容」的同時，更須要的是代碼的可讀性、可維護性。

在軟件開發的領域，有一種開發方式叫作「行爲驅動開發」簡寫爲BDD（Behavior Driven Develop），這種開發的特色就是從用戶的行爲出發進行開發設計，將用戶的需求分解爲UserStory，每一個UserStory就是一個獨立的用戶行爲，這很是符合咱們從「業務功能」的角度出發進行測試的理念。

UserStory的書寫格式爲

 

Story: 標題 （描述故事的單行文字）

As a [角色] I want [特徵] So that [利益]

每一個UserStory包含多個場景來驗證

Scenario 1: 標題 （描述場景的單行文字）

Given [上下文] And [更多的上下文] When [事件] Then [結果] And [其餘結果]

 

例如咱們的需求能夠這樣描述

用戶故事：搜索指定文本

做爲用戶，我想搜索指定文本，從而找到須要的結果

場景1：搜索指定文本

假設在搜索主頁面輸入指定文本，當點擊搜索按鈕的時候，應該在獲得的第一條搜索結果中包含搜索的關鍵字

 

引入Machine Specifications

關於BDD框架，我在這裏推薦咱們項目中用到的Machine Specifications（固然其餘BDD框架一樣優秀）

首先安裝MSpecs到現有的項目中（具體能夠參考個人另外一篇文章NuGet用法參考）

在NuGet中搜索Machine Specification就能夠找到而且安裝

 

而後咱們將測試腳本轉化爲這樣的形式（這裏還添加了上面缺失的斷言到測試中，這是以前犯的一個錯誤，沒有斷言就不能叫測試）

分析上面的代碼：

BDD的UserStory中全部的元素都對應在代碼中

• Story =>Subject
• As a … I want … So that … =>命名空間
• Scenario =>類名
• Given => Establish
• When => Because
• Then => It

在Resharper中的運行結果爲（能夠注意一下測試結果中的中文，幾乎能夠連接成完整的句子）

其實MSpecs是基於NUnit開發的，咱們能夠很容易找到Establish、Because、It、Cleanup和NUnit中Attribute的對應關係，可是MSpecs從BDD的角度出發，讓測試腳本結構變得更簡練、可讀性更高，更清晰的描述用戶艹蛋的真實需求，做爲「鑲嵌在代碼中的文檔」而存在：

除此以外，腳本塊的職責變得很是明顯：

• Establish用於準備上下文
• Because用於執行關鍵步驟
• It用於斷言結果

具體實現中，除去Driver和base_url的初始化還有結束時的清理工做（這些會在從此的文章中清理，這裏只討論MSpecs框架的引入），只剩下對於假設、動做、結果的實現，這些實現很是獨立，而且有配套的「文檔」來解釋其大意。

固然，咱們這裏只討論BDD框架的引入，你也許以爲它和測試絕不相關，用NUnit一樣能夠實現。可是，咱們這裏所講的是「實戰」，我這裏提供的是一種項目中數量龐大的腳本（也是用戶需求）的實現和管理方式。我所在的Skight團隊在開發過程當中一樣也是用這種方式來作測試用例（需求）的管理，而且取得了不錯的效果。

 

文章分了不少次寫，修改了很多，若是各位看官以爲頭暈腦脹就對了。若是對我寫的有任何的疑問，儘管提，我會盡力回答。

 

代碼能夠在https://github.com/zhaoyan42/SeleniumInAction下載，配合以前的這篇文章（猛戳）應該可以很好的獲得可執行代碼

 

相對NUnit更多的優點在下一篇博客中會提到。這裏劇透下，你們也能夠試着思考若是是你，你將如何實現：

例若有兩個測試用例

1. 瀏覽百度首頁，當關鍵字不爲空時點擊搜索，則。。。。。
2. 瀏覽百度首頁，當關鍵字爲空時的搜索，則。。。。。

如何去寫這兩個測試？提示：代碼必然有重複