CN101847123B - 一种机载计算机软件测试通用体系的构建方法 - Google Patents

Abstract

本发明一种机载计算机软件测试通用体系的构建方法，它有五大步骤：步骤一：编写测试计划文档，确立测试体系；步骤二：在代码开发的同时进行单元测试(静态)；步骤三：实际运行功能模块进行单元/集成测试(动态)；步骤四：单元/集成测试完成后进行系统测试；步骤五：验收测试；本发明是一种机载计算机软件测试通用体系，它通过建立一个与代码开发并行的测试体系，最经济、有效地达到测试目的，增强了软件系统的规范性及可靠性，软件测试人员可以依据具体需求，完整、高效地部署并执行测试工作。它在机载计算机软件测试技术领域里具有实用价值和广阔地应用前景。

Description

一种机载计算机软件测试通用体系的构建方法

技术领域

本发明涉及一种机载计算机软件测试通用体系的构建方法，属于机载计算机软件测试技术领域，具体涉及到软件的静态测试、单元/集成测试、系统测试等。

背景技术

机载计算机软件属于嵌入式软件领域，近年来，由于软件功能的逐步增强和规模的逐步扩大，其测试的需求也日益显现，并朝着规范化、系统化发展。依据软件工程的原理，机载计算机软件测试流程，可分为静态测试和动态测试两部分。静态测试主要是在飞行控制软件的各功能模块代码编写完成后，对软件的编程格式、结构等方面进行检查。动态测试则是检验软件各功能模块的实际运行效果是否符合设计标准，根据测试方法可分为白盒与黑盒测试等。

目前机载计算机软件测试过程中，由于缺乏嵌入式软件测试经验以及多数开发人员“重代码轻测试”的开发习惯，测试工作往往仅由开发人员凭经验直接测试自己编写的代码，并没有专业测试人员参与。根据国外近几年来的嵌入式软件开发经验，此种模式开发的应用软件可靠性难以保证，错误定位时间长，后期测试费用偏高。为解决此问题，本发明一种机载计算机软件测试通用体系，通过建立一个与代码开发并行的测试体系，最经济、有效地达到测试目的，增强了软件系统的规范性及可靠性。

发明内容

本发明的目的在于提供一种机载计算机软件测试通用体系的构建方法，在该体系中，软件测试人员可以依据具体需求，完整、高效地部署并执行测试工作。从而保证机载计算机系统的可靠性与及时性，有效的减少软件测试时间，缩减测试成本，提高软件开发的规范性。

本发明一种机载计算机软件测试通用体系的构建方法，其主要内容及程序是：先基于嵌入式软件开发环境以及待测软件的需求分析/概要(详细)设计文档，制定测试计划。然后跟据计划在代码开发的同时进行静态测试，以及单元/集成测试，发现问题及时反馈到开发进程中并予以修正。最后，当模块集成程度达到系统规模时，进行系统/确认测试，并给出测评结果和测试分析。

本发明一种机载计算机软件测试通用体系的构建方法，该方法具体步骤如下：

步骤一：编写测试计划文档，确立测试体系

1)编写需求业务，说明用户及功能，然后根据需求制定《测试需求分析》；

2)经评审通过《测试需求分析》并据其制定《软件总体测试计划》、《单元/(集成)测试计划》、《系统测试计划》等；

3)需求有更改时，写入《需求更改记录》，并随之修改相应测试计划文档。

步骤二：在代码开发的同时进行单元测试(静态)

功能模块开发完成后进行静态测试，内容主要包括代码和设计的一致性，代码对标准的遵循、可读性，代码的逻辑表达的正确性，代码结构的合理性等方面的问题。

具体实现：

1)数据类型问题：包括变量的数据类型是否有错，是否存在不同数据类型的赋值，是否存在不同数据类型的比较

2)变量值问题：包括变量的数据类型是否有错，是否存在不同数据类型的赋值，是否存在不同数据类型的比较；

3)逻辑判断问题：包括变量的初始化或缺省值是否有误，变量是否发生上溢或下溢，变量的精度是否足够；

4)循环问题：包括循环终止条件是否正确，是否存在无法正常终止(死循环)代码，是否错误地修改循环变量，是否有可能存在误差累积；

5)内存问题：包括使用内存之前是否正确地初始化，是否存在内存被释放后却继续被使用，是否存在内存泄漏，是否存在内存越界，是否有可能出现野指针；

