如何衡量鲁棒性？

Question

如何衡量鲁棒性？

javasoftware-qualityrobustness

5

我正在撰写有关产品质量测量的论文。在这种情况下，产品是一个网站。我已经确定了几个质量属性和测量技术。

其中一个质量属性是“健壮性”。我想以某种方式来衡量它，但我找不到任何有用的信息如何以客观的方式进行此操作。

是否有任何静态或动态度量标准可以衡量健壮性？例如，像单元测试覆盖率一样，是否有一种类似于此的方法来衡量健壮性？如果有，是否有任何（免费）工具可以执行此操作？

是否有人有使用此类工具的经验？

最后但并非最不重要的，也许还有其他确定健壮性的方法，如果您有任何想法，请告诉我。

非常感谢您提前的帮助。

- Stefan Hendriks

我认为这个问题根本不特定于Java。它更加普遍和深远。 - Philip Potter

5

迪尔伯特漫画中有一幅关于健壮性的好漫画：http://dilbert.com/2010-02-14/ - Thorbjørn Ravn Andersen

确实，这与Java本身无关。但我的项目与Java有关。 - Stefan Hendriks

@Thor：那是一本很棒的漫画。 - Brandon Yarbrough

5个回答

4

你可以考虑故障间隔时间作为鲁棒性的度量。问题在于它是一个理论量，很难在你将产品部署到真实世界的环境中并承受真实世界的负载之前进行测量。其中一部分原因是测试通常无法覆盖真实世界的可扩展性问题。

- Philip Potter

这是用于生产系统的很棒的统计数据！我要借鉴它并加入到我的答案中去。 - Brandon Yarbrough

偷走本该属于我的声誉？ :P - Philip Potter

1

我发现必须包括恢复的平均时间，才能完整地描绘出全貌。 - Christian

2

在我们的《Fuzzing》一书中（作者为Takanen、DeMott和Miller），我们有几章专门讲述负面测试（健壮性、可靠性、语法测试、模糊测试等）中的度量和覆盖率。此外，我在我们公司的白皮书中总结了最重要的方面，网址如下：http://www.codenomicon.com/products/coverage.shtml。

其中的摘录如下：

覆盖率可以看作是精确度和准确度两个特征的总和。精确度关注协议覆盖范围。测试的精确度取决于测试覆盖不同协议消息、消息结构、标签和数据定义的程度。另一方面，准确度衡量测试能够在不同协议区域内发现漏洞的准确程度。因此，可以把准确度视为异常覆盖的一种形式。然而，精确度和准确度是相当抽象的术语，因此，我们需要查看更具体的度量标准来评估覆盖率。

第一个覆盖分析方面涉及攻击面。测试需求分析始终从识别需要测试的接口开始。不同接口的数量以及它们在各个层面实现的协议设置了模糊测试器的要求。每个协议、文件格式或API可能需要其自己的模糊测试器，具体取决于安全要求。

第二个覆盖度量与模糊测试器支持的规范相关。这种类型的度量标准对基于模型的模糊测试器很容易使用，因为该工具的基础是用于创建模糊测试器的规范，并且它们很容易列出。基于变异的模糊测试器不一定完全符合规范，因为从规范中实现或包括一个消息交换样例并不能保证整个规范都被覆盖。通常，当一个基于变异的模糊测试器声称支持规范时，它意味着它与实现规范的测试目标是互操作的。

特别是关于协议模糊测试，第三个最关键的度量标准是所选模糊测试方法的状态性水平。完全随机的模糊测试器通常只能测试复杂有状态协议中的第一条消息。您使用的模糊测试方法越有状态感知性，模糊测试器就可以深入到复杂协议交换中。状态性是定义模糊测试工具质量的难以定义的要求，因此只能通过运行测试来验证。

希望这对您有所帮助。我们还进行了其他度量研究，例如查看代码覆盖率和其他更或多或少无用的数据。 ;) 度量是论文的好主题。如果您有兴趣获取我们在这个主题上的广泛研究，请给我发电子邮件ari.takanen@codenomicon.com。

- Ari Takanen

确实是非常有帮助的信息。我对任何与那个领域相关的研究都非常感兴趣。不过我有点想知道我们在谈论什么水平的鲁棒性。是代码层面、模块层面还是服务层面？ - Stefan Hendriks

1

鲁棒性是非常主观的，但您可以查看FingBugs, Cobertura和Hudson，当它们正确地组合在一起时，可以让您随着时间的推移获得对软件鲁棒性的安全感。

- cherouvim

0

您可以考虑将故障间隔时间作为强度度量标准。

“MTBF”的问题在于它通常是在正常流量下测量的，而故障往往发生在意外情况下。这不提供任何强度或可靠性的指示。无论一个网站在实验室环境中保持始终开启，如果它有弱点，在互联网上它仍会在一秒钟内被攻击。

- Ari Takanen

不要在新答案中添加评论，而是使用“添加评论”。这样可以防止答案重新排序（根据赞数和发布者声望）。 - Thorbjørn Ravn Andersen

@Thorbjorn：在您获得50点声望之前，您无法留下评论。我认为这是一个愚蠢的要求，但这就是现实。 - Philip Potter

网页内容由stack overflow 提供, 点击上面的

可以查看英文原文，
原文链接

- Brandon Yarbrough · Accepted Answer

嗯，简短的回答是“不”。"Robust"可以有很多含义，但我能想到的最好的定义是“在任何情况下都能正确执行”。如果向一个强大的Web服务器发送一个错误的HTTP头部，它不应该崩溃。它应该返回正确的错误类型，并且应该在某个地方记录这个事件，可能是以可配置的方式。如果一个强大的Web服务器运行了很长时间，它的内存占用应该保持不变。

一个系统的鲁棒性很大程度上取决于它对边缘情况的处理。良好的单元测试是其中的一部分，但很可能系统存在的问题并没有相应的单元测试（如果这些问题是已知的，开发人员可能已经修复了它们，然后再添加测试）。

很遗憾，几乎不可能衡量任意程序的健壮性，因为为了做到这一点，你需要知道该程序应该做什么。如果你有一个规范，你可以编写大量的测试用例，然后对任何客户端运行这些测试用例。例如，看看Acid2浏览器测试。它以一种简单、可重复的方式精确地衡量任何给定的网络浏览器与标准的符合程度。这大概是你能做到的最接近的了，但人们已经指出了这种方法的许多缺陷（例如，一个程序按照规范做了一件额外的事情，但崩溃的次数更多，那它是否更健壮？）

虽然如此，有一些检查方法可以作为系统健康状况的大致数值估计。单元测试覆盖率是一个相当标准的指标，还有它的衍生指标，分支覆盖率、函数覆盖率、语句覆盖率等等。另一个不错的选择是像FindBugs这样的“lint”程序，它们可以指示潜在问题。开源项目通常根据提交的频率和最近的发布来评判。如果一个项目有一个缺陷跟踪系统，你可以测量修复了多少个缺陷以及所占的百分比。如果有一个特定的程序实例需要测量，尤其是一个活动频繁的实例，MTBF（平均故障间隔时间）是一个衡量鲁棒性的好指标（参见Philip's Answer）。

然而，这些测量并不能真正告诉你一个程序有多么鲁棒。它们只是猜测的方式。如果判断一个程序是否鲁棒很容易，我们可能会让编译器来检查。