CN108549598B - 一种软件测试方法和*** - Google Patents

Abstract

本发明涉及一种软件测试方法和***，属于软件测试技术领域。其中，方法包括：获取待测软件的软件需求规约中的需求信息；根据需求信息对软件需求规约进行拆分，得到多个特征，每个特征包括：特征信息；根据每个特征信息中的任务边界信息，对与每个特征信息对应的特征进行拆分，得到多个特征元项，一个特征对应至少一个特征元项，特征元项包括：特征元项信息；根据每个特征元项对待测软件进行测试。一方面，避免了现有技术测试过程复杂，容易产生测试依据含混、测试覆盖不全、测试成果复用困难、错误测试结果等多种技术弊端；另一方面，实现了将需求规约和测试分析以特征元项为核心显示，实现了对待测软件进行高效且精准的测试的技术效果。

Description

一种软件测试方法和***

技术领域

本发明实施例涉及软件测试技术领域，尤其涉及一种软件测试方法和***。

背景技术

软件测试是保证软件功能、性能、可信、可靠等特性获得供需双方认可的关键环节和主要手段之一。软件测试的对象是计算机、嵌入式、web等多种类型的软件，测试依据是软件需求规约说明书，由独立于软件开发的人员实施，检验软件实现是否与软件需求一致。

在现有技术中，通过根据自然语言描述的软件需求规约对待测软件进行测试。使得在软件测试过程中，测试过程复杂，容易产生测试依据含混、测试覆盖不全、测试成果复用困难、错误测试结果等多种技术弊端。

发明内容

为解决上述技术问题，本发明实施例提供了一种软件测试方法和***。

根据本发明实施例的一个方面，本发明实施例提供了一种软件测试方法，所述方法包括：

获取待测软件的软件需求规约中的需求信息；

根据所述需求信息对所述软件需求规约进行拆分，得到多个特征，其中，每个所述特征包括：特征信息；

根据每个所述特征信息中的任务边界信息，对与每个所述特征信息对应的特征进行拆分，得到多个特征元项，其中，一个所述特征对应至少一个所述特征元项，所述特征元项包括：特征元项信息；

根据每个所述特征元项对所述待测软件进行测试。

通过本实施例提供的：对获取的需求信息对软件需求规约进行拆分，得到多个特征，根据特征中的特征信息确定特征元项，以便根据特征元项对待测软件进行测试的技术方案，一方面，避免了现有技术中测试过程复杂，容易产生错误测试结果的技术弊端；另一方面，实现了将需求规约和测试分析以特征元项为核心进行显示，从而实现了对待测软件进行高效且精准的测试的技术效果。

根据本发明实施例的另一个方面，本发明实施例提供了一种计算机可读存储介质，所述可读存储介质包括指令，当其在计算机上运行时，使得计算机执行如上所述的方法。

根据本发明实施例的另一个方面，本发明实施例提供了一种终端，所述终端被配置为执行上述方法。

根据本发明实施例的另一个方面，本发明实施例提供了一种软件测试***，所述***包括：

获取模块：用于获取待测软件的软件需求规约中的需求信息；

拆分模块：用于根据所述需求信息对所述软件需求规约进行拆分，得到多个特征，其中，每个所述特征包括：特征信息，并根据每个所述特征信息中的任务边界信息，对与每个所述特征信息对应的特征进行拆分，得到多个特征元项，其中，一个所述特征对应至少一个所述特征元项，所述特征元项包括：特征元项信息；

测试模块：用于根据每个所述特征元项对所述待测软件进行测试。

附图说明

图1为本发明实施例提供的一种软件测试方法的流程示意图；

图2为本发明实施例提供的特征空间的结构示意图；

图3为本发明另一实施例提供的一种软件测试方法的流程示意图；

图4为本发明实施例提供的一种软件测试***的结构示意图；

图5为本发明另一实施例提供的一种软件测试***的结构示意图；

图6为本发明实施例提供的小卫星姿轨控软件的测试实例图。

具体实施方式

以下描述中，为了说明而不是为了限定，提出了诸如特定***结构、接口、技术之类的具体细节，以便透切理解本发明。然而，本领域的技术人员应当清楚，在没有这些具体细节的其它实施例中也可以实现本发明。在其它情况中，省略对众所周知的方法以及***的详细说明，以免不必要的细节妨碍本发明的描述。

本发明实施例提供了一种软件测试方法和***。

