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