2010-09-17 57 views
3

在我看来FitNesse具有以下优点:为什么在测试高度技术性时使用FitNesse?

  • 让非技术人员定义的测试数据和预期的结果集(他们是如何定义成功)。非技术人员可能是用户,产品经理,或可能是软件质量专家,他们无法访问源代码和/或不知道如何使用源语言进行编程。

  • 让非技术人员运行测试并快速了解待测代码的健康状况。

我有一个代码库,其中“用户界面”是在一个库中的API时,所以它是可以理解的,只与谁知道的语言,并具有对API直接访问其他专业技术人员。我需要选择一种方法来执行集成测试。我对FitNesse很感兴趣,但我不明白为什么我会打扰。这些是仍然适用在这种情况下的优点:

  • 它强制标准样式定义的测试,所以他们很容易被其他软件专业人士谁需要使用相同的代码工作理解。

  • 它让源代码的作者和维护人员能够快速查看测试失败以及失败的方式。

  • 测试用与源代码相同的语言编写,因此不需要单独的专业知识体系(即perl或python)。

但是,还有其他一些简单的方法可以实现同样的目标,而不必离开代码编辑器。另外,为了运行测试,我没有看到将FitNesse测试与自动化系统绑定的方法,例如持续集成服务器使用新版本运行它们。我也没有看到如何在除开发平台以外的其他硬件平台上运行FitNesse测试,因此他们不会发现计时问题。

因此,如果您在“用户”与您一样技术性的环境中使用FitNesse,为什么?如果您尝试过并决定反对,您的理由是什么?

如果您使用FitNesse测试专用于单独专用硬件(嵌入式系统)的代码,那么这是如何工作的?

+0

针对嵌入式系统的自动化测试本身就是一种蠕虫,特别是当测试需要外部刺激时才有意义。 (认为​​安全气囊逻辑可以验证来自多个加速度计的输入)。我亲自通过在PC上测试嵌入式代码进行单元测试,并且通过功能测试证实它通常在嵌入式系统中工作,运气最好。但我的项目也没有预算去购买实验室的可编程信号发生器和数据记录器来构建真正的测试单元。 – RBerteig 2010-09-18 01:08:35

+0

在这个系统上自动化测试更容易,因为没有移动部件,而且它是linux,所以我可以将系统挂载到我的主机linux系统并运行(交叉编译)的可执行文件,而无需通过RTOS或非RTOS下载周期-OS系统。不过,当涉及到它时,软件将世界视为可以模拟的特定输入。模拟是否值得投资是项目特有的。在这种情况下,从设备驱动程序开始实现协议栈,测试注意事项与非嵌入式API开发类似。 – jasper77 2010-09-18 01:44:42

+0

我完全同意你的说法,难以融入自动化构建系统是一个严重的缺陷 – ossandcad 2010-09-19 22:31:48

回答

0

我完全同意你的看法,认为难以融入自动构建系统是一个严重的缺陷(将上面的评论扩展为答案),因此我选择了适用于C++的替代实现,CeeFit。托管CeeFit文档的原始网站(ceefit.woldrich.com)已停机数月,但现在似乎已经备份。 CeeFit可以很容易地自动化并集成到任何配置项中,但CruiseControl.NET可以接受任何格式的输出。至于CeeFit是否可以在嵌入式系统上工作还不确定,文档没有提及任何内容。

+0

是CeeFit特定于Windows开发吗?该网站介绍了DLL和.NET。我正在研究Linux。 – jasper77 2010-09-20 15:53:59

+0

@ jasper77我不这么认为,因为http://ceefit.woldrich.com/?page=Install页面提到了Red Hat和Solaris作为可能的平台。我在非Windows上没有使用CeeFit的经验,所以不能担保,但已经使用了代码+文档达2年之久,我对于它的说法有信心。 – ossandcad 2010-09-21 20:16:10