CN110347580A - 一种构建非嵌入式软件可靠性测试过程模型的方法 - Google Patents

Abstract

本发明涉及一种构建非嵌入式软件可靠性测试过程模型的方法，包括以下步骤：软件可靠性测试策划阶段；软件可靠性测试大纲评审阶段；软件可靠性测试设计和实现阶段；软件可靠性测试执行阶段；软件可靠性测试总结阶段；软件可靠性测试总结评审阶段。本发明首先通过重点研究和解决非嵌入式软件可靠性测试的操作剖面构建、测试数据生成、测试数据分析和处理以及测试充分性评估等可靠性测试关键技术，解决“用什么方法进行非嵌入式软件可靠性测试的问题”，然后通过结合非嵌入式软件的特点，提出非嵌入式软件的可靠性测试过程模型，解决“进行非嵌入式软件可靠性测试使用什么过程模型的问题”，解决了现有技术的不足。

Description

一种构建非嵌入式软件可靠性测试过程模型的方法

技术领域

本发明属于非嵌入式软件可靠性测试技术领域，尤其涉及一种构建非嵌入式软件可靠性 测试过程模型的方法。

背景技术

随着信息技术的飞速发展，在航空航天、核能、通信等关键领域对软件的可靠性和安 全性的要求越来越高。尤其是在某些特殊的领域，由于软件的可靠性和安全性不高，从而在 软件运行过程中发生失效，导致整个系统崩溃或关键性任务未完成，最终带来灾难性的后 果。

下面列举几起因为软件失效而发生的令人印象深刻的事件：

1)1990年，AT&T长途电话网络系统由于switch语句跳出位置错误，导致6万人固话通信中断，造成至少6000万美元的损失。

2)1994年，NASA发射了新型月球探测器克莱门汀号(Clementine)，由于软件BUG，在飞向小行星时未能到达小行星，导致任务失败。

3)2014年，美国商务航空公司使用的机组调度软件存在定时器溢出BUG，导致1100个航班被迫取消，造成数百万美元的经济损失。

4)2016年，日本发射的卫星“瞳”由于在软件运行中对异常情况考虑不全，导致卫星 因自旋而解体，直接经济损失2.86亿美元。

从上述事例中可以看出，当软件的可靠性无法得到保证时，可能会造成人们重大的经 济损失，甚至会威胁到人类的生命安全。

要想从根本上提高软件的可靠性，就必须最大力度的规范软件的开发流程，尽可能充 分地进行软件测试。但是，一般情况下，我们往往只对软件进行单元测试、部件测试、集成 测试、配置项测试和系统测试等常规类的软件测试，这种测试只能尽可能多的发现一些软件 缺陷，但对软件的可靠性无法定量地去进行度量。所以，需要进行一种能对软件的可靠性进 行定量度量的测试，即对软件进行可靠性测试。

软件可靠性测试就是通过分析软件的使用场景(运行环境、用户类型和使用方式等)、 软件的工作流程及数据接口的关系，总结出软件的运行特点，并统计各个功能模块在软件实 际运行过程中的使用概率，构建出适合当前软件的操作剖面、生成测试用例，使其尽可能地 反映软件在真实环境下的运行特点。

目前为止，针对嵌入式软件的可靠性测试方法比较成熟，而对于非嵌入式软件主要是 从单元测试、集成测试、系统测试和回归测试等角度进行测试，面向可靠性测试的研究较 少，且主要集中在测试理论的研究，在相关测试技术和方法上还有诸多问题尚待解决。

发明内容

为了解决上述问题，本发明提出一种构建非嵌入式软件可靠性测试过程模型的方法， 已解决现有技术的不足。

为了解决上述问题，本发明提出一种构建非嵌入式软件可靠性测试过程模型的方法，包 括以下步骤：

步骤1：软件可靠性测试策划阶段；

步骤2：软件可靠性测试大纲评审阶段；

步骤3：软件可靠性测试设计和实现阶段；

步骤4：软件可靠性测试执行阶段；

步骤5：软件可靠性测试总结阶段；

步骤6：软件可靠性测试总结评审阶段。

优选的，所述步骤1的软件可靠性测试策划阶段包括：

