CN106445799A - 软件测试方法及装置 - Google Patents

Abstract

本申请提供一种软件测试方法及装置。方法包括：建立待测软件的业务模型，所述业务模型反映所述待测软件需要测试的功能点；根据所述业务模型，生成测试用例；根据所述测试用例，对所述待测软件进行探索式测试。本申请以业务模型为指导生成测试用例，测试用例与需要测试的功能点之间具有直观的映射关系，测试用例能够更加全面的覆盖需要测试的功能点，测试覆盖性较好，基于覆盖性较好的测试用例进行探索式测试，测试效果较佳。

Description

软件测试方法及装置

【技术领域】

本申请涉及软件测试技术领域，尤其涉及一种软件测试方法及装置。

【背景技术】

探索式测试是一种自由的软件测试风格，强调测试人员同时开展测试学习、测试设计、测试执行和测试结果评估等活动，以持续优化测试工作。作为一种思维方法，探索式测试强调依据当前语境(context)选择合适的测试技术，而不局限于特定的测试技术。

要对软件进行探索式测试，需要生成测试所需的测试用例(case)。现有技术中，一般是测试人员在对软件进行学习和了解后凭借个人经验设计测试用例，缺乏清晰的设计指导，所设计的测试用例与需要测试的功能点之间缺乏直观的映射，导致测试用例对需要测试的功能点的覆盖不够全面，测试覆盖性较低，测试效果较差。

【发明内容】

本申请的多个方面提供一种软件测试方法及装置，用以提高测试覆盖性，提高测试效果。

本申请的一方面，提供一种软件测试方法，包括：

建立待测软件的业务模型，所述业务模型反映所述待测软件需要测试的功能点；

根据所述业务模型，生成测试用例；

根据所述测试用例，对所述待测软件进行探索式测试。

本申请的另一方面，提供一种软件测试装置，包括：

建立模块，用于建立待测软件的业务模型，所述业务模型反映所述待测软件需要测试的功能点；

生成模块，用于根据所述业务模型，生成测试用例；

测试模块，用于根据所述测试用例，对所述待测软件进行探索式测试。

在本申请中，建立待测软件的业务模型，该业务模型反映待测软件需要测试的功能点，基于待测软件的业务模型，生成测试用例，根据测试用例，对待测软件进行探索式测试。由于业务模型能够更加全面的描述待测软件需要测试的功能点，所以本申请以业务模型为指导生成测试用例，测试用例与需要测试的功能点之间具有直观的映射关系，测试用例能够更加全面的覆盖需要测试的功能点，测试覆盖性较好，基于覆盖性较好的测试用例进行探索式测试，测试效果较佳。

【附图说明】

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

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

图2为本申请一实施例提供的业务用例图的示意图；

图3为本申请一实施例提供的业务流程图的示意图；

图4为本申请一实施例提供的软件测试装置的结构示意图；

图5为本申请另一实施例提供的软件测试装置的结构示意图。

【具体实施方式】

为使本申请实施例的目的、技术方案和优点更加清楚，下面将结合本申请实施例中的附图，对本申请实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例是本申请一部分实施例，而不是全部的实施例。基于本申请中的实施例，本领域普通技术人员在没有作出创造性劳动前提下所获得的所有其他实施例，都属于本申请保护的范围。

图1为本申请一实施例提供的软件测试方法的流程示意图。如图1所示，该方法包括：

101、建立待测软件的业务模型，该业务模型反映待测软件需要测试的功能点。

102、根据上述业务模型，生成测试用例。

103、根据上述测试用例，对待测软件进行探索式测试。

本实施例提供一种软件测试方法，可由软件测试装置来执行，用以对软件进行测试。

现有技术中，测试人员一般是凭借个人经验生成测试用例，这种方式生成的测试用例缺乏引导，所生成的测试用例对功能点的覆盖不够全面，测试覆盖性较差，因此测试效果不佳。针对该问题，本实施例提供一种软件测试方法，在本实施例提供的软件测试方法中，对于待测软件，首先建立其业务模型，之后基于待测软件的业务模型生成测试用例，进而根据所生成的测试用例进行测试。其中，业务模型可以更直观的反映待测软件，从业务过程、客户对应的业务状况以及业务参与者的角度来描述待测软件所实现的业务过程，能够更加全面的反映待测软件所实现的业务过程以及业务过程中需要测试的功能点。因此，以待测软件的业务模型为依据生成测试用例，测试用例与需要测试的功能点之间具有直接的映射，可以保证测试用例更加全面的覆盖功能点，提高测试覆盖性，进一步，基于覆盖性较好的测试用例进行测试，测试效果就较佳。

