如何评估软件的可靠性？

Question

我们目前正在制定我们将要进行的贸易研究的评估标准。

我们选择的一个标准是可靠性（和/或鲁棒性 - 它们是否相同？）。

您如何评估该软件是否可靠而又无法承受太多时间评估？

编辑：沿着KenG给出的回应的路线，缩小问题的焦点： 您可以选择50个现有的软件解决方案。您需要评估它们的可靠程度，但不能测试它们（至少在初始阶段）。什么有形指标或其他可用于评估所述可靠性？

Answer 1

可靠性和鲁棒性是一个系统正的两种不同的属性：

Reliability

的IEEE其定义为”系统或组件以 的 能力下执行其所需的功能。 规定的条件为指定的 一段时间。“

Robustness

是强大的，如果它继续，尽管输入，计算异常操作，因为它被设计为内等

所以一个可靠系统执行其功能限制; A 强大的如果出现意外/未预料的情况，系统将继续运行。

如果您有机会获得你正在评估该软件的任何历史，可靠性一些想法可以从报告的缺陷推断，“补丁”的发行数量随着时间的推移，即使在代码库翻腾。

产品是否有自动化测试过程？测试覆盖率可以是另一个信心指标。

一些使用敏捷方法可能不符合这些标准以及项目 - 频繁的发布和大量的重构预计

检查与现实世界的信息的软件/产品的现有用户。

Answer 2

好了，关键字“可靠”可能会导致不同的答案......当可靠性思考，我觉得两个方面： 1〜总是做出正确的答案（或最佳答案） 2〜总是给人相同的答案

无论哪种方式，我认为它归结为一些可重复的测试。如果有问题的应用程序没有使用字符串的单元和验收测试进行构建，您仍然可以想出一套手动或自动测试来重复执行。

事实上，测试总是返回相同的结果将显示方面＃2照顾。对于方面1而言，它确实取决于测试编写者：提出可以暴露错误或缺陷的良好测试。

如果不知道应用程序是关于什么的，对不起，我不能更具体。例如，如果消息总是被传递，永不丢失，从不包含错误等等，那么消息传递系统将是可靠的......计算器对可靠性的定义会有很大的不同。

Answer 3

与已使用它的人交谈。你可以测试自己的可靠性，但这很难，很昂贵，而且根据你测试的内容可能会非常不可靠，特别是如果你时间不够紧的话。大多数公司会愿意让您与当前的客户联系，如果它能帮助您销售他们的软件，他们将能够给您一个关于软件如何处理的真实世界的想法。

Answer 4

这取决于您正在评估哪种类型的软件。一个网站的主要（也可能只是）可靠性标准可能是它的正常运行时间。 NASA将具有完全不同的软件可靠性定义。你的定义可能会介于两者之间。

如果您没有足够的时间来评估可靠性，那么绝对是关键，您可以自动执行您的测量过程。您可以使用continuous integration工具来确保您只需要手动查找一次错误。

我建议你或你公司的某人阅读Continuous Integration: Improving Software Quality and Reducing Risk。我认为这将有助于您引导您对软件可靠性的定义。

Answer 5

如果可靠性是一个关键标准，并且您没有（或不愿意承诺），那么您就必须理解并完全接受您将做出妥协，否则可能会产生负面影响。根据这些资源进行适当的评估。尽管如此 - 确定了使软件可靠性至关重要的关键要求，然后根据这些要求设计测试进行评估。

鲁棒性，并在其相互之间的关系可靠性交叉，但不一定是相同的。

如果不能处理超过10个连接，你指望100000个连接的数据服务器 - 这是不稳健。如果它在> 10个连接处死亡，它将不可靠。如果同一台服务器可以处理所需的连接数量，但间歇性地死亡，则可以说它仍然不健壮并且不可靠。

我的建议是，你有经验的QA人员是谁在为你的研究将开展该领域的知识咨询。该人员将能够帮助您设计关键区域的测试 - 在您的资源限制范围内。我建议一个中立的第三方（而不是软件作者或供应商）来帮助你决定你需要测试的关键功能，以便做出决定。

Answer 6

正如任何事情，如果你没有自己的东西评估的时候，那么你必须依靠他人的判断。

Answer 7

可靠性是出头的有效性..另外两个是维修性和可用性三个方面一个...

一个有趣的纸... http://www.barringer1.com/pdf/ARMandC.pdf讨论得更详细些，但通常

可靠性是基于系统可能中断的概率，即它越容易中断，它的可靠性就越低......在其他系统（软件除外）中，它通常以平均无故障时间（MTBF）来衡量这是硬盘等常见度量标准...（10000小时MTBF）在软件中，我想你可以用平均值关键系统故障之间或应用程序崩溃之间的时间，或不可恢复的错误之间的时间，或任何阻碍或负面影响正常系统生产力的错误之间的时间...

可维护性是衡量多久/工时和/或其他资源），当它发生中断时，需要进行修复。在软件中，您可以添加到这个概念多久或多么昂贵，以增强或扩展软件（如果这是一个持续的需求）

可用性是前两个的组合，并向计划者表明，如果在确定失败后，每个失败的单元在固定，修复等情况下无法使用多长时间后，我有100个这样的东西运行了10年，平均而言，100个中有多少个可以运行一次？ 20％，还是98％？

Answer 8

如果你不能测试它，你将不得不依赖开发人员的声誉，以及他们如何跟随他们的其他测试应用程序在这个应用程序上的相同做法。例如：微软在他们的应用程序的第一版上做得不是很好，但通常很不错（Windows ME的版本是0.0001）。

Answer 9

根据您正在评估的服务类型，您可能会获得可靠性指标或SLI - 服务级别指标 - 衡量服务/产品效果如何的指标。例如 - 在1秒内处理99％的请求。

基于SLI，您可能会设置服务级别协议 - 您和软件提供商之间关于SLO（服务级别目标）的合同，您希望它们不会产生这些后果。