1)由项目负责人下发测试项目任务通知单给测试负责人和开发负责人，开发负责人接 到任务通知单后将软件任务书、需求规格说明提交给测试负责人；

2)测试负责人根据开发方提交的非嵌入式软件任务书和需求规格说明，了解被测软件 信息，包括被测软件的运行状态、运行环境、用户类型、使用方式、软件功能组成及工作流 程、交联环境与及数据接口的关系，并编写出针对本次非嵌入式软件进行软件可靠性测试所 需要的软件可靠性增长测试项目计划或软件可靠性验证测试项目计划；

3)确定非嵌入式软件可靠性测试的环境要求，包括软硬件设备，并给出构建测试环境 的初步方案；

4)结合测试环境和非嵌入式软件的特点，确定非嵌入式软件的可靠性测试关键技术， 如软件可靠性测试操作剖面的构建技术、软件可靠性测试数据生成技术、软件可靠性测试数 据分析与处理技术和软件可靠性测试充分性评估技术；

5)若当前测试为软件可靠性增长测试，则定义失效和可靠性目标，失效和可靠性目标 的定义可由测试方、开发方和用户共同完成；如果软件可靠性要求是根据不同故障等级的失 效提出的，那么按照软件的故障等级对软件失效进行分类，根据不同故障等级的失效数据对 当前软件进行可靠性评估；

6)若当前测试为软件可靠性验证测试，则确定适用于非嵌入式软件的验证统计测试方 案；软件可靠性验证测试中可以选用的统计方案包括：定时截尾方案、序贯方案和无失效运 行方案；

7)确定需采集的数据及采集要求，根据测试的要求，确定要采集的数据及记录方式。

优选的，所述步骤2的软件可靠性测试大纲评审阶段包括：

1)审查测试大纲内容的正确性、完整性和规范性；

2)审查测试策略的正确性和合理性；

3)审查测试过程中使用的评价准则和方法的正确性；

4)审查测试进度的合理性；

5)审查测试任务的结束条件的合理性和正确性。

优选的，所述步骤3的软件可靠性测试设计和实现阶段包括：

1)构造操作剖面，通过对现有的操作剖面构建方法进行对比分析，并结合非嵌入式软 件，构建出适用于非嵌入式软件的操作剖面；

2)搭建软件可靠性测试环境；

3)生成测试用例。

优选的，所述步骤4软件可靠性测试执行阶段包括：

1)测试执行与收集失效数据，可靠性测试需要收集的数据包括软件的输入/输出数据、 软件运行时间数据和可靠性失效数据；

2)测试结果分析与处理，将发现的测试问题按问题的类型加以处理，包括以下两种：

责任问题，由于被测软件本身的缺陷引起的软件问题称为责任问题，此类问题计入被测 软件失效；对于在测试过程中出现的软件失效，如果是增长测试，则在测试期间对其进行更 改；如果是验证测试，则不对其进行修改；

非责任问题，由于被测软件之外的其他测试软件/设备出现问题、使用测试方法的错 误、或测试步骤的不当所引起的软件问题成为非责任问题，非责任问题不计入软件失效，对 产生的问题原因进行更改，确认更改正确后重新投入测试；

3)测试充分性评估，根据不同的软件测试目的，对软件可靠性测试充分性评估分为软 件可靠性验证测试充分性评估和软件可靠性增长测试充分性评估。

优选的，所述测试充分性评估中，当前测试为软件可靠性增长测试，需要满足以下四个 条件：

当前软件已达到软件可靠性要求，在此阶段需要验证被测软件是否满足测试阶段所规定 的可靠性要求；

当前软件中的关键缺陷已被排除，在对被测软件进行软件可靠性增长测试时，将可靠性 测试工程师发现的软件缺陷提交给开发负责人，由开发负责人分配缺陷给开发工程师，开发 工程师对其进行修复，直到测试工程师认为关键缺陷被排除，且在修复过程中未引入新的问 题为止；

满足最小测试用例数，依据被测软件任务书或需求规格说明中给出的失效概率，得出本 次可靠性测试需要满足的最小测试用例数，只有在此用例集中的所有测试用例执行完之后的 结果均与预期输出一致的情况下，才能认为被测软件的失效概率满足指标要求；否则，就认 为被测软件的失效概率不满足指标要求；