根据本发明实施例的一个方面，本发明实施例提供了一种软件测试方法。

请参阅图1，图1为本发明实施例提供的一种软件测试方法的流程示意图。

如图1所示，该方法包括：

S100：获取待测软件的软件需求规约中的需求信息；

S200：根据需求信息对软件需求规约进行拆分，得到多个特征，其中，每个特征包括：特征信息；

S300：根据每个特征信息中的任务边界信息，对与每个特征信息对应的特征进行拆分，得到多个特征元项，其中，一个特征对应至少一个特征元项，特征元项包括：特征元项信息；

S400：根据每个特征元项对待测软件进行测试。

其中，每个特征均对应一个特征唯一标识，每个特征元项均对应一个特征元项唯一标识。

在本实施例中，根据任务边界信息对特征进行拆分，得到特征元项。也就是说，特征元项具有独立的基本功能特征，它与所属特征具有相同的接口属性，但与非本身的其它特征元项有不同的任务边界，特征元项记为META。

在特征迭代至特征元项的过程中，附属特征集F中的元素对应着元项的分解逐步迭代，最终将附属特征元素fi分解至各特征元项。设特征元项之间在自然语言描述需求中蕴含的关系集合为LR，则特征元项逻辑关系的集合RELATION＝F∪LR。特征空间SP可以下式表示：

SP∷B×F (式1)

SP∷META|fun<<META×RELATION>> (式2)

式1中，B×F表示特征空间由基本特征及依附于其上的附属特征，按照基本特征内在的及附属特征要求的逻辑关系组成。

式2中RELATION表示特征元项合法逻辑关系组成的集合，按照函数fun规定的逻辑可从META×RELATION中构造出软件需求规约中表述(显式表达或隐含)的特征空间，同样的，也可构造出复合特征。即，对于特征空间或某个被定义的特征，可以通过不断分解和替换表达式中的复合特征，分层地将其展开为仅含特征元项的表达式。

在一种可能实现的技术方案中，在S200之后，该方法还包括：

根据每个特征构建特征空间；

根据特征空间对待测软件进行测试。

在现有技术中，是以软件需求规约作为对软件进行测试时的依据。但是，软件需求规约存在复杂、歧义、不完整和不规范等问题，所以，当以软件需求规约作为依据对待测软件进行测试时，容易造成测试复杂和测试结果不精准的技术弊端。为避免该技术弊端，本发明实施例提供的一种软件测试方法。

在本实施例中，先对软件需求规约中的需求信息进行获取，具体可为对软件需求规约进行解析，得到需求信息。

可以理解的是，需求信息中包括多种需求，则根据不同的需求对软件需求规约进行拆分，得到多个特征。可以将特征理解为对软件需求规约的分割和组织方式。不同的特征体现了不同的能力或特点，反应了不同的要求和理解。由此可知，特征具有功能性，且不同的特征具有不同的功能，同时，特征也可以理解为对质量属性的要求，或约束条件等。

将得到的多个特征构建特征空间。例如：当特征的数量为10个时，则根据10个特征构建特征空间，将特征空间作为测试待测软件的依据，从而实现对待测软件的测试。

在一种可能实现的技术方案中，根据每个特征构建特征空间，具体包括：

根据每个特征信息对多个特征进行分类，得到基本特征和附属特征；

根据基本特征确定初始特征空间的主节点；

根据附属特征确定所述初始特征空间的分节点；

根据主节点、分节点和初始特征空间确定特征空间。

具体地，以特征作为基本组织单元时，特征空间可以表示为如下形式：

其中B＝{b1,b2,…,bm}，F＝{f1,f2,…,fn}。

其中，S为特征空间，B为基本特征的集合，fi(i∈1,2,…,n)为附加于基本特征集合的若干附属特征。也就是说，特征包括基本特征、附属于基本特征的附属特征。

请参阅图2，图2为本发明实施例提供的特征空间的结构示意图。

如图2所示，若软件需求规约是完备的，可以根据合同、软件测评任务书等有效文件进行相应的裁剪，则特征空间是软件需求规约的子集，软件测试的内容都包含其中。

其中，特征空间除了将基本特征之间的逻辑关系显式化外，还将性能、约束关系等对应至相关的基本功能特征。这一过程很容易发现软件需求规约在功能项上存在的缺漏、逻辑异常、性能无法量化等问题，从而可以与研制方及时沟通解决。

