CN110765005B - 软件可靠性评估方法和装置 - Google Patents

Abstract

本发明公开了一种软件可靠性评估方法和装置，属于数据处理技术领域。包括：获取软件的可靠性评估指标；根据可靠性评估指标，确定软件的测试要求；获取软件中的代码行数；当软件中的代码行数大于或等于测试要求中的代码测试行数时，对软件中的各行代码进行一次测试，统计出现的代码缺陷个数；当软件中的代码行数小于测试要求中的代码测试行数时，对软件中的各行代码进行循环测试，直到测试的代码行数等于测试要求中的代码测试行数，统计出现的代码缺陷个数；当出现的代码缺陷个数小于或等于测试要求中的代码缺陷个数时，判定软件的可靠性通过测试；根据出现的代码缺陷个数和测试的代码行数，确定软件的每千行代码缺陷率。本发明可降低时间和成本。

Description

软件可靠性评估方法和装置

技术领域

本发明涉及数据处理技术领域，特别涉及一种软件可靠性评估方法和装置。

背景技术

软件可靠性(英文：software reliability)是软件产品在规定的条件下和规定的时间区间完成规定功能的能力，是标志军用软件产品质量高低的关键因素。在一些军用标准中，对软件可靠性设计提出了要求，但是没有说明软件可靠性的评价方式，因此并不能确定软件的可靠性设计是否达到预定目标。

目前软件可靠性的评估方法是结合设备可靠性试验标准GJB899A提供的试验方案对软件进行设定时间的测试，并获取软件在测试时间内的失效次数；再根据测试时间和失效次数，计算评估软件可靠性的平均失效前时间(英文：mean time to failure，简称：MTTF)。

在实现本发明的过程中，发明人发现现有技术至少存在以下问题：

获取MTTF需要的可靠性测试时间较长，测试成本较高。

发明内容

本发明实施例提供了一种软件可靠性评估方法和装置，可以解决现有技术试验时间长、试验成本高的问题。所述技术方案如下：

一方面，本发明实施例提供了一种软件可靠性评估方法，所述软件可靠性评估方法包括：

获取软件的可靠性评估指标，所述可靠性评估指标包括每千行代码缺陷率和开发方风险；

根据所述可靠性评估指标，确定所述软件的测试要求，所述测试要求包括代码测试行数和代码缺陷个数；

获取所述软件中的代码行数；

当所述软件中的代码行数大于或等于所述测试要求中的代码测试行数时，对所述软件中的各行代码进行一次测试，统计出现的代码缺陷个数；

当所述软件中的代码行数小于所述测试要求中的代码测试行数时，对所述软件中的各行代码进行循环测试，直到测试的代码行数等于所述测试要求中的代码测试行数，统计出现的代码缺陷个数；

当出现的代码缺陷个数小于或等于所述测试要求中的代码缺陷个数时，判定所述软件的可靠性通过测试；

当出现的代码缺陷个数大于所述测试要求中的代码缺陷个数时，判定所述软件的可靠性未通过测试；

根据出现的代码缺陷个数和测试的代码行数，确定所述软件的每千行代码缺陷率。

可选地，所述根据所述可靠性评估指标，确定所述软件的测试要求，包括：

采用如下公式确定所述测试要求中的代码测试行数和代码缺陷个数：

其中，λ为所述可靠性评估指标中的每千行代码缺陷率；χ²表示计算卡方分布值；C为卡方分布值计算过程中采用的置信度，C＝1-α，α为所述可靠性评估指标中的开发方风险；(2r+2)为卡方分布值计算过程中采用的自由度，r为所述测试要求中的代码缺陷个数，r为正整数；L为所述测试要求中的代码测试行数，L为正整数。

可选地，所述评估方法还包括：

根据测试的代码行数和出现的代码缺陷个数，确定所述软件的每千行代码缺陷率的置信上限。

进一步地，所述根据测试的代码行数和出现的代码缺陷个数，确定所述软件的每千行代码缺陷率的置信上限，包括：

采用如下公式计算所述软件的每千行代码缺陷率的置信上限：

其中，λ_L为所述软件的每千行代码缺陷率的置信上限；χ²表示计算卡方分布值；C为卡方分布值计算过程中采用的置信度，C＝1-α，α为所述可靠性评估指标中的开发方风险；(2r_i+2)为卡方分布值计算过程中采用的自由度，r_i为出现的代码缺陷个数；L_i为测试的代码行数。