6)错误处理问题：包括是否忘记进行错误处理，错误处理程序块是否有可能一直没有机会被运行，错误处理程序块本身是否有误，如与实际错误不一致，处理方式不正确等，是否存在错误处理程序块被调用之前软件已经出错；

针对机载软件开发要点，单元测试对每个程序模块，主要测试5个方面的问题：模块接口、局部数据结构、边界条件、独立的路径和错误处理。

步骤三：实际运行功能模块进行单元/集成测试(动态)

动态测试主要流程如下：

1)逐层划分功能模块，依据需求文件对各功能模块编号；

2)根据接口协议及需求对各带测模块制定测试用例；

3)从最小的独立单元模块起进行动态测试，包括功能测试和路径测试等；

4)统计测试结果，并分析测试效果和代码开发质量；

5)测试结果及问题反馈到开发人员并据此改进软件代码；

集成测试可在单元测试的基础上，以一定规则集成部分功能模块后进行，方法与单元模块测试一致。

步骤四：单元/集成测试完成后进行系统测试

集成测试完成后，退出宿主机测试环境，把系统移植到目标机上来，完成应用到现场环境中，从用户的角度对系统进行黑盒测试，验证每一项具体的功能。具体测试内容如下：

1)压力测试

压力测试的目的是想要破坏程序即检测各类非正常情形，因此需要在反常规数据量、频率或资源的方式下运行系统，以检验系统能力的最高实际限度。可以考虑的测试方法有：1.压力测试中，中断频率为正常情况下的10倍。2.把输入的数据量提高一个数量级来测试输入功能会如何响应。3.若某系统正常运行可支持10个终端并行工作，压力测试则检验50个终端并行工作的情况。4.运行大量的消耗内存或其他系统资源的测试实例。

2)性能测试

跟据项目实际情况，性能测试主要包括软件运行时的CPU占用，内存占用，堆栈占用，平均响应时间等

3)可靠性测试

可靠性测试，是从验证的角度出发，检验系统的可靠性是否达到预期的目标，同时给出当前系统可能的可靠性增长情况。关键的测试数据包括长时间运行时的失效间隔时间，失效修复时间，失效数量，失效级别等。

4)故障恢复测试

故障恢复测试是通过各种手段，强制性地使软件出错，使其不能正常工作，进而检验系统的恢复能力。本项目的恢复测试主要包括两种情况：1.如系统恢复是自动执行(由系统自身完成)，则应该检验：错误记录，重新启动，重新初始化，数据恢复是否正确。2.如果某项恢复需要人为干预，则应检验平均修复时间是否在限定的、可以接受的范围之内。

5)随机测试

随机测试主要是在测试后期，模仿用户实际操作，对系统制造大量随机输入，观察输出结果是否和设计要求一致。

6)确认测试

确认测试目的是检验所开发的软件是否能按用户提出的要求进行。根据实际情况，测试考察软件功能是否满足需求规格说明书的规定。

步骤五：验收测试

在通过对系统测试后，还需进行验收测试。验收测试是每个系统的测试活动中所必须进行的，本项测试完成后，整个测试工作才告最终结束。因此要求所被测试的软件系统和硬件系统和产品实际情况一样。

本发明一种机载计算机软件测试通用体系的构建方法，它与现有技术比，其主要优点是：运用本发明后，软件测试人员可以依据具体需求，完整、高效地部署并执行测试工作，从而保证机载计算机系统的可靠性与及时性，有效的减少软件测试时间，缩减测试成本，提高软件开发的规范性。

附图说明

图1测试工作流程图

图2单元测试任务图

图3测试体系构建图

图4单元测试文档结构图

图5系统测试文档结构图

图6单元/集成测试框架图

图7集成/系统测试任务图

本说明中所有英文符号含义说明如下：

VxWorks：美国风河公司(Wind River)开发的一种嵌入式实时操作系统，广泛应用于国防、航空航天、通信、消费电子、工业控制、汽车电子等领域。

Tornado：美国风河公司(Wind River)开发的一套强大的图形化嵌入式集成开发环境，能够实现创建和管理工程、建立和管理宿主机与目标机之间的通信以及运行、调试和监控VxWorks应用等功能。

Logiscope：瑞典Telelogic公司开发的一套自动化软件测试工具，旨在降低人工工作量、降低成本和提高可靠性，包括Audit、RuleChecker、TestChecker三个功能模块。

C++Test：美国Parasoft公司开发的一套软件测试集成解决方案，可进行编码策略增强、静态分析、综合代码复审以及单元测试和组件测试等。

