一种面向平台插件技术的测试方法
阅读：998发布：2020-06-02
专利汇可以提供一种面向平台插件技术的测试方法专利检索，专利查询，专利分析的服务。并且本 发明 公开了一种面向平台 插件 的测试方法，涉及 软件 测试领域。本发明具体包括测试模型、测试策略、测试设计、测试实施等。本发明在面向插件的软件测试理论、方法研究的 基础 上，结合传统软件测试的思想和项目工程中不同的插件特点，提出了插件测试的分层测试策略，一套相对通用的基于UML的插件化的新的集成测试 用例 设计思想，和基于场景测试的插件构成的新系统的测试方法。采用分层的测试策略，对于新开发的基础插件或核心类插件编码完成后，能够及时开展插件测试；采用新的集成测试方法：插件簇测试，验证了插件间的协作能 力 ，发现并有效 定位 插件间的 接口 问题；采用基于场景的系统测试，保证了系统实现业务能力与用户需求的一致性。，下面是一种面向平台插件技术的测试方法专利的具体信息内容。
1.一种面向平台插件技术的测试方法，其特征在于，包括以下步骤：
步骤1：测试模型选取：分析各测试模型的特点，并结合平台插件的开发方式，采用H测试模型进行指导测试；
步骤2：测试策略确定：依据被测系统的平台插件的体系架构，将被测系统的测试内容进行分层；所述分层的层数最多三层，该三层具体为：插件层、插件簇层和系统业务场景层，插件层为最底层，系统业务场景层为最高层；
步骤3：测试设计：对插件层、插件簇层和系统业务场景层逐层进行测试设计，具体为：
对插件层中的底层基础插件和核心插件采用传统测试法设计测试用例，依据测试用例分别对底层基础插件和核心插件进行灰盒测试；
根据插件的协作、依赖关系，从完成独立功能的角度，将插件按照逻辑划分为插件簇；
对插件簇采用基于UML的插件化的集成测试用例设计思想进行测试设计生成测试用例，依据测试用例对插件簇层进行黑盒测试；
根据插件簇之间的衔接以及协作关系，梳理出所有系统业务场景形成系统业务场景层，采用场景法设计测试用例，依据测试用例对系统业务场景层进行黑盒测试；
步骤4：测试实施：根据H测试模型对测试设计的测试用例逐层进行测试实施。
2.根据权利要求1所述的一种面向平台插件技术的测试方法，其特征在于，插件簇由一个或者多个插件组成，一个插件隶属于一个或者多个插件簇；系统业务场景层包含一个或者多个插件簇，所有插件簇组成被测系统。
3.根据权利要求1或2所述的一种面向平台插件技术的测试方法，其特征在于，步骤3所述的插件簇采用基于UML的插件化的集成测试用例设计思想进行测试设计生成测试用例，具体为：插件簇采用基于UML的插件化的集成测试用例设计思想，并根据测试准则生成操作序列长度各异的插件簇的初始测试用例，当插件簇中包含多个插件，且插件都进行了测试设计时，根据插件的测试用例的验证角度从初始测试用例中选取没有包含和交叉关系的测试用例生成插件簇的测试用例。
4.根据权利要求3所述的一种面向平台插件技术的测试方法，其特征在于：从初始测试用例中选择操作序列长度最大的操作序列对应的测试用例，再考虑测试用例的包含和交叉关系。
5.根据权利要求1所述的一种面向平台插件技术的测试方法，其特征在于，所述步骤4具体包括以下步骤：
(401)当单独的底层基础插件或核心插件具备测试条件时，进行插件的测试实施；
(402)当插件簇内对应的底层基础插件和核心插件已经测试通过后，对单独的插件簇进行测试实施；
(403)当所有的插件簇已经测试通过后，对系统业务场景层进行测试实施。
6.根据权利要求5所述的一种面向平台插件技术的测试方法，其特征在于，所述步骤(401)具体为：当单独的底层基础插件或核心插件具备测试条件时，依据插件的使用手册和内部实现编写测试驱动程序，通过测试驱动程序调用被测插件，依据测试用例对被测插件进行测试实施。
一种面向平台插件技术的测试方法
技术领域
背景技术
[0002] 针对传统的软件开发模式，软件测试一般采用具有代表意义的V测试模型。V模型仅仅把测试过程看作是软件开发过程中一系列串行活动的最后一个阶段，忽略了软件测试不仅包括程序，还应对相应的需求和设计进行测试，导致需求分析阶段隐藏的问题到后期的验收阶段才可能被发现，并且该模型不能对测试流程的完整性进行体现。
[0003] 按照传统的开发模式，测试阶段分为：单元、软件和系统测试。平台插件的开发模式中，系统化分为一个个独立功能的插件，多个插件联合完成独立业务功能，没有软件配置项的明确划分，传统测试阶段的划分已经不完全适用。
[0004] 插件簇是插件的依赖，协作关系形成的逻辑关系，插件簇的形成类似于插件集成，传统的集成测试方式有一次性集成和增殖式方式。插件簇没有层次的控制概念，因此传统的集成测试方式不适用于插件簇测试。
发明内容
[0005] 本发明的主要目的在于提供一种面向平台插件技术的测试方法，并进行项目应用，验证提出的测试方法的可行性，为后续基于平台插件开发方式的系统测试提供方法基础。
[0006] 为了实现上述目的，本发明提出了一种面向平台插件技术的测试方法，包括测试模型选取，测试策略确定，测试设计和测试实施，具体包括以下步骤：
[0007] 测试模型选取：分析各测试模型的特点，并结合平台插件的开发方式，采用H测试模型进行指导测试；
[0008] 测试策略确定：依据被测系统的平台插件的体系架构，将被测系统的测试内容进行分层；所述分层的层数最多三层，该三层具体为：插件层、插件簇层和系统业务场景层，插件层为最底层，系统业务场景层为最高层；
[0009] 测试设计：对插件层、插件簇层和系统业务场景层逐层进行测试设计，具体为：
[0010] 对插件层中的底层基础插件和核心插件采用传统测试法设计测试用例，依据测试用例分别对底层基础插件和核心插件进行灰盒测试；
[0011] 根据插件的协作、依赖关系，从完成独立功能的角度，将插件按照逻辑划分为插件簇；对插件簇采用基于UML的插件化的集成测试用例设计思想进行测试设计生成测试用例，依据测试用例对插件簇层进行黑盒测试；
[0012] 根据插件簇之间的衔接以及协作关系，梳理出所有系统业务场景形成系统业务场景层，采用场景法设计测试用例，依据测试用例对系统业务场景层进行黑盒测试；
[0013] 测试实施：根据H测试模型对测试设计的测试用例逐层进行测试实施。
[0014] 其中，插件簇由一个或者多个插件组成，一个插件隶属于一个或者多个插件簇；系统业务场景层包含一个或者多个插件簇，所有插件簇组成被测系统。
[0015] 其中，步骤3所述的插件簇采用基于UML的插件化的集成测试用例设计思想进行测试设计生成测试用例，具体为：插件簇采用基于UML的插件化的集成测试用例设计思想，并根据测试准则生成操作序列长度各异的插件簇的初始测试用例，当插件簇中包含多个插件，且插件都进行了测试设计时，根据插件的测试用例的验证角度从初始测试用例中选取没有包含和交叉关系的测试用例生成插件簇的测试用例。
[0016] 其中，从初始测试用例中选择操作序列长度最大的操作序列对应的测试用例，再考虑测试用例的包含和交叉关系。
[0017] 其中，所述步骤4具体包括以下步骤：
[0018] (401)当单独的底层基础插件或核心插件具备测试条件时，进行插件的测试实施；
[0019] (402)当插件簇内对应的底层基础插件和核心插件已经测试通过后，对单独的插件簇进行测试实施；
[0020] (403)当所有的插件簇已经测试通过后，对系统业务场景层进行测试实施。
[0021] 其中，所述步骤(401)具体为：当单独的底层基础插件或核心插件具备测试条件时，依据插件的使用手册和内部实现编写测试驱动程序，通过测试驱动程序调用被测插件，依据测试用例对被测插件进行测试实施。
[0022] 本发明相比背景技术的有益效果：
[0023] (1)H测试模型可以尽早和并行测试，有效避免错误的影响范围扩大，解决了开发与测试，以及测试过程内部的协同问题，缩短了项目研发周期；
[0025] (3)探索并提出的一套相对通用的基于UML的插件化的新的集成测试用例设计思想，解决了插件开发带来的测试问题，为后续基于平台插件开发方式的系统的集成测试提供方法基础，通过对该测试方法的应用和测试实施，验证了本发明提出的测试方法的有效性，同时有效保证了系统的稳定性和安全性。
[0026] (4)测试用例的复用在后续项目升级改造之时或者其他类似项目新研时，大部分插件功能不用再重复开发，只需要进行专用插件定制与插件集成。相应的，在对底层基础插件和核心插件以及插件簇测试后，对基于被测系统新搭建的系统，可以复用相应的插件或插件簇测试用例，或进行测试用例组合，对新系统进行插件组装测试和系统测试，测试重点为基于典型或特定应用的系统测试。附图说明
[0027] 图1是本发明的任务管控平台体系架构成图；
[0028] 图2是本发明的方案修正服务契约插件的类关系图；
[0029] 图3是本发明方案修正服务插件的修正接收方案方法的活动图；
[0030] 图4是本发明的多平台任务统筹分析功能集成图；
[0031] 图5是本发明的多平台任务统筹分析功能用例图；
[0032] 图6是本发明的多平台任务分析筹划插件组处理过程序列图；
[0033] 图7是本发明的航天任务处理流程序列图；
[0034] 图8是本发明的观测任务可行性分析插件内的序列图；
[0035] 图9是本发明的TaskFeasbilityAnalyze类关系；
[0036] 图10是本发明的AeraDeal处理流程；
[0037] 图11是本发明的基于场景的测试框架。
具体实施方式
[0038] 为使本发明的目的、技术方案和优点更加清楚明白，以下结合具体实施例，并参照附图，对本发明作进一步的详细说明。
[0039] 本发明提出了一种面向平台插件技术的测试方法，该方法对基于OSGI规范的插件集成框架，采用C#语言开发实现的任务管控平台进行应用和实践，任务管控平台的体系架构如图1所示。基于采用的测试模型，测试策略和测试设计方法，分别进行基础插件和核心插件的接口，功能测试，插件簇的集成测试和系统测试。
[0040] 一种面向平台插件技术的测试方法，包括以下步骤：
[0041] 步骤1：测试模型选取：分析各测试模型的特点，并结合平台插件的开发方式，采用H测试模型进行指导测试；
[0042] 采用H测试模型，将每个层次的测试活动完全独立出来，只要测试条件成熟，测试准备活动完成，测试执行活动就可以进行。有效解决了尽早测试、独立测试、并行测试和迭代测试的问题。
[0043] 采用该模型，对不同的被测件可以分层次进行，将测试和开发紧密结合，同步进行，并有效缩短测试时间。
[0044] 步骤2：测试策略确定：依据被测系统的平台插件的体系架构，将被测系统的测试内容进行分层；所述分层的层数最多三层，该三层具体为：插件层、插件簇层和系统业务场景层，插件层为最底层，系统业务场景层为最高层；
[0045] 插件开发具有分布开发、动态插拔特点，插件的完整性，独立性高于传统单元的特性，结合传统的测试步骤划分，确定了插件的测试层；插件的灵活配置特点，可按照不同的功能需求自由组合形成插件簇，没有软件配置项的明确划分，确定了插件簇的测试层；与传统的系统测试对应的提出了系统业务场景层的测试。
[0046] 采用平台插件开发模式开发的系统，当插件数量多时，逐个插件开展插件测试的工作量大。权衡插件的复杂性和测试充分性准则问题，采用分层测试的测试策略，具体为：
[0047] a)对底层基础插件和核心插件，进行基于规约和基于代码实现的插件测试，采用灰盒测试策略，重点考虑插件接口覆盖、功能覆盖和路径覆盖测试，确保插件接口的一致性，插件使用者调用插件服务实现功能的正确性，从而验证底层和核心插件的稳定性。
[0048] b)插件簇的测试成为该开发方式的插件系统的测试重点，在该层次测试过程中，重点关注插件间交互的覆盖率、事件覆盖率、消息覆盖率等，从而验证插件相互协调完成系统业务能力的正确性。
[0049] c)系统业务场景层重点考虑插件簇之间的正确衔接、数据流向、以及协作完成典型应用模式下的系统能力。
[0050] 步骤3：测试设计：对插件层、插件簇层和系统业务场景层逐层进行测试设计，具体为：
[0051] 对插件层中的底层基础插件和核心插件采用传统测试法设计测试用例，依据测试用例分别对底层基础插件和核心插件进行灰盒测试；
[0052] 根据插件的协作、依赖关系，从完成独立功能的角度，将插件按照逻辑划分为插件簇；对插件簇采用基于UML的插件化的集成测试用例设计思想进行测试设计生成测试用例，依据测试用例对插件簇层进行黑盒测试；
[0053] 根据插件簇之间的衔接以及协作关系，梳理出所有系统业务场景形成系统业务场景层，采用场景法设计测试用例，依据测试用例对系统业务场景层进行黑盒测试；
[0054] (1)插件测试
[0055] a)基础插件
[0056] 对于基础功能的插件进行接口测试，采用黑盒测试方法，从插件使用方角度，通过接口契约的调用参数，调用形式等输入数据得到结果，并进行与接口规范的比较得到测试报告。
[0057] 在设计接口测试输入参数时,除了使用传统的等价类划分、边界值分析等方法外，还要考虑到接口的前置条件和后置条件等约束。同时根据插件的功能特定，选取相应的动态测试方案。若插件主要用于数据交换，则应偏重于数据的测试，可采用数据流的动态测试方案，该方法应用到ESB总线服务的插件测试中。
[0058] 以工作流作业调度插件为例，描述插件接口测试用例设计。
[0060] 工作流引擎服务，是独立部署的webserver，配合第三方工作流产品，负责业务的调度。工作流调度插件是和工作流引擎服务唯一交互的中间层，它封装了统一的工作流引擎服务的交互接口，供插件使用方调度工作流，接口定义如下：
[0061]
[0062] 步骤3-1-2：以正确性和充分性的原则，选取插件的接口数据进行测试。
[0063] 包括：合法的输入数据，即所有有效的和期望的数据；非法的输入数据，即无效的和不期望的数据；能够表达上下文相关的输入数据；各种约束，对输入数据或测试的各种约束。
[0064] 设计的该插件接口测试用例：已定义的工作流信息，不存在的工作流信息。
[0065] b)核心功能插件
[0066] 对于核心功能(服务类)插件，既测试接口，同时又考虑服务的设计实现原理。从插件状态与实现角度出发，依据插件设计说明中的交互图，采用灰盒测试方法，制定测试用例，再实施测试。以方案修改服务插件为例进行测试过程描述。
[0067] 步骤3-2-1：从插件的设计说明中，分析方案修改契约插件的接口定义。
[0068] 方案修正服务契约插件(UpdateRecvContact)包含IUpdateRecv类，该类定义了服务需要实现的方法。类关系图如图2所示。
[0069] 输入参数：
[0070] config：待修正的方案配置信息
[0071] error：修正过程中返回的错误信息。
[0072] 返回值：true表示成功，false表示失败。
[0073] 步骤3-2-2：从插件的设计说明中，方案修正服务插件定义了对方案修正的实现方法，bool Update(ref SchemeConfig config,ref string error)。修正接收方案服务插件的实现类所用的逻辑如图3所示。
[0074] 依据逻辑判定条件，分别从调用预报失败，循环开始，循环结束等多条件分支，设计测试用例。
[0075] 设计的该插件接口测试用例有：方案正确的配置信息，不满足SchemenConfig格式的方案信息，输入参数不完整的调用信息。
[0076] 设计的该插件功能测试用例有：调用测站预报失败用例，只有一个可匹配的接收时段修正用例，方案中的多个接收时段修正用例，方案中的一个接收时段修改接收仰角用例。
[0077] 步骤3-2-3：在测试环境中增加模拟数据，在数据库中录入测试用的不同接收方案数据。
[0078] (2)插件簇测试
[0079] 由于插件簇是多个有协作关系的插件的集合，因此插件簇测试时，用例的设计变得更加复杂。需要考虑的：一是各个插件的顺序如何安排；二是如何测试新增加的插件。为了确定上下文相关关系，我们采用基于协作图和顺序图的方法对测试因素进行描述，分析包含类的实例的UML协作图和顺序图，梳理各插件之间的交互关系，进行插件簇划分和插件簇的测试。
[0080] 具体实施过程是，首先从插件需求规格说明中分析插件组的功能用例图和功能集成图；从插件设计说明中，找出插件不同级别的过程序列图。根据插件间的依赖关系，构造不同的插件簇。对于每个插件簇采用传统黑盒测试方法，从尽可能发现被测插件簇的功能或接口缺陷的角度，设计测试用例，最后实施测试。
[0081] 以多平台任务分析筹划插件组为例，具体描述插件簇逐步划分和插件簇测试的过程。
[0082] 步骤3-3-1：理解，分析插件组功能
[0083] 多平台任务分析筹划插件组的功能为：根据情报侦察、军事测绘等类型任务要求，统筹考虑各类观测资源能力，根据任务的观测要求、目标特性等进行可行性分析与统筹考虑后，将任务分配给不同的观测平台；
[0084] 对于航天任务，结合卫星的观测能力对区域任务进行分解，把一个大区域需求分解成卫星一次观测可以完成的多个小任务；
[0085] 将卫星观测任务经可行性分析与分解处理后，生成可供任务规划插件组可使用的观测元任务。
[0086] 其中多平台任务统筹分析功能集成图如图4所示，多平台任务统筹分析功能用例图如图5所示，多平台任务分析筹划插件组处理过程序列图如图6所示。
[0087] 其中数据持久化插件，日志管理插件，地图显示插件均为基础平台的插件，在基础平台的插件接口和功能测试已经验证。
[0088] 步骤3-3-2：分析，梳理插件组的过程序列关系
[0089] 航天任务处理流程序列图如图7所示，观测任务可行性分析插件内的序列图如图8所示。
[0090] 步骤3-3-3：依据插件簇的划分原则，划分插件簇，形成的测试簇有：观测任务可行性分析簇，航天任务处理簇，航空任务处理簇，多任务统筹分析簇。
[0091] 步骤3-3-4：逐步分析插件簇内的插件类关系图，类内操作的处理流程图，再结合插件簇内的UML序列图的动态行为导出该簇的测试方法序列。
[0092] 其中观测任务可行性分析插件组中的区域可行性分解的类关系图如图9所示，其中AreaTargetDeal的一个操作的处理流程如图10所示。
[0093] 根据确定的测试方法，观测任务处理簇生成的测试用例为：区域任务不能被型号卫星访问、区域任务新的访问条带已经被覆盖、区域任务访问条带与需求未覆盖区域有交叉、点目标被访问和点目标没有被访问等。
[0094] 航天任务处理簇分析生成测试用例时，从该簇的操作序列中选取长度最大的操作序列生成初始测试用例，再去除簇中有包含关系观测任务可行性分析簇的功能，综合考虑不同型号卫星的观测方式上设计最终的测试用例。生成的测试用例为：不同型号卫星的航天任务观测，同一型号卫星不同观测方式的目标观测，不同型号卫星侧摆情况下的任务观测等。
[0095] 其他插件簇的测试设计不再一一赘述。
[0096] (3)系统测试
[0097] 步骤3-4-1：以需求分析中的设计模型为基础，在插件簇的交互序列中添加约束，通过序列联合和序列的精化生成初始场景集，然后从初始场景集中，按照系统的使用方式，选取真实场景来描述系统的总体行为，再从被测系统的完整性，适用性、健壮性、易用性等角度设计生成系统业务场景层测试用例。基于场景的测试框架如图11所示。
[0098] 步骤3-4-2：设计测试用例。对不同系统业务场景层从有利于检验的角度设计测试用例，重点关注被测系统功能的正确性，流程变化的适应性，以及系统对外接口的一致性。
[0099] 被测系统主要分为常规业务场景和应急业务场景。常规业务场景主要功能是面向多用户提交的观测需求，调度多颗卫星和地面资源进行任务安排。在实际使用中多用户可以同时启动多个常规业务，或根据不同的工作需求定制不同的常规业务流程节点。基于实际的使用场景，从插件簇的序列中进行筛选，精化生成测试用例。
[0100] 步骤3-4-3：在实施系统测试的时候，根据需要可以修正并完善用例。
[0101] 步骤4：测试实施：根据H测试模型对测试设计的测试用例逐层进行测试实施。
[0102] 单独的底层基础插件或核心插件的测试实施，验证插件对外交互接口是否与插件规范说明一致，插件实现的功能是否正确。
[0103] 插件簇的测试实施，判断插件簇功能的正确性，以及验证框架对插件数量逐渐增加的动态加载，即插即用能力，以及平台框架的稳定性。
[0104] 对系统业务场景层进行测试实施，验证被测系统在系统业务场景层实现系统行为的正确性和合理性，被测系统的完整性，适用性、健壮性、易用性等。
[0105] 以上所述的具体实施例，对本发明的目的、技术方案和有益效果进行了进一步详细说明，应理解的是，以上所述仅为本发明的具体实施例而已，并不用于限制本发明，凡在本发明的精神和原则之内，所做的任何修改、等同替换、改进等，均应包含在本发明的保护范围之内。
| 标题 | 发布/更新时间 | 阅读量 |
|---|---|---|
| 合流开发模式下的测试方法、装置 | 2020-05-16 | 693 |
| 漏洞检测方法及装置 | 2020-05-19 | 222 |
| 一种基于模型的系统设计及信息流可视化仿真系统及方法 | 2020-05-20 | 407 |
| 一种多CDN辅助的多层云的直播分发系统 | 2020-05-11 | 1008 |
| 一种基于图形用户界面的软件搜索复用方法及系统 | 2020-05-08 | 535 |
| 一种智能自主联动型WEB应用防护主机 | 2020-05-11 | 946 |
| 一种工业控制软件测试系统和软件测试方法 | 2020-05-12 | 267 |
| 基于Java虚拟机的黑盒测试方法、装置、终端及存储介质 | 2020-05-13 | 942 |
| 一种仪控系统黑盒测试系统 | 2020-05-12 | 86 |
| 一种飞机位置灯和防撞灯功能测试电路及应用其的测试台 | 2020-05-13 | 895 |
高效检索全球专利专利汇是专利免费检索,专利查询,专利分析-国家发明专利查询检索分析平台，是提供专利分析，专利查询，专利检索等数据服务功能的知识产权数据服务商。
我们的产品包含105个国家的1.26亿组数据，免费查、免费专利分析。
分析报告
专利汇分析报告产品可以对行业情报数据进行梳理分析，涉及维度包括行业专利基本状况分析、地域分析、技术分析、发明人分析、申请人分析、专利权人分析、失效分析、核心专利分析、法律分析、研发重点分析、企业专利处境分析、技术处境分析、专利寿命分析、企业定位分析、引证分析等超过60个分析角度，系统通过AI智能系统对图表进行解读，只需1分钟，一键生成行业专利分析报告。
黑盒测试热门专利
QQ群二维码
意见反馈
意见反馈