在Steve McConnell的“代码完成”中，他描述了测试加密程序：
我建立了一个完全运用加密的测试数据生成器 解密部分程序。它生成随机文件 随机大小的字符。 [...]对于每个随机案例，它都会生成 随机文件的两个副本，加密一个副本，重新初始化 本身，解密副本，然后比较每个字节 解密复制到加密副本。如果任何字节不同，那么 生成器打印出重现错误所需的所有信息。
此测试详尽地测试加密“单元”，并对其他单元执行一些测试 - 例如，用于文件访问和内存管理的单元。
我不认为这是一个标准的单元测试 - 这将涉及单独测试加密单元。
但是，我也不相信这是一个标准的集成测试，因为它只集中在加密单元上，而仅在传递时使用其他单元。
您如何对与此类似的测试进行分类？
答案 0 :(得分：2)
肯定不是单元测试，因为它是
由于测试未通过GUI（如下面的评论中所述），因此不是系统或验收测试，除非测试非常类似于客户要求并驱动被测系统就好像通过GUI控制一样（例如通过从MVC系统捕获视图的行为然后通过重放行为来移除视图来进行控制）。
所以在大多数情况下，我称之为集成测试：测试{加密单元，文件访问单元，内存管理单元，GUI}的前3个元素的集成。
对于设计良好的测试，集成测试应该关注三个单元的交互。每个单元的详细功能本身应该已经在单元测试中进行了测试。回到史蒂夫麦康奈尔的“代码完成”中给出的引用，我宁愿通过模拟文件访问单元来进行随机加密测试，然后在集成测试中不必测试加密单元的核心功能，而只是测试几个文件（对于像空文件这样的情况;简单的加密文件，例如只包含'a';几乎不加密，例如已经加密的文件;非常大的文件; ......）。
简而言之： Steve McConnell的测试是单元测试和集成测试的混合，我猜这就是导致你问这个问题的原因......
答案 1 :(得分：1)
我称之为功能测试或系统测试（尽管只是部分测试 - 需要另外一个测试，固定的，已知的测试向量产生正确的已知输出）。
原则上，单元测试不应执行项目中的任何代码，除了被测单元。并且可能其他一些独立测试的单元，不参考被测单元，基本上可以重用代码。该测试不采用这种方法。
但是，它可以被视为加密可执行文件的单元测试，但是，如果它的工作方式是使用命令行运行加密程序。我不认为这是这种情况，你的引言谈到“程序的加密和解密部分”，但它是类似的情况。无论如何，除非（也许）你是RMS在早上的小时内从头开始重新实现Unix，你不认为可执行文件是一个“单元”，你把事情分解得比那个小得多。
除了这个测试是否像单元测试那样构建之外，加密“单元”可能根本不是真正的单元，而是可以单独测试的部件集合。通过添加更多的依赖注入或以其他方式重新设计代码，您可以将一个不太可测试的系统变成一个更可测试的系统，从而将一些曾经是单元测试的系统转变为集成测试。我们不知道这段代码到底有多可测试。所以也许您可以将其描述为加密模块的集成测试。但是，由于系统性地尝试集成测试，它看起来并不像是这样，因此将它称之为可能有点误导。
我认为人们经常将测试描述为“单元测试”，即使它们确实不是，也是大多数人都可以接受的。特别是如果你在其名称中使用带有“unit”的测试框架，那么将它简单地描述为“单元测试”是很容易/懒惰的，而实际上你正在批量运行几种不同类型的测试。 p>
就我个人而言，我不认为测试的分类是非常重要的，除了你不应该自欺欺人地认为你的测试比实际更好，认为你是“单位”测试了一切“当你真的没有。我希望如果你与一个大型测试团队进行沟通，那么术语就会变得更加重要，因为每个人都需要知道他们在谈论什么。但我曾与之合作的最大的测试团队只有大约4或5人。