如果我有两个团队，一个开发团队和一个QA团队，让QA团队而不是开发团队进行代码审查是否合适？也许除了开发团队之外？各个公司之间是否有所不同？这只是语义问题吗？
#1 楼
任何人都可以执行代码审查。以我的经验，在开发人员和测试人员之间进行代码审查时，我发现了很多好处-测试人员对代码的看法与开发人员的看法不同（就像他们对功能和特性的看法稍有不同。）从更高层次上讲，软件创建是一个协作过程-我建议不要担心由谁来做，而要更多地关注工作的完成方式。代码评论在这里。
评论
我正在这里工作的两次查询之间阅读本文，我真的很喜欢-我特别喜欢不审查所有内容的想法，直觉是审查决策标准的一部分！只要您在流程中注入常识（或不寻常！），这都是胜利。
–corsiKa♦
2011年6月9日19:38
我在此使用@glow。优秀的纸张。我已经在办公室各处共享了该论文，并将其发送回了我以前的工作地点。
– TristaanOgre
2011-6-10 18:36
@Alan，您在论文中写道“ [...]在最初的步骤中我们没有发现很多错误”。为什么会这样呢？错误数量增加了吗？测试人员是否找到了开发人员往往不会发现的错误？
– dzieciou
2012年12月2日于16:48
从附录中的清单中，我可以得出结论，在代码审查期间，测试人员不仅在寻找错误，还寻找技术债务问题。
– dzieciou
2012年12月2日于17:02
@dzieciou-主要是学习曲线-测试人员花了一段时间才发现规律性问题。
–艾伦
2012年12月3日，7：59
#2 楼
代码审查属于“静态测试”类别，这是质量检查活动的一部分。它是唯一能够及早发现SDLC中的错误的方法。它可以评估代码和算法的合理性，而无需在计算机上实际执行任何操作，因此可以进行“静态”测试。 DEV在以下审查活动中：需求审查
可行性审查
根据标准审查屏幕布局
分析程序的控制和数据流
对作为产品一部分的预期功能进行现有检查
评论
我们都知道，越早发现错误，修复起来越便宜！
– DuncN
11年7月22日在21:26
#3 楼
质量保证（Quality Assurance，QA）是一个时髦的词，它取决于您的环境可能意味着多种情况。在某些站点中，质量检查等同于软件测试人员及其职责。在使用这种质量检查方式的网站中，否，代码审查不是质量检查流程的一部分，因为它们是由开发人员针对开发人员代码执行的，并且不涉及软件测试小组。质量检查小组是与开发人员和软件测试人员分开的一个小组，负责监督开发过程中为管理和确保高质量产品而制定的所有部分。在这种情况下，代码审查是一个质量检查流程，因为质量检查小组会监视并确保在适当的时间执行代码审查。他们不会自己检查代码，但这是开发人员执行的质量检查任务，以满足SDLC的质量检查标准。
评论
我不同意质量检查是一个时髦的词。它具有非常具体的含义和范围。但是，大多数声称负责质量检查的部门或个人都没有达到质量保证的定义。
– Jim Rush
2011年7月21日在21:37
@吉姆·拉什（Jim Rush）-同意。我测试软件。我对影响产品质量的外部因素了解不足，无法对此发表评论。
– DuncN
2011年7月22日在21:27
#4 楼
我已经与众多开发人员，测试人员和经理进行了交谈。当您说代码审查实际上是PEER审查时，您是对的。我个人认为这些主要是开发人员的活动（与团队其他成员经常与其他测试人员分享我的测试策略和案例的相同原因）。但是以我自己的经验，同行评议通常会在进入测试环境之前成为入学标准的一部分。这就是说，在测试过程中配备测试人员/质量保证分析师会带来很多好处代码审查。我们并不是一直在看代码本身，有时会问为什么为什么一段代码是用一种方式而不是另一种方式编写的（对我们来说也是很好的学习经验）。这也是让某人指出一些开发人员可能不知道或没有想到的业务逻辑的好时机。如果在此阶段发现了更多的错误，对每个人来说都比较容易。不要只局限于开发人员或质量检查人员。如果有BA / PM / UAT / BA / PM / UAT /其他人可以理解部分代码，可能会有一些不错的输入，请不要排除它们，但不要使其过大，以致无法相对快速地完成操作。 br />
#5 楼
顾名思义，代码审查显然是一种质量检查。但是，质量检查通常与开发分开进行划分，并使用错误跟踪和测试跟踪软件及方法来确定和评估其过程。代码审查的好处在于，它发生在开发周期中，通常，发现的任何错误或其他问题都会在开发过程中得到纠正，而不是作为错误进行跟踪或在QA周期中进行修复。这避免了将问题传播到产品开发的下一阶段的开销，从而节省了时间和金钱，并提高了质量（后者是因为在代码审查期间发现的缺陷不一定在测试中发现）。完全相同的进行质量检查的哲学，从而在现场不会发现问题，这在客户满意度，重新发布修订等方面的成本很高，同样可以应用于开发过程中的代码审查和缺陷修复在代码审查中是否包括质量保证人员确实取决于所审查的内容。显然，如果正在审查代码并且他们不是程序员，那可能没有多大意义。但是这些单元测试是否与测试有关？或者，让某个来自黑匣子立场的人来查看代码可能会很有用。可以检查的代码和其他非代码文档类型非常多样，开发环境和正在开发的产品也很多种，因此没有一个正确的答案可以解决这个问题。最好只是尝试新方法并启发式地确定哪种方法最适合您的开发过程。
评论
我喜欢这篇文章：区分开发代码和测试代码（即使它们都是由开发人员编写）也很重要。+1
–corsiKa♦
2011年7月22日17:52
#6 楼
这取决于组织。为了使代码审查有效，需要满足一些条件。显然，审阅者需要熟练地阅读代码并确定潜在的问题。不太明显但同样重要的是，审阅者和开发者需要融洽的关系，以促进建设性的批评。如果不满足这些条件，则代码审查可能会浪费时间，甚至更糟，这是破坏工作关系的破坏性过程。审稿人与开发人员的建设性配对可能在开发人员小组内或在质量检查和开发人员之间；它只取决于组织和个人。#7 楼
我认为，如果质量检查小组在技术上健全，我们将获得可观的收益。我引用了我的经验。以黑匣子方式测试系统-您将专注于用户方案，涵盖最大的最终用户方案关于日志记录方面，系统的工作方式以及可能发生故障的地方。混合使用黑盒和一些白盒进行测试是正确的选择
QA团队可能不会审查编码准则或提供技术建议，但他们可以明确地提出要点-系统在此方面的表现如何特殊情况？在这种情况下是否会记录故障？重试逻辑在这里如何工作？
如果不进行代码审查，我至少希望质量保证团队成为设计审查的一部分。
#8 楼
从理论上讲，这取决于各个质量检查人员的能力。如果审查代码的质量检查人员能够测试应用程序而不会因其详细的实现知识而造成任何偏见，那就太好了！实际上，如果质量检查人员正在查看代码，则他/她正在查看实施细节。对如何实现代码的太多了解可能会产生强烈的偏见。质量检查的优势之一是能够将业务和技术知识结合起来，并查看是否达到了良好的平衡。同样的问题可能是“质量检查是否应成为定义业务需求的团队的一部分？”
我曾经在这两种环境中工作过，个人认为代码审查最好不是质量检查的一部分。
评论
+1用于描述测试人员进行代码审查的缺点。解决方案是仅支付此价格的一半。拥有进行代码审查的测试人员和仅进行黑盒测试的人员。
– dzieciou
2012年12月4日在18:08
#9 楼
尽可能接近您的问题“代码审查是否被认为是QA的一部分？”，我想您正在尝试确定哪个团队（QA与Dev）负责“代码审查”。在我看来，他们两个都应该解决这个问题，但是质量检查应该解决这种情况。作为程序员任务的一部分，绝对是开发活动。这是与所需功能编程相关的手动过程。它是在新的/修改的源代码上完成的，因此在此过程中范围有限。无论如何，您（QA）都没有完成工作的任何证据（经过审查的代码？结果吗？）该团队应负责获得度量标准的度量并监视编程标准的遵从性。因此，质量检查团队应制定行动计划，以改进度量标准并减轻检测到的违规行为（下一个版本开发投入）。环境（例如，持续集成）。但是质量检查人员具有领导开发团队的主导作用：制定并确定行动计划的优先级
定义质量模型
管理质量门（软件认证）
评论
欢迎使用SQA。您的建议并不能使SCA处于质量检查之下-IMHO，SCA应该由开发人员完成，目的是在发布之前而不是第二次迭代时将违规次数最小化，我对此并没有信心。
–安德鲁（Andrew）
2012年12月4日13:40
该提议完全没有冲突。我的意思是，开发人员当然应该在发布之前将违规行为减到最少...谁负责接受/拒绝发布？平均而言，SQA团队应分析几个指标：测试结果，违规报告...
–erDave
2012年12月4日14:32
顺便说一句...谢谢您的惠顾：)只是要指出，重要的是要澄清我们在谈论SQA团队时所了解的内容...我不是指“测试人员”，而是负责人分析测试结果和分析代码结果，以确定是否应发布所提供的软件
–erDave
2012年12月4日14:56
@erDave，关于澄清：在这里，“静态代码分析”是什么意思？ “完整的应用程序源代码”是什么意思？
– dzieciou
2012年12月4日在18:03
@erDave：我也不太了解QA如何为静态分析结果定义行动计划。你能举个例子吗？
– dzieciou
2012年12月4日在18:04
#10 楼
通常答案只能是-这取决于...“代码审查”一词本身就是一个广泛的概念。它可以包含相当简单的“此代码闻到了吗？”是否一直检查到对硬实时系统进行高度详细的分析？甚至可以用另一种名称进行架构审查。
这也取决于团队中的自我。一些开发人员会认为，质量检查人员应该审查自己的代码是一种极大的侮辱，而那里的一些质量检查人员却对自己的角色感到惊讶，但会在尝试捕获块的视线下逃脱。
但是，经过所有的模棱两可之后，是的，质量检查人员和其他人员参与了“代码审查”。我当然会提倡质量检查人员/测试人员参与审查单元测试。一些开发人员在这方面需要比其他开发人员更多的帮助。通过帮助他们理解单元测试并编写更好的测试，您也将有所帮助。
#11 楼
我去过QA不参与代码审查的地方，而在QA确实参与的地方，在许多地方，正在实现不同的目标。有些就像代码审查一样，我们查看代码并提出问题，询问有关事物编码的方式。在另外一些案例中，我们还进行了代码演练，这也使开发人员承担了额外的任务，以解释他们对代码的处理方式的想法，这带来了开发人员和质量检查人员的问题，一些开发人员说，一般情况下都不会同行评审;至少在那种环境下。有些评论并不总是能得到质量检查的评论，但至少可以使人们更好地了解事情在幕后的运作方式。了解更多信息和了解从来都不是坏事。
评论
不幸的是，最后一句话并不总是正确的。我们的业务分析员拥有对数据库表及其布局的完全访问权限，并可以决定要去哪里。现在，如果他们甚至拥有更多的信息和理解，那就太好了，但是他们没有，最终他们获得的信息不足以认为他们知道发生了什么，从长远来看最终会使情况变得更糟。
–corsiKa♦
2011年6月10日20:31
@corsiKa，能否举个例子说明这使“从长远来看，情况会变得更糟”？
– dzieciou
2012年12月5日7:55
评论
当您说某项内容属于质量检查或不属于质量检查时，您能否描述您的意思？您是在询问组织边界，某人应该具备的工作类别或其他目的吗？@ user246我澄清了我的总结。如果有两个团队（开发人员和质量检查团队），那么质量检查团队而不是开发人员团队进行代码审查是否合适？还是开发团队应该做的事情，即使它有助于“质量保证”的概念。