2019-03-27之前团队就有人自己开发了一套DSL用来描述验收测试用例，自己跑各种测试，从构建依赖环境，启动虚拟机，到运行测试，不亦乐乎。我发现真有一类人迷恋这种做法，愿意把代码和测试代码以及验收测试代码写得很好，即便开始的时候要花比较多时间，他们非常享受测试通过后的绿色bar。虽然过于迷恋未必有利于项目，但据我观察大多有这样工作习惯的技术人员都很出色作者回复: 我很喜欢一个说法，软件工匠，把写代码这件事当做手艺活来不断打磨。
10
2019-03-31如果在理想状态下，单元测试、持续集成和系统测试等都做的很好，那么验收测试一把过是不是就顺理成章了甚至不需要了？它们几个在软件生命周期里侧重些什么？验收测试作为一个主题单独讲解是不是说明前几个还不能保证足够完善或者需要从别的视角对它们做出修正呢？作者回复: 你都说了“理想状态”下，现实情况是，理想状态不存在。验收测试就是站在业务的视角看待系统的一个过程，而其它几个都是站在软件本身的角度在看。
以我对开发做测试这件事的理解来看，开发人员在测试用例设计上，与测试人员还是有很大差距的，测试人员总是可以探索出不同的角度打败你。 5
2019-05-05类似BDD这种行为驱动开发相关的内容，包括其已有的框架Concordion是第一次了解到，长见识了。不过在我的了解中，能够践行这种验收测试的公司应该很少吧？作者回复: 做测试的程序员不多，做BDD的人就更少，所以，只要学会这些东西，就比业界大部分程序员水平高了。
4
2019-03-27验收测试和常规的集成测试 有什么区别？作者回复: 一般说集成测试，还是站在内部的角度，也就是技术的角度在说，而验收测试应该是站在业务的角度，没做好的另当别论。
4
2019-03-27自动化验收测试确实是很好的东西，比如在回归测试，省去了很多的重复工作。但我理解BDD的初衷是驱动产品、业务、开发、测试等去深入讨论沟通需求，在还没有真的写代码的时候去实例化story，并一起定义验收用例，让每个人对需求的理解都很透彻，当然特别注意的是要从统一的业务角度去描述，可见，真的做好BDD是需要不断的尝试和总结的。作者回复: 你的理解很对，BDD 不太可能一蹴而就，需要各方不断磨合。
2- 2019-03-27请教老师，有真实项目中的一些验收测试的例子吗？有github上的项目可借鉴的吗？
作者回复: 我还真不知道哪个开源项目这么做，我都是在内部项目上这么做的。
1 
2019-03-27公司老项目，没有测试代码，更别说bdd自动化验收代码了。不过我在尝试为核心的一些业务补充测试代码。刚好可以研究下。有价值的活动不仅仅是写需求，如果只是验收需求，整成自动化验收成本是比较高的，业务不见个愿意买单。但如果说成减少测试队友重复工作，提高需求开发速度和项目可扩展性与健壮性（利于重构，而重构能产生以上价值），并给出大概的量化指标，大部分业务都会再斟酌下的。作者回复: 关于遗留系统的讨论正在不远处等着你。
1
2019-03-27作者给出的参考链接和一些参考书名都很好，国内项目实施BDD的很少吧，可能客户觉得这很浪费时间，或者他们觉得开发做这个他们要承受一些成本作者回复: 不做的理由有一万个，做的理由有一个就够了！
1
2019-03-27验收测试是不是针对业务需求的测试？作者回复: 对，应该是这样的。
1- 2019-03-27老师，selenium跟Cucumber，端到端测试跟验收测试，有区别吗？
作者回复: 对比这里的例子，Selenium是用来实现这里的步骤定义的。
1 - 2019-03-27我没有明白举那个例子的意义，配置文件写了几段话，程序里写胶水代码去支持，这个感觉也不动态啊，这不是绑死了吗？
作者回复: 这里面在业务层需要组合的代码是 Given...When...Then 的部分。当你有了足够的基础描述之后，就可以任意组合这些语句了。至于胶水层代码，它本来就是为了支持每一个 Given/When/Then 的实现，不需要更多的能力。
1 
2019-03-27我的团队在做一个web项目， 随着业务复杂， 一个迭代开发完成后， 经常会发现系统某些隐藏的功能用例不在了，除了前面所讲项目中增加单元测试， code-review 外， 如果从自动化验收测试角度， 该如何检查出这样的问题。我们团队测试一般针对当前迭代功能需求进行人工验收测试。很难做不到把系统所有用例都进行一番测试。所有很是一个头疼事， 每次迭代都存在风险。