Q / A，发布版本与调试版本和断言

Question

好奇：

当您将软件版本发布到Q / A时，您是否更喜欢始终使用“RELEASE”版本，还是有时使用DEBUG版本？

这是我的难题： 我们喜欢使用Asserts来捕获不应该发生的条件。

一方面，Q / A可能有助于在启用断言的情况下测试我们的软件，因此如果他们可以创建触发断言的场景，他们可以向我们报告。

另一方面，开发人员始终存在以某种方式对断言进行编码以使其更改代码行为的风险。在这种情况下，Q / A应该在禁用断言的情况下测试构建。

到目前为止，我们一直在我们的Relesae版本上进行Q / A操作，因为这是可以发布的代码。但是，我正在考虑尝试一种模式，在这种模式下，我们真正提前发布到Q / A的版本会启用断言。然后，当我们接近发货时，我们将通知他们他们的构建已禁用断言。

你们有什么想法？

Answer 1

我们将两者都发布到Q / A，并且两者都完成测试通过。如果您对自动化测试很重视，那么这就成了运行测试的额外硬件问题。

必须测试发行版本，因为它们是实际客户使用的版本。调试版本包含添加断言/验证/跟踪/等，这对于发现非明显的错误非常有用。

Answer 2

在早期开发阶段使用QA调试版本并在以后切换到发布版本正是我们也在做的事情。

Answer 3

我肯定会主张质量检查不仅要审核发给客户的版本，还要检查一些中间版本，可能每两周或每月一次。

这符合在开发过程中尽早检查产品的原则。如果您只是在发布版本时才这样做，那么你做得太晚了。

我会给他们调试版本，并为那些早期测试启用断言。 如果代码中的断言失败，则表示您有错误。代码错误或断言。无论哪种方式，您都希望QA对此进行测试。

Answer 4

我也早早调试/发布晚了;我以前的雇主的官方政策（有时违反，但不是我）是测试调试版本直到Beta，然后是版本构建。显然值得运行Debug版本，直到你发布，但一个不幸的政治现实是，如果报告针对Debug版本，很多程序管理员都不会修复错误。

Answer 5

我们发布带有调试符号的发布版本，因此性能正确（广泛使用调试输出和断言可以减慢一些事情）但是如果发生异常，它们仍会报告有意义的堆栈跟踪。

对于例外情况，我们只有一般规则来捕获我们知道如何处理的异常，以便在没有考虑到某些事情时它们会出现在QA中。我们公司一般都禁止捕获。