Unit testing 你会称之为单元测试、集成测试还是其他什么？

在Steve McConnell的“代码完成”中，他描述了测试加密程序：

我设置了一个测试数据生成器，它完全执行了加密和 解密部分程序。它生成了随机生成的文件 随机大小的字符。[…]对于每个随机情况，它生成 随机文件的两个副本，加密一个副本，重新初始化 对副本进行解密，然后比较 将解密副本复制到加密副本。如果任何字节不同，则 生成器打印了复制错误所需的所有信息

此测试彻底测试加密“单元”，并对其他单元执行一些测试，例如，文件访问和内存管理单元

我不认为这是一个标准的单元测试——这将涉及到单独测试加密单元

然而，我也不相信这是一个标准的集成测试，因为它非常专注于加密单元，而只是顺便使用其他单元

---

您如何对类似于此的测试进行分类？

它肯定不是单元测试，因为它是

• 不测试最小的可能单元，这将是核心加密单元的单一方法
• 使用许多其他函数作为文件访问和内存管理，而不是模拟它们
• 对于单元测试来说太慢了

由于测试不是通过GUI进行的（如下面的评论中所述），因此它不是系统或验收测试，除非测试与客户需求非常相似，并像通过GUI控制一样驱动测试中的系统（例如，通过从MVC系统捕获视图的行为，然后通过重放行为删除视图，从而进入引擎盖下）

所以在大多数情况下，我称之为集成测试：{encryption unit，file access unit，memory management unit，GUI}的前3个元素的集成都经过了测试

对于设计良好的测试，集成测试应该关注三个单元的交互。每个单元本身的详细功能应该已经在单元测试中进行了测试。回到您在Steve McConnell的“代码完成”中的引用，我宁愿通过模拟文件访问单元来进行随机加密测试，然后在集成测试中不必测试加密单元的核心功能，而只测试几个文件（适用于空文件；普通可加密文件，例如仅包含“a”；几乎不可加密，例如已加密的文件；非常大的文件；…）

---

简而言之：Steve McConnell的测试是单元测试和集成测试的混合体，我想这就是你问这个问题的原因…

我将其称为功能测试或系统测试（虽然只是部分测试——需要另一个测试，固定的已知测试向量产生正确的已知输出）

原则上，一个单元测试不应该执行任何来自项目的代码，除了被测试的单元。可能还有一些其他单元是独立测试的，没有参考被测试的单元，基本上是重复使用代码的。这个测试不采用这种方法

但是，如果它的工作方式是使用命令行运行加密程序，那么就可以将其视为加密可执行文件的单元测试。我不认为是这种情况，您的引用谈到了“程序的加密和解密部分”，但情况类似。无论如何，除非（可能）在早上的几个小时里，你是RMS从头开始执行UNIX，你不认为一个可执行文件是一个“单元”，你把事情分解得比它小得多。 即使不考虑此测试是否像单元测试一样构造，也可能是加密“单元”它根本不是一个真正的单元，而是一组本身可以单独测试的部分。通过添加更多依赖项注入或以其他方式重新设计代码，您可以将一个不太可测试的系统转变为一个更可测试的系统，从而将一些以前的单元测试转变为集成测试。我们不知道这段代码如何可测试真的是这样。所以也许你可以把它描述为加密模块的集成测试。它看起来不像是集成测试的系统性尝试的结果，所以这样称呼可能有点误导

我认为人们经常将测试描述为“单元测试”，尽管事实并非如此，这是大多数人可以接受的。特别是如果你使用的是一个名为“单元”的测试框架，那么很容易/懒得将其描述为“单元测试”，而事实上，你在一批中运行了几种不同类型的测试

---

就我个人而言，我并不认为测试的分类法非常重要，只是你不应该自欺欺人地认为你的测试比实际的要好，因为你认为你已经“对所有东西进行了单元测试”实际上你没有。我希望如果你与一个大型测试团队交流，术语会变得更加重要，因为每个人都需要知道他们在谈论什么。但我曾经与之合作过的最大测试团队只有大约四五个人。

来自维基百科：“系统测试[…]测试是否在一个完整的集成系统上进行。即使加密程序测试仅在系统核心上运行（例如，没有用户界面），是否也可以将其视为系统测试？因此，测试的加密“单元”永远不会部署给客户（例如，没有命令行或库版本）？假设测试在由{加密单元、文件访问单元、内存管理单元、命令行接口}组成的可执行文件上运行，并且客户收到di