具体实施方式

下面结合附图，对本发明中的各部分设计方法作进一步说明：

本发明一种机载计算机软件测试通用体系，开发环境以Tornado2.2为基础，相应目标板操作系统可以为Vxworks5.5或6.0，上位机采用Windows xp环境。单元/集成测试过程中自动化测试工具可以采用Logiscope或C++Test均可。该体系具体设计步骤如下：

步骤一：编写测试计划文档，确立测试体系

1)编写需求业务，说明用户及功能，然后根据需求制定《测试需求分析》。

整个测试流程在软件系统开发中的位置如图1所示，测试工作贯穿项目需求、设计的全过程。在《测试需求分析》中，根据项目开发的实际情况，如图3所示，需要明确测试项需求、测试时间，人力安排、测试环境、测试工具及测试中可能遇到的风险等。

2)经评审通过《测试需求分析》并据其制定《软件总体测试计划》，计划中应包括测试种类及测试通过标准、测试重点、进度安排、预测风险、暂停标准及再启动要求等。

在各测试阶段需要制定相应测试计划文档，如《单元测试计划》、《集成测试计划》、《系统测试计划》等。

3)需求有更改时，写入《需求更改记录》，并随之修改相应测试计划文档，对每次更改内容均应该编号以方便查询。

步骤二：在代码开发的同时进行单元/集成测试(静态)

功能模块开发完成后进行单元测试，包括静态与动态测试等，其文档结构图如图4所示。一般应先进行静态测试，如图2所示，内容主要包括代码和设计的一致性，代码对标准的遵循、可读性，代码的逻辑表达的正确性，代码结构的合理性等方面的问题。

具体实现：

1)数据类型问题：包括变量的数据类型是否有错，是否存在不同数据类型的赋值，是否存在不同数据类型的比较

2)变量值问题：包括变量的数据类型是否有错，是否存在不同数据类型的赋值，是否存在不同数据类型的比较

3)逻辑判断问题：包括变量的初始化或缺省值是否有误，变量是否发生上溢或下溢，变量的精度是否足够

4)循环问题：包括循环终止条件是否正确，是否存在无法正常终止(死循环)代码，是否错误地修改循环变量，是否有可能存在误差累积

5)内存问题：包括使用内存之前是否正确地初始化，是否存在内存被释放后却继续被使用，是否存在内存泄漏，是否存在内存越界，是否有可能出现野指针

6)错误处理问题：包括是否忘记进行错误处理，错误处理程序块是否有可能一直没有机会被运行，错误处理程序块本身是否有误，如与实际错误不一致，处理方式不正确等，是否存在错误处理程序块被调用之前软件已经出错

针对嵌入式软件开发要点，单元测试对每个程序模块，主要测试5个方面的问题：模块接口、局部数据结构、边界条件、独立的路径和错误处理。各测试要点如下：

模块接口测试要点：

1.调用所测模块时的输入参数与模块的形参是否匹配；

2.所测模块调用子模块时，它输入给子模块的参数与子模块中的形参是否匹配；

3.是否修改了只做输入用的形参；

4.调用函数的参数是否正确；

5.全局变量的定义在各模块中是否一致。

局部数据结构测试要点：

(1)不正确的或不一致的类型说明。

(2)错误的初始化或默认值。

(3)错误的变量名，如拼写错误或书写错误。

(4)下溢、上溢或者地址错误。

路径测试要点：

(1)误解的或不正确的算术优先级。

(2精确度不够精确。

(3)不同数据类型的比较。

(4)不正确的逻辑操作或优先级。

(5)不正确的或不存在的循环终止。

(6)不适当地修改循环变量。

边界条件测试要点：

(1)运算或判断中取最大值、最小值时是否有错误。

(2)在n次循环的第0次、1次、n次是否有错误。

(3)数据流、控制流中刚好等于、大于、小于确定的比较值是否出现错误。

出错处理测试要点：

(1)所报告的错误与实际遇到的错误不一致。

(2)出错后，在错误处理之前就引起系统的干预。

(3)例外条件的处理不正确。

(4)提供的错误信息不足，以至于无法找到错误的原因。

集成各单元模块测试时测试要点如下：

(1)穿越模块接口的数据是否丢失

(2)一个模块功能的实现是否破坏了另一个模块的功能

(3)子功能组合之后是否达到预期的功能

(4)全局数据是否被异常修改

(5)单个模块的误差是否被放大到了不能接受的地步

(6)模块集成为子系统后运行是否稳定

集成测试是在单元测试通过的基础上，按一定规则(自底向上或自顶向下)将各模块集成为子系统进行测试，集成测试的目的是当单个模块集成为子系统的过程中，软件仍然可能出现问题。按照软件开发的实际情况，可采取一次性集成测试方式或增殖式集成测试方式进行测试。

在代码人工走查初步排除错误后可使用自动化测试工具(Logiscope以及C++test)辅助进行静态测试。主要分2个步骤：

1)代码质量分析。

