验收测试：责备工具

大约5年前，我参与了一个项目，该项目旨在建立抵押品管理系统。 该系统已连接到大型金融网络，并通过标准化的金融消息获得了说明。

该项目以瀑布形式运行，对学科之间的协作有很多限制。 无需详细说明，我仍然认为那些项目经理，甚至是经验丰富的项目经理都认为协作不好是很有趣的。 无论如何，一组业务分析人员写下了详细的规范，然后将其交给开发人员。 开发人员根据规范实施系统，然后将软件交付给测试人员团队。

测试系统

由于此特定系统是通过所有这些财务消息运行的，因此与具有常规用户界面的系统相比，测试起来要困难得多。 开发人员创建了一个测试工具，可以使用命令行界面与系统进行交互。 由于其命令行界面的性质，该工具还适用于整个业务流程的脚本测试。 该工具是低级的，就像开发人员需要的那样。

测试团队还需要与系统交互的工具。 开发人员使用的工具对于测试人员来说太底层了。 其中一名测试人员知道他以前使用过的工具以对大多数人更友好的语言描述测试，然后让该工具将友好的语言链接到代码。 这个工具是FitNesse 。

为了能够与FitNesse的主系统进行交互，在开发人员使用的测试工具中添加了一个适配器。 这是让FitNesse运行测试工具的固定装置。 测试工具中还添加了一些其他功能，以允许测试人员创建模板消息，然后在其FitNesse测试表中使用xpath表达式设置特定值。

做出改变

这种方法运行了大约2个月。 在这段时间内，测试团队添加了一个FitNesse插件以连接到系统的数据库，以验证系统的某些中间状态，并且在FitNesse测试中添加了几层间接操作，因此目前尚不清楚执行哪些操作从测试表中的“友好”规格中选择系统。

然后，要支持的财务消息的类型发生了变化。 这影响了到目前为止使用的所有消息模板和所有xpath。 您可以想象，这几乎影响了每个测试，导致测试团队进行了大量的返工。 由于他们无法足够快地完成任务，因此他们从开发团队获得了帮助。

测试全部“迁移”以使用新的消息结构后不久，数据库架构发生了变化。 而且它也没有变化。 再次，大多数验收测试都失败了，需要大量的返工。

责备工具

伙计，我们真的开始讨厌这个FitNesse工具。 每次系统升级时，所有测试都会开始失败。 为了解决这些问题，开发人员将帮助测试人员重做这些测试。 我们可以想到一个更好的任务或两个。

直到离开项目几周后，我才意识到，FitNesse不应为我们面临的问题负责。 我们要怪自己！ 不是错误的工具，而是使用错误的人。 在Bob叔叔（Robert Martin）的高级测试驱动开发大师班上，我了解到FitNesse的目的不是为运行验收测试提供文本抽象。

合作

不要误会我的意思，文本抽象真的很好。 但这不应该是主要目标。

FitNesse是用于自动验收测试的工具，重点是业务人员，开发人员和测试人员之间的协作。 通过协作，一组开发人员和测试人员可以一起了解所有功能，每个人都将自己的技能和素质带到讨论中。 他们在一起将自己的学习记录为测试表或简短的句子。

正如我之前提到的，合作并不是该项目的重点之一。 相反，这是您“不浪费时间”的事情。

在这个特定项目中，问题似乎出在FitNesse周围，我认为对于我读过的许多黄瓜故事来说都是一样的。 在互联网上，关于Cucumber（以及类似的工具）如何为项目增加价值没有很多意见。 我确实认为这在许多项目中都是正确的，但是出于与大多数文章中所预计的原因不同。

诸如Cucumber和FitNesse之类的工具不是开发人员工具。 如果只有开发人员来阅读和编写这些脚本，那么使用这样的工具只不过是在浪费时间。 开发人员可以使用其常规测试框架（例如rspec或junit）更快地自动化验收测试。

但是这些工具都不是质量检查工具。 只有在一起工作时，测试人员和开发人员才能充分利用这些工具，并将其用于真正的好处。 Cucumber和FitNesse都是协作工具。 他们属于敏捷团队的工具带。

参考： 验收测试：从Software Craft博客的JCG合作伙伴 Bart Bakker 抨击工具 。

翻译自: https://www.javacodegeeks.com/2013/12/acceptance-testing-blaming-the-tools.html