Specflow入门-（9）小结

到这里，我们的入门已经结束了，我们已经可以使用Specflow来编写Feature文件，实现BDD格式的case的运行的整个过程了。

完整代码：https://github.com/ZnYang2018/SpecflowTest。

可以看到，Specflow并不是测试工具，它无法帮助我们去测试某个系统或软件，它只是一个BDD工具，作为让客户，开发者，测试人员沟通的工具。和直接用单元测试框架代码去写case相比，Specflow在case的上层添加了Feature文件，而Feature文件使用的Gherkin语言，类自然语言，对于客户和测试人员来说，理解起来没有障碍，通过阅读每个场景中的步骤，就能明白该场景对应的测试用例要验证什么，并且知晓软件的行为应该与该场景中的步骤表现一致。而对于开发和测试人员，除了阅读场景中的步骤，还可以去产看对应的步骤定义（StepDefinition）来明确测试代码执行的逻辑。最终的测试任务就由StepDefinition中的代码，被转换为相应的测试框架代码，来执行并验证的。

注意，这里的测试代码可能会调用某些工具来完成测试，例如做DesktopUI测试可能要使用UIAutomation或CodedUI等UI工具。

如图所示，左边未使用Specflow

需要将业务直接使用某种测试框架，编写测试用例（可以理解为Nunit的一个[Test]方法）以及测试代码。

右边使用Specflow

将对业务功能的描述写入Feature文件，然后生成StepDefinition（这个生成结构，即步骤定义函数的过程算是半自动），后面两部引用单元测试框架编写测试用例是Specflow帮我们完成的，然后最终需要我们编写测试代码。

使用Specflow不仅生成了测试用例，还留下了一套关于软件功能的文档即Feature文件，有时也被称为“活文档”因为这些描述不仅起到说明的作用，也可以去执行，来验证软件是否符合描述信息。