白盒测试方法静态分析_静态分析不是开发测试

白盒测试方法静态分析

我不断收到来自静态分析供应商的电子邮件，告诉我为什么我需要购买他们的技术。 最近，我收到了一封电子邮件，说明我的团队如何使用静态分析工具来完成令人印象深刻的事情，例如“在数分钟内测试数百万条复杂的代码行”。

等一下，pardner。 对您的代码运行静态分析工具以强制实施良好的编码习惯，并检查常见的编码错误和违反安全编码规则的行为，这是一个好主意。 但这不是测试，也不是测试的替代品。

适用于Java开发人员的 Coverity ， Klocwork Insight或Klocwork Solo等静态分析工具， Findbugs ， HP Fortify ，IBM的Software Analyzer ，Microsoft的FXCop和Veracode的按需静态分析检查距编译器和IDE为您检查的内容有所提高（尽管类似IDE IntelliJ IDEA包括一组很好的内置静态分析代码检查器。 这些工具应该是您的开发和持续集成环境的一部分。

它们可以快速有效地发现大型代码库中常见的编码错误和不一致之处。 容易遗漏且难以测试的错误，通常易于修复。 这使代码复审更加高效和有效，因为它使复审者可以专注于更高级别的问题，而不是低级的正确性。 他们可以确定代码中需要重构和简化的区域，以及可能需要更多测试或更深入审查的代码区域，尤其是如果该工具在已经“起作用”的代码中发现问题时。

但是静态分析与测试不一样，或不如测试

静态分析工具无法测试代码以验证其是否可以执行预期的工作。 客户要求的功能全部存在，并且业务逻辑正确（单元测试，功能测试和验收测试）。 他们无法检查模块的接口及其行为是否正确（组件级测试），或者系统的较大部分与其他系统一起正常工作（系统测试和集成测试）。 还是系统将承受负载（性能和压力测试以及浸泡测试），或者它是否容易受到安全攻击（笔测试），或者人们可以真正理解如何使用它（可用性测试）。 静态分析工具，即使是最好的分析工具，也仅限于发现“与代码相关的缺陷的狭窄范围” 。

我感谢静态分析工具供应商希望找到销售其解决方案的新方法。 也许这就是为什么Coverity现在将其静态分析工具集称为“行业首个开发测试平台”的原因 。 他们的信息似乎是开发人员不会测试他们的代码，也不会修复“由于组织孤岛和优先级冲突”而导致测试人员发现的错误。 因此，静态分析必须填补这一可见的空白。

通过改善与Eclipse和Visual Studio等开发工具的集成并提高静态分析检查的运行速度，Coverity使开发人员可以更轻松地尽早发现并修复更多的编码错误-很好。 但是更好的包装和工作流程以及更快的性能并不会改变该工具的实际功能。

开发测试或开发人员测试

运行静态分析工具不是“开发测试”。 开发测试或开发人员测试是开发人员用来测试自己的代码以查看其是否起作用的方法：在调试器中执行代码，并确保其按预期运行，然后对其进行性能分析，以确保性能不受影响糟透了，编写自动化的单元测试和组件测试，以确保代码能够完成其应有的功能。

将静态分析工具与其他自动化测试工具混淆是一个坏主意。 它歪曲了静态分析工具的功能。 它可能使人们相信静态分析可以代替测试。 静态分析专家，FindBugs之父Bill Pugh 明确表示，虽然静态分析工具确实可以工作，但“发现比发现静态分析更有价值”对于发现错误。 而像White Hat Security的Jeremiah Grossman这样的安全专家则认为静态分析足以检查系统中的安全性错误或其他类型的错误。

静态分析工具变得越来越好，更容易使用，它们变得越来越快，更准确，并且比几年前减少了更少的误报。 如果每个人都可以找到适合自己且负担得起的工具，则每个人都应该使用它们。 例如，如果您在Java商店中，没有任何理由不至少使用Findbugs –它是免费的并且可以使用。 我的团队在开发和持续集成的不同阶段使用了多种不同的静态分析工具，因为不同的工具会发现不同类型的问题，并且某些工具需要更长的运行时间。 这些工具会发现真正的错误和编码问题。 但是这个市场有太多的炒作。 在软件测试领域，静态分析工具并不是“统治者” 。

参考： 静态分析不是 JCG合作伙伴 Jim Bird在Building Real Software博客上的开发测试 。

翻译自: https://www.javacodegeeks.com/2012/01/static-analysis-isnt-development.html

白盒测试方法静态分析