满足测试资源的约束，若在一定的测试资源下能排除的软件故障不能再增加或增加很少 的情况下，停止增加测试资源。

优选的，所述测试充分性评估中，若当前测试为软件可靠性验证测试，不需要对测试过 程中发现的软件缺陷进行修复，需要满足以下两个条件：

通过定量估计软件的可靠性，给出接收/拒收回答，根据在测试策划阶段确定的验证统 计测试方案以及测试执行阶段收集的失效数据，得出软件可靠性验证测试的判决是接收还是 拒收；同时，根据给定的置信度计算出被测软件的MTTF置信区间；

满足最小测试用例数，依据被测软件任务书或需求规格说明中给出的失效概率，得出本 次可靠性测试需要满足的最小测试用例数，在此用例集中的所有测试用例执行完之后的结果 均与预期输出一致的情况下，才认为被测软件的失效概率满足指标要求；否则，就认为被测 软件的失效概率不满足指标要求。

优选的，所述步骤6的软件可靠性测试总结评审阶段包括：

审查测试文档与相关记录内容的正确性、完整性和规范性；

审查测试环境是否满足测试要求；

审查软件可靠性测试报告与软件测试记录和缺陷记录的一致性；

审查实际测试过程是否与测试大纲、测试说明中要求的一致；

审查测试过程中暴露的问题是否已经归零或有明确处理意见；

审查测试结论的真实性、正确性、准确性。

本发明的有益效果：本发明首先通过重点研究和解决非嵌入式软件可靠性测试的操作剖 面构建、测试数据生成、测试数据分析和处理以及测试充分性评估等可靠性测试关键技术， 解决“用什么方法进行非嵌入式软件可靠性测试的问题”，然后通过结合非嵌入式软件的特 点，提出非嵌入式软件的可靠性测试过程模型，解决“进行非嵌入式软件可靠性测试使用什 么过程模型的问题”，解决了现有技术的不足。

附图说明

图1为本发明操作剖面构建流程图。

图2为本发明的方法流程图。

具体实施方式

现结合附图对本发明作进一步详细说明：

非嵌入式软件的可靠性测试过程模型包括软件可靠性增长测试过程模型和软件可靠性验 证测试模型。

非嵌入式软件可靠性测试过程划分为如下五个阶段：软件可靠性测试策划阶段、软件可 靠性测试大纲评审阶段、软件可靠性测试设计和实现阶段、软件可靠性测试执行阶段、软件 可靠性测试总结阶段和软件可靠性测试总结评审阶段。

一、测试策划阶段

该阶段的主要工作包括以下内容：

1)由项目负责人下发测试项目任务通知单给测试负责人和开发负责人，开发负责人接 到任务通知单后将软件任务书、需求规格说明提交给测试负责人；

2)测试负责人根据开发方提交的非嵌入式软件任务书和需求规格说明，全面而深入的 了解被测软件信息，包括被测软件的运行状态、运行环境、用户类型、使用方式、软件功能 组成及工作流程、交联环境与及数据接口的关系等，并编写出针对本次非嵌入式软件进行软 件可靠性测试所需要的软件可靠性增长测试项目计划或软件可靠性验证测试项目计划；

3)确定非嵌入式软件可靠性测试的环境要求，包括软硬件设备等，并给出构建测试环 境的初步方案；

4)结合测试环境和非嵌入式软件的特点，确定非嵌入式软件的可靠性测试关键技术， 如软件可靠性测试操作剖面的构建技术、软件可靠性测试数据生成技术、软件可靠性测试数 据分析与处理技术和软件可靠性测试充分性评估技术等；

5)若当前测试为软件可靠性增长测试，则需要定义失效和可靠性目标。失效和可靠性 目标的定义可由测试方、开发方和用户共同完成。如果软件可靠性要求是根据不同故障等级 的失效提出的，那么就应该按照软件的故障等级对软件失效进行分类，以便根据不同故障等 级的失效数据对当前软件进行可靠性评估。

6)若当前测试为软件可靠性验证测试，则需要确定适用于非嵌入式软件的验证统计测 试方案。一般情况下，软件可靠性验证测试中可以选用的统计方案主要包括：定时截尾方 案、序贯方案和无失效运行方案。

