|
|
9 回复 | 直到 13 年前
|
1
5
可靠性和鲁棒性是系统的两个不同属性:
那么 可信赖的 系统在约束条件下执行其设计的功能;A. 强健的 如果发生意外情况,系统将继续运行。 如果您可以访问正在评估的软件的任何历史记录,那么可以从报告的缺陷、随着时间的推移发布的“补丁”数量,甚至代码库中的混乱情况中推断出可靠性的一些想法。 产品是否有自动测试流程?测试覆盖率可以是信心的另一个指标。 一些使用敏捷方法的项目可能不太符合这些标准——频繁的发布和大量的重构是需要的 与软件/产品的当前用户核实真实世界的信息。 |
|
|
2
2
这取决于您正在评估的软件类型。一个网站的主要(也许是唯一)可靠性标准可能是它的正常运行时间。 NASA 如果你没有太多的时间来评估可靠性,那绝对是 批评的 continuous integration 工具,以确保您只需手动查找一次错误。 Continuous Integration: Improving Software Quality and Reducing Risk . 我认为这将有助于引导您自己定义软件可靠性。 |
|
|
3
1
与已经使用它的人交谈。你可以测试自己的可靠性,但这很难,很昂贵,而且可能非常不可靠,这取决于你测试的内容,特别是如果你时间不够的话。大多数公司都愿意让你与现有客户联系,如果这有助于向你销售他们的软件,并且他们能够让你了解软件如何处理。 |
|
|
4
1
与任何事情一样,如果你没有时间自己评估某件事,那么你必须依靠他人的判断。 |
|
|
5
1
可靠性是事物有效性的三个方面之一。。另外两个是可维护性和可用性。。。 一篇有趣的论文。。。 http://www.barringer1.com/pdf/ARMandC.pdf 更详细地讨论了这一点,但总体而言, 可靠性是基于系统发生故障的概率。。i、 例如,它越有可能损坏,就越不可靠。。。在其他系统(软件除外)中,它通常以平均无故障时间(MTBF)来衡量,这是硬盘之类的常见指标。。。(10000小时MTBF)在软件中,我想您可以在关键系统故障之间、应用程序崩溃之间、不可恢复的错误之间或妨碍或对正常系统生产力产生不利影响的任何类型的错误之间的平均时间来衡量它。。。 可维护性是一种衡量当它发生故障时修复它所需的时间/成本(多少工时和/或其他资源)的指标。在软件中,您可以将增强或扩展软件的时间/成本增加到这个概念中(如果这是一个持续的需求)
|
|
|
6
1
好吧,关键词“可靠”可能导致不同的答案。。。在考虑可靠性时,我想到两个方面:
不管怎样,我认为这归结为一些可重复的测试。如果所讨论的应用程序不是使用一套强大的单元测试和验收测试构建的,那么您仍然可以提出一组手动或自动测试来重复执行。 测试总是返回相同的结果这一事实将表明方面2得到了考虑。对于aspect#1,这实际上取决于测试编写者:提出能够暴露bug或缺陷的好测试。
|
|
|
7
0
在这个过程中,你必须理解并完全接受你将做出的妥协,如果可靠性是一个关键标准,而你没有(或不愿意)资源进行适当的评估,这可能会产生负面影响。 话虽如此——确定使软件可靠性至关重要的关键需求是什么,然后根据这些需求设计测试进行评估。 稳健性和可靠性相互交叉,但不一定相同。 如果您的数据服务器不能处理10个以上的连接,并且您希望有100000个连接,那么它就不健壮。如果它在>处死亡,则不可靠;10个连接。如果同一台服务器能够处理所需的连接数,但间歇性地死机,那么可以说它仍然不健壮、不可靠。
|
|
|
8
0
如果你不能测试它,你将不得不依赖开发者的声誉,以及他们在该应用程序上与其他测试应用程序遵循相同做法的情况。示例:微软的应用程序版本1做得不是很好,但版本3&4通常都很好(Windows ME的版本是0.0001)。 |
|
|
9
0
根据SLI,您可以建立服务级别协议,即您与软件供应商之间就您希望的SLO(服务级别目标)签订的合同,其后果是他们不提供这些服务。 |
|
|
10
0
从您需要的工具角度来看可靠性:
|
推荐文章
|
|
Brady H · 防范Windows中函数调用之间的系统更改 7 年前 |