我们目前正在制定我们将要进行的贸易研究的评估标准。
我们选择的标准之一是可靠性（和/或稳健性 - 这些是相同的吗？）。
如何评估该软件是否可靠而无需花费太多时间进行评估？
编辑：根据KenG给出的回应，缩小问题的重点： 您可以选择50种现有软件解决方案。您需要评估它们的可靠性，而无法对它们进行测试（至少在最初阶段）。您可以使用哪些有形指标或其他来评估所述可靠性？
答案 0 :(得分：4)
可靠性和稳健性是系统的两个不同属性：
IEEE将其定义为“...... 系统或组件的能力 执行其所需的功能 规定的条件 一段时间。“
如果输入，计算等异常，它仍然可以继续运行
因此，可靠的系统执行其在限制范围内设计的功能;如果发生意外/意外情况，健壮系统将继续运行。
如果您可以访问您正在评估的软件的任何历史记录，可以从报告的缺陷，随时间推移的“补丁”版本的数量，甚至代码库中的流失中推断出可靠性的一些概念。
产品是否具有自动化测试流程？测试覆盖率可以是另一种信心指示。
一些使用敏捷方法的项目可能不符合这些标准 - 预计会频繁发布和大量重构
与当前软件/产品用户核实真实世界信息。
答案 1 :(得分：1)
好吧，关键词“可靠”可以得出不同的答案......在考虑可靠性时，我想到了两个方面： 1~总是给出正确答案（或最佳答案） 2~总是给出相同的答案
无论哪种方式，我认为它归结为一些可重复的测试。如果有问题的应用程序不是使用单元和验收测试的字符串套件构建的，您仍然可以提出一组手动或自动测试来重复执行。
测试总是返回相同结果的事实将表明方面＃2得到了解决。对于方面＃1，它确实取决于测试编写者：提出可能会暴露错误或缺陷的良好测试。
在不知道应用程序是什么的情况下，我不能更具体，抱歉。例如，如果消息总是被传递，永不丢失，从不包含错误等等，消息传递系统将是可靠的......计算器对可靠性的定义会有很大不同。
答案 2 :(得分：1)
与已经使用它的人交谈。你可以测试自己的可靠性，但它很难，很昂贵，并且根据你测试的内容而非常不可靠，特别是如果你的时间很短。大多数公司愿意让您与现有客户联系，如果它能帮助您销售他们的软件，他们将能够让您真实地了解软件的处理方式。
答案 3 :(得分：1)
这取决于您正在评估的软件类型。网站的主要（也可能是唯一）可靠性标准可能是其正常运行时间。 NASA将对其软件的可靠性有一个完全不同的定义。你的定义可能介于两者之间。
如果您没有足够的时间来评估可靠性，那么您自动完成测量过程绝对是 critical 。您可以使用continuous integration工具确保您只需手动查找一次错误。
我建议您或您公司的某人阅读Continuous Integration: Improving Software Quality and Reducing Risk。我认为这将有助于您自己定义软件可靠性。
答案 4 :(得分：1)
与任何事情一样，如果你没有时间自己评估，那么你必须依赖别人的判断。
答案 5 :(得分：1)
可靠性是某些事物有效性的三个方面之一。另外两个是可维护性和可用性......
一篇有趣的论文...... http://www.barringer1.com/pdf/ARMandC.pdf更详细地讨论了这一点，但一般来说，
可靠性是基于系统破坏的概率......即，破坏的可能性越大，它的可靠性就越低......在其他系统（软件除外）中，它通常以平均时间间隔来衡量失败（MTBF）这是像硬盘这样的常见指标...（10000小时MTBF）在软件中，我猜你可以在关键系统故障之间或应用程序崩溃之间或不可恢复错误之间的平均时间内测量它，或者在阻碍或不利地影响正常系统生产力的任何类型的错误之间......
可维护性是衡量它在断裂时需要多长时间/多少钱（多少工时和/或其他资源）来衡量它的指标。在软件中，您可以添加这个概念，增强或扩展软件需要多长时间/多少钱（如果这是一个持续的要求）
可用性是前两个的组合，并且在计算出故障以及每个故障单元在修复时无法使用多长时间后，向计划员表明，如果我有100个这样的东西运行了十年无论如何，100个平均有多少人会在任何时候启动并运行？ 20％，或98％？
答案 6 :(得分：0)
你必须通过理解并完全接受你将要做出妥协来进入这个过程，如果可靠性是一个关键标准并且你没有（或者不愿意提交）资源，这可能会产生负面影响基于此进行适当的评估。
话虽如此 - 确定使软件可靠性至关重要的关键要求，然后设计测试以根据这些要求进行评估。
鲁棒性和可靠性交叉在彼此的关系中，但不一定相同。
如果您的数据服务器无法处理10个以上的连接，并且您希望连接100000个 - 那么它就不健壮了。如果它在＆gt;处死亡将是不可靠的。 10个连接。如果同一台服务器可以处理所需连接的数量但间歇性地死亡，你可以说它仍然不健壮且不可靠。
我的建议是，您需要咨询经验丰富的质量保证人员，他们对您将进行的研究具有丰富的知识。那个人将能够帮助您设计关键区域的测试 - 在您的资源限制范围内。我建议中立的第三方（而不是软件编写者或供应商）帮助您确定测试所需的关键功能，以便做出决定。
答案 7 :(得分：0)
如果您无法测试它，您将不得不依赖开发人员的声誉以及他们在此应用程序上遵循与其他测试应用程序相同的做法的程度。示例：Microsoft在其应用程序的版本1方面做得不是很好，但3＆amp; 4通常都很不错（Windows ME版本为0.0001）。
答案 8 :(得分：0)
根据您评估的服务类型，您可能会获得可靠性指标或SLI - 服务级别指标 - 衡量服务/产品运行情况的指标。例如 - 在1秒内处理99％的请求。
根据SLI，您可以设置服务级别协议 - 您和软件提供商之间就您希望的SLO（服务级别目标）所达成的合同，以及不能提供这些协议的后果。
答案 9 :(得分：0)
我的建议是围绕SLI，SLO和SLA遵循SRE方法，最好在免费电子书中进行总结：
从工具的角度来看，更多地考虑可靠性：