可选地，所述评估方法包括：

获取所述软件中一个功能模块的代码行数；

根据所述功能模块的代码行数、测试的代码行数和出现的代码缺陷个数，确定所述功能模块的可靠度的置信下限。

进一步地，所述根据所述功能模块的代码行数、测试的代码行数和出现的代码缺陷个数，确定所述功能模块的可靠度的置信下限，包括：

采用如下公式确定所述功能模块的可靠度的置信上限：

其中，R_L为所述功能模块的可靠度的置信下限；exp表示计算以e为底数的指数函数值；χ²表示计算卡方分布值；C为卡方分布值计算过程中采用的置信度，C＝1-α，α为所述可靠性评估指标中的开发方风险；(2r_i+2)为卡方分布值计算过程中采用的自由度，r_i为出现的代码缺陷个数；L_i为测试的代码行数；n为所述功能模块的代码行数。

可选地，所述可靠性评估指标中的开发方风险包括10％、20％和30％。

另一方面，本发明实施例提供了一种软件可靠性评估装置，所述软件可靠性评估装置包括：

指标获取模块，用于获取软件的可靠性评估指标，所述可靠性评估指标包括每千行代码缺陷率和开发方风险；

要求确定模块，用于根据所述可靠性评估指标，确定所述软件的测试要求，所述测试要求包括代码测试行数和代码缺陷个数；

行数获取模块，用于获取所述软件中的代码行数；

代码测试模块，用于当所述软件中的代码行数大于或等于所述测试要求中的代码测试行数时，对所述软件中的各行代码进行一次测试，统计出现的代码缺陷个数；当所述软件中的代码行数小于所述测试要求中的代码测试行数时，对所述软件中的各行代码进行循环测试，直到测试的代码行数等于所述测试要求中的代码测试行数，统计出现的代码缺陷个数；

可靠性判定模块，用于当出现的代码缺陷个数小于或等于所述测试要求中的代码缺陷个数时，判定所述软件的可靠性通过测试；当出现的代码缺陷个数大于所述测试要求中的代码缺陷个数时，判定所述软件的可靠性未通过测试；根据出现的代码缺陷个数和测试的代码行数，确定所述软件的每千行代码缺陷率。

可选地，所述可靠性判定模块还用于，

根据测试的代码行数和出现的代码缺陷个数，确定所述软件的每千行代码缺陷率的置信上限。

可选地，所述行数获取模块还用于，获取所述软件中一个功能模块的代码行数；

所述可靠性判定模块还用于，根据所述功能模块的代码行数、测试的代码行数和出现的代码缺陷个数，确定所述功能模块的可靠度的置信下限。

本发明实施例提供的技术方案带来的有益效果是：

通过先获取软件的可靠性评估指标，进而根据可靠性评估指标确定软件的测试要求，测试要求包括代码测试行数和代码缺陷个数。再对软件中的各行代码进行测试，保证软件中的每行代码都测试到，并且测试的代码行数大于或等于测试要求中的代码测试行数，进而将代码测试过程中出现的代码缺陷个数与测试要求中的代码缺陷个数进行比较，当软件中的代码缺陷个数小于或等于测试要求中的代码缺陷个数时判定软件的可靠性通过测试。整个测试过程只需要对软件的所有代码进行一次测试或者测试行数达到测试要求即可，不需要对代码进行长时间测试，有效缩短测试时长，大大降低测试时间和测试成本。

附图说明

为了更清楚地说明本发明实施例中的技术方案，下面将对实施例描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本发明的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。

图1是本发明实施例提供的一种软件可靠性评估方法的流程图；

图2是本发明实施例提供的一种软件可靠性评估装置的结构示意图。

具体实施方式

为使本发明的目的、技术方案和优点更加清楚，下面将结合附图对本发明实施方式作进一步地详细描述。

本发明实施例提供了一种软件可靠性评估方法。图1为本发明实施例提供的一种软件可靠性评估方法的流程图。参见图1，软件可靠性评估方法包括：

步骤101：获取软件的可靠性评估指标。