特征空间可认为是有向连通图。节点是B集合中的基本特征或F集合中依赖于B的附属特征，边是节点的各种关系，如依赖、互斥、合取、析取等。F集合的特征依赖于B集合的元素，各fi可由依赖、多选多、多选一等逻辑运算体现于B集合的元素中。节点元素可分解为粒度更小的特征，边可分解为更细节的关系，以表示更小粒度特征之间的逻辑。

在一种可能实现的技术方案中，该方法还包括：

根据每个特征构建特征空间；

根据每个特征元项、每个特征和特征空间构建特征元项空间；

根据特征元项空间对待测软件进行测试。

在本实施例中，可以理解的是，构建特征空间时：通过识别出基本特征集B和附属特征集F，组成式(1)所表达的特征空间。在软件测试中，输入驱动软件运行，输出验证软件正确与否，它们是基本特征必备的要素。将软件的接口集定义为INF，特征输入集定义为Ib，输出集定义为Ob，

其中：

设b为基本特征元素，B为基本特征集，

b的输入集合Ib、输出集合Ob分别是软件接口集INF的子集，同时满足

软件需求规约中定义的功能需求点是基本特征集B的备选元素。根据功能需求点间的逻辑关系，选出备选的基本特征集Be，对其中的元素bei，判断是否它的输入集

且

如果满足，则该元素可成为基本特征集中的元素bi，否则，将bei按照逻辑关系合并入其它的功能点bej中，对bej再次判断其输入、输出的符合性，符合则进入B中成为特征元素bj，否则，再次合并，直到成为特征元素bk。

B集合整理出来后，将组成一个有向连通图GB1，GB1＝<VB1,EB1>，其中V是节点的集合，每个节点表示一个基本特征元素b，E是边的集合，对任意边e∈E，都有节点的有序对<vbi,vbj>与之对应。GB1表达了特征与特征之间的控制流、数据流关系，从起始节点vb0到终止节点vbk的通路是软件的一条任务剖面。

集合F中的元素对应至所依赖的B元素上。若在对应过程中出现难以量化、难以找到所依赖的特征，就是需求规约含混、难以量化的地方，应予以修正。

设b为基本特征元素，B为基本特征集，则∪b∈BI_b＝INF，且∪_b∈BO_b＝INF。

软件需求规约中所有的输入、输出都应有基本特征与之对应，所有的基本特征都有软件对外的输入、输出接口。

通过式(1)所描述的特征空间的构建，能够梳理出软件在特征层的任务剖面，识别被测对象，清理这一层次描述模糊、矛盾的问题。如果说软件需求规约是现实世界向软件空间转化的描述，式(1)特征空间的构建就是对描述与现实世界任务要求的定量再现和验证。这一步工作若能及早介入研制过程，能够有效提升后续工作的效率。

式(1)的特征空间是对软件需求规约第一层次的量化分解，可明确分析对象，去除前后不一致、模糊的内容。但随着软件规模的不断增加，基本特征中越来越多地出现了更为复杂的结构，若以基本特征集B中的元素直接作为测试分析对象，仍面临着分析内容庞杂、难以全面测试覆盖的问题。因此，需要将基本特征进一步划分为特征元项。通过识别特征元项，构建式(2)所描述的特征元项空间。

功能较为单一的特征，本身就是一个特征元项。功能较为复杂的特征，按照处理模式的不同向下划分，分解为多个特征元项。例如，特征b在时间[T0,T0+300]范围内，对功能的处理为环节I、II、IV，此时，无论上注任何指令，都保持这一处理方式不变。非[T0,T0+300]时间范围内，在上注指令α时，对功能的处理环节为I、II、III、IV、V；在上注指令β时，对功能的处理环节为I、II、IV、V；默认条件下，处理环节为I、II、III、V。特征b可划分为METAbt0、METAbα、METAbβ、METAbd四个特征元项。

能够分解为多个特征元项的特征存在共同点：第一，功能结构较为复杂，完成任务功能的环节较多；第二，虽然输入、输出接口相同，完成的任务功能大体一致，但具体处理方式却由于输入数据、时间阶段、上注指令、所处环境等原因，有较大区别；第三，若作为整体分析，极易导致缺漏，难以全面覆盖特征功能。特征元项及其隶属特征有以下性质：

若METAbi是特征b的特征元项，则输入元素集I_METAbi＝Ib，输出元素集O_METAbi＝Ob，且METAbi与b处理功能目标一致，处理框架相同。

