CN104636258B - 面向可重构支撑软件的可信测试方法 - Google Patents

Abstract

本发明提供了一种面向可重构支撑软件的可信测试方法，其从过程的角度出发，强调了测试尽早执行的原则；同时，在对目标软件进行测试之前，先获取目标软件的测试需求，从而使得测试更具有针对性和准确性；再次，依据目标软件的通过标准进行测试，由此使得测试更高效和准确；另外，依据获取的目标软件测试需求，能够参与目标软件的全过程，从而对目标软件进行过程控制。

Description

面向可重构支撑软件的可信测试方法

技术领域

本发明涉及软件测试技术领域，特别涉及一种面向可重构支撑软件的可信测试方法。

背景技术

在软件的开发过程中，软件测试是保障软件质量的重要技术手段之一。通过适当的软件测试方法，能尽可能多的找出软件中的缺陷，保障软件质量达到预期，同时还可以达到资源分配的合理化。近些年来，随着软件规模的不断扩大，软件测试方法也在不断地进步。

传统的软件测试方法多使用V模型来实现，典型的V模型框架将软件的测试视作一个过程来评价。它将软件的开发过程划分为几个生命周期，针对不同的生命周期，分别进行了相应的测试活动。V模型将软件的开发过程视作一个串行进行的过程，将软件测试视作编码后的最后一个活动，没有体现尽早测试的原则。这就导致在需求中存在的错误直到最后的验收测试中才会被发现。而软件的缺陷具有放大趋势，当缺陷被传递到最后提交时，已经很难进行修改。

W模型是V模型的改进，软件测试过程与软件开发过程并行进行，能够实现尽早地测试。然而W模型将需求分析、概要分析、编码实现等活动视为串行进行的，无法支持迭代开发的实现。基于W模型的软件测试过程通过对软件开发过程中的各个阶段进行不断评审，只有当评审通过时，才能进入下一阶段，逐步完善软件开发过程。但是重复性地评审会造成资源的大量浪费。

目前，在软件测试过程中采用的策略有如下两种：一种方法是采用大量测试来提升软件质量，但是由于缺乏有效的测试需求分析，会导致资源的浪费。另一种是采用重点测试的方法，对软件中的重点部件进行详细测试，非重点部件则采用较少测试资源。其优点是能够有效整合测试资源，提高效率。但是其缺点是对测试人员素质要求较高，且易出现测试遗漏。

可重构处理器有以下特点：1.可重构编译平台功能、结构比较复杂；2.其属于软硬件协同开发的项目，软件中的缺陷可能追溯到硬件的开发过程中；3.整个项目的开发周期长，版本迭代、需求变更频繁。由于这类项目的特点，导致传统软件测试过程无法满足可重构支撑软件的质量要求。

发明内容

本发明的目的在于提供一种面向可重构支撑软件的可信测试方法，以解决现有的软件测试过程无法满足可重构支撑软件的质量要求的问题。

为解决上述技术问题，本发明提供一种面向可重构支撑软件的可信测试方法，所述面向可重构支撑软件的可信测试方法包括：

步骤10：对目标软件进行可信度建模；

步骤20：获取目标软件测试需求；

步骤30：依据步骤10及步骤20，得到目标软件的通过标准；

步骤40：依据步骤20及步骤30，对目标软件进行测试。

可选的，在所述的面向可重构支撑软件的可信测试方法中，依据软件开发人员、测试人员、用户以及软件需求说明书对目标软件进行可信度建模。

可选的，在所述的面向可重构支撑软件的可信测试方法中，获取目标软件测试需求包括：获取目标软件的非形式化需求、子单元完备性、预定义集合和类型、状态变量、初始状态、正常操作、意外操作以及前置条件中的一种或多种。

可选的，在所述的面向可重构支撑软件的可信测试方法中，当获取目标软件的非形式化需求、子单元完备性、预定义集合和类型、状态变量、初始状态、正常操作、意外操作以及前置条件中的多种时，每一个测试需求具有一个通过标准。

可选的，在所述的面向可重构支撑软件的可信测试方法中，目标软件的可信度包括：功能可信度、可靠性可信度、易用性可信度、效率可信度、维护性可信度以及可移植性可信度中的一种或多种。

