logo标签列表

何时使用测试脚本而不是单元测试？

unit-testingtesting
14

我目前正在从事一个已经生产运行超过两年的项目。该项目广泛使用单元测试和脚本化UI测试。最初的单元测试覆盖了系统框架、业务规则和状态转换(或工作流)。测试脚本用于黑盒测试。然而，随着时间的推移，维护我们完整的单元测试集的成本变得越来越昂贵，特别是与状态相关的单元测试。

经过一番调查后，我们发现与工作流程相关的单元测试相比，测试脚本更加有效(即提供更好的覆盖面)，而且维护成本更低廉。这并不是说单元测试的价值完全被否定了，但确实提出了这样一个问题，是否可以放弃某些类别的单元测试以支持测试脚本。

我们的项目采用迭代增量模型运行。

6个回答
11

在很多方面，我也曾经像你一样体验到了关于单元测试的痛苦，尤其是在那些成员对单元测试不感兴趣甚至为了欺骗源代码控制和节省时间而忽略或注释掉测试的项目中。我的一位前同事甚至为此创造了“期限驱动开发”这个词。

在我看来，当面临这种挑战时，以下是一些关于单元测试的准则:

  • 舍弃过时的测试 - 如果数百上千行的测试本质上是不准确或无关紧要的，那么尝试更新它们通常是没有意义的。立即舍弃这些测试。不要“忽略”它们，不要注释掉它们。完全删除它们。
  • 为新功能编写测试 - 任何新的功能仍需进行单元测试，并以可单元测试的方式编写。
  • 为漏洞修复编写测试 - 当对应用程序进行回归测试时，确保漏洞修复已经进行单元测试并确保漏洞已被修复可能是相关的。
  • 与代码覆盖率说拜拜 - 这可能会让我失去一些赞同者，但在确保功能和将测试作为延迟工作的借口之间存在着微妙的界限。重点应该放在确保核心功能上，而不是遵循任意代码覆盖率百分比。

话虽如此，我仍然认为单元测试不应该完全舍弃。测试脚本和单元测试都有自己的用途。但是，在维护TDD的狂热尝试和面对企业应用程序开发的现实之间应该取得平衡。

6
在SO上关于“单元测试的限制”的问题中，有一个答案是，当单元测试用于测试与INTEGRATION相关的任何内容时，它会变得复杂。连接和使用外部服务（数据库、SSH到另一台服务器等）以及用户界面是其中提到的两个例子。
并不是说你不能用单元测试来做这些事情，只是覆盖所有基础知识所涉及的难度使得使用这种测试方法不值得，除非可靠性至关重要。
对于我所有的自定义JavaScript UI代码（模板引擎、效果和动画等），我使用“脚本测试”，如果做得正确，我发现它快速而可靠。
3
你通常使用单元测试来做这个事情：测试单元。更精确地说，测试一个单元是否符合接口规范/契约。如果一个单元测试失败了，你就知道问题出现在哪里：它在被测试的单元内部。这使得调试变得更容易，特别是因为单元测试的结果可以自动处理。在这里，自动回归测试是很重要的。
当你想要离开单元测试的范围或者想要测试那些无法用单元测试很好地测试的东西时，你开始使用脚本化的 UI 测试。例如，在测试与许多外部 API 接口交互的代码时，你无法模拟这些接口。现在你可以引发某些错误，但追踪故障在代码中具体出现的位置就变得更加困难。
这个问题更适用于大型系统，其中现有单元测试的数量很高。在某些情况下，新需求对单元测试的影响比对测试脚本的影响更大。在理想的情况下，我会更新所有的单元测试，但实际上这是代价高昂的。 - Richard Dorman
2
实际上，有四个测试级别，其中三个可能涉及脚本，第一个则没有。
单元测试：在完全隔离于系统其余部分的情况下测试类或方法。
组件测试：在与系统外部其他组件（即来自不同功能域的组件）完全隔离的情况下测试系统中的一个场景。
集成测试：测试包括来自外部部分的输入和输出到其他系统的系统（即来自其他功能域）。
验收测试：最终验证，如Gishu所说，以检查正确的代码（即正确的功能）是否存在。
功能域示例：服务层总线，即所有项目（通常封装一些核心参考数据库）能够在总线上公开其服务。
您可以进行以下操作：
对发布者类进行单元测试
与SLB的其他组件协作进行发布者机制的组件测试
针对您的SLB服务和在SLB之外开发的其他组件及其服务客户端进行集成测试
对整个系统进行验收测试。
正如所说，最后3种测试可能涉及大量脚本，并且可以快速覆盖更多的代码。根据需要对类/方法进行单元测试的数量，良好的组件测试可能是更好的方法。
1

两件不同的事情

  • 单元测试 - 开发人员 - 验证代码是否正确
  • 验收测试 - 客户/QA/BA - 验证开发了正确的代码。

这两个类别应该是不同的，都扮演着同等重要的角色。放弃其中一个并不好。正如您所提到的，测试脚本属于第二类。我建议使用 FIT / Fitnesse 来实现此目的。如果不可行，则使用测试脚本/录制回放工具。但不要放弃好的单元测试.. 你说的“维护测试的成本变得昂贵”是什么意思？

一般来说，单元测试必须根据新的业务需求进行更改，但在某些情况下，更改涉及到系统的许多方面，更新所有受影响的单元测试的影响非常大。在这种情况下，测试脚本已被证明比单元测试更便宜修改。 - Richard Dorman
你应该非常警惕那些对单元测试产生如此重大影响的变化。现在，单元测试可能正在为自己买单，帮助你发现和理解所引入的变化。 - slim
1
这可能有点线程死灵术...但仅仅因为某个测试不是“单元测试”，并不意味着它就是验收测试。验证代码正确性的层次很多，从单元层一直到整个系统的配合。我在我的工作场所使用外部测试脚本，它们绝对只验证代码是否正确，而不是开发了正确的代码。 - Tom
0

我的假设是，你的单元测试维护工作量增加，是因为你的应用程序架构已经崩溃。由于除了你以外没有人真正知道你的代码中有什么，你可能想要应用五个为什么的方法来决定你真正的、本质的、根本性的问题是什么。在我看来，只要采用高度解耦、基于接口的架构，单元测试就不应该成本高昂。

网页内容由stack overflow 提供, 点击上面的
可以查看英文原文，
原文链接