61阅读

软件可靠性-软件可靠性

发布时间:2017-07-30 所属栏目:软件安全性与可靠性

一 : 软件可靠性

软件可靠性(Software Reliability)

什么是软件可靠性

软件可靠性是指在给定时间内,特定环境下软件无错运行的概率。

(www.61k.com)

软件可靠性的内容

软件可靠性包含了以下三个要素:

1.规定的时间

软件可靠性只是体现在其运行阶段,所以将“运行时间”作为“规定的时间”的度量。 “运行时间”包括软件系统运行后工作与挂起(开启但空闲)的累计时间。由于软件运行的环境与程序路径选取的随机性,软件的失效为随机事件,所以运行时间属于随机变量。

2.规定的环境条件

环境条件指软件的运行环境。它涉及软件系统运行时所需的各种支持要素,如支持硬件、操作系统、其它支持软件、输入数据格式和范围以及操作规程等。不同的环境条件下软件的可靠性是不同的。具体地说,规定的环境条件主要是描述软件系统运行时计算机的配置情况以及对输入数据的要求,并假定其它一切因素都是理想的。有了明确规定的环境条件,还可以有效判断软件失效的责任在用户方还是研制方。

3.规定的功能

软件可靠性还与规定的任务和功能有关。由于要完成的任务不同,软件的运行剖面会有所区别,则调用的子模块就不同(即程序路径选择不同),其可靠性也就可能不同。所以要准确度量软件系统的可靠性必须首先明确它的任务和功能。

软件可靠性的测试

软件可靠性测试的目的

软件可靠性测试的主要目的有:

(1)通过在有使用代表性的环境中执行软件,以证实软件需求是否正确实现。

(2) 为进行软件可靠性估计采集准确的数据。估计软件可靠性一般可分为四个步骤,即数据采集、模型选择、模型拟合以及软件可靠性评估。可以认为,数据采集是整个软件可靠性估计工作的基础,数据的准确与否关系到软件可靠性评估的准确度。

(3)通过软件可靠性测试找出所有对软件可靠性影响较大的错误。

软件可靠性测试的特点

软件可靠性测试不同于硬件可靠性测试,这主要是因为二者失效的原因不同。硬件失效一般是由于元器件的老化引起的,因此硬件可靠性测试强调随机选取多个相同的产品,统计它们的正常运行时间。正常运行的平均时间越长, 则硬件就越可靠。软件失效是由设计缺陷造成的,软件的输入决定是否会遇到软件内部存在的故障。因此,使用同样一组输入反复测试软件并记录其失效数据是没有意义的。在软件没有改动的情况下,这种数据只是首次记录的不断重复,不能用来估计软件可靠性。软件可靠性测试强调按实际使用的概率分布随机选择输入,并强调测试需求的覆盖面。软件可靠性测试也不同于一般的软件功能测试。相比之下,软件可靠性测试更强调测试输入与典型使用环境输入统计特性的一致,强调对功能、输入、数据域及其相关概率的先期识别。测试实例的采样策略也不同,软件可靠性测试必须按照使用的概率分布随机地选择测试实例,这样才能得到比较准确的可靠性估计,也有利于找出对软件可靠性影响较大的故障。

此外,软件可靠性测试过程中还要求比较准确地记录软件的运行时间,它的输入覆盖一般也要大于普通软件功能测试的要求。

对一些特殊的软件,如容错软件、实时嵌入式软件等,进行软件可靠性测试时需要有多种测试环境。这是因为在使用环境下常常很难在软件中植入错误,以进行针对性的测试。

软件可靠性测试的效果

软件可靠性测试是软件可靠性保证过程中非常关键的一步。经过软件可靠性测试的软件并不能保证该软件中残存的错误数最小,但可以保证该软件的可靠性达到较高的要求。从工程的角度来看,一个软件的可靠性高不仅意味着该软件的失效率低,而且意味着一旦该软件失效,由此所造成的危害也小。一个大型的工程软件没有错误是不可能的,至少理论上还不能证

明一个大型的工程软件能没有错误。因此,保证软件可靠性的关键不是确保软件没有错误,而是要确保软件的关键部分没有错误。更确切地说,是要确保软件中没有对可靠性影响较大的错误。这正是软件可靠性测试的目的之一。软件可靠性测试的侧重点不同于一般的软件功能测试,其测试实例设计的出发点是寻找对可靠性影响较大的故障。因此,要达到同样的可靠性要求,可靠性测试比一般的功能测试更