7)确定需采集的数据及采集要求。根据测试的要求，确定要采集的数据及记录方式。

此阶段的主要输出是软件可靠性测试大纲。一般情况下，软件可靠性测试大纲完成后需 要组织评审。

二、大纲评审阶段

针对编写的非嵌入式软件可靠性测试大纲，由项目负责人、开发人员(开发负责人、开 发工程师)、测试人员(测试负责人、可靠性测试工程师)和质量保证(QA)人员共同对其 进行评审，主要内容有：

1)审查测试大纲内容的正确性、完整性和规范性；

2)审查测试策略的正确性和合理性；

3)审查测试过程中使用的评价准则和方法的正确性；

4)审查测试进度的合理性；

5)审查测试任务的结束条件的合理性和正确性。

待大纲评审会议结束后，测试人员根据评审意见将修改完的软件可靠性测试大纲提交给 开发方负责人和项目负责人。

三、测试设计和实现阶段

该阶段的主要工作包括构造操作剖面与建立测试环境，以及在此基础上生成软件可靠性 测试用例。

1)构造操作剖面。构造操作剖面是软件可靠性测试中的一项关键技术，也是软件可靠 性测试区别于其他类型软件测试方法的关键环节之一。其核心思想是通过对现有的操作剖面 构建方法进行对比分析，并结合非嵌入式软件的特点，构建出适用于非嵌入式软件的操作剖 面。

非嵌入式软件具有以下特点：

使用软件的直接用户是软件操作人员，间接用户有软件所在系统的其他软件和其他 交互系统的软件。软件的输入方式包括交联系统的消息输入，还包括人机界面的操作输入。

在软件运行中管理者根据实际的工作需要执行各功能，并且没有固定的执行顺序和 工作流程。各功能之间相对独立，可以重复执行多次，也可能从未执行。

被测软件在运行过程中长时间处于巡视状态。在巡视状态下被测软件处于对系统的 监控之中，没有对软件的输入激励，软件不做任何的功能处理；当有消息处理时进入工作状 态，执行相关的功能流程，当工作完成后返回到巡视状态中。

软件不需要频繁的上电和断电，软件长时间保持在运行状态。因此，对被测软件一 次完整的使用并不是传统的软件以上电为开始到断电结束，而是指执行一次完整的工作流 程，即以进入工作状态为开始，到返回巡视状态为结束。

操作剖面的建模过程就是用户对软件使用情况的建模过程。

由于非嵌入式软件的运行往往会依赖于当前的操作系统、网络状况或使用场景，在操作 过程中也更多的是对按键、对编辑框、下拉框的操作，所以，在剖面的构建过程中，应该更 侧重于验证软件的以下方面：

在不同的操作系统下或不同的网络状况下，软件界面的显示及界面风格能够保持与 软件任务书或软件需求规格说明中要求的一致；

对于错误的命令或非法数据的输入具有一定的检测能力，能够及时报错或给出提 示；

对于非常规操作、误操作能够采取一定的规避措施，以防软件因异常操作而出现死 机或非法退出的情况；

对于可能导致软件运行方式改变的一些边界条件或环境条件软件要进行判断并给出 正确处理；

对于显示界面的输入框、下拉框内容中输入数据类型和长度要进行判断或限制；

对于错误操作流程要进行检测与提示。

对键盘的一些常用快捷键进行屏蔽或处理，不要实现一些任务书或软件需求规格说 明中未规定的功能。

2)搭建软件可靠性测试环境。正常情况下，测试环境应该尽可能地与真实运行环境相 同。如果真实测试环境受限，也可以使用仿真测试环境进行测试，但仿真测试环境必须满足 任务书或需求中提出的接口需求。

3)生成测试用例。根据构造的操作剖面，结合非嵌入式软件的测试输入特点：

测试输入与测试环境：包括硬件和软件测试环境；

测试输入方式和分类：输入方式包括直接操作、测试面板、数据文件等，分类包括 连续性/离散性、直接输入/相关测试输入/故障测试输入等；

测试输入之间的关系：包括顺序、并发、约束等；

