帮你做到零bug地编程方法 - ATDD.pdfVIP

《验收测试驱动开发：ATDD实例详解》第一本成功实施和应用ATDD 的入门实践操作指南 1 ATDD 的原则 传统的软件需求（Specification）存在一个问题：需要特别的努力才能做得好。然而一旦它们编写完成， 很快就会因为各种原因（你能控制的，或无法控制的）而迅速过时。举个例子，如果一个竞争对手发布了一个 新特性，你的需求要立刻响应以保持你的市场份额。由于这显然是一个非技术决策，所以至少需要一些有业务 背景的人参与需求决策过程。 在确定需求过程中获得的意见越是多样化，你就越能看清楚整个应用的全景。通常来说，你至少需要从三 个不同的视角考虑。首先，需要考虑业务视角。在敏捷团队中，这方面需求通常由客户代表、客户代理人或是 Scrum中的产品负责人（Product Owner）来提出。 其次需要考虑技术视角。在传统的团队中，资深开发人员或技术负责人通常会站在这个视角。在敏捷团队 中，你会希望讨论会中有一个参与实际开发工作并熟悉源代码的团队成员参加。 最后，需要有人在这两种视角中充当中间人。在传统项目中，你会发现业务分析人员会提供这种视角。一 个富有经验的软件测试人员会带来同样的价值。 1 见识“三的力量” 可是为什么这三种不同的视角可以帮助我们确定产品的需求呢？设计软件系统包含很多对这两个方面的权 衡：业务功能与技术限制。我们的软件代码中充满了对功能和限制所做的折衷。另一方面，我们的缺陷数据库 中则充满了由明显决策失误而导致的问题。 这些决策中，有些在软件开发过程中很难改变，有些则很容易改正。通过尽早让业务功能和技术限制这两 种不同的视角接触，我们可以尽早找到正确的决策平衡点。因而，可以将引入难以改正的bug和容易改正的bug 的概率降到最低。顺便我们也可以避免这两种极端情况中间的那些bug 。 软件系统的功能分布在一个解决方案空间中[GW89]。这个解决方案空间中存在很多可以实现所需功能的 可行设计方案。这就解释了为什么你可以带着性能或负载等特性的需要去探索解决方案空间。这些特性限制了 解决方案空间中能满足用户期望的方案的数量。 另一方面，软件实现还存在技术方面的制约。这些制约同样限制了实现所有功能以及特性的设计方案数 目。 将业务功能和特性与技术的制约尽早放在一起考虑，可以帮助参与者在解决方案空间中探索可能的设计。 这是验收测试驱动开发方法可以成功的重要因素之一。并且，它证明了测试人员在这个探索过程中也能发挥作 用，他们可以对软件在功能、特性以及制约方面提出问题和建议。 但是，怎么看待独立的测试团队能带来独特的视角这一观点呢？在过去数十年的测试培训中，我们学到的 观点是：开发人员和测试人员应当基于需求文档这一共同的基础而完全独立的工作。这避免了在现代心理学中 被称为共识偏见(confirmation bias)的现象。测试人员必须避免受到开发人员观点的影响，并且在应当在适当的 时候对产品作出评价。一些团队将这条规则发挥到这样一种极致：开发人员与测试人员被完全禁止与对方交 谈。 与开发人员一起描述软件需求并不会给测试人员带来先入为主的偏见。相反，开发人员、测试人员与业务 专家应该一起捕捉软件需求。如果你认为这也会使测试人员产生偏见，那么你是不是该开始怀疑阅读需求文档 也同样会使测试人员产生偏见？对于测试人员，与开发人员以及业务专家一起描述需求实例和参加需求讨论会 的功用是一样的，这也是大多数测试人员在他们的职业生涯中都梦想能做到的。 事实上，在Gojko Adzic的书《实例化需求》（Specification by Example）[Adz11]中采访到的团队反映，由 至少一个开发人员和一个测试人员提供的综合观点，会让我们在项目初期就更好地理解需求。就像我们在机场 的实例中看到的一样，这种讨论通常会达到以下的效果，开发人员通过提出技术性的问题来澄清业务流程，同 时测试人员提出的问题则增加了需求的可理解性，并且用表格这一更加可视化的方式记录了需求。 1 《验收测试驱动开发：ATDD实例详解》第一本成功实施和应用ATDD 的入门实践操作指南 2 在迭代过程中，开发人员与测试人员基于对特性共同的基本理解开展工作。作为验收测试的实例则成为衡 量团队进度的指标。 为