TDD对我这个测试人员而言的意义?

我有在开发团队作为测试员并且使用TDD的工作经验，但我从未真正思考过TDD对我有什么样的影响，直到有人明确的问我：

测试驱动开发（TDD）是一种以编程为主驱动的做法，那么你作为一个测试人员对此有何看法？

真是一个好问题！

我当时的回答是，TDD使我能够理解该软件，以及相关的测试，所以我可以更好的完成设计决策、抛出运营风险和潜在对GUI/验收测试的影响。

本文试着详细解释我是如何努力在TDD环境提供价值。

谁是这场游戏的参与者？

TDD是一种被极限编程团体所采用的做法，因此我采用了一个开发团队所使用的极限编程角色的术语：

•   程序员
•   测试员
•   客户

我是怎么看待TDD的？

我以为，最好从我认为TDD是什么开始。我当然不能说是TDD的世界级专家，所以我会保持我的说明简洁。 TDD背后的想法是，你写一个失败的测试，只写所需的产品代码，以使测试通过，然后你重构代码，以更清洁，更高效，或坚持于一些编码标准。这就是俗称的TDD周期（red，green，重构）

TDD主要是关于代码的设计;所得到的测试是一个很好的副作用，我们测试人员可以利用我们的优势，只要我们不屈服于他们那自信有100％安全性的错觉。

TDD的周期为程序员提供他们所需要的快速反馈使其能为代码设计做出明智的决策。大大降低了反馈回路也是持续集成（CI）和持续交付（CD）自动化框架的核心原则。测试人员可以而且应该利用这个快速反馈环路—— 它可以帮助防止代码被“各人自扫门前雪”，并有助于使CI和CD成为可能。

TDD的周期被认为是与创建一个失败的测试的开始。我觉得这是误导，因为我的观察使我相信，加入测试不是循环的第一步;首先，我们需要思考什么是失败的测试。

如果测试人员不写代码，如何使他们参与TDD？

最主要是，程序员关心的是代码设计而测试人员所关心的是软件的表现。然而，这两个问题之间的分界线是很模糊的——测试人员可以而且应该思考设计，程序员同样也可以而且应该考虑表现。

测试者在代码的设计追求可测试性。据詹姆斯·巴赫，测试人员应该考虑可测试性的两个主要部分，可控性和可观察性：我们是否可以把系统变成我们所需要的，再观察系统是如何表现的呢？得到不同测试所需的不同测试状态是否容易？我们如何知道应用程序在一个给定的时间点做什么——通过日志记录来实现？日志记录应该是什么样子？

在谈到程序员对软件，我喜欢用序列图（从UML通过）绘制出请求和响应系统的不同部分。这使我们都了解系统的流程和不同的状态，这有助于我们明白在什么地方需要怎样的测试。

下面是一个典型的Web应用程序的一个示例：

图片由 blog.quent.in 提供，通过websequencediagrams.com创建

我们认可对方，我对系统的理解，以及程序员那模块级的深入理解，以帮助防止不必要的重复测试，或者更好的是预防无效的测试。这是我们双方都共识的测试策略。

下面是保罗（程序员），特里（测试人员）和卡尔（客户）之间的关于协同测试策略对话的人为的例子

保罗：“喂卡尔，特里，你们有时间吗？

特里：“有”

卡尔：“当然”

保罗：“太好了，拿把椅子过来。我们的系统会对我们的应用程序之外的系统做出请求。目前，当这些外部第三方系统无响应或不可用时，我们会在用户界面显示每一个错误信息。从技术角度来看，这不太好——用户界面不应该显示这些不同的错误。

卡尔，你会乐意在用户界面上显示第三方无法服务这类的错误吗？”

卡尔：（经过一番商议）“是的，我很乐意显示这类错误消息。

特里：“OK。我们已经有一系列的测试用于检查关于UI的这些错误消息——这些测试仍然有效吗？”

保罗：“不。我们会找到后台服务的错误，并给出一般错误消息“。

特里：“OK。有什么我可以在UI中声明的呢？“

保罗：“你真的需要在UI声明？我们会为我们后台服务的错误作出声明。“

特里：“但是你在后台对错误做出了声明，但我们不知道该错误已被显示在用户界面。我想对用户界面进行测试，以检查所显示的错误消息，并且用户具有在错误消息后的后续界面。”

保罗：“谢谢提醒了我关于后续界面，我没想到那个。卡尔，你希望在后续的和目前的一致吗？”

卡尔：“如果可能的话，麻烦了”

保罗：“OK。这将需要更多的工作，但我们应该能够做到这一点。我们需要更新记录，以显示给出了新的一般错误——我们可以在短期内让你知道的变化是什么。”

特里：“太好了，所以我应该能够重构的误差情形之一来说明一般性错误，并移除多余的错误的情况。我怎样才能在测试中持续引发这个情况的错误？”

保罗：“引发错误的过程应该是一样的，现在，我们只是处理错误的方式不同。第三方服务的现有模拟应该还是有效的，但我们会在写单元测试时检查它，所以我们会让你知道。大家都满意吗？”

特里：“是的！”

卡尔：“是的！”

保罗：“好极了！让我们在几个小时内抓紧时间，看看我们能完成到哪儿。”

在运作中的TDD周期

写一个失败的测试

程序员开始他们的TDD周期编写代码，并听从单元测试的反馈。

我开始更深刻地思考我想探讨的测试理念和不同的边界情况。我可能开始写了以后可以通过自动化来执行一些场景。

随着设计的发展，更多需要解答的问题将接踵而来。

例如，程序员可以到我这里来测试一个特定的场景，我认为需要较高水准的测试来完成而他们试图用一个单元测试来完成的情况，但是测试证明是不够的。

同样的，我的边界情况下，可能需要改变设计或微调。 

(待续)

【英文原文：http://www.ministryoftesting.com/2014/08/tdd-testers/】

{测试窝原创译文，译者：大头}