BDD的优势
1. 代码即文档，由测试用例管理需求，最大限度的消除项目团队人员对需求理解不一致。
2. 由测试代码监督，约束着开发代码。开发者需要时刻考虑去满足测试的需要。这样使得开发者的代码保持着方向的正确性，也使开发者的代码足够的精练，产生较少的垃圾代码。
3. 开发者需要设计良好定义的接口，来满足测试的需要，降低系统模块的耦合度。
4. 有测试用例的保障，系统代码可以放心的重构。
5. 增强开发者的信心。一个测试用例的通过标志着系统一个需求的实现，这样的成果可以增加开发者的成就感与信心。
BDD的缺点
1. 测试用例只能体现系统细节设计，不能体现系统总体设计。
2. 测试用例无法覆盖全部的测试工作。
3. 约束开发者的发挥，开发者需要时刻考虑能否满足系统行为，能否使测试用例通过，这样会局限创造力。
4. 项目初期在测试方面投入过多，引起开发人员的不满。这一点上尤其对于新近实行TDD理念的团队来说，这方面的怀疑更多。
总结
BDD基于TDD发展起来，具有很好的实践基础，并且越来越多的人开始接触并且接受其的测试理念，受到了很多人的热捧。
个人认为，我们可以在小范围内用BDD的方式来开展项目开发工作，然后看效果，调整成为最符合我们公司开发需要的方式，进而推广。
在我们的日常测试中，我们也可以借鉴其系统设计的概念，将我们的测试用例设计成可以体现系统行为的风格，这样做的好处有两点，一是方便维护，别人一看就懂得我们的测试用例的校验点在哪里；二是方便我们定位问题，导致用例不通过的原因是系统的哪一步处理出错，不需要我们调试跟踪就直接看出来，可以节约我们大量的时间。
最后，用一个博友的话来总结BDD：优美的测试代码，就是一个个优美的故事。也用一句话说出我们所有测试人员的心声：我不做软件，但我使软件变得更好！
1116
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