有效,所花的时间也更少。另外, 软件可靠性测试的环境是具有使用代表性的环境,这样,所获得的测试数据与软件的实际运行数据比较接近,可用于软件可靠性估计。

总之, 软件可靠性测试比一般的功能测试更加经济和有效,它可以代替一般的功能测试,而一般的软件功能测试却不能代替软件可靠性测试,而且一般功能测试所得到的测试数据也不宜用于软件可靠性估计。

软件可靠性测试中需注意的问题

软件可靠性测试一般可分为四个阶段:制定测试方案,制定测试计划,进行测试并记录测试结果,编写测试报告。

制定测试方案时需要特别注意被测功能的识别和失效等级的定义。制定测试计划时需设计测试实例,决定测试时要确定输入顺序,并确定程序输出的预期结果,这时也需注意测试覆盖问题。

1. 功能识别

软件可靠性测试的第一步就是进行功能识别,确定使用剖面。功能识别的目标是:识别所有被测功能以及执行这些功能所需的相关输入,识别每一个使用需求及其相关输入的概率分布。为达到第一个目标,需要分析软件功能的所有集合,这些功能之间全部的约束条件,功能之间的独立性、相互关系和相互影响,还需分析系统的不同运行模式、失效发生时系统重构策略等对软件运行方式有较大影响的因素。第一个目标也是一般软件功能测试需要达到的目标,但第二个目标则是软件可靠性测试特别强调的。为了得到能够反映软件使用的有代表性的概率分布,测试人员必须和系统工程师、系统运行分析员和顾客共同合作。需要指出的是,由于可靠性的要求,输入数据的概率分布应包括合法数据的概率分布和非法数据的概率分布两部分。有时为了更好地反映实际使用状况,还需给出那些影响程序运行方式的条件,如硬件配置.负荷等的概率分布。

2. 定义换效等级

定义失效等级主要是为了解决下面两个问题:

·对发生概率小但失效后危害严重的功能需求的识别。

·对可不查找失效原因、并不做统计的功能需求的识别。

在制定测试计划时,失效及其等级的定义应由测试人员、设计人员和用户共同商定,达成协议。

3. 可靠性测试覆盖

可靠性测试必须保证输入覆盖和环境覆盖,这是准确估计软件可靠性的基础。

输入覆盖包括下面几个内容:

·输入域覆盖,即所有被测输入值域的发生概率之和必须大于软件可靠度的要求。

·重要输入变量值的覆盖。

·相关输入变量可能组合的覆盖,以确保相关输入变量的相互影响不会导致软件失效。

·设计输入空间与实际输入空间之间区域的覆盖,即不合法输入域的覆盖。

·各种使用功能的覆盖。

环境覆盖是指测试时必须覆盖所有可能影响程序运行方式的条件。

软件可靠性测试的步骤

软件可靠性测试分为四个阶段:

1.制订测试方案

本阶段的目标是识别软件功能需求,触发该功能的输入和对应的数据域,确定相关的概率分布及需强化测试的功能。

以下是我们推荐的步骤。在一些特定的应用中,有的步骤并不是必须的。

(1)分析功能需求 分析各种功能需求, 识别触发该功能的输入及相关的数据域(包括合法

与不合法的两部分)。分析时要注意下述问题:

·该软件是否存在不同的运行模式?如果存在,那么应列出所有的系统运行模式。

·是否存在影响程序运行方式的外部条件?如果存在,那么有多少?它们的影响程度如何

·各种功能需求之间是相互独立的还是相关的?如果相关,是密切相关还是部分相关?如果两种功能密切相关,那么可将两种功能合并为一种功能。如果功能之间为部分相关,则需列出相应输入变量的合法组合。

(2)定义失效等级

判断是否存在出现危害度较大的1级和2级失效的可能性。如果这种可能性存在,则应进行故障树分析,标识出所有可能造成严重失效的功能需求和其相关的输入领域。

(3)确定概率分布

·确定各种不同运行方式的发生概率,判断是否需要对不同的运行方式进行分别测试。如果需要,则应给出各种运行方式下各数据域的概率分布;否则,给出各数据域的概率分布。

·判断是否需要强化测试某些功能。

(4)整理概率分布的信息 将这些信息编码送入数据库。

2.制订测试计划

