代码评审通常涉及UAT/QA测试吗？

Question

代码评审通常涉及UAT/QA测试吗？我们正试图建立一个有意义的代码评审过程，并且我们的开发团队之间也出现了分歧。有些人认为审阅者应该签出来自TFS的开发分支，并根据User Story (我们的审查单元)的接受标准实际执行UAT；还有一些人认为，代码是否具有功能的责任是并且应该继续由开发人员负责。

你有什么经验？关于这个问题，有行业标准吗？

Answer 1

一般情况下不会。在我的经验中，代码评审发生在任何开发人员驱动的测试之后。负责的开发人员将对代码进行更改，更新任何单元或集成测试，如果可能的话，通常在本地环境中运行代码。一旦进行了更改，并且至少通过了一些有关更改的基本测试(无论是手动的还是自动化的)，这些更改就可以提交给代码评审。

您的流程是否应该允许作为代码评审的一部分进行质量保证或用户验收测试？这取决于你和你的组织来决定。这似乎增加了很多开销。不同类型的测试所寻找的内容是不同的。相对容易的是运行一些自动化的单元测试，看到测试通过，查看代码的差异，然后看到自动化测试提供了适当的覆盖，只有在两个开发人员理解更改并说更改满足需求的情况下，才会将其交给质量保证或用户。

Answer 2

我不是一个开发人员，而是一个敏捷的教练。所以我的回答是从这个角度出发的。有一种逻辑的方式来思考你的问题，应该回答它，而不需要一个开发背景。我希望你能幽默我。通常，我们看到开发人员在一项功能上工作，假设它是用Java编写的，他或她编写代码和测试(单元，也许是TDD)，并验证代码是否工作并满足需求(或验收标准)。在这一点上，另一个更高级的开发人员执行代码评审。此时，分析是关于结构质量的，并通过代码评审来执行或验证。审查寻找许多偏离代码标准，甚至是代码质量的“先验”视角，这是很难定义的，而且有点“艺术性”。开发人员同意在这些考虑的基础上对代码进行改进，他们已经完成，开发人员再次运行他的测试，并验证代码评审产生的更改没有破坏功能。此时，通过QA和UAT验证代码的功能质量。

如果您更改了订单，让QA和UAT花时间进行测试，然后执行代码评审并对代码进行更改，难道您不需要让QA和UAT再次验证一切都符合他们的规范吗？

你可以走一条捷径，假设什么都没有改变，但是如果你在测试中发现了一些你没有发现的东西，这可能是个大问题。如果你让他们再次重复他们的测试，那是非常低效的，也不会受到赞赏。

所以没有，我从来没有见过我的团队这样做，而且我已经和至少十几个或两个敏捷团队一起工作了8年。

Answer 3

为了增加'no's，我要补充的是名称'Code‘而不是给出它--您正在检查代码，而不是应用程序。在简介中添加测试实际上是有害的--如果作为开发人员，我必须同时包括测试，作为代码检查的一部分，那么我的大部分精力将放在测试结果上，而不是从代码的角度正确地检查代码。这意味着任何目前没有症状的问题都更有可能被忽视。