CN102591779B - 基于工作流的通用软件测试过程模型的建立方法 - Google Patents
基于工作流的通用软件测试过程模型的建立方法 Download PDFInfo
- Publication number
- CN102591779B CN102591779B CN201210008291.XA CN201210008291A CN102591779B CN 102591779 B CN102591779 B CN 102591779B CN 201210008291 A CN201210008291 A CN 201210008291A CN 102591779 B CN102591779 B CN 102591779B
- Authority
- CN
- China
- Prior art keywords
- test
- atom action
- node
- atom
- action
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Expired - Fee Related
Links
Landscapes
- Debugging And Monitoring (AREA)
Abstract
本发明提供的基于工作流的通用软件测试过程模型的建立方法,包括以下步骤:S1:将软件测试过程中的各个业务活动细化,得到原子活动;S2:定义所述原子活动的要素,得到所述通用软件测试过程模型的组成结构图;S3:根据所述组成结构图通过软件测试过程描述语言定义元素,并设置与所述元素对应的属性;通过所述元素和所述属性得到所述原子活动的原子活动逻辑;S4:利用XML语言对所述原子活动逻辑进行形式化描述,得到与所述软件测试过程对应的软件测试过程模型。本发明克服了一般现有的软件测试过程模型由于基于业务逻辑而建立所造成的不能够通用的缺点,当业务发生变动时,该模型依然适用,因此,具有通用性强的优点。
Description
技术领域
本发明涉及计算机技术领域,具体涉及一种基于工作流的通用软件测试过程模型的建立方法。
背景技术
软件测试,是指在软件投入运行前,对软件需求分析、设计规格说明和编码的最终复查。
软件测试过程是指软件测试的不同开发阶段,通常包括:单元测试、集成测试、系统测试和验收测试。其中,对每一个测试阶段均定义了相关测试人员的进出准则、规范活动及输出的工作产品。完善的软件测试过程可以有效的提高软件测试的质量。
现有软件测试过程模型通常是基于业务逻辑而建立的,当业务发生变动时,原软件测试过程模型不再适用,因此,现有软件测试过程模型具有通用性差的缺点。
发明内容
针对现有技术存在的缺陷,本发明提供一种基于工作流的通用软件测试过程模型的建立方法,将工作流方法引入软件测试过程,并且基于原子活动逻辑来建立通用软件测试过程模型,从而提高了通用软件测试过程模型的通用性。
本发明所采用的技术方案如下:
本发明提供一种基于工作流的通用软件测试过程模型的建立方法,包括以下步骤:
S1:将软件测试过程中的各个业务活动细化,得到原子活动;
S2:定义所述原子活动的要素,得到所述通用软件测试过程模型的组成结构图;
S3:根据所述组成结构图通过软件测试过程描述语言定义元素,并设置与所述元素对应的属性;通过所述元素和所述属性得到所述原子活动的原子活动逻辑;
S4:利用XML语言对所述原子活动逻辑进行形式化描述,得到与所述软件测试过程对应的软件测试过程模型。
优选的,所述原子活动为包括以下信息的活动:与所述原子活动对应的输入数据、与所述原子活动对应的输出数据、与所述原子活动对应的操作方法、与所述原子活动对应的参与者信息、与所述原子活动对应的功能和与所述原子活动对应的目的;各个所述原子活动间通过预设逻辑相关联。
优选的,S2中,所述要素包括:与所述原子活动对应的软件测试过程定义、测试参与者的活动、所述原子活动的变迁条件、测试相关数据信息、角色信息、测试参与者信息和应用程序;其中,
所述软件测试过程定义为定义所述软件测试过程的基本信息,所述基本信息包括:所述软件测试过程的过程简介信息、所述软件测试过程的开始时间、所述软件测试过程的创建者信息;
所述测试参与者的活动为所述测试参与者需要执行的具体任务;
所述原子活动的变迁条件为所述原子活动向其他原子活动发生变迁的条件,如果满足所述变迁条件,则进行变迁,否则不进行变迁;
所述测试相关数据信息包括:所述原子活动的变迁方向、与所述原子活动对应的控制数据;所述控制数据为全局数据;
所述角色信息为所述测试参与者的具体角色;
所述测试参与者信息包括:所述测试参与者的姓名信息;
所述应用程序为被所述原子活动调用的应用程序,所述应用程序为全局变量。
优选的,所述组成结构图为所述原子活动的UML图。
优选的,S3中,所述元素包括:源节点、目标节点、转移条件、活动节点、测试数据、应用程序、测试参与者;
其中,所述活动节点用于标记所述原子活动;
所述源节点用于标记与当前连接线的出发点对应的活动节点;
所述目标节点用于标记与所述当前连接线的结束点对应的活动节点;
所述转移条件用于标记所述原子活动间的变迁条件,如果满足所述变迁条件,则由当前原子活动跳转到下一个原子活动;如果不满足所述变迁条件,则所述当前原子活动不进行跳转;
所述测试数据用于表示所述软件测试过程中的所述控制数据,所述测试数据为全局变量;
所述应用程序用于表示被调用的应用程序,所述应用程序为全局变量;
所述测试参与者用于标记所述软件测试过程中各个所述原子活动的参与者,所述测试参与者为全局变量。
优选的,所述活动节点包括以下内容:
手动节点:用于标记需要所述测试参与者手动执行的原子活动;
自动节点:用于标记通过调用所述应用程序完成的原子活动;
选择节点:用于标记所述软件测试过程中多个任务流的汇集情况;
并行节点:用于标记需要并行执行的多个所述原子活动;
子过程节点:用于标记子过程活动;
开始节点:用于标记所述通用软件测试过程模型的唯一入口点;
结束节点:用于标记所述通用软件测试过程模型的唯一出口点。
优选的,S4中,所述利用XML语言对所述原子活动逻辑进行形式化描述,具体为分别定义以下内容:定义各个标记的公共属性;定义应用程序;定义变量;定义传输线;附加定义活动节点;定义标志节点;定义任务节点;过程定义标记;过程定义XML文件根元素标记。
本发明的有益效果如下:
本发明提供的基于工作流的通用软件测试过程模型的建立方法,该方法引入工作流方法中相关技术的概念及关系,并参考工作流元模型,设计出通用软件测试过程模型。该模型克服了一般现有的软件测试过程模型由于基于业务逻辑而建立所造成的不能够通用的缺点,当业务发生变动时,该模型依然适用,因此,具有通用性强的优点。
附图说明
图1为本发明实施例提供的基于工作流的通用软件测试过程模型的建立方法的流程示意图;
图2为本发明实施例提供的业务逻辑和原子活动逻辑的双层结构图;
图3为本发明实施例提供的一种原子活动要素的UML图;
图4为本发明实施例提供的软件测试过程描述语言的元素层次图;
图5为本发明实施例提供的语言元素描述软件测试过程步骤图;
图6为本发明实施例提供的系统测试基本流程图。
具体实施方式
以下结合附图对本发明的一个具体的实施方式进行说明。
本发明提供一种基于工作流的通用软件测试过程模型的建立方法,该方法引入工作流方法中相关技术的概念及关系,并参考工作流元模型,设计出通用软件测试过程模型。该模型克服了一般现有的软件测试过程模型由于基于业务逻辑而建立所造成的不能够通用的缺点,当业务发生变动时,该模型依然适用。本发明提供的基于工作流的通用软件测试过程模型的建立方法,如图1所示,包括以下步骤:
S101:将软件测试过程中的各个业务活动细化,得到原子活动。
本步骤中,将软件测试过程分两个层面描述,将业务部分进行细化,分解成更细的原子活动,从而形成高层为业务逻辑,底层为原子活动逻辑的模型,而底层的原子活动逻辑是更为本质的描述方法,并且,原子活动不可再分解,从而提高了软件测试过程的通用性和灵活性。如图2所示,为业务逻辑和原子活动逻辑的双层结构图。将多个原子活动通过相应的规则连接起来,就形成了一个测试过程。
因此,当给定测试对象以后,对软件测试过程以原子活动为单位细分并加以关联,从而能够实现所有的软件测试过程中的业务活动都可以由相应的原子活动组合而成。
所述原子活动为包括以下信息的活动:与所述原子活动对应的输入数据、与所述原子活动对应的输出数据、与所述原子活动对应的操作方法、与所述原子活动对应的参与者信息、与所述原子活动对应的功能和与所述原子活动对应的目的;各个所述原子活动间通过预设逻辑相关联。其中,原子活动间的逻辑通过下面步骤介绍,在此不再赘述。
S102:定义所述原子活动的要素,得到所述通用软件测试过程模型的组成结构图;
本发明中,为每一个原子活动均定义对应的要素,其中,要素的种类可根据实际使用需要进行调整,如图3所示,为当采用7个要素时,得到的一种原子活动要素的UML(Unified Modeling Language,统一建模语言)图,所述要素包括:与所述原子活动对应的软件测试过程定义、测试参与者的活动、所述原子活动的变迁条件、测试相关数据信息、角色信息、测试参与者信息和应用程序;其中,
所述软件测试过程定义为定义所述软件测试过程的基本信息,所述基本信息包括:所述软件测试过程的过程简介信息、所述软件测试过程的开始时间、所述软件测试过程的创建者信息;
所述测试参与者的活动为所述测试参与者需要执行的具体任务;
所述原子活动的变迁条件为所述原子活动向其他原子活动发生变迁的条件,如果满足所述变迁条件,则进行变迁,否则不进行变迁;
所述测试相关数据信息包括:所述原子活动的变迁方向、与所述原子活动对应的控制数据;所述控制数据为全局数据;
所述角色信息为所述测试参与者的具体角色;
所述测试参与者信息包括:所述测试参与者的姓名信息;
所述应用程序为被所述原子活动调用的应用程序,所述应用程序为全局变量。
S103:根据所述组成结构图通过软件测试过程描述语言定义元素,并设置与所述元素对应的属性;通过所述元素和所述属性得到所述原子活动的原子活动逻辑;
本发明中,定义的元素的具体数量根据实际需要进行调整,本实施例中,以提供7个元素为例进行说明。如图4所示,为软件测试过程描述语言的元素层次图,如图5所示,为语言元素描述软件测试过程步骤图,所述元素包括:源节点、目标节点、转移条件、活动节点、测试数据、应用程序、测试参与者;
其中,所述活动节点用于标记所述原子活动;
所述源节点用于标记与当前连接线的出发点对应的活动节点;
所述目标节点用于标记与所述当前连接线的结束点对应的活动节点;
所述转移条件用于标记所述原子活动间的变迁条件,如果满足所述变迁条件,则由当前原子活动跳转到下一个原子活动;如果不满足所述变迁条件,则所述当前原子活动不进行跳转;
所述测试数据用于表示所述软件测试过程中的所述控制数据,所述测试数据为全局变量;如判断“转移条件”是否为真时所需要的数据即为控制数据。
所述应用程序用于表示被调用的应用程序,所述应用程序为全局变量;
所述测试参与者用于标记所述软件测试过程中各个所述原子活动的参与者,所述测试参与者为全局变量。
进一步的,所述活动节点包括以下内容:
手动节点:用于标记需要所述测试参与者手动执行的原子活动;
自动节点:用于标记通过调用所述应用程序完成的原子活动,而不需要人工参与;
选择节点:用于标记所述软件测试过程中多个任务流的汇集情况;
并行节点:用于标记需要并行执行的多个所述原子活动;
子过程节点:用于标记子过程活动,用于比较复杂的软件测试过程描述;
开始节点:用于标记所述通用软件测试过程模型的唯一入口点,它没有前驱节点,所有的软件测试过程模型都是从开始节点执行,然后根据相关条件节点激活后续活动节点;
结束节点:用于标记所述通用软件测试过程模型的唯一出口点,它没有后续节点,一旦激活了结束节点,则整个软件测试过程结束。
S104:利用XML(extensible markup language,可扩展标记语言)语言对所述原子活动逻辑进行形式化描述,得到与所述软件测试过程对应的软件测试过程模型。
所述利用XML语言对所述原子活动逻辑进行形式化描述,具体为分别定义以下内容:定义各个标记的公共属性;定义应用程序;定义变量;定义传输线;附加定义活动节点;定义标志节点;定义任务节点;过程定义标记;过程定义XML文件根元素标记。
利用XML语言对底层原子活动逻辑进行形式化描述,提供与平台无关的模型表示方法。该描述有利于软件测试过程在跨平台或多平台实现。
因此,当给定一个测试对象的时候,根据以上步骤即可方便的对该软件测试对象定义一个测试过程,实现对测试过程的形式化、标准化的描述,再经过具体的一系列工作,得到有效的测试结果。
基于工作流的思想,通过使用本发明提供的软件测试过程模型,将软件测试过程分解成八层结构,使用XML语言八层结构进行描述。
下面以基于GJBZ-141标准体系的软件系统测试中的一个阶段性过程为例,介绍该通用软件测试过程模型的应用方式。
基于GJBZ-141的软件系统测试是以完整的、集成的计算机系统为测试对象,目的是在真实系统或仿真系统工作环境下,验证完整的软件配置项能否和系统正确连接、并满足系统或子系统设计文档和软件开发任务书规定的要求。
系统测试的人员配置如下:
测试项目负责人:管理监督测试项目、提供技术指导、获取适当的资源、指定基线、技术协调、负责项目的安全保密和质量管理。
测试分析员:确定测试计划、测试内容、测试方法、测试数据生成方法、测试(软、硬件)环境、测试工具、评估测试工作的有效性。
测试设计员:设计测试用例,确定测试用例的优先级,建立测试环境。
测试程序员:编写测试辅助软件。
测试员:执行测试、记录测试结果。
测试系统管理员:对测试环境和资产进行管理和维护。
配置管理员:设置、管理和维护测试配置管理数据库。
系统测试一般由软件的需方组织、由独立于软件开发的组织实施。如果系统测试由第三方实施,必须是军方认可的第三方测试组织。
系统测试要求强化配置管理,已经通过测试的系统状态和各项参数应详细记录,归档保存,未经测试负责人允许,任何人无权改变。
系统测试过程由四个阶段组成,分别是测试策划阶段、测试设计与实现阶段、测试执行阶段、测试总结阶段。
每个阶段都会有相应的验证工作,如果该阶段的测试工作通过验证,则开始下一阶段,否则继续迭代执行本阶段工作。每个测试阶段都由很多测试任务构成,篇幅所限,我们只介绍测试设计与实现、测试执行两个阶段的测试任务。
在测试设计与实现阶段,测试设计人员和测试程序员应该完成以下测试工作任务:
1)设计测试用例:将需测试的软件特性分解,针对分解后的每种情况设计测试用例,每个测试用例的设计应符合GJBZ-141标准的要求;
2)获取测试数据:包括获取现有的测试数据和生成新的测试数据,并按照要求验证所有数据;
3)确定测试顺序:可从资源约束、风险以及测试用例失效造成的影响等方面考虑;
4)获取测试资源:对于支持测试的软件,有的需要从现有的工具中选定,有的需要开发;
5)编写测试程序:包括开发测试支持工具;
6)建立和校准测试环境;
7)按照GJBZ-141标准编写系统测试说明;
8)评审和验证。
在明确了软件测试过程实例的基本内容之后,我们开始用软件测试过程描述语言来描述这个测试过程实例。首先要对测试过程实例做深入分析。
经分析可知,测试过程实例包括一个有4个任务节点的串行的过程,这四个过程分别为测试策划、测试设计与实现、测试执行、测试总结,每个测试任务节点之间都有相应的转换条件。如由测试策划阶段转向测试设计与实现阶段的转换条件为:测试策划通过评审。即如果转换条件不满足,那么测试策划阶段继续迭代进行。实例对各阶段的人员配置做了明确的说明:测试策划阶段由测分析员参与;测试设计与实现阶段由测试设计员和测试程序员参与;测试执行阶段由测试员和测试分析员参与,测试总结阶段由测试分析员参与。图6明确地表示了该测试过程。
下面介绍如何利用软件测试过程描述语言描述该流程:
第一步:定义全局变量。
测试过程实例的流程涉及到了四次验证,每次验证都需要有一个条件判断,因此可将四个验证条件定义为BOOL型的全局变量,具体如下:
定义BOOL型的全局变量TestSchemeIsOK,若该变量的值为True,表明测试策划阶段验证通过;若值为False,表明验证未通过。
定义BOOL型的全局变量DesignandImplementationIsOK,若该变量的值为True,表明测试设计与实现阶段验证通过;若值为False,表明验证未通过。
定义BOOL型的全局变量TestExecutionIsOK,若该变量的值为True,表明测试执行阶段验证通过;若值为False,表明验证未通过。
定义BOOL型的全局变量TestSumIsOK,若该变量的值为True,表明测试总结阶段验证通过;若值为False,表明验证未通过。
用软件测试过程描述语言描述这四个全局变量:
第二步:分析并定义各节点类型。
首先,分析四个任务节点,每一个节点实际上都是子过程节点(其中测试设计与实现、测试执行两个子过程节点在后文中会详细描述),各个子过程节点之间是顺序关系,用WF-STPDL分别定义,我们先给出描述,然后进行解释,具体如下:
测试策划阶段的任务节点定义:
测试设计与实现阶段的任务节点定义:
测试执行阶段的任务节点定义:
测试总结阶段的任务节点定义:
因为开始和结束标记节点、传输线等数据尚未定义,因而任务节点定义中相应的属性值暂时未空。
下面开始定义开始节点和结束节点:
开始节点的定义:
结束节点定义:
同理,因传输线等数据尚未定义,因而标记节点定义中相应的属性值暂时为空。
下面开始定义传输线。
本过程测试实例包含5条传输线,每条传输线包含一个转换条件,下面分别定义各传输线:
开始节点到测试策划任务节点的传输线定义:
测试策划到测试设计与实现的传输线定义:
测试设计与实现到测试执行的传输线定义:
测试执行到测试总结的传输线定义:
测试总结到过程实例结束的传输线定义:
以上是5条传输线的定义,这些定义需要用传输线集合标签组织起来,传输线集合标签的定义为:
<transitions/>,它包含0个或以上的<Transition/>标记。
定义完全部传输线之后,标记节点和任务节点的属性即可以补全,且节点之间的联系也建立起来了。
然后,我们需要定义测试过程实例的根节点和过程定义标记,它们用于描述实例的基本情况,具体如下:
最后,依据传输线、标记节点、任务节点之间的属性对应关系,将任务节点和标记节点的相关属性补充完整,就得到了最终的基于WF-STPDL的实例过程描述,代码如下:
以上是用WF-STPDL描述的一个简单的软件系统测试过程实例。
以上所述仅是本发明的优选实施方式,应当指出,对于本技术领域的普通技术人员来说,在不脱离本发明原理的前提下,还可以做出若干改进和润饰,这些改进和润饰也应视本发明的保护范围。
Claims (3)
1.一种基于工作流的通用软件测试过程模型的建立方法,其特征在于,包括以下步骤:
S1:将软件测试过程中的各个业务活动细化,得到原子活动;
具体的,将软件测试过程分两个层面描述,将业务部分进行细化,分解成更细的原子活动,从而形成高层为业务逻辑,底层为原子活动逻辑的模型,而底层的原子活动逻辑是更为本质的描述方法,并且,原子活动不可再分解;
S2:定义所述原子活动的要素,得到所述通用软件测试过程模型的组成结构图;
S3:根据所述组成结构图通过软件测试过程描述语言定义元素,并设置与所述元素对应的属性;通过所述元素和所述属性得到所述原子活动的原子活动逻辑;
S4:利用XML语言对所述原子活动逻辑进行形式化描述,得到与所述软件测试过程对应的软件测试过程模型;
其中,所述原子活动为包括以下信息的活动:与所述原子活动对应的输入数据、与所述原子活动对应的输出数据、与所述原子活动对应的操作方法、与所述原子活动对应的参与者信息、与所述原子活动对应的功能和与所述原子活动对应的目的;各个所述原子活动间通过预设逻辑相关联;
S2中,所述要素包括:与所述原子活动对应的软件测试过程定义、测试参与者的活动、所述原子活动的变迁条件、测试相关数据信息、角色信息、测试参与者信息和应用程序;
所述软件测试过程定义为定义所述软件测试过程的基本信息,所述基本信息包括:所述软件测试过程的过程简介信息、所述软件测试过程的开始时间、所述软件测试过程的创建者信息;
所述测试参与者的活动为所述测试参与者需要执行的具体任务;
所述原子活动的变迁条件为所述原子活动向其他原子活动发生变迁的条件,如果满足所述变迁条件,则进行变迁,否则不进行变迁;
所述测试相关数据信息包括:所述原子活动的变迁方向、与所述原子活动对应的控制数据;所述控制数据为全局数据;
所述角色信息为所述测试参与者的具体角色;
所述测试参与者信息包括:所述测试参与者的姓名信息;
所述应用程序为被所述原子活动调用的应用程序,所述应用程序为全局变量;
S3中,所述元素包括:源节点、目标节点、转移条件、活动节点、测试数据、应用程序、测试参与者;
其中,所述活动节点用于标记所述原子活动;
所述源节点用于标记与当前连接线的出发点对应的活动节点;
所述目标节点用于标记与所述当前连接线的结束点对应的活动节点;
所述转移条件用于标记所述原子活动间的变迁条件,如果满足所述变迁条件,则由当前原子活动跳转到下一个原子活动;如果不满足所述变迁条件,则所述当前原子活动不进行跳转;
所述测试数据用于表示所述软件测试过程中的所述控制数据,所述测试数据为全局变量;
所述应用程序用于表示被调用的应用程序,所述应用程序为全局变量;
所述测试参与者用于标记所述软件测试过程中各个所述原子活动的参与者,所述测试参与者为全局变量;
所述活动节点包括以下内容:
手动节点:用于标记需要所述测试参与者手动执行的原子活动;
自动节点:用于标记通过调用所述应用程序完成的原子活动;
选择节点:用于标记所述软件测试过程中多个任务流的汇集情况;
并行节点:用于标记需要并行执行的多个所述原子活动;
子过程节点:用于标记子过程活动;
开始节点:用于标记所述通用软件测试过程模型的唯一入口点;
结束节点:用于标记所述通用软件测试过程模型的唯一出口点。
2.根据权利要求1所述的方法,其特征在于,S2中,所述组成结构图为所述原子活动的UML图。
3.根据权利要求1所述的方法,其特征在于,S4中,所述利用XML语言对所述原子活动逻辑进行形式化描述,具体为分别定义以下内容:定义各个标记的公共属性;定义应用程序;定义变量;定义传输线;附加定义活动节点;定义标志节点;定义任务节点;过程定义标记;过程定义XML文件根元素标记。
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN201210008291.XA CN102591779B (zh) | 2012-01-12 | 2012-01-12 | 基于工作流的通用软件测试过程模型的建立方法 |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN201210008291.XA CN102591779B (zh) | 2012-01-12 | 2012-01-12 | 基于工作流的通用软件测试过程模型的建立方法 |
Publications (2)
Publication Number | Publication Date |
---|---|
CN102591779A CN102591779A (zh) | 2012-07-18 |
CN102591779B true CN102591779B (zh) | 2015-04-08 |
Family
ID=46480473
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
CN201210008291.XA Expired - Fee Related CN102591779B (zh) | 2012-01-12 | 2012-01-12 | 基于工作流的通用软件测试过程模型的建立方法 |
Country Status (1)
Country | Link |
---|---|
CN (1) | CN102591779B (zh) |
Families Citing this family (4)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN103995781B (zh) * | 2014-06-10 | 2017-08-25 | 浪潮通用软件有限公司 | 一种基于模型的构件测试用例生成方法 |
CN106502892B (zh) * | 2016-10-20 | 2018-11-13 | 杭州电子科技大学 | 一种基于uml模型的测试用例优先排序方法 |
CN108491428B (zh) * | 2018-02-09 | 2020-07-10 | 武汉大学 | 一种基于xml的海洋地理信息数据交换方法和系统 |
CN111813694B (zh) * | 2020-08-11 | 2024-03-15 | 中国工商银行股份有限公司 | 测试方法、测试装置、电子设备及可读存储介质 |
Citations (1)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN1926563A (zh) * | 2005-01-28 | 2007-03-07 | 三菱电机株式会社 | 工作流管理装置、工作流管理系统以及测试方案生成方法 |
-
2012
- 2012-01-12 CN CN201210008291.XA patent/CN102591779B/zh not_active Expired - Fee Related
Patent Citations (1)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN1926563A (zh) * | 2005-01-28 | 2007-03-07 | 三菱电机株式会社 | 工作流管理装置、工作流管理系统以及测试方案生成方法 |
Non-Patent Citations (2)
Title |
---|
基于工作流技术的软件测试流程定义与监控;郑小军等;《计算机应用研究》;20070228(第2期);论文44,45,88页,表1 * |
测试流程管理与监控技术的研究与实现;柳永坡等;《第五届中国测试学术会议论文集》;20080531;论文234-237页 * |
Also Published As
Publication number | Publication date |
---|---|
CN102591779A (zh) | 2012-07-18 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
CN104391934B (zh) | 数据校验方法和装置 | |
CN103631720B (zh) | 测试用例的生成方法和装置 | |
Izurieta et al. | A multiple case study of design pattern decay, grime, and rot in evolving software systems | |
Kerbrat et al. | Automated test generation from SDL specifications | |
CN110287097A (zh) | 批量测试方法、装置及计算机可读存储介质 | |
CN107220539B (zh) | 基于需求的ima安全验证分析方法 | |
CN102591779B (zh) | 基于工作流的通用软件测试过程模型的建立方法 | |
Olszewska et al. | Tailoring complexity metrics for Simulink models | |
Oster | Feature model-based software product line testing | |
Keshavarz et al. | Metric for early measurement of software complexity | |
Wiecher et al. | Integrated and iterative requirements analysis and test specification: A case study at Kostal | |
CN104598375B (zh) | 一种用于软件开发的缺陷预测方法 | |
Jetley et al. | Applying software engineering practices for development of industrial automation applications | |
CN111966665B (zh) | 数据迁移测试方法及装置 | |
Gunawardena et al. | Concerns identified in code review: A fine-grained, faceted classification | |
Reimanis et al. | Towards assessing the technical debt of undesired software behaviors in design patterns | |
CN110928761B (zh) | 需求链及其应用的系统和方法 | |
Fagerström et al. | Verdict machinery: On the need to automatically make sense of test results | |
Song et al. | Quantifying consistency between conceptual and executable business processes | |
Liu et al. | An approach to integrating non-functional requirements into uml design models based on nfr-specific patterns | |
Park et al. | Deriving software process simulation model from spem-based software process model | |
CN115328442B (zh) | 基于低代码平台构建的危化品企业安全风险管控平台 | |
Zdun et al. | On the design and architecture of deployment pipelines in cloud-and service-based computing-A model-based qualitative study | |
Zhang et al. | A tool to create process-agents for OEC-SPM from historical project data | |
CN108509330B (zh) | 一种数据处理方法及系统 |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
C06 | Publication | ||
PB01 | Publication | ||
C10 | Entry into substantive examination | ||
SE01 | Entry into force of request for substantive examination | ||
C14 | Grant of patent or utility model | ||
GR01 | Patent grant | ||
CF01 | Termination of patent right due to non-payment of annual fee |
Granted publication date: 20150408 Termination date: 20170112 |
|
CF01 | Termination of patent right due to non-payment of annual fee |