所以这件事在我的脑海里已经有一段时间了。我已经看到了它的提及,我已经阅读了健身网页,但我仍然不太了解它。Fitnesse 似乎是另一个测试框架,如 NUnit 或 MbUnit 或任何其他框架,因为您定义了您想要查看的输入和输出,但它似乎旨在测试整个应用程序而不是单元。
如果是这样,它是如何运行的?您是否必须使用钩子设计您的应用程序以进行适合性测试?它实际上属于测试范围的哪个位置?有人可以给我一个很好的例子,说明可以在哪里以及如何使用拟合测试,以及有哪些优点/缺点?
NUnit/MbUnit 和 FitNesse 之间的区别在于 NUnit/MbUnit 旨在用于单元测试,而 FitNesse 用于验收测试。
单元测试测试单个小代码单元,例如方法,以确保它按照程序员的预期执行。例如,您可以使用单元测试来确保阶乘计算方法为一组数字返回正确的结果,包括一些边缘情况。
验收测试旨在测试是否满足高级设计要求。例如,如果您正在编写一个 Pac-Man 克隆,并且其中一个要求是“当前一个级别的最后一个点被吃掉时,一个新级别开始”,验收测试将测试该要求是否作为一个整体由代码满足——而不是使用点、检查结束条件和加载新级别的特定代码片段(尽管该代码将在运行验收测试的过程中执行)。验收测试通常是在不考虑需求的具体实现的情况下编写的。
许多 QA 部门手动执行一长串验收测试,这可能非常耗时。Fit 和 FitNesse 是帮助自动化验收测试的工具,可以节省大量时间。
Ward Cunningham 的 wiki上有很多关于验收测试的好信息。
我合作的最后一家公司使用 FitNesse 取得了一定程度的成功。它的使用方式与 NUnit 不同,后者的测试程度非常精细。FitNesse 更多地用于“验收测试”,涉及粒度较小的“大规模”测试。为了比较两者,假设我们正在编写一个用于在银行处理支票的应用程序:
如果我们使用 NUnit 编写单元测试,我们将测试 Check 对象、Transaction 对象、TransactionProcessor 工厂的每个单独方法,测试数据访问层的每个方法等。您的测试非常接近源代码.
如果我们正在编写验收测试,我们可能会设置一天的交易,提示应用程序处理交易,并确保代码生成正确的发票报表和报告。您的水平比单元测试高得多,通常处于可以同时测试所有应用程序业务规则的有利位置。
单元测试告诉程序员代码是否包含任何缺陷,验收测试告诉业务分析师应用程序满足用户期望。
FitNesse 测试用例旨在由没有技术知识的人编写。您仍然需要程序员编写 DLL 以向 FitNesse 公开应用程序的内部结构,否则用例应该由对源代码一无所知的非技术人员编写(即业务分析师和 QA) .
我的公司使用 FitNesse 测试我们的一个“核心”应用程序,该应用程序恰好是在 20 年的时间里使用一种死掉的类似 COBOL 的语言编写的。核心应用没有单元测试,用原始语言创建单元测试框架几乎是不可能的。幸运的是,该语言具有 COM 绑定,它向 .NET 和 Java 公开了一些公共方法,使我们能够为该应用程序编写自动化测试用例,这是 20 年来的第一次。它不漂亮,但商界人士喜欢它。
FitNesse
基本上是一个wiki
存储所有测试用例的。最有可能用于验收测试。在测试优先开发中,测试用例应仅在需求收集阶段编写,即客户也将参与编写测试,这往往会编写有关验收测试的测试......
所以优点是如果应用程序满足所有用户要求,则不需要单独的验收测试。
缺点是当需求发生变化时,测试用例也会发生变化,但这当然不是什么大问题。
也fitnesse
将适用于中小型项目。在大型项目的情况下,它可能很笨拙,因为Fitnesse
无法导出 PDF 文件,它只能导出 Excel 或 worddoc 等电子表格。所以它的缺点是不能用于大型项目。
从我的角度来看:它几乎不依赖于要测试的应用程序的挂钩。如果这不能开发出好的 API,那它几乎是没用的。并且不要尝试将其用于 GUI 测试。
它可用于运行您的回归测试套件。可用于查看发布后的数据库发布情况。它可用于测试存储过程。它可以用来比较不同的环境。