Logiscope Gnu.def配置：以Tornado2.2集成开发环境装在C:\盘根目录为例，目标机采用Pentium处理器(可依据开发实际情况，根据相应BSP也可配置PowerPC)

//System include paths

//TODO：complete according to your environment

IC:\Tornado2.2\target\h

IC:\Tornado2.2\target\config\pcPentium

IC:\Tornado2.2\host\x86-win32\lib\gcc-lib\i386-pc-mingw32\gcc-2.96\include

IC:\Tornado2.2\target\config\comps\src

//Compiler predefined macros

D_GNUC_＝1

D_STDC_＝1

DCPU＝PENTIUM

依照Logiscope提供的质量模型，对被检测的程序文件可以给出2部分质量检测结果：系统质量检测结果和函数质量检测结果。

其中系统质量度量元主要有：ap_cg_levl，ap_comf，ap_eloc，ap_func，ap_scomm，ap_sline，ap_sloc，ap_ssbra，ap_stat，ap_vg，ap_wmc等，可根据实际要求采用不同质量度量元来分析程序质量。

函数质量分析包括：可维护性，可分析性，适应变化性，稳定性，易测试性等。

2)编码规则检查

C++test内嵌了多套常用编码规则以供检测，如MISRA C，Effective C++，GJB5369以及Parasoft推荐规则等，也可根据实际需要自定义编码规则。

步骤三：实际运行功能模块进行单元/集成测试(动态)

单元/集成测试的主要流程如下：

1)功能模块编号

依据需求文件从上至下逐层划分功能模块，并按层级对每个功能模块进行测试编号。编号中应突出测试层级(如单元、集成、系统测试可分别用U，I，S开头编号表示Unit/Integration/System)、测试对象(如测试编号中应包括所测试的函数/文件名)及测试内容(需要测试的功能编号)等

2)制定测试用例

进行动态测试前，须对所编号的各测试项编写测试用例，测试用例按照一定规则进行编号，内容应包括输入数据，期望输出数据，实际输出数据等。各类用例制定要点如下：

黑盒(功能)测试：一般在测试模块接口处时使用。用例设计可采用等价类划分和边界值分析相结合的方法。如：输入值域为0-2000，精度为0.1，等价类用例可取{-10.2，150.6，2100.7)，边界值用例可取{0±0.1，2000±0.1)

白盒(覆盖)测试：一般在测试各模块内部路径时使用。可先对模块程序流程图进行简化，得出控制流图。然后依实际情况确定不同覆盖方式进行测试，如语句覆盖、判定覆盖、条件覆盖、判定/条件覆盖、组合覆盖和路径覆盖等，并据其制定测试数据。条件覆盖举例如下：

void TaskReadData_HighCAN1()

    {

            if(HighCAN1 Packet.m_msgID＜5)           分支1

        {

           msgQSend()；

        }

           else                                      分支2

               {

                if(msgQSend()＝＝ERROR)

        logMsg(″Send CAN Message to TaskDataManage failed！\n″，0，0，0，0，0，0)；

    }

}

路径覆盖举例如下：

void Input_Broadcast()

{

    if(CanPacket_R.m_msgID＜＝IDT_MAINNODE_4)

    {

        CanPacket_R.m_msgID＝IDT_MAINNODE_4；

    }

    switch(CanPacket_R.m_msgID)

    {

        case IDT_MAINNODE_4：路径1

        {

             Input_Timing()；

             break；

        }

        case IDNP_DETECT_BROADCAST：路径2

        {

              break；

        }

        default：break；            路径3

    }

}

3)执行测试

依照测试进度安排，从最小的独立单元模块起进行动态测试，然后逐层往上，包括功能测试和路径测试等。对于需要插桩的被测模块需首先编写好桩模块然后一并运行，大致架构如图6。测试用例编写完后，依机载软件的实际情况，方法可以选择人工测试或自动化工具辅助测试等