在本实施例中，可靠性评估指标包括每千行代码缺陷率和开发方风险。每千行代码缺陷率为平均每一千行代码中缺陷代码的个数；开发方风险为显著性水平，即估计软件的代码缺陷在每千行代码缺陷率的要求范围内可能犯错误的概率。

在实际应用中，每千行代码缺陷率和开发方风险(通常与使用方风险相等)均由客户提出。例如，每千行代码缺陷率可以为每千行代码中缺陷代码的个数小于或等于2个，开发方风险可以包括10％、20％和30％。设定多个开发方风险，以便得到不同开发方风险对应的可靠性，有利于对软件可靠性进行更全面的评估。

步骤102：根据可靠性评估指标，确定软件的测试要求。

在本实施例中，测试要求包括代码测试行数和代码缺陷个数。代码测试行数为测试代码的最少数量，即测试的代码行数要求大于或等于代码测试行数；代码缺陷个数为缺陷代码允许出现的最多数量，即出现的缺陷代码个数要求小于或等于代码缺陷个数。

可选地，该步骤102可以包括：

采用如下公式(1)计算测试要求中的代码测试行数和代码缺陷个数：

其中，λ为可靠性评估指标中的每千行代码缺陷率；χ²表示计算卡方分布值；C为卡方分布值计算过程中采用的置信度，C＝1-α，α为可靠性评估指标中的开发方风险；(2r+2)为卡方分布值计算过程中采用的自由度，r为测试要求中的代码缺陷个数，r为正整数；L为测试要求中的代码测试行数，L为正整数。

卡方检验是一种用途广泛地计数资料的假设检验方法，主要是比较和分析至少两个变量的关联性，根本思想在于比较理论比例和实际比例的吻合程度。因此，公式(1)中的卡方分布值为在开发方风险下的代码缺陷个数，这个与代码缺陷个数相关的卡方分布值除以代码测试行数，自然与每千行代码缺陷率之间存在一定的大小关系。所以，公式(1)可以准确限定可靠性评估指标中的每千行代码缺陷率和开发方风险、测试要求中的代码测试行数和代码缺陷个数之间的关系。

另外，卡方分布服从标准正态分布，但是代码行数为正数，因此公式(1)中相应部分进行了乘以2的处理。同时考虑到代码行数为整数，缺陷代码行数计算过程中可能存在小数的情况，因此公式(1)中自由度部分进行了加上1的处理。

例如，每千行代码缺陷率为每千行代码中缺陷代码的个数小于或等于2个，开发方风险包括10％、20％和30％时得到的代码测试行数和代码缺陷个数如下表一所示：

表一可靠性评估指标与测试要求的关系表

步骤103：获取软件中的代码行数。当软件中的代码行数大于或等于测试要求中的代码测试行数时，执行步骤104；当软件中的代码行数小于测试要求中的代码测试行数时，执行步骤105。

在实际应用中，可以根据代码中的换行符号统计软件中的代码行数。

例如，软件中的代码行数为3680行，因此当开发方风险为10％时，对应的代码测试行数为3341行，对应的代码缺陷个数为3行；当开发方风险为20％时，对应的代码测试行数为2758行，对应的代码缺陷个数为3行；当开发方风险为20％时，对应的代码测试行数为2382行，对应的代码缺陷个数为3行。由于各个开发方风险对应的代码测试行数均小于软件中的代码行数，因此各个开发方风险下的测试均只对软件中的所有代码进行一次(即步骤104)。

步骤104：对软件中的各行代码进行一次测试，统计出现的代码缺陷个数。

在实际应用中，对软件中的代码逐行进行测试；当代码测试出现一个缺陷(英文：bug)时，记为一次异常。整个测试过程中记录的异常数量，即为出现的代码缺陷个数。

步骤105：对软件中的各行代码进行循环测试，直到测试的代码行数等于测试要求中的代码测试行数，统计出现的代码缺陷个数。

例如，软件中的代码行数为2000行，测试要求中的代码测试行数为3000行，则第一次对软件中的所有代码进行一次测试，第二次重新对软件中的代码进行测试，第二次的测试在完成1000行代码的测试之后立即停止。

又如，软件中的代码行数为1000行，测试要求中的代码测试行数为2500行，则第一次对软件中的所有代码进行一次测试，第二次重新对软件中的所有代码进行一次测试，第三次对软件中的代码进行测试，第三次测试在完成500行代码的测试之后立即停止。