本阶段的目标是:

(1)根据前一阶段整理的概率分布信息生成相对应的测试实例集,并计算出每一测试实例预期的软件输出结果。

本阶段需要注意:在按概率分布随机选择生成测试实例的同时,要保证测试的覆盖面。

(2)编写测试计划,确定测试顺序,分配测试资源。由于本阶段前一部分的工作需要考虑大量的信息和数据,因此需要一个软件支持工具,建立数据库,并产生测试实例。另外,有时预测软件输出结果也需要大量的计算,有些复杂的软件甚至要用到仿真器模拟输出结果。总之,具体实施与被测应用软件的实际功能类型有关。

3. 测试

本阶段进行软件测试。需注意的是被测软件的测试环境(包括硬件配置和软件支撑环境

)应和预期的实际使用环境尽可能一致,对某些环境要求比较严格的软件(如嵌入式软件)则应完全一致。测试时按测试计划和顺序对每一个测试实例进行测试,判断软件输出是否符合预期结果。测试时应记录测试结果、运行时间和判断结果。如果软件失效,那么还应记录失效现象和时间,以备以后核对。

4.编写测试报告

按软件可靠性估计的要求整理测试记录,并将结果写成报告。

笔者认为,软件可靠性测试的关键在于:

·对需求、输入、数据域的识别及相关概率分布的确定。

·按照概率分布随机生成测试实例,并确定测试顺序。

据国外有关文献报导,这种测试方法已成功应用于大量应用软件的可靠性测试,包括一些商用软件和航空、航天电子设备中嵌入式软件的测试,其效果很好。因此,我们有必要投入一定的人力、物力,针对我们的实际需要,有目的地对各类应用软件进行软件可靠性测试,从实践中逐步积累经验。同时需要软件开发方和使用方共同合作,进行软件可靠性测试方法的研究和有关支持工具的开发,促进我国软件可靠性水平的提高。

软件可靠性的评测技术

软件可靠性评测是指运用统计技术对软件可靠性测试和系统运行期间采集的软件失效数据进行处理并评估软件可靠性的过程。软件可靠性评测的主要目的是测量和验证软件的可靠性,当然实施软件可靠性评测也是对软件测试过程的一种完善,有助于软件产品本身的可靠性增长。

软件测试者可以使用很多方法进行软件测试,如按行为或结构来划分输入域的划分测试,纯粹随机选择输入的随机测试,基于功能、路径、数据流或控制流的覆盖测试,等等。对于给定的软件,每种测试方法都局限于暴露一定数量和一些类别的错误。通过这些测试能够查找、定位、改正和消除某些错误,实现一定意义上的软件可靠性增长。但是,由于它们都是面向错误的测试,测试所得到的结果数据不宜用于软件可靠性评估。

软件可靠性测试是指在软件的预期使用环境中,为进行软件可靠性评估而对软件实施的一种测试。软件可靠性测试应该是面向故障的测试,以用户将要使用的方式来测试软件,每一次测试代表用户将要完成的一组操作,使测试成为最终产品使用的预演。这就使得所获得的测试数据与软件的实际运行数据比较接近,可用于软件可靠性估计。

软件可靠性评测由可靠性目标的确定、运行剖面的开发、测试的计划与执行和测试结果的分析与反馈等四个主要的活动组成。

可靠性目标是指客户对软件性能满意程度的期望。通常用可靠度、故障强度、MTTF等指标来描述,根据不同项目的不同需要而定。建立定量的可靠性指标需要对可靠性、交付时间和成本进行平衡。为了定义系统的可靠性指标,必须确定系统的运行模式,定义故障的严重性等级,确定故障强度目标。

为了对软件可靠性进行良好的预计,必须在软件的运行域上对其进行测试,首先定义一个相应的剖面来镜像运行域,然后使用这个剖面驱动测试,这样可以使测试真实的反映软件的使用情况。由于可能的输入几乎是无限的,测试必须从中选择出一些样本,即测试用例,测试用例要能反映实际的使用情况,反映系统的运行剖面。将统计方法应用到运行剖面开发和测试用例生成,在运行剖面中的每个元素都被定量地赋予一个发生概率值和关键因子,然后根据这些因素分配测试资源、挑选和生成测试用例。在这种测试中, 优先测试那些最重要或最频繁使用的功能,释放和缓解最高级别的风险,有助于尽早发现那些对可靠性有最大影响的故障,以保证软件的按期交付。一个产品有可能需要开发多个运行剖面,这取决于它所包含的运行模式和关键操作,通常需要为关键操作单独定义运行剖面。

