代码之家 › 专栏 › 技术社区 › JMarsch

Q/A、发布版本与调试版本以及断言

qa testing

JMarsch · 技术社区 · 15 年前

只是好奇:

当您将软件版本发布到Q/A时,您更喜欢始终使用“发布”版本,还是有时使用调试版本?

我的难题是: 我们喜欢使用断言来捕获不应该发生的条件。

一方面,Q/A在启用断言的情况下测试我们的软件可能很有用,这样如果他们能够创建触发断言的场景,他们就可以向我们报告它。

另一方面,开发人员对断言的编码方式总是存在这样的风险,即它会改变代码的行为。在这种情况下,Q/A应该在禁用断言的情况下测试A构建。

到目前为止,我们一直在对我们的发布版本进行Q/A操作,因为这是将要发布的代码。但是,我正在考虑尝试一种模式,在这种模式中,我们真正早期发布的Q/A将与启用断言的模式相结合。然后,当我们接近发货时,我们将通知他们,他们的构建禁用了断言。

你们觉得怎么样?

5 回复 | 直到 15 年前

Michael 15 年前

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

发布版本必须经过测试,因为它们是实际客户使用的版本。调试版本包含附加断言/验证/跟踪等,在查找不明显的错误时非常有用。

Adrian Grigore 15 年前

在早期的开发阶段使用面向QA的调试构建,稍后切换到发布构建,这正是我们正在做的。

Treb 15 年前

我肯定会建议,不仅要让QA审查发给客户的版本,还要对一些中间版本进行审查,可能每两周或每月审查一次。

这符合在开发过程中尽早检查产品的原则。如果你只是在发布一个版本的时候才这么做,那就太晚了。

我将为他们提供调试构建,为那些早期的测试启用断言。如果代码中有一个断言失败,则会出现错误。要么代码错误,要么断言错误。不管怎样,您都希望QA对此进行测试。

Flash Sheridan 15 年前

我也在早期调试/后期发布;我以前的雇主的官方政策(有时违反,但不是由我)是在测试版之前测试调试版本,之后发布版本。很明显,在发布之前偶尔运行调试构建是值得的,但不幸的政治现实是,如果针对调试构建报告错误,那么许多程序管理器将不会修复错误。

Lucero 15 年前

我们发布带有调试符号的版本,这样性能是正确的(大量使用调试输出和断言可以稍微降低速度),但是如果发生异常,它们仍然报告有意义的堆栈跟踪。

对于异常,我们的一般规则是只捕获我们知道如何处理的异常,这样,如果没有想到什么,它们就会出现在QA中。我公司一般禁止捕杀。