步骤106：当出现的代码缺陷个数小于或等于测试要求中的代码缺陷个数时，判定软件的可靠性通过测试。该步骤106在执行步骤104或者步骤105之后执行。

例如，出现的代码缺陷个数为3个，等于测试要求中的代码缺陷个数，因此判定软件的可靠性通过测试。

步骤107：当出现的代码缺陷个数大于测试要求中的代码缺陷个数时，判定软件的可靠性未通过测试。该步骤107在执行步骤104或者步骤105之后执行。

步骤108：根据出现的代码缺陷个数和测试的代码行数，确定软件的每千行代码缺陷率。该步骤108在执行步骤106或者步骤107之后执行。

在实际应用中，将出现的代码缺陷个数除以测试的代码行数，即为软件的每千行代码缺陷率。

本发明实施例通过先获取软件的可靠性评估指标，进而根据可靠性评估指标确定软件的测试要求，测试要求包括代码测试行数和代码缺陷个数。再对软件中的各行代码进行测试，保证软件中的每行代码都测试到，并且测试的代码行数大于或等于测试要求中的代码测试行数，进而将代码测试过程中出现的代码缺陷个数与测试要求中的代码缺陷个数进行比较，当软件中的代码缺陷个数小于或等于测试要求中的代码缺陷个数时判定软件的可靠性通过测试。整个测试过程只需要对软件的所有代码进行一次测试或者测试行数达到测试要求即可，不需要对代码进行长时间测试，有效缩短测试时长，大大降低测试时间和测试成本。而且可靠性评估指标包括每千行代码缺陷率和开发方风险，由于测试要求是根据可靠性评估指标确定的，因此测试要求是满足开发方风险的。又由于测试结果是根据测试要求判定的，因此测试结果也是满足开发方风险的，可以达到要求的准确度。

步骤109：根据测试的代码行数和出现的代码缺陷个数，确定软件的每千行代码缺陷率的置信上限。

该步骤109为可选步骤。通过确定置信上限，以便了解软件可靠性评估的可信度。

进一步地，该步骤107可以包括：

采用如下公式(2)确定软件的每千行代码缺陷率的置信上限：

其中，λ_L为软件的每千行代码缺陷率的置信上限；χ²表示计算卡方分布值；C为卡方分布值计算过程中采用的置信度，C＝1-α，α为可靠性评估指标中的开发方风险；(2r_i+2)为卡方分布值计算过程中采用的自由度，r_i为出现的代码缺陷个数；L_i为测试的代码行数。

与公式(1)类似，公式(2)可以准确限定可靠性评估指标中的每千行代码缺陷率和开发方风险、出现的代码缺陷个数和测试的代码行数之间的关系。

例如，出现的代码缺陷个数为3个，开发方风险包括10％、20％和30％时得到的软件的每千行代码缺陷率的置信上限如下表二所示：

表二软件的每千行代码缺陷率的置信上限

步骤110：获取软件中一个功能模块的代码行数。

步骤111：根据功能模块的代码行数、测试的代码行数和出现的代码缺陷个数，确定功能模块的可靠度的置信下限。

该步骤110～步骤110为可选步骤。通过确定置信下限，以便了解功能模块可靠性评估的可信度。

进一步地，该步骤109可以包括：

采用如下公式(3)确定功能模块的可靠度的置信上限：

其中，R_L为功能模块的可靠度的置信下限；exp表示计算以e为底数的指数函数值；χ²表示计算卡方分布值；C为卡方分布值计算过程中采用的置信度，C＝1-α，α为可靠性评估指标中的开发方风险；(2r_i+2)为卡方分布值计算过程中采用的自由度，r_i为出现的代码缺陷个数；L_i为测试的代码行数；n为功能模块的代码行数。

由于各个功能模块的可靠度存在很小的波动，因此公式(3)在公式(2)的基础上计算以e为底数的指数函数值，有利于放大各个功能模块的可靠度的差异。

例如，功能模块的代码行数为165行，开发方风险包括10％、20％和30％时得到的功能模块的可靠度的置信下限如下表三所示：

表三功能模块的可靠度的置信下限

本发明实施例提供了一种软件可靠性评估装置，适用于实现图1所示的软件可靠性评估方法。图2为本发明实施例提供的一种软件可靠性评估装置的结构示意图。参见图2，软件可靠性评估装置包括：