选择合适的抽样方法、生成确定型/变化型的操作序列，最终得到软件可靠性测试数 据。常用的抽样方法包括概率分支抽样、范围均值抽样和偏移量抽样等。

该阶段的主要输出是软件可靠性测试说明，软件可靠性测试用例集作为软件可靠性测试 说明的附件。鉴于操作剖面的构架好坏在软件可靠性测试中起到了关键性的作用，所以在操 作剖面构建完成之后需要进行严格的评审，重点审查操作剖面的合理性和测试环境的可行 性。

四、测试执行阶段

该阶段主要进行的工作为由测试方对开发单位提交的被测软件执行测试用例，记录、分 析测试结果并收集失效数据，同时进行数据处理和测试充分性评估。

1)测试执行与收集失效数据。可靠性测试需要收集的数据包括软件的输入/输出数据、 软件运行时间数据和可靠性失效数据。测试数据收集的质量与最终的可靠性分析结果息息相 关、相互影响，因此，在数据收集的过程中应尽可能采用自动化手段，以提高效率、准确性 和完整性。

软件输入/输出数据的收集：根据软件的需求规格说明、概要设计、详细设计和接口文 档等输入类文档，分析出软件的使用场景(运行环境、用户类型和使用方式等)、软件功能 组成及工作流程、交联环境与及数据接口的关系，得出整个软件所需要的所有输入数据和预 期输出结果。然后，通过执行软件各功能的工作流程，获得软件的实际输出结果。

软件运行时间数据的收集：软件可靠性测试的直接结果是得到了一些故障数据，这些数 据同时也是软件可靠性测试过程模型的输入数据，但是不同的模型要求输入的数据类型是不 同的。通常有失效时间数据、失效间隔时间数据、分组数据和分组时间内的累积失效数等。

软件失效数据的收集：需收集的失效数据包括故障时间数据、故障数数据和故障等级3 种。

2)测试结果分析与处理。需要将发现的测试问题按问题的类型加以处理，通常情况下 分为两种：

责任问题。由于被测软件本身的缺陷引起的软件问题成为责任问题，此类问题计入 被测软件失效。对于在测试过程中出现的软件失效，如果是增长测试，则在测试期间应对其 进行更改；如果是验证测试，则不对其进行修改。

非责任问题。由于被测软件之外的其他测试软件/设备出现问题、使用测试方法的错 误、或测试步骤的不当所引起的软件问题成为非责任问题。对于非责任问题不计入软件失 效，此时应通知相关人员对产生的问题原因进行更改，确认更改正确后重新投入测试。

另外，还需要对数据进行预处理，如进行滤波处理等。

3)测试充分性评估。

根据不同的软件测试目的，对软件可靠性测试充分性评估也分为软件可靠性验证测试充 分性评估和软件可靠性增长测试充分性评估。若当前测试为软件可靠性增长测试，则需要满 足以下四个条件：

当前软件已达到软件可靠性要求。在此阶段需要验证被测软件是否满足测试阶段所 规定的可靠性要求。

当前软件中的关键缺陷已被排除。在对被测软件进行软件可靠性增长测试时，需要 将可靠性测试工程师发现的软件缺陷提交给开发负责人，由开发负责人分配缺陷给开发工程 师，开发工程师对其进行修复，直到测试工程师认为关键缺陷被排除，且在修复过程中未引 入新的问题为止。

满足最小测试用例数。依据被测软件任务书或需求规格说明中给出的失效概率，得 出本次可靠性测试需要满足的最小测试用例数，只有在此用例集中的所有测试用例执行完之 后的结果均与预期输出一致的情况下，才能认为被测软件的失效概率满足指标要求；否则， 就认为被测软件的失效概率不满足指标要求。

满足测试资源的约束。若在一定的测试资源下能排除的软件故障不能再增加或增加 很少的情况下，就应该停止增加测试资源，以防造成测试资源的浪费。

若当前测试为软件可靠性验证测试，则不需要对测试过程中发现的软件缺陷进行修复， 故只需要满足以下两个条件：

通过定量估计软件的可靠性，给出接收/拒收回答。根据在测试策划阶段确定的验证 统计测试方案以及测试执行阶段收集的失效数据，得出软件可靠性验证测试的判决结果(接 收/拒收)。同时，根据给定的置信度计算出被测软件的MTTF置信区间。

