Questions tagged «integration-testing»

我们团队中的所有程序员都熟悉单元测试和集成测试。我们都与之合作。我们都对其进行了书面测试。我们中有些人甚至对他/她自己的代码感到更加信任。 但是，由于某种原因，编写单元/集成测试尚未成为团队任何成员的反思。当不与实际代码同时编写单元测试时，我们所有人实际上都不会感到难过。结果，我们的代码库大部分没有被单元测试发现，并且项目未经生产就进入生产。 当然，这样做的问题是，一旦您的项目投入生产并且已经正常运行，就几乎不可能获得时间和/或预算来添加单元/集成测试。 我的团队和成员自己已经熟悉了单元测试的值（1，2），但它似乎并没有帮助将单元测试到我们的工作流程自然不会。根据我的经验，强制执行单元测试和/或目标覆盖范围只会导致质量测试不佳，并且会降低团队成员的速度，这仅仅是因为没有自发产生这些测试的动力。同样，一旦压力减轻，就不再编写单元测试。 我的问题是：您是否尝试过任何方法来帮助团队内部建立动力/动力，导致人们自然地希望创建和维护这些测试？

27 project-management  unit-testing  code-quality  integration-testing 

在工作中，我们有一个非常复杂的系统。我们将此系统称为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？为此，没有人能够提供满意的答复。 对此问题的任何指导表示赞赏。

10 unit-testing  testing  qa  acceptance-testing  integration-testing