指标获取模块201，用于获取软件的可靠性评估指标，可靠性评估指标包括每千行代码缺陷率和开发方风险；

要求确定模块202，用于根据可靠性评估指标，确定软件的测试要求，测试要求包括代码测试行数和代码缺陷个数；

行数获取模块203，用于获取软件中的代码行数；

代码测试模块204，用于当软件中的代码行数大于或等于测试要求中的代码测试行数时，对软件中的各行代码进行一次测试，统计出现的代码缺陷个数；当软件中的代码行数小于测试要求中的代码测试行数时，对软件中的各行代码进行循环测试，直到测试的代码行数等于测试要求中的代码测试行数，统计出现的代码缺陷个数；

可靠性判定模块205，用于当出现的代码缺陷个数小于或等于测试要求中的代码缺陷个数时，判定软件的可靠性通过测试；当出现的代码缺陷个数大于测试要求中的代码缺陷个数时，判定软件的可靠性未通过测试；根据出现的代码缺陷个数和测试的代码行数，确定软件的每千行代码缺陷率。

可选地，可靠性评估指标中的开发风险可以包括10％、20％和30％。

可选地，要求确定模块202可以用于，采用公式(1)计算测试要求中的代码测试行数和代码缺陷行数。

可选地，可靠性判定模块205还可以用于，

根据测试的代码行数和出现的代码缺陷个数，确定软件的每千行代码缺陷率的置信上限。

进一步地，可靠性判定模块205可以采用公式(2)确定软件的每千行代码缺陷率的置信上限。

可选地，行数获取模块还可以用于，获取软件中一个功能模块的代码行数。

相应地，可靠性判定模块205可以还可以用于，根据功能模块的代码行数、测试的代码行数和出现的代码缺陷个数，确定功能模块的可靠度的置信下限。

进一步地，可靠性判定模块205可以采用公式(3)确定功能模块的可靠度的置信上限。

需要说明的是：上述实施例提供的软件可靠性评估装置在评估软件可靠性评估时，仅以上述各功能模块的划分进行举例说明，实际应用中，可以根据需要而将上述功能分配由不同的功能模块完成，即将装置的内部结构划分成不同的功能模块，以完成以上描述的全部或者部分功能。另外，上述实施例提供的软件可靠性评估装置与软件可靠性评估方法实施例属于同一构思，其具体实现过程详见方法实施例，这里不再赘述。

上述本发明实施例序号仅仅为了描述，不代表实施例的优劣。

本领域普通技术人员可以理解实现上述实施例的全部或部分步骤可以通过硬件来完成，也可以通过程序来指令相关的硬件完成，所述的程序可以存储于一种计算机可读存储介质中，上述提到的存储介质可以是只读存储器，磁盘或光盘等。

以上所述仅为本发明的较佳实施例，并不用以限制本发明，凡在本发明的精神和原则之内，所作的任何修改、等同替换、改进等，均应包含在本发明的保护范围之内。

Claims (10)

1.一种软件可靠性评估方法，其特征在于，所述软件可靠性评估方法包括：

获取软件的可靠性评估指标，所述可靠性评估指标包括每千行代码缺陷率和开发方风险；

根据所述可靠性评估指标，确定所述软件的测试要求，所述测试要求包括代码测试行数和代码缺陷个数；

获取所述软件中的代码行数；

当所述软件中的代码行数大于或等于所述测试要求中的代码测试行数时，对所述软件中的各行代码进行一次测试，统计出现的代码缺陷个数；

当所述软件中的代码行数小于所述测试要求中的代码测试行数时，对所述软件中的各行代码进行循环测试，直到测试的代码行数等于所述测试要求中的代码测试行数，统计出现的代码缺陷个数；

当出现的代码缺陷个数小于或等于所述测试要求中的代码缺陷个数时，判定所述软件的可靠性通过测试；

当出现的代码缺陷个数大于所述测试要求中的代码缺陷个数时，判定所述软件的可靠性未通过测试；

根据出现的代码缺陷个数和测试的代码行数，确定所述软件的每千行代码缺陷率。

2.根据权利要求1所述的软件可靠性评估方法，其特征在于，所述根据所述可靠性评估指标，确定所述软件的测试要求，包括：