在软件的开发过程中使用软件可靠性测试和利用软件可靠性测试对最终产品进行评价,在测试计划的制定上有所不同。用于设计过程的可靠性测试称为可靠性增长测试,测试与故障的排除联系在一起,一般安排在开发过程的系统测试阶段执行,将测试所确定的故障提交给开发者进行修改,建立软件的一个新的版本,再进行下一次测试。在这种“测试—排错—新版本”的迭代过程中,跟踪故障强度的变化,确认测试是否可以终止及软件是否可以发布。可靠性增长测试的测试脚本将执行多次。针对最终产品的可靠性测试称为可靠性验证测试,通过验证测试可确定软件产品当前的可靠性水平。就单个软件版本而言,可靠性验证测试的测试脚本将仅执行一次。软件可靠性故障数据的收集是测试活动的一部分,在测试周期内,纪录每个故障的资料,如与时间相关的故障频度、类型、严重性和故障的根源等,并且应区分设计阶段和最终产品的故障。

可靠性增长测试和可靠性验证测试将从不同的角度理解故障数据。在可靠性增长测试中,测试以迭代的方式进行,根据测试期间跟踪到的故障,使用基于软件可靠性增长模型和统计推理的可靠性评估程序进行故障强度的估计,并用于跟踪测试的进展情况。可靠性验证测试是软件系统提交前进行的最后测试。它是最终检验而不是调试。在验证测试中,其目标是确定一个软件组件或系统在风险限度内是被接受还是被拒绝。验证测试使用可靠性示图,故障被绘制在图上。根据它落入的区域,来决定被测软件是被接受还是被拒绝,或者继续进行测试。可以根据不同的客户风险(接受一个不良程序的风险)和供应商风险(拒绝一个好程序的风险)级别构造图表。

二 : 质量:软件的可靠性要求

上一篇 / 下一篇 2008-12-11 09:44:06

查看( 204 ) / 评论( 1 ) / 评分( 0 / 5 )

软件有用,而且好用,但是如果经常突然宕机或无法使用,用户肯定不会满意这种提心吊胆的感觉。因此软件还必须可靠,让人放心使用。

软件的可靠性质量属性,主要体现了系统持续不间断地满足客户相关应用目标的能力。它们属于软件外在的与其使用价值可获取度有关的质量属性。

■有效性—与软件持续正常运行,而可供用户使用相关的软件属性。例如平均可用时间等。如果在用户急需软件来完成某项任务时,系统却不能使用,那么将有可能严重损坏客户的利益。

■成熟性—与由软件中的缺陷而造成故障的频度相关的软件属性。例如软件的系统缺陷率、平均无故障时间MTBF等。

■故障承受能力—软件在运行时,有可能会遇到故障(例如硬件失效),或者其某些特定接口部分遭到侵害;在此情形下,软件应当仍然保持一定工作能力,从而避免彻底中断服务而造成的更大损失。

■可恢复性—一旦遇到故障,软件重新恢复工作性能所需的时间越短,受损数据的修复程度越高,则因故障而造成的损坏就越轻。

■可预测性Predictability—软件的运行状态与行为是可以预测和把握的。行为不可预测的软件,将使得用户无法掌控它的运作,会给客户带来巨大的风险。

用户关注软件所带来的使用价值,而这种使用价值必须是随时能够获得的;也就是说,软件有用、好用,还要可靠、能用。软件有效性体现了它持续能用的程度;成熟性是软件在正常情形下确保有效性的基础;而故障承受能力、和可恢复性则是软件在异常情形下提高有效性的主要途径;另外,可预测性帮助用户消除因使用软件而带来风险的疑虑。

软件可靠性质量,往往难以独立于硬件之外来单独度量,而且其本身与硬件有密切的关系,但与性能、效率等不同,其本质上还是属于软件的一种属性。

性能与效率要求

软件有用,且好用,同时也很可靠,但是如果用户执行一项简单的操作,就得等上几分钟,恐怕谁也没有这么好的耐心来忍受这种等待的煎熬。因此,软件的执行必须具备让人可以接受的性能。性能等质量属性,是软件与硬件一同协作,所体现出的系统满足客户对相关运行效率、速度与规模方面要求的能力。它们属于软件外在的与其时空特性有关的质量属性。

