我们目前正在为我们将要进行的贸易研究制定评估标准。
我们选择的标准之一是可靠性（和/或稳健性 - 这些是否相同？）。
您如何评估软件是否可靠而无需花费大量时间进行评估？
编辑：按照 KenG 的回答，缩小问题的重点：您可以在 50 种现有软件解决方案中进行选择。您需要评估它们的可靠性，而不是能够测试它们（至少在最初）。您可以使用哪些有形指标或其他指标来评估所述可靠性？
问问题
3431 次
10 回答
5
可靠性和稳健性是系统的两个不同属性：
IEEE 将其定义为“……系统或组件在规定的时间段内，在规定的条件下执行其所需功能的能力”。
如果它在输入、计算等异常的情况下继续运行，则它是稳健的。
因此，一个可靠的系统会按照其设计的约束条件执行其功能；如果发生意外/未预料到的情况，稳健的系统将继续运行。
如果您可以访问您正在评估的软件的任何历史记录，则可以从报告的缺陷、随着时间的推移“补丁”发布的数量，甚至代码库中的流失中推断出一些关于可靠性的想法。
产品是否有自动化测试流程？测试覆盖率可能是信心的另一个指标。
一些使用敏捷方法的项目可能不太符合这些标准——预计会频繁发布和大量重构
与软件/产品的当前用户核实真实世界的信息。
于 2008-11-07T15:33:00.543 回答
2
这取决于您正在评估的软件类型。网站的主要（也许是唯一的）可靠性标准可能是其正常运行时间。 NASA将对其软件的可靠性有一个完全不同的定义。您的定义可能介于两者之间。
如果您没有很多时间来评估可靠性，那么自动化您的测量过程绝对是至关重要的。您可以使用持续集成工具来确保您只需手动查找一次错误。
我建议您或您公司的某个人阅读持续集成：提高软件质量和降低风险。我认为这将有助于引导您对软件可靠性进行自己的定义。
于 2008-11-07T15:16:03.837 回答
1
好吧，“可靠”这个关键词可能会导致不同的答案……在考虑可靠性时，我想到了两个方面：
- 总是给出正确答案（或最佳答案）
- 总是给出相同的答案
无论哪种方式，我认为它归结为一些可重复的测试。如果有问题的应用程序没有使用强大的单元测试和验收测试套件构建，您仍然可以提出一组手动或自动测试来重复执行。
测试总是返回相同结果的事实将表明第 2 方面得到了照顾。对于第 1 方面，这实际上取决于测试编写者：提出可以暴露错误或缺陷的良好测试。
如果不知道应用程序是关于什么的，我无法更具体，抱歉。例如，如果消息始终被传递、永不丢失、永不包含错误等，那么消息传递系统将是可靠的……计算器对可靠性的定义会大不相同。
于 2008-11-07T15:16:02.573 回答
1
与已经使用它的人交谈。您可以测试自己的可靠性，但这很困难、昂贵，并且可能非常不可靠，具体取决于您要测试的内容，尤其是在您时间紧迫的情况下。大多数公司愿意让您与现有客户联系，如果这有助于向您销售他们的软件，并且他们将能够让您对软件的处理方式有一个真实的了解。
于 2008-11-07T15:16:03.337 回答
1
与任何事情一样，如果您没有时间自己评估某件事，那么您必须依靠他人的判断。
于 2008-11-07T15:16:56.627 回答
1
可靠性是事物有效性的三个方面之一。另外两个是可维护性和可用性...
一篇有趣的论文... http://www.barringer1.com/pdf/ARMandC.pdf更详细地讨论了这一点，但一般来说，
可靠性基于系统崩溃的概率。即，越有可能崩溃，可靠性越低……在其他系统（软件除外）中，它通常以平均故障间隔时间 (MTBF) 来衡量）这是硬盘之类的常用指标...（10000 小时 MTBF）在软件中，我想您可以用关键系统故障之间、应用程序崩溃之间、不可恢复错误之间或错误之间的平均时间来衡量它任何阻碍或不利影响正常系统生产力的...
可维护性是衡量当它发生故障时修复它需要多长时间/多昂贵（多少工时和/或其他资源）的量度。在软件中，您可以在此概念中添加增强或扩展软件的时间/成本（如果这是一个持续的要求）
可用性是前两者的结合，它向计划者表明，如果我有 100 个这样的东西运行了十年，在计算出故障以及每个故障单元在修复、修理时不可用多长时间之后，平均而言，这 100 家中有多少家会在任何时候启动并运行？20% 还是 98% ？
于 2008-11-07T15:59:04.577 回答
0
您必须通过理解并完全接受您将做出妥协来进入该过程，如果可靠性是关键标准并且您没有（或不愿意承诺）适当评估的资源，这可能会产生负面影响基于此。
话虽如此 - 确定使软件可靠性至关重要的关键要求是什么，然后设计测试以根据这些要求进行评估。
鲁棒性和可靠性相互交叉，但不一定相同。
如果您的数据服务器无法处理超过 10 个连接，并且您希望有 100000 个连接 - 它并不可靠。如果它在 > 10 个连接处死掉，那将是不可靠的。如果同一台服务器可以处理所需的连接数但间歇性地死机，您可以说它仍然不健壮且不可靠。
我的建议是您咨询一位经验丰富的 QA 人员，该人员在您将进行的研究方面具有丰富的知识。该人将能够帮助您设计关键领域的测试 - 希望在您的资源限制范围内。我会推荐一个中立的第三方（而不是软件编写者或供应商）来帮助你决定你需要测试的关键特性来做出决定。
于 2008-11-07T15:16:13.963 回答
0
如果您无法对其进行测试，则必须依赖开发人员的声誉以及他们在此应用程序上遵循与其他测试应用程序相同的做法的程度。示例：Microsoft 在其应用程序的版本 1 方面做得不是很好，但 3 和 4 通常都非常好（Windows ME 是版本 0.0001）。
于 2009-02-08T04:44:36.600 回答
0
根据您正在评估的服务类型，您可能会获得可靠性指标或 SLI - 服务级别指标 - 衡量服务/产品执行情况的指标。例如 - 在 1 秒内处理 99% 的请求。
根据 SLI，您可以设置服务级别协议 - 您和软件提供商之间关于您想要什么 SLO（服务级别目标）的合同，而不是他们不提供这些的后果。
于 2016-09-04T20:14:50.400 回答
0
我的建议是围绕 SLI、SLO 和 SLA 遵循 SRE 方法，最好在免费电子书中进行总结：
更多地从您需要的工具角度看待可靠性：
- 监控基础设施（我推荐Prometheus）
- 警报（我推荐Prometheus AlertManager、OpsGenie或PagerDuty）
- SLO 计算工具，例如slo-exporter
于 2020-09-28T15:08:04.307 回答