在此说明，本申请不对待测软件进行限定，待测软件可以是各种软件，例如游戏软件、即时通讯软件、电子商务软件、办公软件、压缩软件、输入法软件、客户关系管理(Customer Relationship Management，CRM)软件等。

在上述实施例中，首先需要建立待测软件的业务模型。建立待测软件的业务模型实质上是以软件模型的方式描述待测软件所实现的整体功能、整体业务构成、整体业务构成中的子业务、子业务所实现的功能以及子业务之间的交互等。通过待测软件的业务模型，测试人员可以全面把握待测软件所实现的整体功能(或称为整体价值)、业务构成、各个子业务所实现的功能以及各个子业务之间的协作关系，同时可以更方便的把控各个风险，进而可以根据业务模型清晰地产出需要测试的功能点，以在整个测试过程中作为指导。

一种建立待测软件的业务模型的方式包括：

对待测软件进行业务分析，以获取待测软件的整体业务构成、整体功能、待测试软件中子业务的功能以及子业务之间的交互；

根据待测试软件的整体业务构成、整体功能、待测试软件中子业务的功能以及子业务之间的交互，建立用于描述业务模型的业务模型图。

其中，业务模型可以通过业务模型图来描述。根据待测软件的不同，业务模型图也会有所不同。一般来说，业务模型图可以包括对象图、类图、交互图、业务用例图、业务流程图中的至少一种。

其中，采用不同业务模型图对业务模型进行描述，在对待测软件进行业务分析过程中，要求测试人员从不同的角度思考、学习、分析待测软件。例如，若利用业务用例图描述业务模型，则需要测试人员寻找待测软件的执行者，也就是用户；在寻找用户的同时需要进一步明确待测软件涉及的要素、角色、功能等，在明确用户后需要进一步明确业务用例，也即是待测软件所实现的功能。又例如，若利用业务流程图描述业务模型，则需要测试人员考虑子业务之间的相关交互。业务流程图是业务用例的具体实现，用面向对象的思想描述业务流程，可看作是一系列业务对象之间为了完成业务用例而进行的协作。业务流程图直观的反应了待测软件的业务构成、子业务之间的交互以及各个子所实现的功能等。

举例说明，假设待测软件所实现的整体功能为：基于第三方认证机构的认证功能。该整体功能对应的业务流程为：销售人员通过各种渠道采集客户信息后将客户信息提交到认证***，认证***经过内部认证后将客户信息交送到第三方认证机构对客户信息进一步认证，并反馈认证结果给认证***。测试人员采用上述实施方式对待测软件进行业务分析，最终建立其对应的业务用例图和业务流程图，分别如图2和图3所示。

在图2中，认证***涉及的业务用例包括：认证申请，认证审核，认证挂起，认证变更，认证撤销，认证加急以及认证查询。在图3中，认证业务流程主要涉及：处理客户信息，认证处理，记录认证信息，内部审核，认证商分发，认证受理，以及认证处理。

在上述实施例中，在建立待测软件的业务模型之后，需要基于该业务模型，生成测试用例。基于采用业务模型图描述业务模型，所述根据业务模型，生成测试用例实际上是基于业务模型图，设计测试用例的过程。该过程具体为：对业务模型图进行分析，以确定待测软件的功能点、与功能点相关的协作功能点以及待测软件存在的风险等信息，进而根据这些信息生成待测软件的功能列表；基于所生成的功能列表，设计测试用例。

继续以图2和图3所示为例进行说明。由图2和图3所示可知：认证***提供的功能主要包括：记录认证信息、认证申请、认证审核、认证挂起、认证变更、认证撤销、认证加急以及认证查询等。进一步可以想到认证***涉及的协作功能主要包括：认证信息存储，内部审核，与第三方认证商的交互，数据库存储，权限管理、认证状态记录、认证结果管理、以及展现方式等。结合图2所示的业务用例图和图3所示的业务流程图，最终生成如表1所示的功能列表。

表1

