为另一个质量保证（QA）创建完全重复的系统是否是不良做法？

在工作中，我们有一个非常复杂的系统。我们将此系统称为System_A。我们的质量检查小组创建了另一个系统，称为系统_B，以测试系统_A。

System_B的使用方式如下。我们生成输入（使用System_B本身）IN，再通过System_B处理此类输入，并生成输出O_B。因此过程如下：

System_B(IN) -> O_B。

然后，我们对System_A进行相同的操作以生成自己的输出O_A：

System_A(IN) -> O_A。

在任何时候，都假定O_B是预期输出，而O_A是观测/实际输出。暗示O_B是“金”源（事实）。但是，我们遇到了一系列问题。

• O_A是错误的，O_B是正确的
• O_A是正确的，O_B是正确的
• O_A错误，O_B错误
• O_A是正确的，O_B是错误的

如果假定O_B永远是对的（或期望的是什么），谁来决定对的呢？好吧，事实证明，在人工检查和分析中，O_B有时（或经常）是错误的。使用此过程，一切都会通过质量检查，真正的用户会抱怨，我们回到发现O_B毕竟是错误的。

问题是这样的：创建“测试系统”以测试实际系统是否是错误的做法？

• 湿滑的斜坡呢？然后，我们不能说我们需要另一个系统来测试“测试系统”吗？
• 成本绝对是高得让人望而却步，因为开发人员现在需要学习至少2个代码库，而System_B的复杂性可能大于System_A。我们如何量化拥有System_B对组织有多好？
• 创建System_B的最初“诱人”原因之一是“自动化”测试。现在，我们为完全自动化而感到自豪（因为System_B生成输入以引导使用其自身也生成输出的过程）。但是我认为我们以一种无法量化的方式造成了更大的伤害并引入了更多的复杂性。质量检查的工作是否完全自动化？这个理由足以证明创建并行系统吗？
• 我真正担心的是，即使我们都知道System_B是错误的（经常）。如果System_B擅长处理输入并且其输出是黄金来源，为什么不用System_B替换System_A？为此，没有人能够提供满意的答复。

对此问题的任何指导表示赞赏。

• O_A是错误的，O_B是正确的

修复A

• O_A是正确的，O_B是错误的

修复B

• O_A是正确的，O_B是正确的

希望他们也同意。

• O_A错误，O_B错误

希望他们不同意，所以您会知道要做些什么。

没有任何过程能够抓住一切。当然，您已将代码加倍，但将其想像为O（2n）中的2。一直到集成测试的自动化QA都是一件很了不起的事情。手动测试是创新的障碍。尤其是在需要全面测试的跨领域变更中。同样，由于您将让不同的程序员实现相同的事情，因此您可以使其竞争。

应该由不同的人来增加获得不同错误的可能性。我不建议您通过应对系统A来创建系统B。这为您提供了一个重新测试的机会。通过保存O_A的旧副本与新副本进行比较，您可以得到相同的结果。

问题是这样的：创建“测试系统”以测试实际系统是否是错误的做法？

如果是，则所有测试均不正确。

• 湿滑的斜坡呢？然后，我们不能说我们需要另一个系统来测试“测试系统”吗？

是的，我们可以争论。我们将这个第三系统称为system_A。：P

• 成本绝对是高得让人望而却步，因为开发人员现在需要学习至少2个代码库，而System_B的复杂性可能大于System_A。我们如何量化拥有System_B对组织有多好？

根据支付给我们使用nerf枪支的满意客户的数量。您已经摆脱了手动测试的麻烦。您已经创建了一些东西，每当它被发现一个bug时，它的有用性就会得到证明。早期发现bug的费用远远少于后期报告的bug。

• 创建System_B的最初“诱人”原因之一是“自动化”测试。现在，我们为完全自动化而感到自豪（因为System_B生成输入以引导使用其自身也生成输出的过程）。但是我认为我们以一种无法量化的方式造成了更大的伤害并引入了更多的复杂性。质量检查的工作是否完全自动化？这个理由足以证明创建并行系统吗？

System_B的复杂性与System_A完美隔离。向System_A添加功能并不困难，因为System_B存在。实际上更容易，因为System_B使他们有信心快速前进。

• 我真正担心的是，即使我们都知道System_B是错误的（经常）。如果System_B擅长处理输入并且其输出是黄金来源，为什么不用System_B替换System_A？为此，没有人能够提供满意的答复。

这是错字吗？System_B通常是错误的，所以这是您要用来取代System_A的黄金标准吗？

我将假设您的意思是System_A通常是错误的。哪一个最经常出错并不重要。哪一个错是需要工作的那一个。这些系统不能决定是非，开发人员可以决定。测试所做的是产生分歧，这意味着不正确。开发人员知道这是什么。请记住，这里没有生产黄金标准。只有同意或不同意。意见分歧要求工作要做。这项工作的一部分是弄清楚在哪里。

当您拥有一个供客户实际使用的生产系统时，绝对必须有一个质量检查系统来验证错误修正和新功能。从质量的角度来看，它应尽可能接近生产系统的副本。这样，如果您确保生产系统及其质量检查系统相同，那么在一个系统上起作用的应该在另一个系统上起作用。如果不是这种情况，则系统不相同，输入不相同，和/或输出被误解。

如果您的系统是关键任务并且需要24/7可用，那么这会变得更加困难。这样一来，您就无法没有QA系统，这是因为您必须绝对减少生产系统的停机时间。如果是24/7全天候系统，那么非常推荐您使用生产系统的精确副本。

现在，这种方法的明显缺点是成本。它使硬件成本增加了一倍，并增加了部署和维护成本。另外，必须实现从生产系统到QA的连续数据复制，以使由于系统使用的数据不同而导致产生不同结果的可能性降至最低。

通常，相对于生产系统，通过缩小QA系统的某些组件，可以找到一些平衡，以便可以正确测试大多数功能。这些通常是冗余服务器，服务器大小或工作站数量。但是，根据我的经验，总是总是在缩小尺寸的零件中发现一些错误，然后再生产该问题并实施修复程序，同时又将生产系统中的停机时间保持在最低限度，这是一场噩梦。

每当您测试系统时，都必须知道预期的结果是什么。

让系统产生预期结果的问题显然是“我如何测试该系统”

即便如此，看到人们使用电子表格生成预期结果集也并不常见。

归根结底，您确实需要人工来解释系统的要求并手动产生预期的结果。如果您有系统，并且仅检查差异，那么您将跳过测试。