敏捷测试，TDD&ATDD

敏捷开发

现今软件产品丰富多彩， 任何产品都有其竞争与替代产品，产品发布与更新周期也越来越短，敏捷开发正是在这样市场环境而诞生并流行，其迭代反馈、拥抱变化的理念和方法，能够使得团队更能开发出符合市场和客户的高质量软件。在敏捷软件开发领域，更注重的以人为核心，迭代，循序渐进的开发方法，通过一系列的方法把市场和客户的需求和期望分散到个整个软件的生命周期中，从而使软件产品质量风险降低，能够最大可能的符合市场和客户的需求。而传统的开发模式基于中央控制的计划，没有足够的迭代和反馈理念和方法，犹如把所有钱都投资到一件事上，导致风险很大。

敏捷开发的最突出特性就是拥抱变化，需求的变动是必不可少的，每次的决定和需求的调整都是将产品开发推向更正确的方向。而在接受变化的同时，会对软件架构、编码、测试、文档都会造成很大影响，这就要求有严格的质量控制流程，否则，最终将可能使质量出现大问题。如可扩展性、架构、可用性、测试稳定性Bug 等。

敏捷测试

软件质量概念

质量就是软件产品对于某个（或某些）人的价值”（某个或某些人文章中统称之为用户），这里面包含两个层次的质量含义，即“正确的软件”及“软件运行正确”：

• “正确的软件”是说，一个软件要能够满足用户的需求，为用户创造价值。此处的价值可以体现在两个方面，即为用户创造利润或者减少成本。如果一个软件能够满足需求的用户群体越大、创造的利润越大或减少的成本越大，则该软件产品的质量越高。反之，一个产品尽管运行良好，没有 Bug，扩展性很强，性能很好，但如果没有服务的用户人群，没有为用户创造价值，则这样的软件尽管运行良好，也无任何质量可言。
• “软件运行正确”是说软件没有或很少 Bug，扩展性很强，性能良好，易用性高等。这样的软件是一个运行良好的软件，但还不能称之为高质量的软件。只有在软件符合用户的需求的基础上，运行良好的软件，才是一个高质量的软件。当然，如果软件完全符合用户需求，但不易使用，经常出错，性能很差，这样的软件也不是一个高质量的软件。

“正确的软件”及“软件运行正确”二者相辅相成，前者关系到软件的成败，后者关系到软件的好坏。

敏捷测试

敏捷测试人员

在敏捷开发流程中，测试不再是瀑布试开发流程的一个环节，而是全程参与整个开发流程。测试人员应该持续的反馈、沟通、分享与学习在这个过程中。

一个良好的敏捷测试人员除了应该具备测试的基本技能，也应具有批判性思维，分析和调查技能。他们了解风险，对软件中的错误有深刻的理解与分析，擅长探索性测试。他们有良好的沟通技巧，希望了解客户在做什么，以此更好地理解客户的软件需求。同时敏捷测试人员应该具有优秀的技术能力，如系统管理，数据库，网络等等。对于编程能力，我个人认为还是很必要的，这样才能与开发人员进行平等的对话，也才能知道如何与他人合作实现自动化测试。

TDD

测试驱动开发(Test-driven development TDD)，只涉及到开发者，基本流程如下：

• 增加测试新的用例
• 运行所有用例，然后查看是否有新失败的用例
• 开发代码
• 运行测试用例
• 重构代码
• 另一个新的测试开始，循环重复推进功能

在我的实际工作中， TDD在WEB API testing中得到很好的应用，但有下面的几个问题：

• 开发人员对需求理解不准备，这意味着写的用例也会不准确
• 通常 开发人员还是会先写代码，然后再增加单元测试用例，里面许多测试数据都是Hardcode. 不能真实反应测试场景。
• 测试状态与错误信息记录不完整。

后来我们做了一些改进，作为测试人员我们对所有SERVICES业务逻辑是非常熟悉的，我们创建数据生成器根据实际业务场景，然后开发人员在他们测试用例引用动态生成的数据对象，我们也创建了一系列的DRIVEN, STUB 模块，去模拟真实的调用环境 。在这里我想说的是，做这些事是需要时间的，所以对于一个大而且复杂，周期长的项目，这些时间成本的付出我认为是非常值得的，否则就得不偿失了。更多细节，请看

http://en.wikipedia.org/wiki/Test-driven_development#Fakes.2C_mocks_and_integration_tests

ATDD

“高质量”的软件，可以认为是：能为客户在最少时间内，带来最大价值的软件。测试人员在测试软件的时候，所有的测试标准也将围绕这个“高质量”的衡量标准进行，一个高质量的软件，不仅要能够按照既定的设计良好运行，还应该是一个很好用的软件。只有客户能够方便的使用软件，软件才能为客户创造价值，也才能称该软件为一个高质量的软件。所以测试团队在软件测试的过程中，要时刻站在客户的角度思考问题，设计测试用例，以及测试产品。

这里就不得不说Acceptance Test-Driven Development(ATDD), 在开发之前，业务人员，测试以及开发人员，甚至包括客户一起讨论需求，确定用户想要软件做什么与不做什么。然后拟定验收标准，规划制定验收测试用例。这些测试用例不一定要自动化。其实在实际工作中，验收测试用例都是最为核心功能，通常我们会把P1,P2的用例都自动化。在敏捷开发过程中，测试用例自动化的过程与开发是类似的，也是在不断增加新功能与重构中进行的。

这种测试方法的思路就是通过积极讨论挖掘需求上的细节，使用户深入思考他们到底什么是他们想要的，比如边界条件，配置或者用户操作顺序等等，而不必等到测试过程中提交了一大堆BUG后才达到共识。提取的验收标准表示为自然语言，而不是编程语言，这能使我们完全从任何技术细节与依赖中脱离而与期望值直接衔接。在自动测试框架中，我们也能慢慢理顺核心的业务流程，然后使我们用例基于业务模型进行测试。

具体的实施细节，请参考下面的文档，讲得非常详细

http://testobsessed.com/wp-content/uploads/2011/04/atddexample.pdf

除此以外，我们可能看到一些其它概念,比如TDR,FTDD, BDD, and STDD， 我觉得与ATDD大同小异，只是叫的名称不同而已。