设E为特征元素b的环境条件集，I为b的输入元素集，IDA为I的取值集合，

Ei≠Ej，

IDAi≠IDAj，由Ei或IDAi导致b的处理不同于Ej和IDAj条件下b的处理，则METAbi、METAbj分别是b的特征元项，特征元项的集合{METAb1,…,METAbk}组成了b的任务处理流簇。

如果说B集合组成的有向连通图GB1表示了软件的任务剖面，特征b的每个特征元项都是b的一条任务剖面，将METAb在b节点展开，则相当于对GB1节点的分解，形成更具体的GBM。式(2)所示的特征元项空间是对特征空间叶节点的分解，形成更为具体、清晰的任务剖面图。在此过程中，特征内部的模糊、不一致的内容也会被发现。这一步的工作若能及早介入，能够有效提高设计的准确性和效率。

在一种可能实现的技术方案中，请参阅图3，图3为本发明实施例提供的一种软件测试方法的流程示意图。

如图3所示，在根据每个特征元项、每个特征和特征空间构建特征元项空间之后，该方法还包括：

S700：根据每个特征元项信息，对与每个特征元项信息对应的特征元项进行拆分，得到多个测试项，其中，一个特征元项对应至少一个测试项；

S800：为每个测试项分配一个唯一标识，得到标识测试项，其中，一个标识测试项包括：测试内容信息、多条测试充分性条目和唯一标识，且每条所述测试充分性条目对应至少一个分解项；每个所述分解项均对应一个分解项唯一标识，每个所述分解项对应至少一个分解项条目，每个所述分解项条目至少对应一个所述测试用例，且每个所述分解项条目均对应一个分解项条目唯一标识，每个所述测试用例均对应一个测试用例唯一标识。

S900：根据每个标识测试项对待测软件的测试。

在本实施例中，唯一标识为ID。例如：

ID是测试项有且仅有的唯一标识。名称(Name)是测试项有意义的命名，表述了测试项的目的。说明(Explanation)简要描述测试项需要测试的特征元项处理的主要内容，包括测试重点、测试方向等。充分性要求(Adequacy Claim)则是测试充分性覆盖条目，每条充分性都由测试项所对应的分解项予以支撑。充分性要求条目由充分性标识(Adequacy ID)予以唯一标识。

在一种可能实现的技术方案中，该方法还包括：

根据分解项和预设的测试规则对每个标识测试项进行测试，得到测试结果，以实现对待测软件的测试，其中，分解项是指利用测试方法生成的不同测试用例对待测软件测试时，对待测软件的测试充分性予以支撑的记录单元。

在本实施例中，分解项是利用相同的或不同测试方法对测试充分性分析予以支撑的记录单元。测试方法包括等价类、边界值、功能分解、判定表、因果图、状态机等，随着测试技术的发展，也可再并入更新的研究成果。等价类、边界值通常用于输入域的分析，功能分解、判定表、因果图、状态机通常结合处理过程进行分析，为了保证测试的全面，输出域全覆盖、输出域计数值最大值跳变等用于输出域的测试分析。

分解项以各测试方法对应的分析表记录分析内容，及分析内容与充分性要求、测试用例的对应关系。如等价类表记录对输入的等价类分析，等价类表的每一分析条目都包括本身的标识、对应的充分性标识、对应的测式用例标识，用以贯通测试项、分解项和测试用例。

通过测试体系的实施，能够将软件需求规约以实用的测试技术予以全面覆盖，不仅能解决需求含混、模糊的问题，充分利用测试技术研究的进展，还可对后续的回归、复用予以有效支撑。

其中，每个分解项均对应一个分解项唯一标识，每个分解项对应至少一个分解项条目，每个分解项条目至少对应一个测试用例，且每个分解项条目均对应一个分解项条目唯一标识，每个测试用例均对应一个测试用例唯一标识。

在本实施例中，更进一步地，根据每个测试用例对待测软件进行测试。

在一种可能实现的技术方案中，该方法还包括：

根据特征元项、分解项、测试用例对测试过程进行追踪。

具体地，设特征元项集合为META，测试项集合为TEO，测试项分解项集合为TEI，测试用例集合为TUC。从META至TUC、TUC至META两个方向都可说明全流程是可跟踪、全覆盖的。

1、META至TUC方向

