java如何度量健壮性？

Question

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

一个质量属性是“鲁棒性”。我想以某种方式确保这一点，但我找不到任何有用的信息，如何以客观的方式做到这一点

是否有任何静态或动态指标可以衡量稳健性？也就是说，像单元测试覆盖率一样，有没有一种方法可以保证这样的健壮性？如果是这样，有没有（免费）工具可以做这样的事情

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

最后但并非最不重要的一点是，如果您对我洗耳恭听有任何想法，也许还有其他方法可以确定健壮性

先谢谢你

Answer 1

健壮性是非常主观的，但是您可以看看FingBugs、Cobertura和Hudson，如果将它们正确地结合在一起，可以让您随着时间的推移产生安全感，即软件是健壮的

Answer 2

简而言之，答案是“不”。稳健可能意味着很多事情，但我能给出的最佳定义是“在任何情况下都能正确执行。”如果您向一个健壮的web服务器发送一个错误的HTTP头，它就不会崩溃。它应该返回正确的错误类型，并且应该以可配置的方式将事件记录在某个地方。如果一个健壮的web服务器运行很长时间，它的内存占用应该保持不变

使系统健壮的很多因素是它对边缘情况的处理。好的单元测试是其中的一部分，但很可能不会对系统存在的任何问题进行单元测试（如果这些问题是已知的，开发人员可能会修复它们，然后才添加测试）

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

然而，有各种各样的检查可以作为系统健康状况的粗略的数字估计。单元测试覆盖率是一个相当标准的覆盖率，它的兄弟节点、分支覆盖率、函数覆盖率、语句覆盖率等也是如此。另一个不错的选择是FindBugs之类的“lint”程序。这些可能表明存在潜在的问题。开源项目通常根据提交或发布的频率和最近发布的版本来判断。如果一个项目有一个bug系统，您可以测量修复了多少bug以及修复的百分比。如果您正在测量的程序有一个特定的实例，特别是一个具有大量活动的实例，那么MTBF（平均无故障时间）是一个很好的健壮性度量（参见Philip's Answer）

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

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

Answer 3

您可以将mean time between failures作为稳健性度量。问题在于，这是一个难以测量的理论量，特别是在您将产品部署到具有真实负载的真实情况之前。部分原因是测试通常不涉及现实世界的可伸缩性问题

Answer 4

在我们的模糊化书籍（由Takanen、Demot、Miller撰写）中，我们有几个章节专门介绍负面测试中的度量和覆盖（健壮性、可靠性、语法测试、模糊化、同一事物的许多名称）。我还试图在这里总结我们公司白皮书中最重要的方面：

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

其中的片段：

---

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

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

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

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

---

我希望这是有帮助的。我们还研究了其他指标，如查看代码覆盖率和其他或多或少无用的数据度量是一个很好的论文主题。给我发电子邮件到ari。takanen@codenomicon.com如果您有兴趣访问我们在这个主题上的广泛研究

Answer 5

You could look into mean time between failures as a robustness measure.

“MTBF”的问题在于，它通常以正流量进行测量，而故障通常发生在意外情况下。它没有给出任何鲁棒性或可靠性的指示。无论一个网站是否总是在实验室环境中运行，如果它有弱点，它仍然会在互联网上被黑客攻击