Java理论与实践:均衡测试,第1部份:不要仅编写测试,还要编写bu[Java编程]

关于很多团队来说,单元测试目前是开辟历程的一个主要部份;JUnit 之类 的框架可以举行无损测试,固然我们并不喜好它,甘愿为某些 代码编写某些 测 试.单元测试运行效率很低,只能测试单个代码片段,并且,普通情形下,测试 代码的重用性普通很也低 —— 昨天为组件 A 编写的测试不能很好地用于测试 组件 B（示例代码除外）.

典型的单元测试场景

在发现 bug 时,要做的第一件事是什么?您大概只是想去修复它,但是,在 长时间的运行中,这不是一个最有效的办法.在很多开辟部门中,处理 bug 的 历程以下:

针对 bug 编写测试用例

确保测试用例在碰到 bug 时运行失利

修复 bug

确保测试用例通过

确保其他测试套件仍能通过

查抄改正和测试用例,形成版本掌握

将改正记录在 bug 跟踪系统中

固然此办法在短时间内比仅修复 bug 要多做很多工作,但它供应了很多更有价 值的东西:得到修复 bug 的更多信心,因为您已经对它举行了测试;得到 bug 将不会再呈现的更多信心,因为测试用例是回归测试套件的一部份.在版本掌握 系统和 bug 跟踪系统之间,还可以得到一个记录,该记录描写了 bug 是什么以 及若何修复它 —— 这是非常有效的信息,其他人会从中受益.

假如进取心较强,那么可以考虑一下 bug 是怎样呈现的,并在其他位置查找 同一错误.假如在别处发现同一错误,那么可以对这些 bug 举行测试和修复. 单元测试作为质量管理工具的主要弱点是每个测试用例只能测试一个代码片段. 因为测试用例是专为每个组件和每个潜在错误情势计划的,所以只有编写充足多 的单元测试才能测试大量的产品,这非常耗时并且代价昂扬.

QA 经济

测试是一种基本的质量管理工具,我们知道唯一多组测试用例还不足以找出 复杂软件片段中的全部 bug.事实上,关于任何优异程序而言,“查找全部 bug ” 是不大概实现的目标.据预计,NASA 向每个开辟人员供应了 20 个测试程序 （大大超越任何商业实体）来负责质量评价 (QA) —— 但软件仍有缺陷.因此 ,质量评价的目标不该是查找全部的 bug,因为这是不大概的.相反,质量评价 的目标应当是提高代码运行杰出的信心,从而最大程度地供应可用资源.

要高效运行质量评价计 (QA),则需求对可用 QA 办法中的可用资源做预算, 这样才能最大限度地提高信心.覆盖范围大的测试套件可以提高我们对代码利用 的信心,因为它举行了一次完好的代码检查.履行两次比履行一次较果好,因为 每次城市发现另一次大概错过的错误.两次一样遵守收益递减法则,所以测试价 值为 X 美圆和代码检查代价为 Y 的 QA 筹划要比代价为 X+Y 的任何一次测试 或代码检查的效果好.

增添静态解析

静态解析是在不运行代码的情形下对其举行解析的历程,它与举行前面的代 码检查时我们履行的操作非常类似,大概与标志可疑构造时 IDE 履行的操作非 常类似.静态解析是增添到 QA 混合（QA mix）中的一项优异技术,因为它擅长 查找其他办法（如测试和代码检查）大概错过的错误.静态解析相对对比简单一 些,不像单元测试那样必须为要测试的每个类重新编写测试,您可以在任何代码 上运行静态解析工具.

FindBugs 是一种开放源码的静态解析工具,它包含用于很多常见 bug 情势 的 bug 情势检测器,令人惊奇的是,即便在测试杰出的软件中,FindBugs 也常 常会发现一些 “沉默” 的 bug,但是单元测试和专业代码检查都大概错过这些 bug.FindBugs 还答应编写新的 bug 情势检测器,并将它们包装为插件,所以 假如一组尺度的检测器不能按您的需求履行,那么您可以很简单地编写自已的检 测器.此扩大性使 FindBugs 成为非常强盛的质量管理工具,因为当发现新范例 的错误时,可以针对该错误编写检测器,并在整个代码基址中搜索该错误.

静态解析的主要作用是解析输出,并肯定报告的条目是真的 bug 还是假警报 .编写的部份优异解析工具或 bug 情势检测器会管理误报率;核心 FindBugs 包中的检测器已经举行了调优,目的是使误报率不超越 50 ％,这样解析输出时 不会有太多的烦麻.（将此阈值与针对 C 的 lint-like 工具举行对比,后者常 常发出很多假警报,利用时相当耗时.）

　　以上是“Java理论与实践:均衡测试,第1部份:不要仅编写测试,还要编写bu[Java编程]”的内容，如果你对以上该文章内容感兴趣，你可以看看七道奇为您推荐以下文章：