采用如下公式确定所述测试要求中的代码测试行数和代码缺陷个数：

其中，λ为所述可靠性评估指标中的每千行代码缺陷率；χ²表示计算卡方分布值；C为卡方分布值计算过程中采用的置信度，C＝1-α，α为所述可靠性评估指标中的开发方风险；(2r+2)为卡方分布值计算过程中采用的自由度，r为所述测试要求中的代码缺陷个数，r为正整数；L为所述测试要求中的代码测试行数，L为正整数。

3.根据权利要求1或2所述的软件可靠性评估方法，其特征在于，所述评估方法还包括：

根据测试的代码行数和出现的代码缺陷个数，确定所述软件的每千行代码缺陷率的置信上限。

4.根据权利要求3所述的软件可靠性评估方法，其特征在于，所述根据测试的代码行数和出现的代码缺陷个数，确定所述软件的每千行代码缺陷率的置信上限，包括：

采用如下公式计算所述软件的每千行代码缺陷率的置信上限：

其中，λ_L为所述软件的每千行代码缺陷率的置信上限；χ²表示计算卡方分布值；C为卡方分布值计算过程中采用的置信度，C＝1-α，α为所述可靠性评估指标中的开发方风险；(2r_i+2)为卡方分布值计算过程中采用的自由度，r_i为出现的代码缺陷个数；L_i为测试的代码行数。

5.根据权利要求1或2所述的软件可靠性评估方法，其特征在于，所述评估方法包括：

获取所述软件中一个功能模块的代码行数；

根据所述功能模块的代码行数、测试的代码行数和出现的代码缺陷个数，确定所述功能模块的可靠度的置信下限。

6.根据权利要求5所述的软件可靠性评估方法，其特征在于，所述根据所述功能模块的代码行数、测试的代码行数和出现的代码缺陷个数，确定所述功能模块的可靠度的置信下限，包括：

采用如下公式确定所述功能模块的可靠度的置信上限：

其中，R_L为所述功能模块的可靠度的置信下限；exp表示计算以e为底数的指数函数值；χ²表示计算卡方分布值；C为卡方分布值计算过程中采用的置信度，C＝1-α，α为所述可靠性评估指标中的开发方风险；(2r_i+2)为卡方分布值计算过程中采用的自由度，r_i为出现的代码缺陷个数；L_i为测试的代码行数；n为所述功能模块的代码行数。

7.根据权利要求1或2所述的软件可靠性评估方法，其特征在于，所述可靠性评估指标中的开发方风险包括10％、20％和30％。

8.一种软件可靠性评估装置，其特征在于，所述软件可靠性评估装置包括：

指标获取模块，用于获取软件的可靠性评估指标，所述可靠性评估指标包括每千行代码缺陷率和开发方风险；

要求确定模块，用于根据所述可靠性评估指标，确定所述软件的测试要求，所述测试要求包括代码测试行数和代码缺陷个数；

行数获取模块，用于获取所述软件中的代码行数；

代码测试模块，用于当所述软件中的代码行数大于或等于所述测试要求中的代码测试行数时，对所述软件中的各行代码进行一次测试，统计出现的代码缺陷个数；当所述软件中的代码行数小于所述测试要求中的代码测试行数时，对所述软件中的各行代码进行循环测试，直到测试的代码行数等于所述测试要求中的代码测试行数，统计出现的代码缺陷个数；

可靠性判定模块，用于当出现的代码缺陷个数小于或等于所述测试要求中的代码缺陷个数时，判定所述软件的可靠性通过测试；当出现的代码缺陷个数大于所述测试要求中的代码缺陷个数时，判定所述软件的可靠性未通过测试；根据出现的代码缺陷个数和测试的代码行数，确定所述软件的每千行代码缺陷率。

9.根据权利要求8所述的软件可靠性评估装置，其特征在于，所述可靠性判定模块还用于，

根据测试的代码行数和出现的代码缺陷个数，确定所述软件的每千行代码缺陷率的置信上限。

10.根据权利要求8或9所述的软件可靠性评估装置，其特征在于，所述行数获取模块还用于，获取所述软件中一个功能模块的代码行数；

所述可靠性判定模块还用于，根据所述功能模块的代码行数、测试的代码行数和出现的代码缺陷个数，确定所述功能模块的可靠度的置信下限。

Images