从测试用例集合TEO至特征元项集合META方向存在满射函数。函数fTUC-TEI:TUC——>TEI为满射，函数fTEI-TEO:TEI——>TEO为满射，函数fTEO-META:TEO——>META为满射。需要说明的是，由fTUC-TEI、fTEI-TEO、fTEO-META组成的复合函数也是满射函数。

g1＝fTUC-TEI°fTEI-TEO：TUC——>TEO，g1为满射函数；

g2＝fTEI-TEO°fTEO-META：TEI——>META，g2为满射函数；

g3＝fTUC-TEI°fTEI-TEO°fTEO-META：TUC——>META，g3为满射函数。f系列、g系列函数说明，

2、TUC至META方向

从特征元项集合META至测试用例集合TEO方向不存在函数，只有集合之间的关系。设集合META至集合TEO存在关系集RMETA-TEO：META——>TEO，(meta,test object)为R中的有序对，若

必然

(

objecti|test objecti∈TEO1)，构成有序对(metai,test objecti)∈RMETA-TEO，其中

类似的，从集合TEO至集合TEI存在关系集RTEO-TEI：TEO——>TEI，若

object|test object∈TEO，必然

(

item|test item∈TEI1)，构成有序对(test object,test item)∈RTEO-TEI，其中

从集合TEI至集合TUC存在关系集RTEI-TUC：TEI——>TUC，若

item|test item∈TEI，必然

(

use case|test use case∈TUC1)，构成有序对(test item,test use ase)∈RTEI-TUC，其中

由RMETA-TEO、RTEO-TEI、RTEI-TUC构成三类组合关系Rg1、Rg2、Rg3。

Rg1＝RMETA-TEO°RTEO-TEI：META——>TEI；

Rg2＝RTEO-TEI°RTEI-TUC：TEI——>TUC；

Rg3＝RMETA-TEO°RTEO-TEI°RTEI-TUC：META——>TUC。

设第一元素集为FIRST，第二元素集为SECOND，则

(

|second∈SECOND1)，其中

Rg系列组合关系同样满足上述约束。

特征元项集合META至测试用例集合TEO方向，R系列、Rg系列关系满足任取有序对第一元素所在集合中的元素，第二元素集合中必然存在一个子集，该子集中的任一元素与第一元素构成的有序对隶属于组合关系集合；

从测试用例集合TEO至元项集合META方向存在f系列、g系列满射函数；

软件测试过程中，可追踪、前后可完全覆盖。

根据本发明实施例的另一个方面，本发明实施例提供了一种计算机可读存储介质，该可读存储介质包括指令，当其在计算机上运行时，使得计算机执行上述任一可能实现的技术方案中的方法。

根据本发明实施例的另一个方面，本发明实施例提供了一种终端，该终端被配置为执行上述任一可能实现的技术方案中的方法。

其中，该终端可以是电脑、手机、平板等能够对(电子文件等)进行处理(如编辑等)的用户设备。

终端的结构包括：处理器和存储器。处理器是终端的控制中心，通过各种总线接口连接整个终端的各个部分，通过运行或执行存储在存储器内的软件程序(或指令等)，以及调用存储在存储器内的数据，执行终端的各种功能和处理数据，从而对终端进行整体监控。

如，在本实施例中，存储器用于存储执行上述任一可能实现的技术方案中的方法对应的程序或指令，处理器对该程序或指令进行运行，以实现上述任一可能实现的技术方案中的方法流程。

存储器可主要包括存储程序区和存储数据区，其中，存储程序区可存储操作***、至少一个功能所需的应用程序等；存储数据区可存储根据终端的使用创建的数据等。此外，存储器可以包括高速随机存储存储器，还可以包括非易失性存储器，例如至少一个磁盘存储器件、内存器件、或其他易失性固态存储器件。

根据本发明实施例的另一个方面，本发明实施例提供了与上述方法相对应的一种软件测试***。

请参阅图4，图4为本发明实施例提供的一种软件测试***的结构示意图。

如图4所示，该***包括：

获取模块：用于获取待测软件的软件需求规约中的需求信息；

拆分模块：用于根据需求信息对软件需求规约进行拆分，得到多个特征，其中，每个特征包括：特征信息，并根据每个特征信息中的任务边界信息，对与每个特征信息对应的特征进行拆分，得到多个特征元项，其中，一个特征对应至少一个特征元项，特征元项包括：特征元项信息；

