如何衡量稳健性？
我正在撰写关于测量产品质量的论文。 在这种情况下，产品是一个网站。 我已经确定了几个质量属性和测量技术。
一个质量属性是“健壮性”。 我想以某种方式告诉我，但我找不到任何有用的信息如何以客观的方式做到这一点。
是否有任何静态或动态指标可以确保稳健性？ 即，就像unit testing覆盖一样，有没有办法可以确保这样的稳健性？ 如果是这样，是否有任何（免费）工具可以做这样的事情？
有没有人有这种工具的经验？
最后但并非最不重要的是，也许还有其他方法可以确定稳健性，如果您对此有任何想法，我会全神贯注。
非常感谢提前。
嗯，简短的回答是“不”。 强大可能意味着很多事情，但我能提出的最佳定义是“在任何情况下都能正确执行”。 如果您将错误的HTTP标头发送到健壮的Web服务器，它不应该崩溃。 它应该返回正确的错误类型，它应该以某种可配置的方式将事件记录到某处。 如果一个强大的Web服务器运行很长一段时间，它的内存占用应该保持不变。
使系统健壮的许多因素是它处理边缘情况。 良好的unit testing是其中的一部分，但很可能不存在系统所遇到的任何问题的unit testing（如果这些问题已知，开发人员可能会修复它们，然后才添加测试） 。
不幸的是，几乎不可能测量任意程序的健壮性，因为为了做到这一点，你需要知道该程序应该做什么。 如果你有一个规范，你可以编写大量的测试，然后作为测试对任何客户端运行它们。 例如，查看Acid2浏览器测试。 它以简单，可重复的方式仔细衡量任何给定的Web浏览器符合标准的程度。 这就是你能得到的尽可能接近，人们已经指出了这种方法的许多缺陷（例如，一个程序会更频繁地崩溃，但根据规范更加强大，还会做一件额外的事情吗？）
但是，您可以使用各种检查作为系统健康状况的粗略数值估计。 unit testing覆盖率非常标准，其兄弟姐妹，分支机构覆盖范围，function覆盖范围，语句覆盖率等等。另一个不错的选择是像FindBugs这样的“lint”程序。 这些可以表明存在问题的可能性。 开源项目通常根据提交或发布的提交频率和最近发布次数来判断。 如果项目有bug系统，您可以测量已修复的错误数量和百分比。 如果您正在测量的程序的特定实例，尤其是具有大量活动的程序，则MTBF（平均故障间隔时间）是稳健性的一个很好的衡量标准（参见Philip的答案 ）
但是，这些测量并不能真正告诉您程序的稳健性。 他们只是猜测它的方法。 如果很容易弄清楚程序是否健壮，我们可能只是让编译器检查它。
祝你的论文好运！ 我希望你能想出一些很酷的新测量！
您可以将故障之间的平均时间视为稳健性度量。 问题在于它是一个难以衡量的理论数量，特别是在您将产品部署到具有真实负载的真实环境之前。 部分原因是测试通常不包括实际可扩展性问题。
在我们的Fuzzing书中（由Takanen，DeMott，Miller撰写），我们有几章专门针对负面测试的指标和覆盖范围（稳健性，可靠性，语法测试，模糊测试，同一事物的许多名称）。 此外，我试图在这里总结公司白皮书中最重要的方面：
http://www.codenomicon.com/products/coverage.shtml
那里的片段：
覆盖范围可视为两个特征，精度和准确度的总和。 精度与协议覆盖有关。 测试的精确度取决于测试覆盖不同协议消息，消息结构，标签和数据定义的程度。 另一方面，准确度衡量测试在不同协议区域内查找错误的准确程度。 因此，准确度可以被视为exception覆盖的一种forms。 但是，精确度和准确度是相当抽象的术语，因此，我们需要查看更具体的度量标准来评估覆盖率。
第一个覆盖分析方面与攻击面有关。 测试需求分析总是通过识别需要测试的接口来开始。 不同接口的数量和它们在各层中实现的协议设置了模糊器的要求。 根据安全要求，每种协议，文件格式或API可能都需要自己的模糊器类型。
第二个覆盖率指标与模糊器支持的规范相关。 这种类型的度量标准易于使用基于模型的模糊器，因为该工具的基础由用于创建模糊器的规范形成，因此它们易于列出。 基于模型的模糊器应涵盖整个规范。 然而，基于突变的模糊器不一定完全涵盖规范，因为实现或包括来自规范的一个消息交换样本并不保证涵盖整个规范。 通常，当基于突变的模糊器声称规范支持时，这意味着它可以与实现规范的测试目标互操作。
特别是关于协议模糊测试，第三个最关键的指标是所选模糊测试方法的有状态级别。 完全随机的模糊器通常仅测试复杂的有状态协议中的第一条消息。 您正在使用的模糊测试方法越多，感知模式越多，模糊器在复杂的协议交换中就越深入。 有状态是为Fuzzing工具定义的一个困难要求，因为它更像是用于定义所使用的协议模型的质量的度量，因此只能通过运行测试来validation。
我希望这可以帮到你。 我们还研究了其他指标，例如查看代码覆盖率和其他或多或少无用的数据。 ;）度量标准是论文的一个重要主题。 如果您有兴趣访问我们关于此主题的广泛研究，请发送电子邮件至ari.takanen@codenomicon.com。
鲁棒性是非常主观的，但你可以看看FingBugs ， Cobertura和Hudson ，当它们正确地组合在一起时，可以让你随着时间的推移感觉到软件是健壮的。
您可以将故障之间的平均时间视为稳健性度量。
“MTBF”的问题在于它通常以正流量来衡量，而故障通常在意外情况下发生。 它没有给出任何稳健性或可靠性的指示。 无论一个网站是否始终保持在实验室环境中，如果它有一个弱点，它仍然会在互联网上被盗一秒。