可选的，在所述的面向可重构支撑软件的可信测试方法中，当目标软件的可信度包括功能可信度、可靠性可信度、易用性可信度、效率可信度、维护性可信度以及可移植性可信度中的多种时，对涉及到的每一种可信度进行可信度建模。

可选的，在所述的面向可重构支撑软件的可信测试方法中，通过等级表达目标软件的可信度。

在本发明提供的面向可重构支撑软件的可信测试方法中，从过程的角度出发，强调了测试尽早执行的原则；同时，在对目标软件进行测试之前，先获取目标软件的测试需求，从而使得测试更具有针对性和准确性；再次，依据目标软件的通过标准进行测试，由此使得测试更高效和准确；另外，依据获取的目标软件测试需求，能够参与目标软件的全过程，从而对目标软件进行过程控制。

附图说明

图1是本发明实施例的面向可重构支撑软件的可信测试方法的流程示意图；

图2是本发明实施例的目标软件的可信度内容示意图；

图3是本发明实施例的面向可重构支撑软件的可信测试方法的具体实现过程示意图。

具体实施方式

以下结合附图和具体实施例对本发明提出的面向可重构支撑软件的可信测试方法作进一步详细说明。根据下面说明和权利要求书，本发明的优点和特征将更清楚。需说明的是，附图均采用非常简化的形式且均使用非精准的比例，仅用以方便、明晰地辅助说明本发明实施例的目的。

请参考图1，其为本发明实施例的面向可重构支撑软件的可信测试方法的流程示意图。如图1所示，所述面向可重构支撑软件的可信测试方法具体包括：

步骤10：对目标软件进行可信度建模；

步骤20：获取目标软件测试需求；

步骤30：依据步骤10及步骤20，得到目标软件的通过标准；

步骤40：依据步骤20及步骤30，对目标软件进行测试。

其中，目标软件即指需要开发的软件或者说是需要测试的软件。此外，易知的，当对目标软件进行测试时，该目标软件已经完成了部分或者全部的编码。

在本申请实施例中，依据软件开发人员、测试人员、用户以及软件需求说明书对目标软件进行可信度建模。进一步的，按照ISO/IEC9126标准，所述目标软件的可信度包括：功能可信度、可靠性可信度、易用性可信度、效率可信度、维护性可信度以及可移植性可信度中的一种或多种，对此可相应参考图2。优选的，通过等级表达目标软件的可信度。即当目标软件的可信度包括功能可信度、可靠性可信度、易用性可信度、效率可信度、维护性可信度以及可移植性可信度中的多种时，对涉及到的每一种可信度进行可信度建模，同时，每一种可信度通过相应的等级予以表示。例如，目标软件的可信度由低到高分成T0、T1、T2、T3、T4及T5六个等级，则每一种可信度通过T0、T1、T2、T3、T4或者T5予以表示。

在本申请实施例中，目标软件的测试需求包括：目标软件的非形式化需求、子单元完备性、预定义集合和类型、状态变量、初始状态、正常操作、意外操作以及前置条件中的一种或多种。其中，非形式化需求，包括软件需求的基本功能；子单元完备性，包括对已定义的软件子单元模块进行分析，找出测试点，用以判断是否满足软件需求；预定义集合和类型、状态变量、初始状态这三个测试项目是用来对软件中的基本状态和状态改变这类功能进行测试需求分析，主要针对各个状态之间的跳转测试；正常操作是用来测试软件使用过程中在无意外操作的情况下，软件是否能够按照预期的模式进行工作；意外操作主要是用来测试软件输入异常的情况下，是否具有足够的鲁棒性，能够对异常输入有预期的反馈，而不导致程序异常；前置条件用来发掘在软件运行时需要具备的前置条件的测试需求。

进一步的，所述步骤30：依据步骤10及步骤20，得到目标软件的通过标准具体包括：得到目标软件每一个测试需求的通过标准。例如，若目标软件的测试需求包括：目标软件的非形式化需求、子单元完备性、预定义集合和类型、状态变量以及初始状态，则在步骤30中，将得到目标软件的非形式化需求、子单元完备性、预定义集合和类型、状态变量以及初始状态所属的等级，即属于T0、T1、T2、T3、T4或者T5。

接着，便可执行步骤40：依据步骤20及步骤30，对目标软件进行测试。即根据目标软件的测试需求以及目标软件的通过标准，对目标软件进行测试，使得每一项测试需求得到相应的测试。由此，便可使得测试更高效和准确，并且能够参与目标软件的全过程，从而对目标软件进行过程控制。

