帮你做到零bug的编程方法 - ATDD

ATDD的原则

传统的软件需求（Specification）存在一个问题：需要特别的努力才能做得好。然而一旦它们编写完成，很快就会因为各种原因（你能控制的，或无法控制的）而迅速过时。举个例子，如果一个竞争对手发布了一个新特性，你的需求要立刻响应以保持你的市场份额。由于这显然是一个非技术决策，所以至少需要一些有业务背景的人参与需求决策过程。

在确定需求过程中获得的意见越是多样化，你就越能看清楚整个应用的全景。通常来说，你至少需要从三个不同的视角考虑。首先，需要考虑业务视角。在敏捷团队中，这方面需求通常由客户代表、客户代理人或是Scrum中的产品负责人（Product Owner）来提出。

其次需要考虑技术视角。在传统的团队中，资深开发人员或技术负责人通常会站在这个视角。在敏捷团队中，你会希望讨论会中有一个参与实际开发工作并熟悉源代码的团队成员参加。

最后，需要有人在这两种视角中充当中间人。在传统项目中，你会发现业务分析人员会提供这种视角。一个富有经验的软件测试人员会带来同样的价值。

1 见识“三的力量”

可是为什么这三种不同的视角可以帮助我们确定产品的需求呢？设计软件系统包含很多对这两个方面的权衡：业务功能与技术限制。我们的软件代码中充满了对功能和限制所做的折衷。另一方面，我们的缺陷数据库中则充满了由明显决策失误而导致的问题。

这些决策中，有些在软件开发过程中很难改变，有些则很容易改正。通过尽早让业务功能和技术限制这两种不同的视角接触，我们可以尽早找到正确的决策平衡点。因而，可以将引入难以改正的bug和容易改正的bug 的概率降到最低。顺便我们也可以避免这两种极端情况中间的那些bug。

软件系统的功能分布在一个解决方案空间中[GW89]。这个解决方案空间中存在很多可以实现所需功能的可行设计方案。这就解释了为什么你可以带着性能或负载等特性的需要去探索解决方案空间。这些特性限制了解决方案空间中能满足用户期望的方案的数量。

另一方面，软件实现还存在技术方面的制约。这些制约同样限制了实现所有功能以及特性的设计方案数目。

将业务功能和特性与技术的制约尽早放在一起考虑，可以帮助参与者在解决方案空间中探索可能的设计。这是验收测试驱动开发方法可以成功的重要因素之一。并且，它证明了测试人员在这个探索过程中也能发挥作用，他们可以对软件在功能、特性以及制约方面提出问题和建议。

但是，怎么看待独立的测试团队能带来独特的视角这一观点呢？在过去数十年的测试培训中，我们学到的观点是：开发人员和测试人员应当基于需求文档这一共同的基础而完全独立的工作。这避免了在现代心理学中被称为共识偏见(confirmation bias)的现象。测试人员必须避免受到开发人员观点的影响，并且在应当在适当的时候对产品作出评价。一些团队将这条规则发挥到这样一种极致：开发人员与测试人员被完全禁止与对方交谈。

与开发人员一起描述软件需求并不会给测试人员带来先入为主的偏见。相反，开发人员、测试人员与业务专家应该一起捕捉软件需求。如果你认为这也会使测试人员产生偏见，那么你是不是该开始怀疑阅读需求文档也同样会使测试人员产生偏见？对于测试人员，与开发人员以及业务专家一起描述需求实例和参加需求讨论会的功用是一样的，这也是大多数测试人员在他们的职业生涯中都梦想能做到的。

事实上，在Gojko Adzic的书《实例化需求》（Specification by Example）[Adz11]中采访到的团队反映，由至少一个开发人员和一个测试人员提供的综合观点，会让我们在项目初期就更好地理解需求。就像我们在机场的实例中看到的一样，这种讨论通常会达到以下的效果，开发人员通过提出技术性的问题来澄清业务流程，同时测试人员提出的问题则增加了需求的可理解性，并且用表格这一更加可视化的方式记录了需求。

