如何衡量稳健性?

时间:2010-03-01 07:30:17

标签: java software-quality robustness

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

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

是否存在可以确保稳健性的静态或动态指标?即,就像单元测试覆盖一样,有没有一种方法可以确保这样的稳健性?如果是这样,是否有任何(免费)工具可以做这样的事情?

有没有人有这种工具的经验?

最后但并非最不重要的,也许还有其他方法可以确定稳健性,如果您对此有任何想法,我会全力以赴。

提前多多感谢。

5 个答案:

答案 0 :(得分:13)

嗯,简短的回答是“不”。强大可能意味着很多事情,但我能想出的最佳定义是“在任何情况下都能正确执行”。如果您将错误的HTTP标头发送到健壮的Web服务器,它不应该崩溃。它应该返回正确的错误类型,它应该以某种可配置的方式将事件记录到某处。如果一个强大的Web服务器运行很长一段时间,它的内存占用应该保持不变。

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

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

但是,您可以使用各种检查作为对系统健康状况的粗略估计。单元测试覆盖率非常标准,其兄弟姐妹,分支机构覆盖范围,功能覆盖范围,声明覆盖率等等。另一个不错的选择是像FindBugs这样的“lint”程序。这些可以表明存在问题的可能性。开源项目通常根据发布的次数和最近的提交或发布的次数来判断。如果项目有错误系统,您可以测量已修复的错误数量和百分比。如果您正在测量的程序的特定实例,尤其是具有大量活动的程序,则MTBF(平均故障间隔时间)是稳健性的良好衡量标准(参见Philip's Answer

但是,这些测量并不能真正告诉您程序的稳健性。他们只是猜测它的方法。如果很容易弄清楚程序是否健壮,我们可能只是让编译器检查它。

祝你的论文好运!我希望你能想出一些很酷的新测量结果!

答案 1 :(得分:4)

您可以将mean time between failures视为稳健性衡量指标。问题在于它是一个难以衡量的理论数量,特别是在您将产品部署到具有实际负载的真实环境之前。部分原因是测试通常不包括实际可扩展性问题。

答案 2 :(得分:2)

在我们的Fuzzing书中(由Takanen,DeMott,Miller撰写)我们有几章专门针对负面测试的指标和覆盖范围(稳健性,可靠性,语法测试,模糊测试,同一事物的许多名称)。此外,我试图在公司白皮书中总结最重要的方面:

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

来自那里的片段:


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

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

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

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


我希望这很有帮助。我们还研究了其他指标,例如查看代码覆盖率和其他或多或少无用的数据。 ;)度量标准是论文的一个重要主题。如果您有兴趣访问我们对该主题的广泛研究,请发送电子邮件至ari.takanen@codenomicon.com。

答案 3 :(得分:1)

健壮性是非常主观的,但您可以查看FingBugsCoberturaHudson,如果正确组合在一起,可以让您随着时间的推移感受到软件的稳健性

答案 4 :(得分:0)

  

你可以考虑两者之间的平均时间   失败是一种稳健性措施。

“MTBF”的问题在于它通常以正流量来衡量,而故障通常在意外情况下发生。它没有给出任何稳健性或可靠性的指示。无论一个网站是否始终保持在实验室环境中,如果它存在缺陷,它仍会在互联网上被盗一秒。