测试模块：用于根据每个特征元项对待测软件进行测试。

在一种可能实现的技术方案中，请参阅图5，图5为本发明另一实施例提供的一种软件测试***的结构示意图。

如图5所示，该***还包括：构建模块，其中，

构建模块用于：根据每个述特征构建特征空间，并根据每个特征元项、每个特征和特征空间构建特征元项空间；

测试模块还用于：根据特征元项空间对待测软件进行测试。

在一种可能实现的技术方案中，请参阅图5，图5为本发明另一实施例提供的一种软件测试***的结构示意图。

如图5所示，该***还包括：分配模块，其中，

拆分模块还用于：根据每个特征元项信息，对与每个特征元项信息对应的特征元项进行拆分，得到多个测试项，其中，一个特征元项对应至少一个测试项；

分配模块用于：为每个测试项分配一个唯一标识，得到标识测试项，其中，一个标识测试项包括：测试内容信息、多条测试充分性条目和唯一标识，且每条测试充分性条目对应至少一个分解项；其中，每个分解项均对应一个分解项唯一标识，每个分解项对应至少一个分解项条目，每个分解项条目至少对应一个测试用例，且每个分解项条目均对应一个分解项条目唯一标识，每个测试用例对应一个测试用例唯一标识。

测试模块还用于：根据每个标识测试项对待测软件进行测试。

其中，由拆分模块将测试项拆分为多条测试充分性条目，由拆分模块将测试充分性条目拆分为至少一个分解项，由拆分模块将分解项拆分为至少一个分解项条目，由拆分模块将分解项条目拆分为至少一个测试用例。

具体地，测试模块用于：根据每个测试用例对待测软件进行测试。

进一步地，测试模块还用于：根据分解项和预设的测试规则对每个标识测试项进行测试，得到测试结果，以实现对待测软件的测试，其中，分解项是指利用测试方法生成的不同测试用例对待测软件测试时，对待测软件的测试充分性予以支撑的记录单元。

在一种可能实现的技术方案中，

构建模块还用于：根据每个特征构建特征空间；

测试模块还用于：根据特征空间对待测软件进行测试。

在一种可能实现的技术方案中，构建模块具体用于：

根据每个特征信息对多个特征进行分类，得到基本特征和附属特征；

根据基本特征确定初始特征空间的主节点；

根据附属特征确定初始特征空间的分节点；

根据主节点、分节点和初始特征空间确定特征空间。

为使对本申请的技术方案有更清楚的理解，现以小卫星姿轨控软件的测试实例进行说明，并证明该方法的有效性。

请参阅图6，图6为本发明实施例提供的小卫星姿轨控软件的测试实例图。

如6所示，小卫星姿轨控软件的控制由三部分功能实现，分别是GPS定位、姿态控制和轨道控制。

具体地，根据需求信息对该软件测试的软件需求规约进行拆分，可拆分为GPS定位特征、姿态控制特征和轨道控制特征。其中，GPS定位特征将当前轨道位置、速度数据转换并外推至姿态控制特征需要使用的数据类型。姿态控制特征利用太阳敏感器、磁强计采集的数据，与轨道数据共同计算出当前的姿态角和角速度。轨道控制特征利用姿态控制特征计算出的姿态角，判断当前是否是正常的定姿状态，以决策能否正常变轨。

对特征进一步分析，GPS定位特征包括了两种定位方式，GPS单机方式和注入轨道方式，两者接口一致，但处理流程各异，划分为2个特征元项，如图6所示。

GPS单机特征元项和注入轨道特征元项之间的转换较为复杂，在特征元项的测试项分析中，作为独立的转换流程测试项置于GPS单机特征元项中，以避免分析的遗漏和冗余。在该测试项对应的分解项中，功能分解法对应的用例发现了时间限制等缺陷。

姿态控制特征较为复杂，不仅算法多、难，处理逻辑繁杂，而且需求规约的描述是将不同模式下的姿态控制作为整体进行的，若不详细分解，极易发生漏测、误判的情况。

按照特征元项分析，姿态控制特征分为上电未分离特征元项、对地定向特征元项、对日定向特征元项、绕飞特征元项、变轨姿态机动特征元项、变轨姿态维持特征元项、安全特征元项，如图6所示。