1

在迭代过程中，开发人员与测试人员基于对特性共同的基本理解开展工作。作为验收测试的实例则成为衡量团队进度的指标。

为了达到最好的结果，确认需求的过程应包含以下三种不同的角色：一个业务专家（例如Produce Owner，或驻厂的用户）、一个开发人员和一个测试人员。基于所包含的角色个数，Janet Gregory和Lisa Crispin把这叫做“三的力量”。

“三种解释原则”[Wei93，90页]提醒我们在对收到的信息下结论之前，至少要想到3种可能的情况。

如果我对收到的信息不能想到至少3种解释，就说明我对它的含义考虑的还不够全面。

“三的力量”可以帮助我们克服想象力的不足。让代表三种视角的人坐在一张桌子旁，充分理解特性或用户故事的可能性就会大大增加。这就是“三的力量”为何如此强大的原因。

“三的力量”不仅限于功能性需求。开发人员会注意到代码可能存在的性能问题，而要求澄清这方面的需求。测试人员通常会注意到可用性方面的问题。开发人员、测试人员和业务代表可以澄清对所有特性在质量方面的要求——有些时候这被称为非功能性需求。记住，要考虑到自动化测试无法覆盖的问题，并使用测试象限（见图9-2）来构建你的测试交响曲（见9.4节）。大多数的性能、负载以及稳定性的需求可以通过自动化测试来检测。

2 举办讨论会

如同我们在第一部分看到的，讨论会可以使整个团队对将要实现的功能获得一致的理解。你必须仔细考虑以下方面，才能组织一场让大家（包括不出席会议的）都满意的需求讨论会。

2 1 参加者

首先，你要确保自己选择了正确的参与者。对有些团队来说，这可能意味着包含整个开发团队以及来自不同公司的所有用户。这些团队通常都会举办一次比较大型的会议，但每个迭代都会开个小的碰头会。

另一方面，也有团队在讨论会中只包含三个角色的代表，就是只有三个人参加的小型会议。无论哪种情况，你都需要保证存在不同的视角。通常这意味着要包含熟悉产品业务方面的人。你同样需要有直接能接触到专业用户的人[Coc06]。

如同我在10.1节中提到的，你应当包含至少一个开发人员和一个测试人员。这个开发人员要熟悉代码。在需求讨论会中，开发人员会基于功能的技术实现提出问题。由于他们自身的特点，开发人员会考虑功能如何实现并且在他们的脑海中构建领域模型。讨论会能使他们对新功能点对应的业务领域取得一致的理解。

测试人员通过他们批判性的眼光，可以很快发现业务规则中的漏洞。测试人员在需求讨论会中发挥的另一个独特作用是：他们能够使用表格记录业务规则，使其变得清楚透明。无论他们是否使用过被称为“敏捷友好”的自动化测试框架，有经验的测试人员都知道如何使用决策表以及如何用表格形式表达复杂的业务规则。如果大家在需求讨论会中使用这样的表达方式，那么开发人员、测试人员和业务专家就可以在没有写任何代码之前就对讨论的功能点达成共识。

2 2 讨论会的目标

为了使需求讨论会能开得成功，你要知道谁是你的主要听众。虽然领域专家带来了关于新特性的必要知识，但是开发团队（开发人员和测试人员）才是你的主要听众。还要记住很重要的一点，客户和外部业务专家通常都很忙。如果你邀请他们参加会议，而会上你的开发人员们在激烈争论是否要使用最新的Web服务器，以及要使用哪种技术，那么下一次他们可能就不会再参加你的讨论会了。

你需要一个有经验的引导者使会议集中于讨论特性，而不是争论具体实现的技术问题。讨论会的目标是对业务规则取得一致的理解。你可以在业务代表离开之后再接着讨论所有的技术问题。在需求讨论会上花费的时间应该用来使团队获得共同的理解和愿景。