CN107729226A - 基于业务流的测试用例自动生成系统及方法 - Google Patents

Abstract

本发明涉及计算机软件技术领域，具体是一种基于业务流的测试用例自动生成系统及方法。包括测试抽取器、序列生成器、程序生成器、模型检测/求解器，其中测试抽取器和序列生成器共用模型检测/求解器，还包括一种利用上述系统的计算机软件系统中一种基于业务流的测试用例自动生成方法，其特征在于，所述的方法包括如下步骤：建模、全状态空间检查、生成测试序列、将测试序列变换成可执行程序。本发明基于形式化方法中的遍历技术，找出高覆盖率的业务流，自动生成基于业务流的测试用例，可以根据项目情况合理调整挑选粒度，并且可以找出执行测试所需要的操作顺序，由此可以得到可执行的测试程序，实现测试的高覆盖和自动化。

Description

基于业务流的测试用例自动生成系统及方法

技术领域

本发明涉及计算机软件技术领域，尤其涉及企业应用系统测试，具体是一种基于业务流的测试用例自动生成系统及方法。

背景技术

在基于业务的软件系统开发过程中，业务流的测试工作是非常难以实施的工作，一般由人工根据经验来完成，必须要求测试人员对业务和测试两个领域的知识都非常熟悉，理解如何用相应的数据和操作以驱动业务按照设计实施。但是随着业务量和复杂度的增加，人工的测试变得特别困难。这是当今业务类系统出错的主要原因，例如银行系统、医疗监控系统等。另外，在系统完成或维护升级完毕时，一般需要进行回归测试，而系统每次改版，回归测试意味着复杂艰巨的测试工作必须重新设计和执行。目前工程上尚无解决方案，可自动化生成高覆盖率的业务流程测试用例。人工执行一般无法保证流程的合理性和覆盖率，这样会导致回归测试无法保证回归的覆盖率，进而无法保证系统的质量。

现有的开发现场中，对现有测试用例的生成，由于必须满足复杂的条件：a:高覆盖率、b:低重复率，c:根据开发进度决定挑选粒度。而人工挑选只能由对系统业务和开发管理都十分有经验的人，根据经验决定从现有的测试用例中挑选一部分子集，并考虑实施目标测试所需要的操作步骤。对于复杂系统的流程，人工生成的覆盖率一般都是相当低的，因为无法考虑过于复杂的情况，而提取复杂系统的测试操作步骤尤其困难。因此，传统测试方法无法满足以上陈述的条件a-c。

发明内容

本发明的目的在于解决业务流的测试用例自动生成问题。提供一种基于业务流的测试用例自动生成系统和方法。

为实现以上目的，本发明采用的技术方案为：基于业务流的测试用例自动生成系统，包括测试抽取器、序列生成器、程序生成器、模型检测/求解器，其中测试抽取器和序列生成器共用模型检测/求解器，由人工描述的抽象化形式化/半形式化模型输入到测试抽取器，由模型检测/求解器对模型进行全状态空间探索，找出所有业务测试需求的点。序列生成器针对每一个测试用例，再一次进行模型检测/求解后得到每个测试用例的在测试时的操作顺序，程序生成器将测试序列变换成可执行程序，以实现测试操作的自动化。模型检测/求解器检测或求解抽象出来的形式化/半形式化语言形成建模语言，模型检测/求解器还可以进行全状态空间探索，找出所有业务测试需求的点。

还包括一种利用上述系统的计算机软件系统中一种基于业务流的测试用例自动生成方法，其特征在于，所述的方法包括如下步骤：

(1)建模，该步骤用形式化/半形式化建模语言对业务流程进行抽象化描述，得到一个基于业务的抽象模型，抽象的元素包括业务要点以及它们之间的关系，关系包括相互激励或相互制约。

(2)全状态空间检查，对由步骤(1)中抽象出来的形式化/半形式化模型，用模型检测/求解器进行全状态空间探索，找出所有业务测试需求的状态点，即该模型的全覆盖测试用例集合，这个过程需要用模型检测/求解器，对全状态空间进行检索。

(3)生成测试序列，针对每个测试用例，由模型检测/求解器自动探索模型路径，而模型是针对业务流建立的，因此可以根据模型路径确定测试操作顺序。