上电未分离特征元项在软件的需求规约中篇幅极少，但特征元项分析发现，在该模式下隐含着可进行几乎所有的指令控制操作，可能对卫星姿态造成影响，须独立为特征元项。变轨姿态机动和变轨姿态维持虽然都为变轨调整姿态，但两者关注点不同，对轨控特征的影响不同，须分别独立为特征元项。姿控控制特征中各特征元项之间的转换规则较为明确，在各特征元项对应的测试项主流程中进行分析。测试项对应的分解项利用功能分解、等价类等多种方法不仅支撑了测试项分析的充分性，也澄清了需求中多处含糊、缺失的描述，确定了判定依据，发现了五十余处缺陷。若不分解特征元项，则至少二十余处缺陷会在分析中遗漏。

类似的，轨道控制特征可细分为释放前特征元项、轨控安全特征元项、预热特征元项、指向准备特征元项、推力器特征元项。对应的测试项为各元项主流程，测试项的充分性条目以多种测试方法组成的分解项支撑，如图6所示。该特征下，通过对不同特征元项下测试项充分性的分解项分析，对应的测试用例发现了在不同阶段注入指令或轨道数据所引起的不同后果，其中的一些会导致任务失败。而这些若不细分特征元项，是难以直接利用需求规约测试出来的。

在小卫星姿轨控软件的测试中，利用基于特征元项的测试体系分析，明确梳理出了需求规约对应的特征、特征元项、测试项，避免了需求规约含混、缺失，分析遗漏的问题。将特征元项及其关系解耦至各测试项中，保证了全面覆盖及并行分析的能力。针对各测试项不同的特点，以分解项灵活运用多种测试技术，确保测试的高效和先进。在该软件测试实例中，基于特征元项的测试体系共产生了约1000个测试用例，都可在测试用例及特征之间双向追踪。其中5个特征元项是传统测试方式难以明确分析的，这些特征元项对应了约400个用例，发现了三十余处缺陷。实验证明该方法能够全面、有效地对软件进行测试分析。

读者应理解，在本说明书的描述中，参考术语“一个实施例”、“一些实施例”、“示例”、“具体示例”、或“一些示例”等的描述意指结合该实施例或示例描述的具体特征、结构、材料或者特点包含于本发明的至少一个实施例或示例中。在本说明书中，对上述术语的示意性表述不必针对的是相同的实施例或示例。而且，描述的具体特征、结构、材料或者特点可以在任一个或多个实施例或示例中以合适的方式结合。此外，在不相互矛盾的情况下，本领域的技术人员可以将本说明书中描述的不同实施例或示例以及不同实施例或示例的特征进行结合和组合。

所属领域的技术人员可以清楚地了解到，为了描述的方便和简洁，上述描述的装置和单元的具体工作过程，可以参考前述方法实施例中的对应过程，在此不再赘述。

在本申请所提供的几个实施例中，应该理解到，所揭露的装置和方法，可以通过其它的方式实现。例如，以上所描述的装置实施例仅仅是示意性的，例如，单元的划分，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式，例如多个单元或组件可以结合或者可以集成到另一个***，或一些特征可以忽略，或不执行。

作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部单元来实现本发明实施例方案的目的。

另外，在本发明各个实施例中的各功能单元可以集成在一个处理单元中，也可以是各个单元单独物理存在，也可以是两个或两个以上单元集成在一个单元中。上述集成的单元既可以采用硬件的形式实现，也可以采用软件功能单元的形式实现。

可以理解的是，在上述实施例中，可以全部或部分地通过软件、硬件、固件或者其他任一组合来实现。当使用软件实现时，可以全部或者部分地以计算机程序产品的形式实现。

集成的单元如果以软件功能单元的形式实现并作为独立的产品销售或使用时，可以存储在一个计算机可读取存储介质中。基于这样的理解，本发明的技术方案本质上或者说对现有技术做出贡献的部分，或者该技术方案的全部或部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质中，包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)执行本发明各个实施例方法的全部或部分步骤。而前述的存储介质包括：U盘、移动硬盘、只读存储器(ROM，Read-Only Memory)、随机存取存储器(RAM，Random Access Memory)、磁碟或者光盘等各种可以存储程序代码的介质。

还应理解，在本发明各实施例中，上述各过程的序号的大小并不意味着执行顺序的先后，各过程的执行顺序应以其功能和内在逻辑确定，而不应对本发明实施例的实施过程构成任何限定。

