我们目前正在使用Fitness进行子系统测试。 我们在使用该工具时遇到了很多问题，很少提及
我们计划使用其他工具进行测试 我们知道的几个选项
我不确定我们是否会遇到与这些工具类似的问题 很高兴知道某人是否有使用这些工具的经验并可以指导我们
在我们的项目中，我们采用了TDD，因此我们有Nuits进行单元测试。 如果有人知道可以为子系统测试扩展nunits的工具/想法，那将是很棒的。
答案 0 :(得分：3)
组件测试工具都是关于调用函数的。您的测试会导致在“灯具”中调用函数，然后调用SUT。任何基于此前提的工具都会遇到您在上面提到的问题。
但是，大多数问题都是可以控制的。例如，你不应该写很多灯具。如果你是，那就错了。其次，你的灯具应该只是连接代码来调用应用程序中的API。如果您的灯具正在做重要的工作，那么就会出现问题。
在大多数FitNesse环境中，灯具数量相当少。例如，对于fitnesse本身有超过200个验收测试，但是大约有十几个灯具的数量，而且它们都相对简单。
获取fitnesse@yahoogroups.com网站的帮助。那里的人通常对问题非常敏感。
答案 1 :(得分：1)
如果您可以使用文本与您的软件进行通信，那么我已经使用expect在过去的项目上取得了成功。
我编写的框架使用简单的xUnit样式标记将测试存储为XML文件。然后使用样式表将xml文件转换为可执行测试。我最终将测试转换为Tcl / Expect，但您可以将它们转换为任何东西。事实上，如果您愿意，可以根据需要将它们转换为多种语言。
有几个人好心地提醒我（以同样的方式你提醒你可怜的溺爱祖父关于他下巴上的流口水）我们在21岁以上的时候他们会问我为什么选择Tcl超过一些现代语言。事实证明，出于这种测试的目的，我还没有找到更好的选择。 Tcl语言仍然在这个区域踢出了屁股。相信我，有一天我没有醒来并对自己说“自我，我需要一个用脚本语言实现的测试框架，每个人都会讨厌！”
信不信由你，我真的在寻找一种具有以下特点的工具，任何工具：
我没有像往常一样在家里成长。最初，我查看了DejaGnu和android等已建立的测试框架。大多数情况下，它们的功能太多了。它们如此特殊，以至于我认为如果没有大量的前期培训，项目就很容易开始使用。看一下DejaGnu，让我对Tcl感兴趣，在简短地看一下tcltest之后，我几乎放弃了。 DejaGnu和tcltest都认为你是一个高级的Tcl脚本编写者，我认为我公司的任何人都不会这样。另外，我希望测试框架（如果可能的话）支持xUnit类型的测试框架，而这些工具都没有。
最终我找到了TclTkUnit，这是一个基于Tcl的测试框架，是根据xUnit线设计的。这只是一个短暂的逻辑跳跃，意识到我可以在Expect中运行TclTkUnit而不是tclsh并获得我需要的一切。
随着它的使用越来越多，我添加了另一个样式表来在Web浏览器中很好地呈现xml文件。测试框架生成了自己的文档。
在另一个项目中，我们需要一个非常基本的模拟/刺激环境来模拟一个人在我们没有的硬件上投掷开关和按钮。只需几个小时就可以破解测试框架以充当模拟器。创建框架需要一些工作，但我们认为从长远来看它确实带来了好处。我真的相信创建自己的工具所带来的这些类型的不可预见的后果是敏捷社区中人们的原因。特别是XP一直都是如此强烈的拥护者。
答案 2 :(得分：1)
我们采用了基于Fitnesse但实际上无代码的方法，使用GenericFixture（谷歌为Anubhava找到他的wordpress网站）为Fitnesse。 这使我们能够做的是使用对业务方面友好的语言（而不是技术方面）创建“可执行测试叙述”。在通用夹具中，这种语言非常容易定义，实际上没有编码，被称为DSL（域专用语言）。因此，我们可以使用例如医学术语，甚至是英语以外的语言。基本上我们得到的是将我们的用例转换为可执行的叙述。 我们开始在一个大项目中使用它（15个人2年），似乎（到目前为止）有一个美好的未来。 它可以轻松地允许测试驱动开发或开发后的测试创建（传统方法）。 它是基于wiki的（Fitnesse），它的版本控制和重构功能已经证明到目前为止已经足够了。 如果有人有兴趣，我可以提供更多信息。
最好的问候，
亚里士多德。
答案 3 :(得分：0)
我们使用像NUnit这样的单元测试框架来驱动我们的子系统测试 - 测试并不关心它们的运行方式。但是，它没有fitnesse基于文档的方法。