满足最小测试用例数。依据被测软件任务书或需求规格说明中给出的失效概率，得 出本次可靠性测试需要满足的最小测试用例数，只有在此用例集中的所有测试用例执行完之 后的结果均与预期输出一致的情况下，才能认为被测软件的失效概率满足指标要求；否则， 就认为被测软件的失效概率不满足指标要求。

该阶段的主要输出是软件可靠性测试记录和缺陷记录。这两份文档作为最终的软件可靠 性测试报告的附件。

五、测试总结阶段

在该阶段主要进行的工作为对非嵌入式软件可靠性测试过程和结果进行总结，给出软件 的可靠性验证测试结论。该阶段的主要输出为软件可靠性测试报告。

六、总结评审阶段

测试总结评审对象为非嵌入式软件可靠性测试报告(含测试记录、缺陷记录)，测试总 结评审的主要内容有：

审查测试文档与相关记录内容的正确性、完整性和规范性；

审查测试环境是否满足测试要求；

审查软件可靠性测试报告与软件测试记录和缺陷记录的一致性；

审查实际测试过程是否与测试大纲、测试说明中要求的一致；

审查测试过程中暴露的问题是否已经归零或有明确处理意见；

审查测试结论的真实性、正确性、准确性。

待总结评审会议结束后，测试人员根据评审意见将修改完的软件可靠性测试报告提交给 开发方负责人和项目负责人。

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

Claims (8)

1.一种构建非嵌入式软件可靠性测试过程模型的方法，其特征在于,包括以下步骤：

步骤1：软件可靠性测试策划阶段；

步骤2：软件可靠性测试大纲评审阶段；

步骤3：软件可靠性测试设计和实现阶段；

步骤4：软件可靠性测试执行阶段；

步骤5：软件可靠性测试总结阶段；

步骤6：软件可靠性测试总结评审阶段。

2.根据权利要求1所述的一种构建非嵌入式软件可靠性测试过程模型的方法，其特征在于：所述步骤1的软件可靠性测试策划阶段包括：

1)由项目负责人下发测试项目任务通知单给测试负责人和开发负责人，开发负责人接到任务通知单后将软件任务书、需求规格说明提交给测试负责人；

2)测试负责人根据开发方提交的非嵌入式软件任务书和需求规格说明，了解被测软件信息，包括被测软件的运行状态、运行环境、用户类型、使用方式、软件功能组成及工作流程、交联环境与及数据接口的关系，并编写出针对本次非嵌入式软件进行软件可靠性测试所需要的软件可靠性增长测试项目计划或软件可靠性验证测试项目计划；

3)确定非嵌入式软件可靠性测试的环境要求，包括软硬件设备，并给出构建测试环境的初步方案；

4)结合测试环境和非嵌入式软件的特点，确定非嵌入式软件的可靠性测试关键技术，如软件可靠性测试操作剖面的构建技术、软件可靠性测试数据生成技术、软件可靠性测试数据分析与处理技术和软件可靠性测试充分性评估技术；

5)若当前测试为软件可靠性增长测试，则定义失效和可靠性目标，失效和可靠性目标的定义可由测试方、开发方和用户共同完成；如果软件可靠性要求是根据不同故障等级的失效提出的，那么按照软件的故障等级对软件失效进行分类，根据不同故障等级的失效数据对当前软件进行可靠性评估；

6)若当前测试为软件可靠性验证测试，则确定适用于非嵌入式软件的验证统计测试方案；软件可靠性验证测试中可以选用的统计方案包括：定时截尾方案、序贯方案和无失效运行方案；

7)确定需采集的数据及采集要求，根据测试的要求，确定要采集的数据及记录方式。

3.根据权利要求1所述的一种构建非嵌入式软件可靠性测试过程模型的方法，其特征在于，所述步骤2的软件可靠性测试大纲评审阶段包括：

1)审查测试大纲内容的正确性、完整性和规范性；

2)审查测试策略的正确性和合理性；

3)审查测试过程中使用的评价准则和方法的正确性；

4)审查测试进度的合理性；