以上，仅为本发明的具体实施方式，但本发明的保护范围并不局限于此，任何熟悉本技术领域的技术人员在本发明揭露的技术范围内，可轻易想到各种等效的修改或替换，这些修改或替换都应涵盖在本发明的保护范围之内。因此，本发明的保护范围应以权利要求的保护范围为准。

Claims (6)

1.一种软件测试方法，其特征在于，所述方法包括：

获取待测软件的软件需求规约中的需求信息；

根据所述需求信息对所述软件需求规约进行拆分，得到多个特征，其中，每个所述特征包括：特征信息；

根据每个所述特征信息中的任务边界信息，对与每个所述特征信息对应的特征进行拆分，得到多个特征元项，其中，一个所述特征对应至少一个所述特征元项，所述特征元项包括：特征元项信息；

根据每个所述特征元项对所述待测软件进行测试；

所述方法还包括：

根据每个所述特征构建特征空间；

根据每个所述特征元项、每个所述特征和所述特征空间构建特征元项空间；

根据所述特征元项空间对所述待测软件进行测试；

在所述根据每个所述特征元项、每个所述特征和所述特征空间构建特征元项空间之后，所述方法还包括：

根据每个所述特征元项信息，对与每个所述特征元项信息对应的特征元项进行拆分，得到多个测试项，其中，一个所述特征元项对应至少一个所述测试项；

为每个所述测试项分配一个唯一标识，得到标识测试项，其中，一个所述标识测试项包括：测试内容信息、多条测试充分性条目和唯一标识，且每条所述测试充分性条目对应至少一个分解项；

根据每个所述标识测试项对所述待测软件的测试。

2.根据权利要求1所述的一种软件测试方法，其特征在于，所述方法还包括：

根据所述分解项和预设的测试规则对每个所述标识测试项进行测试，得到测试结果，以实现对所述待测软件的测试，其中，所述分解项是指利用测试方法生成的不同测试用例对所述待测软件测试时，对所述待测软件的测试充分性予以支撑的记录单元。

3.根据权利要求2所述的一种软件测试方法，其特征在于，

每个所述分解项均对应一个分解项唯一标识，每个所述分解项对应至少一个分解项条目，每个所述分解项条目至少对应一个所述测试用例，且每个所述分解项条目均对应一个分解项条目唯一标识，每个所述测试用例均对应一个测试用例唯一标识。

4.一种软件测试***，其特征在于，所述***包括：

获取模块：用于获取待测软件的软件需求规约中的需求信息；

拆分模块：用于根据所述需求信息对所述软件需求规约进行拆分，得到多个特征，其中，每个所述特征包括：特征信息，并根据每个所述特征信息中的任务边界信息，对与每个所述特征信息对应的特征进行拆分，得到多个特征元项，其中，一个所述特征对应至少一个所述特征元项，所述特征元项包括：特征元项信息；

测试模块：用于根据每个所述特征元项对所述待测软件进行测试；

所述***还包括：构建模块，其中，

所述构建模块：用于根据每个所述特征构建特征空间，并根据每个所述特征元项、每个所述特征和所述特征空间构建特征元项空间；

所述测试模块还用于：根据所述特征元项空间对所述待测软件进行测试；

所述***还包括：分配模块，其中，

所述拆分模块还用于：根据每个所述特征元项信息，对与每个所述特征元项信息对应的特征元项进行拆分，得到多个测试项，其中，一个所述特征元项对应至少一个所述测试项；

所述分配模块用于：为每个所述测试项分配一个唯一标识，得到标识测试项，其中，一个所述标识测试项包括：测试内容信息、多条测试充分性条目和唯一标识，且每条所述测试充分性条目对应至少一个分解项；

所述测试模块还用于：根据每个所述标识测试项对所述待测软件的测试。

5.根据权利要求4所述的一种软件测试***，其特征在于，

所述测试模块还用于：根据所述分解项和预设的测试规则对每个所述标识测试项进行测试，得到测试结果，以实现对所述待测软件的测试，其中，所述分解项是指利用测试方法生成的不同测试用例对所述待测软件测试时，对所述待测软件的测试充分性予以支撑的记录单元。

6.根据权利要求5所述的一种软件测试***，其特征在于，

每个所述分解项均对应一个分解项唯一标识，每个所述分解项对应至少一个分解项条目，每个所述分解项条目至少对应一个所述测试用例，且每个所述分解项条目均对应一个分解项条目唯一标识，每个所述测试用例均对应一个测试用例唯一标识。

Images