通过上述功能列表，测试人员可以清晰、全面思考待测软件提供的价值，建立功能列表的主干；并且对于特定功能点，测试人员能够运用其技能和经验清晰描绘出功能列表的分支以及功能点的细节，还可以想到从与该功能点相关的协作功能点去发掘待测软件存在的缺陷。另外，通过上述功能列表，测试人员可以站在用户使用的角度，站在功能设计是否合理的角度，站在破坏者的角度，站在功能是否正确的角度，站在市场的角度等考虑待测软件的质量问题。

由上述分析可知，功能列表为测试过程提供了足够多的信息，因此可以将功能列表视作覆盖率指南，生成覆盖每个功能点的测试用例，测试覆盖率较高，基于所生成的测试用例，逐个测试每个功能点，并根据相关协作功能点完成对应结果检查，提高测试效果较佳。值得说明的是，每个功能点可以对应一个或多个测试用例。

在本申请中，采用探索式测试方式对待测软件进行测试。在获得测试用例之后，根据测试用例，对待测软件进行探索式测试。

进一步，在上述测试过程中，还可以根据探索式测试结果，修正业务模型，形成一种闭环测试方式。具体的，可以根据探索式测试结果，确定改进点，该改进点为业务逻辑、软件代码以及测试方案中的至少一个；根据所确定的改进点，修正业务模型。

例如，在探索式测试结束后记录当前问题及风险，假设发现在送认证***交互环节消息发送没有重试机制或者超时阈值设置不合理，则在下一次测试过程中需要增加该功能点的其他异常测试，这属于测试方案的改进，基于此改进业务模型，进而引导着改进测试方案。

本申请通过对待测软件进行抽象、分析建立业务建模，并采用业务用例图、业务流程图等方式对业务模型进行描述，以业务模型为指导能够更高效的开展探索式测试，测试逻辑更加清晰，测试方向更加明确，每个功能点都能映射到业务模型上，进而在整个过程中该业务模型很好的起到指导作用，因此测试效果较佳。另外，在探索式测试过程中通过反馈思想不断优化测试方案，同时能够将测试结果进一步反馈给业务模型，进一步映射到业务实现上，从而形成了闭环的探索式测试方案。

需要说明的是，对于前述的各方法实施例，为了简单描述，故将其都表述为一系列的动作组合，但是本领域技术人员应该知悉，本申请并不受所描述的动作顺序的限制，因为依据本申请，某些步骤可以采用其他顺序或者同时进行。其次，本领域技术人员也应该知悉，说明书中所描述的实施例均属于优选实施例，所涉及的动作和模块并不一定是本申请所必须的。

在上述实施例中，对各个实施例的描述都各有侧重，某个实施例中没有详述的部分，可以参见其他实施例的相关描述。

图4为本申请一实施例提供的软件测试装置的结构示意图。如图4所示，该装置包括：建立模块41、生成模块42和测试模块43。

建立模块41，用于建立待测软件的业务模型，该业务模型反映待测软件需要测试的功能点。

生成模块42，用于根据建立模块41建立的业务模型，生成测试用例。

测试模块43，用于根据生成模块42生成的测试用例，对待测软件进行探索式测试。

在一可选实施方式中，建立模块41具体用于：

对待测软件进行业务分析，以获取待测软件的整体业务构成、整体功能、待测试软件中子业务的功能以及子业务之间的交互；

根据待测试软件的整体业务构成、整体功能、待测试软件中子业务的功能以及子业务之间的交互，建立用于描述业务模型的业务模型图。

可选的，上述业务模型图可以包括对象图、类图、交互图、业务用例图、业务流程图中的至少一种。

在一可选实施方式中，生成模块42具体可用于：

对业务模型图进行分析，以确定待测软件需要测试的功能点、与功能点相关的协作功能点以及存在的风险；

根据待测软件需要测试的功能点、与功能点相关的协作功能点以及存在的风险，生成功能列表；

基于功能列表，设计测试用例。

进一步，如图5所示，该装置还包括：修正模块44。

修正模块44，用于根据测试模块43输出的探索式测试结果，修正业务模型。

可选的，修正模块44具体用于：

根据探索式测试结果，确定改进点，改进点为业务逻辑、软件代码以及测试方案中的至少一个；

根据改进点，修正业务模型。