自动化测试工具以C++test为例，custom flow在PowerPC架构下配置如下：

<SetProperty key＝″nm″value＝″nmppc″/><！--GNU toolchain-->

<SetProperty key＝″munch_opts″value＝″-asm ppc″/>

testLogFile＝″/tgtsvr/cpptest_results.tlog″

covLogFile＝″/tgtsvr/cpptest_results.clog″

<ReadTestLogStep

            testLogFile＝″F:/cpptest_results.tlog″

            timeoutInfoProperty＝″test_exec_timeouted″/>

<ReadDynamicCoverageStep

            covLogFile＝″F:/cpptest_results.clog″

这里把C++test的Logfile放到F:\根目录下。

4)统计测试结果，并分析测试效果和代码开发质量

把单元/集成测试的用例运行的实际结果同理论结果对比，得出单元测试bug数量、覆盖率等数据，并加以分析总结。

5)测试结果及问题反馈到开发人员并据此改进软件代码

步骤四：单元/集成测试完成后进行系统测试

集成/系统测试的文档结构如图5所示，测试项分布如图7所示，根据项目开发实际情况可以有所删减。集成测试完成后，退出宿主机测试环境，把系统移植到目标机上来，完成应用到现场环境中，从用户的角度对系统进行测试，验证每一项具体的功能。具体测试内容如下：

1)压力测试

压力测试的目的是想要破坏程序即检测各类非正常情形，因此需要在反常规数据量、频率或资源的方式下运行系统，以检验系统能力的最高实际限度。可以考虑的测试方法有：1.压力测试中，中断频率为正常情况下的10倍。2.把输入的数据量提高一个数量级来测试输入功能会如何响应。3.若某系统正常运行可支持10个终端并行工作，压力测试则检验50个终端并行工作的情况。4.运行大量的消耗内存或其他系统资源的测试实例。根据机载计算机软件的实际情况，压力测试主要包括测试总线在不同周期下的表现。参考记录方式如下：

2)性能测试

根据实际情况性能测试需和压力测试结合进行，重点考察在数据传输率增大的情况下，系统的表现情况。性能测试主要包括软件运行时的CPU占用，内存占用，堆栈占用，平均响应时间等。参考记录方式如下：

3)可靠性测试

可靠性测试，是从验证的角度出发，检验系统的可靠性是否达到预期的目标，同时给出当前系统可能的可靠性增长情况。关键的测试数据包括长时间运行时的失效间隔时间，失效修复时间，失效数量，失效级别等。根据获得的测试数据，可以得到系统的失效率及可靠性增长趋势。跟据机载软件实际情况，本测试可分为正常情况长时间工作测试及故障情况长时间工作测试两类。参考记录方式如下：

4)故障恢复测试

故障恢复测试是通过各种手段，强制性地使软件出错，使其不能正常工作，进而检验系统的恢复能力。本项目的恢复测试主要包括两种情况：1.如系统恢复是自动执行(由系统自身完成)，则应该检验：错误记录，重新启动，重新初始化，数据恢复是否正确。2.如果某项恢复需要人为干预，则应检验平均修复时间是否在限定的、可以接受的范围之内。测试前，测试人员需与开发人员协商，事先拟定故障列表，并依据列表进行测试。参考记录方式如下：

5)随机测试

随机测试主要是在测试后期，模仿用户实际操作，对系统制造大量随机输入，观察输出结果是否和设计要求一致。参考记录方式如下：

6)确认测试

确认测试目的是检验所开发的软件是否能按用户提出的要求进行。根据实际情况，测试考察软件功能是否满足需求规格说明书的规定。

步骤五：验收测试

在通过对系统测试后，还需进行验收测试。验收测试是每个系统的测试活动中所必须进行的，本项测试完成后，整个测试工作才告最终结束。因此要求所被测试的软件系统和硬件系统和产品实际情况一样。

测试要点：

1.所被测的系统应该是稳定版本，各项技术指标要求符合技术文档规定。

2.验收测试应该在系统被封版后进行。

3.验收测试的测试用例有些不能够采用在确认测试中的，一般情况下必须重新制定符合验收测试的测试用例，设计时要尽量考虑到实际环境状态下，如机载软件运行时的低温、低气压条件等。

4.在进行验收测试期间，原则上开发人员不能对正在进行验收测试的系统进行修改。

Claims (1)

1.一种机载计算机软件测试通用体系的构建方法，其特征在于：该方法具体步骤如下：