在本申请实施例中，当在步骤30中得到目标软件的一测试需求的通过标准比较高时，在后续的对目标软件的测试过程中，便可予以更多的测试资源，例如在测试策略、测试责任人、测试工具、测试复查、测试文档以及测试可追踪性，从而也实现了测试资源的高效性以及测试结果的准确性的兼容。

接下去请参考图3，其为本发明实施例的面向可重构支撑软件的可信测试方法的具体实现过程示意图。如图3所示，在面向可重构支撑软件的可信测试方法的具体实现过程中，包括如下内容：

首先，需要测试人员进行系统的了解，完成对目标软件的相关文档阅读、测试人员熟悉被测软件，掌握其具体功能。

然后进入测试计划编写的阶段。与该阶段同步进行的包括制定测试需求、测试用例设计。测试计划需要可包含如下信息：目标可信性划分说明、测试策略、测试方法、通过标准及测试资源和组织。

测试需求制定完毕后可进行评审，确定完备后生成测试需求说明书，然后进入测试用例设计的步骤。

测试用例设计中需要注意的一点是，软件的测试用例需要包含测试需求中的所有测试需求，对其中所有的测试点都能够进行测试。

在测试用例设计完毕后，进入测试执行的阶段。其工作就是运行测试用例库中的测试用例并及时做好记录。当发现存在缺陷时，需要及时进行处理。通过目标软件可信性模型来缺陷优先级，并移交给软件开发人员进行处理。在软件开发人员自测无误后，再次测试验证缺陷是否解决。同时进行风险评估，是否需要更改测试用例。如果需要更改测试用例，则需要对测试用例库及时进行更新。在每次的测试完成后，都需要进行测试记录。同时，对于存在的缺陷，还要进行缺陷记录。

在测试总结环节，对本次迭代开发中存在的缺陷以及测试过程进行总结，提交测试分析报告。

综上可见，在本发明提供的面向可重构支撑软件的可信测试方法中，从过程的角度出发，强调了测试尽早执行的原则；同时，在对目标软件进行测试之前，先获取目标软件的测试需求，从而使得测试更具有针对性和准确性；再次，依据目标软件的通过标准进行测试，由此使得测试更高效和准确；另外，依据获取的目标软件测试需求，能够参与目标软件的全过程，从而对目标软件进行过程控制。

上述描述仅是对本发明较佳实施例的描述，并非对本发明范围的任何限定，本发明领域的普通技术人员根据上述揭示内容做的任何变更、修饰，均属于权利要求书的保护范围。

Claims (6)

1.一种面向可重构支撑软件的可信测试方法，其特征在于，包括：

步骤10：依据软件开发人员、测试人员、用户以及软件需求说明书对目标软件进行可信度建模；

步骤20：获取目标软件测试需求；

步骤30：依据步骤10及步骤20，得到目标软件的通过标准；

步骤40：依据步骤20及步骤30，对目标软件进行测试。

2.如权利要求1所述的面向可重构支撑软件的可信测试方法，其特征在于，获取目标软件测试需求包括：获取目标软件的非形式化需求、子单元完备性、预定义集合和类型、状态变量、初始状态、正常操作、意外操作以及前置条件中的一种或多种。

3.如权利要求2所述的面向可重构支撑软件的可信测试方法，其特征在于，当获取目标软件的非形式化需求、子单元完备性、预定义集合和类型、状态变量、初始状态、正常操作、意外操作以及前置条件中的多种时，每一个测试需求具有一个通过标准。

4.如权利要求1所述的面向可重构支撑软件的可信测试方法，其特征在于，目标软件的可信度包括：功能可信度、可靠性可信度、易用性可信度、效率可信度、维护性可信度以及可移植性可信度中的一种或多种。

5.如权利要求4所述的面向可重构支撑软件的可信测试方法，其特征在于，当目标软件的可信度包括功能可信度、可靠性可信度、易用性可信度、效率可信度、维护性可信度以及可移植性可信度中的多种时，对涉及到的每一种可信度进行可信度建模。

6.如权利要求1所述的面向可重构支撑软件的可信测试方法，其特征在于，通过等级表达目标软件的可信度。