5)审查测试任务的结束条件的合理性和正确性。

4.根据权利要求1所述的一种构建非嵌入式软件可靠性测试过程模型的方法，其特征在于，所述步骤3的软件可靠性测试设计和实现阶段包括：

1)构造操作剖面，通过对现有的操作剖面构建方法进行对比分析，并结合非嵌入式软件，构建出适用于非嵌入式软件的操作剖面；

2)搭建软件可靠性测试环境；

3)生成测试用例。

5.根据权利要求1所述的一种构建非嵌入式软件可靠性测试过程模型的方法，其特征在于，所述步骤4软件可靠性测试执行阶段包括：

1)测试执行与收集失效数据，可靠性测试需要收集的数据包括软件的输入/输出数据、软件运行时间数据和可靠性失效数据；

2)测试结果分析与处理，将发现的测试问题按问题的类型加以处理，包括以下两种：

责任问题，由于被测软件本身的缺陷引起的软件问题称为责任问题，此类问题计入被测软件失效；对于在测试过程中出现的软件失效，如果是增长测试，则在测试期间对其进行更改；如果是验证测试，则不对其进行修改；

非责任问题，由于被测软件之外的其他测试软件/设备出现问题、使用测试方法的错误、或测试步骤的不当所引起的软件问题成为非责任问题，非责任问题不计入软件失效，对产生的问题原因进行更改，确认更改正确后重新投入测试；

3)测试充分性评估，根据不同的软件测试目的，对软件可靠性测试充分性评估分为软件可靠性验证测试充分性评估和软件可靠性增长测试充分性评估。

6.根据权利要求5所述的一种构建非嵌入式软件可靠性测试过程模型的方法，其特征在于，所述测试充分性评估中，当前测试为软件可靠性增长测试，需要满足以下四个条件：

当前软件已达到软件可靠性要求，在此阶段需要验证被测软件是否满足测试阶段所规定的可靠性要求；

当前软件中的关键缺陷已被排除，在对被测软件进行软件可靠性增长测试时，将可靠性测试工程师发现的软件缺陷提交给开发负责人，由开发负责人分配缺陷给开发工程师，开发工程师对其进行修复，直到测试工程师认为关键缺陷被排除，且在修复过程中未引入新的问题为止；

满足最小测试用例数，依据被测软件任务书或需求规格说明中给出的失效概率，得出本次可靠性测试需要满足的最小测试用例数，只有在此用例集中的所有测试用例执行完之后的结果均与预期输出一致的情况下，才能认为被测软件的失效概率满足指标要求；否则，就认为被测软件的失效概率不满足指标要求；

满足测试资源的约束，若在一定的测试资源下能排除的软件故障不能再增加或增加很少的情况下，停止增加测试资源。

7.根据权利要求5所述的一种构建非嵌入式软件可靠性测试过程模型的方法，其特征在于，所述测试充分性评估中，若当前测试为软件可靠性验证测试，不需要对测试过程中发现的软件缺陷进行修复，需要满足以下两个条件：

通过定量估计软件的可靠性，给出接收/拒收回答，根据在测试策划阶段确定的验证统计测试方案以及测试执行阶段收集的失效数据，得出软件可靠性验证测试的判决是接收还是拒收；同时，根据给定的置信度计算出被测软件的MTTF置信区间；

满足最小测试用例数，依据被测软件任务书或需求规格说明中给出的失效概率，得出本次可靠性测试需要满足的最小测试用例数，在此用例集中的所有测试用例执行完之后的结果均与预期输出一致的情况下，才认为被测软件的失效概率满足指标要求；否则，就认为被测软件的失效概率不满足指标要求。

8.根据权利要求1所述的一种构建非嵌入式软件可靠性测试过程模型的方法，其特征在于，所述步骤6的软件可靠性测试总结评审阶段包括：

审查测试文档与相关记录内容的正确性、完整性和规范性；

审查测试环境是否满足测试要求；

审查软件可靠性测试报告与软件测试记录和缺陷记录的一致性；

审查实际测试过程是否与测试人纲、测试说明中要求的一致；

审查测试过程中暴露的问题是否已经归零或有明确处理意见；

审查测试结论的真实性、正确性、准确性。