步骤一：编写测试计划文档，确立测试体系

1)编写需求业务，说明用户及功能，然后根据需求制定《测试需求分析》；

2)经评审通过《测试需求分析》并据其制定《软件总体测试计划》、《单元/集成测试计划》和《系统测试计划》；

3)需求有更改时，写入《需求更改记录》，并随之修改相应测试计划文档；

步骤二：在代码开发的同时进行单元测试即静态测试；

功能模块开发完成后进行静态测试，内容主要包括代码和设计的一致性，代码对标准的遵循、可读性，代码的逻辑表达的正确性和代码结构的合理性；

具体实现的方法是：

1)数据类型问题：包括变量的数据类型是否有错，是否存在不同数据类型的赋值，是否存在不同数据类型的比较；

2)变量值问题：包括变量的数据类型是否有错，是否存在不同数据类型的赋值，是否存在不同数据类型的比较；

3)逻辑判断问题：包括变量的初始化、缺省值是否有误，变量是否发生上溢、下溢，变量的精度是否足够；

4)循环问题：包括循环终止条件是否正确，是否存在无法正常终止即死循环代码，是否错误地修改循环变量，是否有可能存在误差累积；

5)内存问题：包括使用内存之前是否正确地初始化，是否存在内存被释放后却继续被使用，是否存在内存泄漏，是否存在内存越界，是否有可能出现野指针；

6)错误处理问题：包括是否忘记进行错误处理，错误处理程序块是否有可能一直没有机会被运行，错误处理程序块本身是否有误，是否存在错误处理程序块被调用之前软件已经出错；

针对机载软件开发要点，单元测试对每个程序模块，主要测试5个方面的问题：模块接口、局部数据结构、边界条件、独立的路径和错误处理；

步骤三：实际运行功能模块进行单元/集成测试即动态测试

动态测试实现方法如下：

1)逐层划分功能模块，依据需求文件对各功能模块编号；

2)根据接口协议及需求对各代测模块制定测试用例；

3)从最小的独立单元模块起进行动态测试，包括功能测试和路径测试；

4)统计测试结果，并分析测试效果和代码开发质量；

5)测试结果及问题反馈到开发人员并据此改进软件代码；

集成测试可在单元测试的基础上，以一定规则集成部分功能模块后进行，方法与单元测试一致；

步骤四：单元/集成测试完成后进行系统测试

集成测试完成后，退出宿主机测试环境，把系统移植到目标机上来，完成应用到现场环境中，从用户的角度对系统进行黑盒测试，验证每一项具体的功能，具体测试内容如下：

1)压力测试

压力测试的目的是想要破坏程序即检测各类非正常情形，因此需要在反常规数据量、频率或资源的方式下运行系统，以检验系统能力的最高实际限度；测试方法有：1.压力测试中，中断频率为正常情况下的10倍；2.把输入的数据量提高一个数量级来测试输入功能会如何响应；3.若某系统正常运行可支持10个终端并行工作，压力测试则检验50个终端并行工作的情况；4.运行大量的消耗内存及其他系统资源的测试实例；

2)性能测试

跟据项目实际情况，性能测试主要包括软件运行时的CPU占用，内存占用，堆栈占用，和平均响应时间；

3)可靠性测试

可靠性测试，是从验证的角度出发，检验系统的可靠性是否达到预期的目标，同时给出当前系统可能的可靠性增长情况；关键的测试数据包括长时间运行时的失效间隔时间，失效修复时间，失效数量和失效级别；

4)故障恢复测试

故障恢复测试是通过各种手段，强制性地使软件出错，使其不能正常工作，进而检验系统的恢复能力；本项目的恢复测试主要包括两种情况：1.如果系统恢复是自动执行，则应该检验：错误记录，重新启动，重新初始化，数据恢复是否正确；2.如果某项恢复需要人为干预，则应检验平均修复时间是否在限定的、可以接受的范围之内；

5)随机测试

随机测试是在测试后期，模仿用户实际操作，对系统制造大量随机输入，观察输出结果是否和设计要求一致；

6)确认测试

确认测试目的是检验所开发的软件是否能按用户提出的要求进行；根据实际情况，测试考察软件功能是否满足需求规格说明书的规定；

步骤五：验收测试

在通过对系统测试后，还需进行验收测试；验收测试是每个系统的测试活动中所必须进行的，要求所被测试的软件系统及硬件系统和产品实际情况一样；本项测试完成后，整个测试工作才告最终结束。

Images