(一)时间行为上的效率—与响应、处理时间以及执行功能时的吞吐率相关的软件属性。

响应时间:系统从用户提交请求到返回处理结果的时间。

响应速度:系统对用户操作的反馈速度。有反馈并不意味系统已有了处理结果;在响应时间过长的情形下,中途插入及时的反馈,可以避免用户对系统是否死机的疑虑。

处理时间:系统处理用户所提交请求的时间。

延迟时间:用户提交的请求传递给系统,和系统的反馈结果返还用户所花费的时间。

吞吐量(扇入扇出量):系统在单位时间内完成的处理量。

负载(并发性):系统在单位时间内同时被服务的用户数量。

处理能力:系统可有效支持的最大负载(通常是能够满足可接受的响应时间阀值之下的最大负载)。

另外,还有关机时间、开机时间、恢复时间等。

(二)资源行为上的效率—与系统完成某项任务时,所使用的资源数量及其持续时间相关的软件属性。包括:内存占用量、存储空间、CPU的占用率、网络带宽使用率等。

软件的功能属性体现了其使用价值中“质”的方面,而性能等属性则体现了其使用价值中“量”的方面。例如,负载或并发用户数体现了软件使用价值在空间上的量;而响应时间则体现了软件使用价值在时间上的量。换句话说,性能等属性代表了软件功能行为在时空上所表现的附属特性。

软件有用、好用,而且可靠,同时还要速度快,这样单个用户才有长期使用它的意愿;而软件还应支持更多的负载,这样才能让众多用户来接受它。

软件的性能,与可靠性、易用性一样,都会直接影响软件运行过程中的使用成本。例如,性能低下的软件将浪费用户大量的时间用于等待。

软件性能等质量属性,不能独立于硬件来度量,而且其本身体现的就是软件对硬件资源的利用效率。我们无法脱离硬件来单独定义软件的性能规格,因此,在定义性能需求时,必须列出对应的硬件配置规格。(笔者曾经见到不少项目的需求规格说明中,在性能需求这一项,就没有列出对应的硬件配置)

可支持与维护性要求

软件的外部质量属性,归根结底是由其内部质量属性所决定的。这些内部属性中,诸如软件架构质量、源代码质量、其它中间制品质量等,主要用于衡量开发过程中间产出的质量属性,并为软件开发者所关注;而类似软件可支持、可维护性、可扩展性等,主要在软件开发成功之后,用以衡量软件满足客户长期应用系统而保持较低成本的能力。后者将同时为客户、开发者所关注。

软件被交付之后,并不意味着开发者的工作可以完结。用户在使用软件的过程中,总是可能发现遗留下来的bug;或者发现有的功能操作不便,需要改进。这些问题都需要开发者来加以解决。而下列软件的内部相关质量属性,将直接影响到整个维护过程中的成本。

可验证(测试)性 与验证被修改软件所需努力相关的软件属性。软件具有不可视的特性,测试是让软件可视,同时也是唯一能客观验证软件质量的途径。

可分析性 与诊断缺陷、故障,或者确定需要修改的部分所需努力相关的软件属性。所谓“可分析性”主要受软件结构的良好与可理解性、代码的可读性、元素间的低耦合性等因素的影响。

可变性 与修改、去除错误、实施需求或设计变更(例如改变运行环境)等难易程度相关的软件属性。这是度量软件内部架构合理性、代码冗余度、可读性、元素间耦合性等质量的重要指标。

稳定性与修改过程中未预料到作用的风险相关的软件属性。软件容易修改和变更,但是如果一旦实施了变更,就会造成软件的崩溃与失效,并引入更多新的bug,那么可变性仍然只是一句空话。

可审计性 与找出客观的证据来检验软件是否符合标准、规范或既定规格之难易程度相关的软件属性。配置管理中的逻辑审计与物理审计是软件项目中的主要审计途径。

可维护性与软件在使用过程中被修改、更新、演进和修复所需努力相关的软件属性。它基本上由上述其它可支持性质量属性所综合决定。

移植适应性与可扩展性要求

软件被交付之后,除了普通的维护需求之外,很多时候还会遇到客户的其它要求。客户有可能升级了新的硬件设备,而原有软件并不能直接在新的平台环境下运行;客户的业务不断发展,业务量急剧增长,原有系统的性能无法支撑;客户面临很大的竞争压力,需要开展新的业务,而原有软件不具备相应的功能。这些问题最终都依靠开发者来加以解决。下列软件的内部相关质量属性,将直接影响到解决前述这些问题的成本。