(4)本步骤是将测试序列变换成可执行程序，以实现测试操作的自动执行，测试执行后的系统状态，可以将系统实际运行后的状态和设计状态进行对比以确认测试结果。

本发明的有益效果在于：本发明可以解决业务流的测试用例自动生成问题。该方法基于形式化方法中的遍历技术，找出高覆盖率的业务流，自动生成基于业务流的测试用例，可以根据项目情况合理调整挑选粒度，并且可以找出执行测试所需要的操作顺序，由此可以得到可执行的测试程序，实现测试的高覆盖和自动化。因此，可大幅度提高产品开发、维护、升级、改造过程中，回归测试的效率和质量。

附图说明

图1基于业务流的测试用例自动生成原理；

图2应用例-血压监控画面。

具体实施方式

如图1所示，基于业务流的测试用例自动生成系统，包括测试抽取器、序列生成器、程序生成器，测试抽取器和序列生成器共用模型检测/求解器，抽象化描述的业务流程可输入到测试抽取器，序列生成器可针对每一个测试用例，以什么步骤执行以达到测试和确认的目的，针对测试用例,生成测试序列，可以得到针对每个测试用例的在测试时的操作顺序，程序生成器可将测试序列变换成可执行程序，以实现测试操作的自动执行，模型检测/求解器检测或求解抽象出来的形式化/半形式化语言形成建模语言，模型检测/求解器还可以进行全状态空间探索，找出所有业务测试需求的状态点，以及到达状态点的路径。

对业务的建模是解决方案的关键之处，本研究采用可配置的建模方法，系统的特征作为模型输入，在每一次系统变更时，模型不需要调整，而只需要重新配置输入条件。

本发明还包括一种根据所述的计算机软件系统中基于业务流的测试用例自动生成的方法，所述的方法包括如下步骤：

(1)建模。该步骤用形式化/半形式化建模语言对业务流程进行抽象化描述，得到一个基于业务的抽象模型。抽象的元素包括业务要点以及它们之间的关系，关系包括相互激励或相互制约。建模语言包括任意可以由模型检测/求解器检测或求解的形式化/半形式化语言。抽象及建模过程要求人员熟悉业务，能准确地把握抽象的粒度及相互依赖关系，也需要在建模的过程及测试过程中反复修订模型，直到满足需求为止。该步骤中得到业务的抽象形式化/半形式化模型，并输入到测试用例抽取器。

(2)全状态空间检查。对由步骤(1)中抽象出来的形式化/半形式化模型，用模型检测/求解器进行全状态空间探索，找出所有业务测试需求的状态点，即该模型的全覆盖测试用例集合。这个过程需要用模型检测/求解器，对全状态空间进行检索，可能会发生状态空间组合爆炸的问题，需要用户根据情况对模型抽象粒度及测试用例抽取条件进行调节。如果发生状态空间组合爆炸问题，或者模型检测时间过长，则适当增大模型粒度(合并状态以减小状态数)，或者使测试用例抽取条件更严，减少抽取样本数，抑制状态空间组合爆炸的产生。相反，如果抽取的测试用例不充分，则应该在模型检测/求解允许的时间范围内，降低模型粒度(使得模型描述更细致)，或者放宽测试用例抽取条件，得到可测得更充分的测试用例集合。在此步骤中，得到一个模型全覆盖的测试用例集合，用户也可以针对项目状况以及交付时期的情况，从中抽取子集。例如交付期短，则只需要针对修改流程进行测试，而不考虑整个业务流程，因此只抽取业务修订部分的测试用例。该步骤产生的测试用例集合，作为序列生成器的输入。

(3)生成测试序列。针对每个测试用例，需制定操作顺序以达到测试目的。该工作目前仍然是需要人工根据经验考虑的，当系统足够复杂的时候，该过程是费时且容易出错的一项工作。本发明可以针对每个测试用例，由模型检测/求解器自动探索模型路径。而模型是针对业务流建立的，因此可以根据模型路径确定测试操作顺序。本步骤是生成测试序列，即针对每一个测试用例，以什么步骤执行以达到测试和确认的目的。例如，在步骤(2)中生成测试用例集合{A,B,C,D,E}，在步骤(3)中分别针对A-E，找出到达可测状态的路径，也就是探索终点为测试对象的模型路径。例如针对测试用例A,生成测试序列step_1a,step_2a,…,A；针对B,生成测试序列step_1b,step_2b…B；以此类推。这样可以得到针对每个测试用例在测试时的操作顺序。

