让我认为这并不常见的唯一原因是，因为测试工具大部分时间都在使用在
git diff中难以比较的文件。但我想知道是否还有其他原因。而且我相信我们不应该仅仅因为我们的工具不使用看起来像代码的文件而避免开发人员的良好做法。#1 楼
只需添加答案即可，同行评审不仅仅涉及代码评审。它有助于：识别代码逻辑方面的改进
识别测试中的改进或遗漏的应用程序逻辑
。
确定更简单的测试方法以进行改进测试覆盖率
确定解决问题的更好方法。
等等。
我们在编写代码时都会遇到思维障碍和作者偏见，所以有第二意见总是很高兴。它不会使我们看起来很糟，但是它提供了学习的机会。例如，在最初的编码时代，我曾经写过专注于功能的测试。例如，对于支付系统，我将测试字段是否针对无效输入引发错误并显示针对有效输入的正确消息。但是我错过了验证付款是否适用于所有有效输入的功能，而我只用一个有效输入进行了测试，并假设其他所有功能也都可以使用。
我只是在验证消息功能而未验证实际流。
在代码审查期间，一位同事建议测试所有有效输入的端到端流，然后猜测！！！！系统因一个极端情况而失败。
#2 楼
根据我的经验，对测试用例进行同行评审（复审测试设计本身）很有用。如果要自动化e2e测试，还应该复审代码。
如果您想要一个好的测试自动化项目-您应该像对待其他任何软件项目一样对待它，并应用所有最佳实践，包括代码审查。
问题是，因为您正在处理代码（无论其意图是什么，测试自动化框架，企业应用程序或pet项目），所以如果要避免出现常见问题，则应遵循行业惯例，因为无论发生什么事情都可能发生代码作者的角色-开发人员，QA，DevOps和BA。
查看测试可以使您发现问题并轻松解决。
评论
您是否解决过非纯代码的工具文件扩展名？就我而言，我们使用ReadyAPI和JMeter，并且都使用xml文件，很难与diff进行比较。我感到很难更改公司的工作流程，因为我有必须更改所有工具的感觉。但是，如果您遇到问题，我会很好奇如何处理从与版本控制工具不太兼容的工具中进行切换。
–冰焰
20年6月15日在8:11
不要让工具来驱动流程，而要根据流程来调整工具。我使用GitLab / BitBucket / Azure DevOps等基于Web的平台执行（或执行）代码检查。更改在合并请求中列出。对于文件本身-可能存在问题，因为更改可能未正确列出。不幸的是，我没有一个简单的解决方案。这是使用不允许我们轻松查看更改的工具的缺点。
– 501NotImplemented
20年6月15日在8:35
换句话说，无法查看文件中的更改可能是考虑从现有工具集迁移到替代工具的重要考虑因素。但是，这一事实需要仔细评估。
– 501NotImplemented
20年6月15日在8:38
#3 楼
但是我想知道是否还有其他原因。
我可以想到一些我个人遇到的问题：
预算紧张，因此即使从长远来看会损害项目，商务人士也不会给您必要的时间进行审核，并且您会连续数周进行解释；您也许可以加班半年，但他们没有精力，或者您意识到每周工作70个小时会犯更多错误，因此您停止这样做
没有足够的人：小公司可能只对几个项目使用一个测试人员，所以甚至没有其他人可以审查您的测试项目
忙碌的人：即使您在公司中有其他测试人员，他们也会忙于自己的测试项目，因此当业务人员四处走动时，他们不太可能花时间进行审查，不知道我们何时从积压中交付另一个功能
您的项目中没有足够的人：这与上一点是一致的。如果您在敏捷团队中工作，则很有可能，您是某个项目的唯一测试人员，因此，没有其他测试人员知道您的项目处于同一级别，并且在同一级别上，该级别可以审查您的工作/>这些主要是组织和人员问题，但我不会低估它们。以我有限的个人经验，在我工作过的每家公司中，我都至少遇到过其中一种或几种。
#4 楼
“质量是免费的，但仅限于那些愿意为此付出高昂代价的人。” – T. DeMarco和T. Lister
作为一个从事十年以上测试审查的人，在测试审查的“为什么”和“什么”方面会增加几点：
清晰度：首先，测试实际上应该只测试应该测试的内容，并清楚地报告。每个测试都应该清楚地说明到底是什么，而不是什么。 />
可读：代码应可读；即使没有任何评论，只要阅读它就应该可以理解。如果有人要解释，则说明它的设计不正确。
可维护：如果存在错误修复/功能，如果AUT发生变化，则应在一段时间内轻松更改多次。如果在应用程序中进行一次适度的更改需要在自动化的多个位置进行较大的更改，则效率不高（DRY）。
评论
审查的技巧是找到尚未完成的工作，然后找到已完成工作的小改进。很少有人拥有这种技能+1好的问题，是的，出于与开发代码相同的原因，我们应该以正确的方式验证它是否确实在按预期进行。