下面的质量属性主要体现了系统满足客户不同的应用场景与环境要求的能力:

适应性,是看与是否能适应在不同环境下运行使用相关的软件属性。

一致性/兼容性,则是指软件与特定标准、协定,以及平台环境相容的软件属性。

可配置性,即与软件为了适应不同的环境和应用场景,而进行简单的配置以便实现此目的所付出努力相关的软件属性。

可移植性,即将软件通过重新编译或改造,从而能够在新的环境下被运行使用,为此所需要付出努力相关的软件属性。例如平台移植、本地化移植等。

可安装性,是指与将软件安装在指定环境中所需努力相关的软件属性。

质量属性主要体现了系统满足客户未来发展与变化了的应用场景与规模要求的能力:功能可扩充性和性能可伸缩性。

软件支持维护性以及移植扩展性等质量属性,实际上不仅仅只在软件交付之后发生作用,它们同样会影响软件开发本身。例如,软件开发过程中总是有大量的测试与bug修复活动,较高的可验证(测试)性、可分析性、可变性以及稳定性等都直接有助于上述活动的执行;又如,软件的构造过程,总是从部分到全部逐步完成的,高可扩充性的架构,使得开发者能够逐次地向软件交付添加功能增量(实际上,迭代开发就严重依赖于这一内在的质量属性)。

开发阶段的内部质量要求

软件在交付之后的质量属性,无论是外部属性还是内部属性,都是由软件在开发阶段的内部质量属性所决定的。这些质量属性,主要体现于不同中间制品的质量属性上。

业务建模质量属性—业务模型应当准确(性)地反映客户的业务现状isBe或期望状况toBe;同时它还是完备(性)的,能够反映客户业务的全局关系;另外,业务模型必须是可理解(性)的,方便涉众进行沟通时使用。

需求质量属性—软件规格定义(需求)相对于其支持的业务或领域应用而言应当是适宜(性)的,以满足业务和用户操作的需要;它同时还必须是精确(无二义性)的,以避免理解偏差和最终交付的不一致;而需求规格定义的完备性则决定了软件交付的功能完备性;为了实现软件的易用性质量属性,需要交互设计良好,以消除交互逻辑上的缺陷;需求的可理解性往往也决定了软件操作的可理解性;最后,需求必须是可验证(性)的,否则软件交付将失去验收的客观依据。

架构与分析设计质量属性—软件设计必须是正确(性)的,要满足各类功能与非功能需求;架构设计应当结构良好,模块的划分是合适的,职责的分配是自然的;软件架构应当是健壮(性)的和可扩展(性)的,支持方便地添加功能,同时又不打破原有结构;设计的各个模块或元素本身应当是高内聚(性)的,模块或元素之间的关联应当是低耦合(性)的;软件设计在整体上是低冗余(性)的;另外,设计模型应当简洁优雅(性)、具备较强的可理解性,方便开发人员掌握和遵照实施;最后,软件架构还应当具备较强的可测试性,大幅减少测试成本,并最终有助于提升软件交付的质量。

代码质量属性—代码必须正确(性)地实现设计规格中所定义的功能;同时还提供一定的健壮(性),以容纳一些超出规格定义之外的输入参数、以及错误调用。

测试质量属性—测试案例必须是非常具体而可执行(性)的;通过执行这些测试案例,能够达到要求的代码语句或分支等覆盖率;测试活动应当是有效(性)的,能够最大限度地发现代码中隐藏的缺陷。

部署质量属性—软件交付应当是易部署(性)的,例如,提供了自动安装工具;部署后的软件副本应当是易配置(性)的,方便客户进行调整来适应其不同的要求。

软件质量属性的相互关系

软件的质量属性种类繁多,分别涉及到软件的多个方面。而这些质量属性之间存在着密切的关联关系:有的质量属性被其它质量属性所支持;而有些质量属性则相互增强对方;另外,也存在一些质量属性,它们之间存在相互冲突。(见图1)
本文标题:软件可靠性-软件可靠性
本文地址: http://www.61k.com/1055526.html

61阅读| 精彩专题| 最新文章| 热门文章| 苏ICP备13036349号-1