(4)生成执行序列。在步骤(3)中生成的测试序列，需要在实际系统中执行。如果是基于GUI的业务流程，也可以对应每个测试序列做相应的操作，并人工确定系统状态是否和设计需求一致。但是当系统复杂到一定程度时，手工执行需要耗费大量时间。而且对于非GUI系统，例如无显示的嵌入式系统，则无法用人工执行达到测试和确认的目的。本步骤是将测试序列变换成可执行程序，以实现测试操作的自动执行。实现原理是针对测试操作步骤调用现有函数或者增加新的函数，使得系统实现按照在步骤(3)中得到的顺序运行，以达到顺序执行测试操作的目的。测试执行后的系统状态，可以将系统实际运行后的状态和设计状态进行对比以确认测试结果。如果一致则表示测试通过，如果不一致可以抛出异常，或输出相应的错误报告。该步骤产出为可直接在系统上运行，并完成测试目的的可执行程序。

以下结合附图和实施例，对本发明中的技术方案进行清楚、完整地描述。基于本发明中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本发明保护的范围。

具体实施例

医疗肾透析仪监控界面测试验证实施例，如图2所示，本发明在医疗肾透析机的验证项目中投入使用，效果良好。根据系统设计需求，对监视控制功能的调用迁移关系实施建模。建模元素包括所有的113个画面、1891组件，以及3595个数据项。将这些元素之间的约束关系用形式化建模语言进行描述。例如：“血压大于140→血压高阈值警戒灯点亮”；“主画面压力设定→压力设定画面→压力设定操作→压力设定完毕”。对于该项目，共自动生成测试用例8035条，并完成自动执行测试。对以往需要10人月的回归测试缩短到3天测试自动执行完毕后，系统自动给出测试报告，由人工确认结果。覆盖率由以前的60％大幅度提高到分支覆盖93％。人力成本的降低和覆盖率自动化率的大幅上升，提高了产品的质量和信誉，减少了维护成本，降低产品上市和更新的速度，增加了企业的竞争力，给企业带来收益。

Claims (2)

1.基于业务流的测试用例自动生成系统，其特征在于：包括测试抽取器、序列生成器、程序生成器、测试抽取器和序列生成器，其中测试抽取器和序列生成器共用模型检测/求解器，抽象化描述的业务流程可输入到测试抽取器，序列生成器可针对每一个测试用例，以什么步骤执行以达到测试和确认的目的，针对测试用例,生成测试序列，可以得到针对每个测试用例的在测试时的操作顺序，程序生成器可将测试序列变换成可执行程序，以实现测试操作的自动执行，模型检测/求解器检测或求解以形式化/半形式化语言的描述建模，模型检测/求解器还可以对模型进行全状态空间探索，找出所有业务测试需求的状态点，并找出到测试点的执行路径，从而可生成用作自动测试的可执行程序。

2.一种根据权利要求1所述的系统的计算机软件系统中基于业务流的测试用例自动生成的方法，其特征在于，所述的方法包括如下步骤：

(1)建模，该步骤用形式化/半形式化建模语言对业务流程进行抽象化描述，得到一个基于业务的抽象模型，抽象的元素包括业务要点以及它们之间的关系，关系包括相互激励或相互制约。

(2)全状态空间检查，对由步骤(1)中抽象出来的形式化/半形式化模型，用模型检测/求解器进行全状态空间探索，找出所有业务测试需求的状态点，即该模型的全覆盖测试用例集合。

(3)生成测试序列，针对每个测试用例，由模型检测/求解器自动探索模型路径，而模型是针对业务流建立的，因此可以根据模型路径确定测试操作顺序。

(4)本步骤是将测试序列变换成可执行程序，以实现测试操作的自动执行，测试执行后的系统状态，可以将系统实际运行后的状态和设计状态进行对比以确认测试结果。