只是好奇：
当您向 Q/A 发布软件构建时，您更喜欢始终使用“RELEASE”版本，还是有时使用 DEBUG 版本？
这是我的难题：我们喜欢使用断言来捕获不应该发生的情况。
一方面，Q/A 在启用断言的情况下测试我们的软件可能很有用，这样如果他们可以创建一个触发断言的场景，他们就可以向我们报告。
另一方面，开发人员编写断言的方式总是存在改变代码行为的风险。在这种情况下，Q/A 应该在禁用断言的情况下测试构建。
迄今为止，我们一直在我们的 Relesae 版本上运行 Q/A，因为这是将要发布的代码。但是，我正在考虑尝试一种模式，让我们真正早期的 Q/A 版本在启用断言的情况下退出。然后，随着我们接近发货，我们将通知他们他们的构建已禁用断言。
你们有什么感想？
我们将两者都发布给 Q/A，并且两者都完成了测试。如果您对自动化测试很感兴趣，那么这只是一个需要额外硬件来运行测试的问题。
发布版本必须经过测试，因为它们是实际客户使用的版本。调试版本包含额外的断言/验证/跟踪/等，它们在发现非显而易见的错误方面非常有用。
在早期开发阶段使用调试版本进行 QA 并在稍后切换到发布版本正是我们也在做的事情。
我肯定会提倡让 QA 不仅审查发给客户的版本，而且还审查一些中间版本，可能每两周或每月一次。
这符合在开发过程中尽早检查您的产品的原则。如果你只是在发布版本时才这样做，那你就太晚了。
我会给他们调试版本，为这些早期测试启用断言。如果您在代码中有一个失败的断言，那么您就有一个错误。要么代码错误，要么断言错误。无论哪种方式，您都希望 QA 对此进行测试。
我也是 Debug early/Release late; 我以前雇主的官方政策（有时违反，但不是我）是在 Beta 之前测试 Debug 版本，然后再测试 Release 版本。显然，在您发布之前偶尔运行 Debug 构建是值得的，但不幸的政治现实是，如果针对 Debug 构建报告了错误，许多程序管理人员将无法修复该错误。
我们发布带有调试符号的发布版本，因此性能是正确的（广泛使用调试输出和断言可能会使事情变慢一点），但如果发生异常，它们仍然会报告有意义的堆栈跟踪。
对于异常，我们的一般规则是只捕获我们知道如何处理的异常，以便在没有想到的情况下它们会在 QA 中弹出。我们公司一般禁止包罗万象。