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. 浏览百度首页，当关键字为空时的搜索，则。。。。。

如何去写这两个测试？提示：代码必然有重复