本实施例提供的软件测试装置，建立待测软件的业务模型，该业务模型反映待测软件需要测试的功能点，基于待测软件的业务模型，生成测试用例，根据测试用例，对待测软件进行探索式测试。由于业务模型能够更加全面的描述待测软件需要测试的功能点，所以本实施例提供的软件测试装置以业务模型为指导生成测试用例，测试用例与需要测试的功能点之间具有直观的映射关系，测试用例能够更加全面的覆盖需要测试的功能点，测试覆盖性较好，基于覆盖性较好的测试用例进行探索式测试，测试效果较佳。

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

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

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

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

上述以软件功能单元的形式实现的集成的单元，可以存储在一个计算机可读取存储介质中。上述软件功能单元存储在一个存储介质中，包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)或处理器(processor)执行本申请各个实施例所述方法的部分步骤。而前述的存储介质包括：U盘、移动硬盘、只读存储器(Read-Only Memory，ROM)、随机存取存储器(Random Access Memory，RAM)、磁碟或者光盘等各种可以存储程序代码的介质。

最后应说明的是：以上实施例仅用以说明本申请的技术方案，而非对其限制；尽管参照前述实施例对本申请进行了详细的说明，本领域的普通技术人员应当理解：其依然可以对前述各实施例所记载的技术方案进行修改，或者对其中部分技术特征进行等同替换；而这些修改或者替换，并不使相应技术方案的本质脱离本申请各实施例技术方案的精神和范围。

Claims (10)

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

建立待测软件的业务模型，所述业务模型反映所述待测软件需要测试的功能点；

根据所述业务模型，生成测试用例；

根据所述测试用例，对所述待测软件进行探索式测试。

2.根据权利要求1所述的方法，其特征在于，所述建立待测软件的业务模型，包括：

对所述待测软件进行业务分析，以获取所述待测软件的整体业务构成、整体功能、所述待测试软件中子业务的功能以及子业务之间的交互；

根据所述待测试软件的整体业务构成、整体功能、所述待测试软件中子业务的功能以及子业务之间的交互，建立用于描述所述业务模型的业务模型图。

3.根据权利要求2所述的方法，其特征在于，所述根据所述业务模型，生成测试用例，包括：

对所述业务模型图进行分析，以确定所述待测软件需要测试的功能点、与所述功能点相关的协作功能点以及存在的风险；

根据所述待测软件需要测试的功能点、与所述功能点相关的协作功能点以及存在的风险，生成功能列表；

基于所述功能列表，设计所述测试用例。

4.根据权利要求1-3任一项所述的方法，其特征在于，还包括：

根据探索式测试结果，修正所述业务模型。

5.根据权利要求4所述的方法，其特征在于，所述根据探索式测试结果，修正所述业务模型，包括：

根据所述探索式测试结果，确定改进点，所述改进点为业务逻辑、软件代码以及测试方案中的至少一个；

根据所述改进点，修正所述业务模型。

6.一种软件测试装置，其特征在于，包括：

建立模块，用于建立待测软件的业务模型，所述业务模型反映所述待测软件需要测试的功能点；

生成模块，用于根据所述业务模型，生成测试用例；

测试模块，用于根据所述测试用例，对所述待测软件进行探索式测试。

7.根据权利要求6所述的装置，其特征在于，所述建立模块具体用于：

对所述待测软件进行业务分析，以获取所述待测软件的整体业务构成、整体功能、所述待测试软件中子业务的功能以及子业务之间的交互；

根据所述待测试软件的整体业务构成、整体功能、所述待测试软件中子业务的功能以及子业务之间的交互，建立用于描述所述业务模型的业务模型图。

8.根据权利要求7所述的装置，其特征在于，所述生成模块具体用于：

对所述业务模型图进行分析，以确定所述待测软件需要测试的功能点、与所述功能点相关的协作功能点以及存在的风险；

根据所述待测软件需要测试的功能点、与所述功能点相关的协作功能点以及存在的风险，生成功能列表；

基于所述功能列表，设计所述测试用例。

9.根据权利要求6-8任一项所述的装置，其特征在于，还包括：

修正模块，用于根据探索式测试结果，修正所述业务模型。

10.根据权利要求9所述的装置，其特征在于，所述修正模块具体用于：

根据所述探索式测试结果，确定改进点，所述改进点为业务逻辑、软件代码以及测试方案中的至少一个；

根据所述改进点，修正所述业务模型。