如何衡量健壮性？

Question

我正在写一篇关于保证产品质量的论文。本例中的产品是一个网站。我已经确定了几个质量属性和度量技术。

一个质量属性是“健壮性”。我想以某种方式保证这一点，但我找不到任何有用的信息来客观地做到这一点。

是否有任何静态或动态指标可以确保健壮性？也就是说，就像单元测试覆盖率一样，有没有办法来保证健壮性呢？如果是这样的话，有没有(免费的)工具可以做这样的事情？

有没有人有使用这种工具的经验？

最后但并非最不重要的是，也许还有其他方法来确定健壮性，如果你对此有任何想法，我洗耳恭听。

在此之前非常感谢。

Answer 1

嗯，简短的回答是“不”。健壮可以意味着很多事情，但我能给出的最好定义是“在每种情况下都能正确执行”。如果你发送一个错误的HTTP报头到一个健壮的web服务器，它应该不会崩溃。它应该准确地返回正确的错误类型，并且应该在某个地方记录事件，也许是以一种可配置的方式。如果一个健壮的web服务器运行很长时间，它的内存占用应该保持不变。

使系统健壮的很大一部分原因是它对边缘情况的处理。好的单元测试是其中的一部分，但很可能不会有针对系统存在的任何问题的单元测试(如果知道这些问题，开发人员可能已经修复了它们，然后才添加了测试)。

不幸的是，要衡量一个任意程序的健壮性几乎是不可能的，因为要做到这一点，你需要知道这个程序应该做什么。如果你有一个规范，你可以编写大量的测试，然后将它们作为测试运行在任何客户端上。例如，查看Acid2浏览器测试。它以一种简单、可重复的方式仔细地衡量任何给定的web浏览器符合标准的程度。这是你能得到的最接近的结果，人们已经指出了这种方法的许多缺陷(例如，程序崩溃更频繁，但根据规范做一件额外的事情更健壮吗？)

但是，您可以使用各种检查作为对系统健康状况的粗略、数字估计。单元测试覆盖率是非常标准的，它的兄弟程序、分支覆盖率、函数覆盖率、语句覆盖率等等也是如此。另一个很好的选择是像FindBugs这样的"lint“程序。这些可以指示潜在的问题。开源项目通常通过提交或发布的频率和最近发布的频率来判断。如果项目有bug系统，您可以测量修复了多少bug和百分比。如果您正在测量程序的特定实例，特别是具有大量活动的实例，MTBF (平均无故障时间)是一个很好的健壮性度量(请参阅Philip's Answer)

然而，这些测量并不能真正告诉你一个程序有多健壮。它们仅仅是猜测的方式。如果很容易确定一个程序是否健壮，我们可能只需要让编译器检查它。

祝你的论文好运！我希望你能想出一些很酷的新测量方法！

Answer 2

您可以将mean time between failures视为一种健壮性度量。问题是，这是一个很难测量的理论数量，特别是在您将产品部署到具有真实负载的实际情况之前。这样做的部分原因是，测试通常不会涵盖实际的可伸缩性问题。

Answer 3

在我们的fuzzing一书(由Takanen，DeMott，Miller)中，我们有几个章节专门介绍负测试中的度量和覆盖率(健壮性，可靠性，语法测试，模糊，同一事物的许多名称)。我还试着在这里总结了我们公司白皮书中最重要的方面：

http://www.codenomicon.com/products/coverage.shtml

来自那里的代码片段：

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

第一个覆盖率分析方面与攻击面有关。测试需求分析总是从识别需要测试的接口开始。不同接口的数量和它们在不同层中实现的协议对fuzzers提出了要求。根据安全要求，每种协议、文件格式或API都可能需要自己类型的模糊器。

第二个覆盖度量与fuzzer支持的规范相关。这种类型的指标很容易与基于模型的模糊器一起使用，因为该工具的基础是由用于创建模糊器的规范形成的，因此它们很容易列出。基于模型的fuzzer应该涵盖整个规范。然而，基于突变的模糊器不一定完全覆盖规范，因为实现或包括规范中的一个消息交换样本并不能保证覆盖整个规范。通常，当基于突变的fuzzer声称支持规范时，这意味着它可以与实现规范的测试目标互操作。

特别是对于协议模糊，第三个最关键的指标是所选模糊方法的状态级别。完全随机的fuzzer通常只测试复杂有状态协议中的第一个消息。您使用的模糊方法对状态的感知越强，fuzzer在复杂协议交换中的程度就越深。对于模糊工具来说，有状态是一个很难定义的要求，因为它更多地是用于定义所使用协议模型的质量的度量，因此只能通过运行测试来验证。

我希望这能对你有所帮助。我们还对其他指标进行了研究，例如查看代码覆盖率和其他或多或少无用的数据。;) Metrics是一个很好的论文主题。如果你有兴趣访问我们关于这个主题的广泛研究，请给我发电子邮件到ari.takanen@codenomicon.com。