CN115203008A - 一种测试方法、装置、存储介质及设备 - Google Patents

一种测试方法、装置、存储介质及设备 Download PDF

Info

Publication number
CN115203008A
CN115203008A CN202110382456.9A CN202110382456A CN115203008A CN 115203008 A CN115203008 A CN 115203008A CN 202110382456 A CN202110382456 A CN 202110382456A CN 115203008 A CN115203008 A CN 115203008A
Authority
CN
China
Prior art keywords
fault
state
test
path
tested
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.)
Pending
Application number
CN202110382456.9A
Other languages
English (en)
Inventor
罗彩云
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Tencent Technology Shenzhen Co Ltd
Original Assignee
Tencent Technology Shenzhen Co Ltd
Priority date (The priority date 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 date listed.)
Filing date
Publication date
Application filed by Tencent Technology Shenzhen Co Ltd filed Critical Tencent Technology Shenzhen Co Ltd
Priority to CN202110382456.9A priority Critical patent/CN115203008A/zh
Publication of CN115203008A publication Critical patent/CN115203008A/zh
Pending legal-status Critical Current

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/36—Preventing errors by testing or debugging software
    • G06F11/3668—Software testing
    • G06F11/3672—Test management
    • G06F11/3684—Test management for test design, e.g. generating new test cases
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/36—Preventing errors by testing or debugging software
    • G06F11/3668—Software testing
    • G06F11/3672—Test management
    • G06F11/3688—Test management for test execution, e.g. scheduling of test suites
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/36—Preventing errors by testing or debugging software
    • G06F11/3668—Software testing
    • G06F11/3672—Test management
    • G06F11/3692—Test management for test results analysis

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Computer Hardware Design (AREA)
  • Quality & Reliability (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Test And Diagnosis Of Digital Computers (AREA)

Abstract

一种测试方法、装置、存储介质及设备，该方法包括：确定待测试系统的模型图，所述模型图中包括用于表征系统状态的状态节点以及状态节点之间的转移路径，所述转移路径用于表征状态节点之间的状态转移条件；对所述模型图中的目标状态节点添加故障路径，生成添加故障路径后的模型图，所述故障路径用于进行故障逻辑注入；根据所述添加故障路径后的模型图生成测试用例，所述测试用例中包括故障逻辑，所述故障逻辑是针对所述故障路径注入的；利用所述测试用例对所述待测试系统进行测试，生成测试结果。通过本申请可以高效地生成测试用例，同时还可以在测试用例中设计故障注入，提高测试的质量和效率。

Description

一种测试方法、装置、存储介质及设备
技术领域
本申请涉及计算机技术领域，尤其涉及一种测试方法、装置、存储介质及设备。
背景技术
软件故障通常是在软件设计过程中引入的，随着计算机系统复杂程序和性能的提高，不管是面向的应用还是软件系统的复杂程度和规模都迅速提高，而任何编程语言、编程方法以及任何程序员都不能保证在程序设计和编码过程中不引入故障或出现问题，因此对开发的软件系统进行可靠性和容错性测试是非常有必要的。在测试过程中，需要尽可能地提高场景覆盖率，简化测试流程，提高测试效率和测试效果。
发明内容
本申请实施例提供了一种测试方法、装置、存储介质及设备，可以高效地生成测试用例，同时还可以在测试用例中设计故障注入，提高测试的质量和效率。
一方面，本申请实施例提供了一种测试方法，所述方法包括：
确定待测试系统的模型图，所述模型图中包括用于表征系统状态的状态节点以及状态节点之间的转移路径，所述转移路径用于表征状态节点之间的状态转移条件；
对所述模型图中的目标状态节点添加故障路径，生成添加故障路径后的模型图，所述故障路径用于进行故障逻辑注入；
根据所述添加故障路径后的模型图生成测试用例，所述测试用例中包括故障逻辑，所述故障逻辑是针对所述故障路径注入的；
利用所述测试用例对所述待测试系统进行测试，生成测试结果。
另一方面，本申请实施例提供了一种测试装置，所述装置包括：
确定模块，用于确定待测试系统的模型图，所述模型图中包括用于表征系统状态的状态节点以及状态节点之间的转移路径，所述转移路径用于表征状态节点之间的状态转移条件；
处理模块，用于对所述模型图中的目标状态节点添加故障路径，生成添加故障路径后的模型图，所述故障路径用于进行故障逻辑注入；
所述处理模块，还用于根据所述添加故障路径后的模型图生成测试用例，所述测试用例中包括故障逻辑，所述故障逻辑是针对所述故障路径注入的；
所述处理模块，还用于利用所述测试用例对所述待测试系统进行测试，生成测试结果。
相应地，本申请实施例提供了一种计算机设备，该设备包括处理器、通信接口和存储器，所述处理器、所述通信接口和所述存储器相互连接，其中，所述存储器存储有可执行程序代码，所述处理器用于调用所述可执行程序代码，执行上述任一可能实现方式所述的测试方法。
相应地，本申请实施例提供了一种计算机可读存储介质，存储有计算机程序，所述处理器执行上述任一可能实现方式所述的测试方法所涉及的程序。
相应地，本申请实施例提供了一种计算机程序产品或计算机程序，该计算机程序产品或计算机程序包括计算机指令，该计算机指令存储在计算机可读存储介质中。计算机设备的处理器从计算机可读存储介质读取该计算机指令，处理器执行该计算机指令，使得该计算机设备执行上述任一可能实现方式所述的测试方法。
本申请实施例中，首先通过在待测试系统的模型图中的目标状态节点添加故障路径，生成添加故障路径后的模型图，接着根据添加故障路径后的模型图生成测试用例，其中，测试用例中包括故障逻辑，最后利用测试用例对待测试系统进行测试，生成测试结果，可以高效地生成测试用例，同时还可以在测试用例中设计故障注入，提高测试的质量和效率。
附图说明
为了更清楚地说明本申请实施例技术方案，下面将对实施例描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图是本申请的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。
图1为本申请实施例提供的一种测试方法的架构示意图；
图2为本申请实施例提供的另一种测试方法的流程示意图；
图3为本申请实施例提供的模型图的示意图；
图4为本申请实施例提供的添加故障逻辑后的模型图的示意图；
图5是本申请实施例提供的一种测试装置的结构示意图；
图6是本申请实施例提供的一种计算机设备的结构示意图。
具体实施方式
下面将结合本申请实施例中的附图，对本申请实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本申请一部分实施例，而不是全部的实施例。基于本申请中的实施例，本领域普通技术人员在没有作出创造性劳动前提下所获得的所有其他实施例，都属于本申请保护的范围。
需要说明的是，本申请实施例中所涉及到的“第一”、“第二”等描述仅用于描述目的，而不能理解为指示或者暗示其相对重要性或者隐含指明所指示的技术特征的数量。因此，限定有“第一”、“第二”的技术特征可以明示或者隐含的包括至少一个该特征。
在利用本申请提出的测试方法生成测试用例之前，需要对待测试系统分析，确定待测试系统的系统状态，以及确定引起系统状态转化的转移路径，即需要确定可否通过执行某个动作，来实现待测试系统从一个系统状态转换为另一个系统状态，通常在达成这一前提要求时，才可以建立待测试系统的模型图，从而在模型图中添加故障路径来对待测试系统进行故障注入。
请参见图1，图1为本申请实施例提供的一种测试方法的流程示意图，该方法包括以下步骤：
S101、确定待测试系统的模型图，所述模型图中包括用于表征系统状态的状态节点以及状态节点之间的转移路径，所述转移路径用于表征状态节点之间的状态转移条件。
在一个实施例中，通过对待测试系统的功能进行分析，可以确定待测试系统的系统状态，以及系统状态之间进行转移的状态转移条件，状态转移条件为一个系统状态到另一个系统状态需要进行的动作。
进一步地，将确定的系统状态作为模型图的状态节点，将状态转移条件作为模型图中的转移路径，利用转移路径实现模型图中状态节点之间的转移。
S102、对所述模型图中的目标状态节点添加故障路径，生成添加故障路径后的模型图，所述故障路径用于进行故障逻辑注入。
其中，目标状态节点为模型图中的任一状态节点，目标状态节点可以为一个或多个状态节点，本申请对此不作限定。故障逻辑为根据故障类型确定的结构化语句，故障类型具体可以根据实际需求确定，例如为网络包丢失、网络包重复、进程杀死等，本申请对此不作限定。
其中，由于故障路径主要用于将故障逻辑注入到待测试系统中，因此不会因为故障逻辑的注入而对系统状态进行转换，基于此，本申请在目标状态节点上添加故障路径，故障路径为一个环形路径，即起点和终点都是目标状态节点。
具体地，首先生成故障逻辑注入这个动作的结构化语句，即故障注入逻辑，将故障注入逻辑作为模型图中目标状态节点的故障路径，得到添加故障路径后的模型图。
S103、根据所述添加故障路径后的模型图生成测试用例，所述测试用例中包括故障逻辑，所述故障逻辑是针对所述故障路径注入的。
具体地，在获取到添加故障路径后的模型图后，可以利用自动化测试工具，例如GraphWalker，对添加故障路径后的模型图中包括的路径进行遍历，从而生成测试用例，在遍历过程中，可以设定路径覆盖率或节点覆盖率，或其它条件作为遍历的停止条件，并确保测试用例中包括故障路径，从而对待测试系统进行故障逻辑注入。
其中，GraphWalker为一个基于模型的用例生成工具。它主要应用于有限状态机(Finite State Machine,FSM)、事件驱动型有限状态机(event finite state machine,EFSM)模型、json模型等模型，能够通过直接读取FSM、EFSM图形模型、json模型等模型来生成测试用例。
S104、利用所述测试用例对所述待测试系统进行测试，生成测试结果。
具体地，在搭建待测试系统的测试环境后，调用测试用例对待测试系统进行测试时，通过收集待测试系统的状态信息得到测试状态信息，并跟期望的系统状态进行对比，得到测试结果。
在本申请实施例中，通过在待测试系统的模型图中的目标状态节点添加故障路径，生成添加故障路径后的模型图，根据添加故障路径后的模型图生成测试用例，其中，测试用例中包括故障逻辑，利用测试用例对待测试系统进行测试，生成测试结果，可以高效地生成测试用例，同时还可以在测试用例中设计故障注入，提高测试的质量和效率。
与传统软件架构相比，微服务架构具有更高的发布频率和速度，在运营环境中进行广泛性能测试的可行性受到限制，同时微服务间的依赖日益复杂，很难评估单个微服务故障对整个系统的影响，同时业务和技术迭代快，如何持续保障系统的稳定性和高可用性受到很大的挑战。本申请提供的测试方法可以很好地针对微服务架构中的各个微服务的性能(包括可靠性和容错性)进行测试，当然也可以针对传统软件架构下的软件系统进行测试。
下面对本申请提到的测试方法在基于微服务框架的服务发现系统的应用实践进行一些介绍，在微服务框架中，微服务和微服务之间的通信，是通过服务发现系统来做的，服务发现系统相当于一个基本组件，可以提供一些基本功能，包括：服务注册，服务发现、服务注销、服务上线、服务离线，当微服务在服务发现系统进行服务注册后，服务发现系统可以通过微服务注册时发送的记录信息，包括：接口(service)名字，模块(server)名字，网际互连协议(Internet Protocol,ip)，端口，机器属性等信息，来控制微服务的在线、离线、注销。
可以理解的是，上述描述的服务发现系统是为了更加清楚的说明本申请实施例的技术方案，并不构成对于本申请实施例提供的技术方案的限定，本申请实施例提供的技术方案对于类似的技术问题，同样适用。
请参见图2，图2为本申请实施例提供的另一种测试方法的流程示意图，该方法包括以下步骤：
S201、确定所述待测试系统的系统状态，以及确定所述待测试系统的任意两个系统状态之间的状态转移信息，所述状态转移信息用于指示两个系统状态之间是否可转移，并且当两个系统状态之间可转移时用于指示两个系统状态之间进行有向转移的条件。
具体地，在确定待测试系统的系统状态之后，需要确定待测试系统中的任意两个系统状态之间的状态转移信息，其中状态转移信息包括两个系统状态之间是否可以进行转移，以及当两个系统状态之间可以转移时，两个系统状态进行有向转移的条件，即该条件只能从一个系统状态A转换为一个系统状态B，而不可以从一个系统状态B转换为系统状态A。
在一个实施例中，本申请以基于微服务框架的服务发现系统为例，通过对该服务发现系统的功能进行分析，可以确定该服务发现系统可以用于实现微服务的上线(check_register_online)、离线(check_register_unline)和注销(check_unregister)。通过分析，这三个系统状态进行转移时主要可以通过模块名称(server)+ip、接口名称(service)+ip、ip+端口(port)、以及实例_ip(instace_ip)这四个接口实现，其中模块名称+ip是指根据某个模块名字，去操作某个ip或者某几个ip来对指定的微服务进行系统状态的转换，接口名称+ip是指根据某个接口名字，去操作某个ip或者某几个ip来对指定的微服务进行系统状态的转换，ip+端口是指对所有微服务进行系统状态的转换，实例_ip是指根据某一个ip来对指定的微服务进行系统状态的转换。
进一步地，在确定该服务发现系统的系统状态和对有向转移的条件进行分析后，可以确定任意两个系统状态之间的状态转移信息，利用状态转移信息指示的当两个系统状态之间可转移时进行有向转移的条件，建立如表1所示的状态转移信息表，其中，将系统状态作为状态节点，有向转移的条件作为转移路径。
表1
Figure BDA0003011989850000061
Figure BDA0003011989850000071
从上述表1中可以看出，状态转移信息表可以用于当两个状态节点之间可转移时指示两个状态节点之间的转移路径。以上线(check_register_online)到离线(check_register_unline)为例，其主要有4种方式：test_mbt_unline_by_service_ip、test_mbt_unline_by_server_ip、test_mbt_unline_by_ip_port、test_mbt_unline_by_instance_id，分别是利用接口名称+ip、模块名称+ip、ip+端口、以及实例_ip实现指定的微服务离线。其中，test_mbt_register、test_mbt_register_and_online、和test_mbt_unregister分别是指利用模块名称实现指定的微服务离线、上线和注销。同时，从表1可以看出，上线(check_register_online)和离线(check_register_unline)支持重入操作。
在一个可行的实施例中，可以将模块名称+名字空间(namespace)作为微服务的唯一标识，从数据库中查询微服务的系统状态，当检测到系统状态为-1时，表示该微服务未注册，检测到系统状态为0时，表示该微服务处于离线状态，检测到系统状态为1时，表示该微服务处于上线状态。具体地，可以通过以下代码进行查询：
def check_unregister():
check_status(server,namespace,-1,real_machine[‘ip’],1314)
restart_agent(real_machine)
def check_online():
check_status(server,namespace,1,real_machine[‘ip’],1314)
def check_unline():
check_status(server,namespace,0,real_machine[‘ip’],1314)
在一个可行的实施例中，任一转移路径执行相应的逻辑时，依旧可以通过相应的代码实现，本申请以test_mbt_unregister_by_service_ip为例，具体执行代码如下：
def test_mbt_unregister_by_service_ip():
stark_openapi＝stark_openapi_Class(length＝‘’,start＝‘’,filedname＝‘’,filedorder＝‘’)
stark_openapi.set_body(‘server’,server)
stark_openapi.set_body(‘oper’,2)
stark_openapi.set_body(‘ipList’,[{‘ip’:real_machine[‘ip’],‘port’:1314,‘weight’:1000}])
stark_openapi.set_body(‘namespace’,namespace)
local_openapi＝“/starkOpenApi/InstanceOperByIpServer”
openapi_result＝stark_openapi.CALL_OMS(local_openapi,check_log＝False)
assert openapi_result[“retCode”]＝＝‘0’
其中，该代码的实现逻辑为先初始化传参server、oper、ipList和nameGroup，其中，oper用于确定执行的操作，ipList用于确定执行该操作的机器，server+namespace用于确定微服务；然后调用接口/starkOpenApi/InstanceOperByIpServer；最后判断接口返回值是否为0。
S202、根据所述待测试系统的系统状态以及所述待测试系统的任意两个系统状态之间的状态转移信息，构建所述待测试系统的模型图。
具体地，在确定待测试系统的系统状态以及待测试系统的任意两个系统状态之间的状态转移信息后，可以利用画图工具yEd构建待测试系统的模型图。如图3所示，根据表1的状态转移信息，将上线(check_register_online)、离线(check_register_unline)和注销(check_unregister)作为模型图中的三个状态节点，并利用转移路径实现状态节点之间的转换。图3中的start节点不是必需的，从start节点出发只能有1个边，且start节点不会包括在任何生成的测试用例中，它只表示一个开始位。
S203、从所述模型图包括的状态节点中确定目标状态节点。
具体地，目标状态节点为模型图中包括的状态节点中的任一状态节点，可以从模型图中确定一个或多个状态节点作为目标状态节点，目标状态节点为待添加故障路径的状态节点。
S204、确定故障注入逻辑，根据所述故障注入逻辑在所述模型图中为所述目标状态节点添加故障路径，得到添加故障路径后的模型图。
在一个实施例中，故障注入逻辑是根据故障逻辑注入这个动作生成的结构化语句，通过将故障注入逻辑作为故障路径添加到模型图中，使得后续可以通过对添加故障路径后的模型图遍历，从而在生成的测试用例中根据故障路径对待测试系统注入故障逻辑。例如故障注入逻辑为add_manual_operator，将离线(check_register_unline)作为目标状态节点，对离线(check_register_unline)添加故障路径后的模型图如图4所示，虚线只是起到强调作用，并不对故障路径进行限制。其中，故障注入逻辑(add_manual_operator)中还定义了故障逻辑生成的策略，以使得可以根据该策略确定故障路径对应的目标故障逻辑，详细说明可参见S206。
S205、从所述添加故障路径后的模型图包括的状态节点中确定起始状态节点和结束状态节点，并对所述添加故障路径后的模型图进行遍历，确定从所述起始状态节点到所述结束状态节点的一条或多条参考路径。
具体地，可以从添加故障路径后的模型图包括的状态节点中确定起始状态节点和结束状态节点，将start节点转移后对应的状态节点作为起始状态节点，例如起始状态节点和结束状态节点分别为注销(check_register_unregister)和离线(check_register_unline)，然后可以利用GraphWalker的jar包对添加故障路径后的模型图进行遍历，具体执行的命令是：java-jar$jar_path offline--model$grap_file"a_star(check_register_unline)"，grap_file为添加故障路径后的模型图，从而确定从起始状态节点到结束状态节点的一条或多条参考路径。
在一个可行的实施例中，还可以通过完全随机的方式遍历添加故障路径后的模型图。该方法通过随机从顶点选择出边，并且在下一个顶点时重复此过程。具体执行的命令是：java-jar$jar_path offline--model$grap_file"random(some stop condition(s))，其中some stop condition(s)为遍历停止条件，可以为edge_coverage(s)，含义为当路径覆盖率达到s％时停止遍历，遍历停止条件还可以是状态节点覆盖率等，本申请对此不作限定。还可以尝试遍历添加故障路径后的模型图的最短路径，具体执行的命令是：java-jar$jar_path offline--model$grap_file"quick_random(some stop condition(s))。
S206、根据所述一条或多条参考路径生成相应的测试用例。
在一个实施例中，根据一条或多条参考路径生成相应的测试用例，具体可以包括以下步骤：从一条或多条参考路径中确定故障路径和转移路径，确定故障逻辑集合，故障逻辑集合中包括一个或多个故障逻辑，从故障逻辑集合中确定故障路径对应的目标故障逻辑，并根据目标故障逻辑和转移路径生成相应的测试用例。
其中，故障逻辑集合中包括一个或多个故障逻辑，故障逻辑是根据相应的故障类型生成的，故障类型可以根据需求进行设定，在本申请中，示例性地显示了如下表2所示的13种故障类型。
表2
Figure BDA0003011989850000101
Figure BDA0003011989850000111
在一个实施例中，故障类型对应的故障逻辑可以通过相应的代码进行实现，以cpu_load进行举例，其具体代码如下：
defcpu_load(blade_machine):
mylogger.debug(“＝＝＝cpu_load(s％)＝＝＝”％blade_machine[“ip”])
try:
msg＝machine_blade_oper_cmd(blade_machine,’./chaos_test.shcreatecpufullload–timeout 60’)
id＝check_blade_oper_exce(msg)
finally:
msg＝machine_blade_oper_cmd(blade_machine,’./chaos_test.shdestrory％s’％id)
id＝check_blade_oper_exce(msg)
其中，在制造cpu_load时主要使用了chaos_test.sh工具，具体指令为：./chaos_test.sh create cpufullload--timeout 60，表示cpu满持续60秒后，将自动恢复到正常状态。
具体地，通过上述S205确定了从起始状态节点到结束状态节点的一条或多条参考路径。由于参考路径中包括故障路径和转移路径，而故障路径仅仅指示了针对待测试系统进行故障逻辑注入，因此需要进一步地确定故障路径对应的故障类型，并根据故障类型确定对应的故障逻辑，即目标故障逻辑。其中，参考路径中的故障路径可以为一条或多条，当故障路径为多条时，故障路径对应的目标故障逻辑可以是一种也可以是多种，本申请对此不作限定。
在一个可行的实施例中，从故障逻辑集合中确定故障路径对应的目标故障逻辑时，可以利用随机生成的方法确定，例如路障逻辑集合中有6中故障逻辑，从1-6中随机生成一个数字，将每个数字对应一种故障逻辑。其具体执行代码可以如下所示：
defadd_manual_operator(blade_machine):
random_operator＝random.randint(1,6)
if random_operate＝＝1:
cpu_load(blade_machine)
elifrandom_operate＝＝2:
disk_full(blade_machine)
elifrandom_operate＝＝3:
network_loss(blade_machine)
elifrandom_operate＝＝4:
network_drop(blade_machine)
elifrandom_operate＝＝5:
processor_kill(blade_machine)
elifrandom_operate＝＝6:
processor_stop(blade_machine)
else:
assert random_operator＝＝“wrong”
return random_operate
其中，random.randint(1,6)表示从1-6中随机生成一个数作为random_operate，例如当random_operate等于1时，对待测试系统执行cpu达到100％。
在一个实施例中，确定故障路径对应的目标故障逻辑后，根据S205中确定的一条或多条参考路径中故障路径对应的目标故障逻辑和转移路径生成相应的测试用例，在测试用例中还需要包括故障路径和转移路径对应的状态节点，用于检测待测试系统是否达到期望的系统状态。作为本申请生成的一个测试用例的具体示例，如下所示：
def test_MBT():
init()
check_unregister()
test_mbt_register()
check_register_unline()
test_agent_network_recoder()
check_register_unline()
test_mbt_unline_by_instance_id()
check_register_unline()
test_mbt_online_by_ip_port()
check_register_online()
test_mbt_unline_by_server_ip()
check_register_unline()
test_agent_disk_full()
check_register_unline()
其中，测试用例中包括的目标故障逻辑有两种：网络包乱序(network_recoder)和磁盘满(disk_full)，test_agent_network_recoder()和test_agent_disk_full()分别指示的是执行网络包乱序(network_recoder)和磁盘满(disk_full)的结构化语句。
S207、利用所述测试用例对所述待测试系统进行测试，生成测试结果。
在一个实施例中，利用测试用例对待测试系统进行测试时，可以得到待测试系统的测试状态信息，根据测试系统信息与期望的系统状态进行对比，如果测试系统信息和期望的系统状态一致时，可以认为测试用例执行成功，当测试系统信息与期望的系统状态不一致时，可以根据测试用例中的故障逻辑和测试状态信息，生成测试结果。
在一个实施例中，根据测试用例中的故障逻辑和测试状态信息，生成测试结果，可以包括以下步骤：
(1)根据测试用例中的故障逻辑和测试状态信息，确定待测试系统的故障位置和故障位置对应的故障类型。
(2)根据故障位置和故障位置对应的故障类型，生成测试结果。
在一个实施例中，当待测试系统的测试系统信息与期望的系统状态一致时，会按照测试用例中预置的路径(包括故障路径和转移路径)的执行顺序进行执行，当待测试系统的测试系统信息与期望的系统状态不一致时，可以确定测试用例中当前执行的路径，从而得到待测试系统的故障位置，同时根据已在待测试系统中注入的故障逻辑，确定故障位置对应的故障类型，并根据故障位置和故障位置对应的故障类型生成测试报告，以供开发人员针对该测试报告解决问题。
在一个可行的实施例中，可以设定故障路径对应的目标故障逻辑为同一个故障类型，此时只针对待测试系统注入特定的故障类型，以使得针对待测试系统中的特定的故障类型确定解决方案。
在本申请实施例中，通过对服务发现系统进行分析，创建服务发现系统的模型图，并对模型图中的目标状态节点添加故障路径，生成添加故障路径后的模型图，根据添加故障路径后的模型图生成测试用例，其中，测试用例中包括故障逻辑，利用测试用例对服务发现系统进行测试，生成测试结果，可以高效地生成测试用例，同时还可以在测试用例中设计故障注入，提高测试的质量和效率。
如图5所示，图5是本申请实施例提供的一种测试装置的结构示意图，所述装置包括：
确定模块501，用于确定待测试系统的模型图，所述模型图中包括用于表征系统状态的状态节点以及状态节点之间的转移路径，所述转移路径用于表征状态节点之间的状态转移条件；
处理模块502，用于对所述模型图中的目标状态节点添加故障路径，生成添加故障路径后的模型图，所述故障路径用于进行故障注入；
所述处理模块502，还用于根据所述添加故障路径后的模型图生成测试用例，所述测试用例中包括故障逻辑，所述故障逻辑是针对所述故障路径注入的；
所述处理模块502，还用于利用所述测试用例对所述待测试系统进行测试，生成测试结果。
在一个实施例中，所述确定模块501，具体用于：
确定所述待测试系统的系统状态，以及确定所述待测试系统的任意两个系统状态之间的状态转移信息，所述状态转移信息用于指示两个系统状态之间是否可转移，并且当两个系统状态之间可转移时用于指示两个系统状态之间进行有向转移的条件；
根据所述待测试系统的系统状态以及所述待测试系统的任意两个系统状态之间的状态转移信息，构建所述待测试系统的模型图。
在一个实施例中，所述确定模块501，具体用于：
从所述模型图包括的状态节点中确定目标状态节点；
确定故障注入逻辑，根据所述故障注入逻辑在所述模型图中为所述目标状态节点添加故障路径，得到添加故障路径后的模型图。
在一个实施例中，所述处理模块502，具体用于：
从所述添加故障路径后的模型图包括的状态节点中确定起始状态节点和结束状态节点；
对所述添加故障路径后的模型图进行遍历，确定从所述起始状态节点到所述结束状态节点的一条或多条参考路径；
根据所述一条或多条参考路径生成相应的测试用例。
在一个实施例中，所述处理模块502，具体用于：
从所述一条或多条参考路径中确定故障路径和转移路径；
确定故障逻辑集合，所述故障逻辑集合中包括一个或多个故障逻辑；
从所述故障逻辑集合中确定所述故障路径对应的目标故障逻辑，并根据所述目标故障逻辑和所述转移路径生成相应的测试用例。
在一个实施例中，所述处理模块502，具体用于：
利用所述测试用例对所述待测试系统进行测试，得到所述待测试系统的测试状态信息；
根据所述测试用例中的故障逻辑和所述测试状态信息，生成测试结果。
在一个实施例中，所述处理模块502，具体用于：
根据所述测试用例中的故障逻辑和所述测试状态信息，确定待测试系统的故障位置和所述故障位置对应的故障类型；
根据所述故障位置和所述故障位置对应的故障类型，生成测试结果。
在本申请实施例中，通过在待测试系统的模型图中的目标状态节点添加故障路径，生成添加故障路径后的模型图，根据添加故障路径后的模型图生成测试用例，其中，测试用例中包括故障逻辑，利用测试用例对待测试系统进行测试，生成测试结果，可以高效地生成测试用例，同时还可以在测试用例中设计故障注入，提高测试的质量和效率。
如图6所示，图6是本申请实施例提供的一种计算机设备的结构示意图，该设备内部结构如图6所示，包括：一个或多个处理器601、存储器602、通信接口603。上述处理器601、存储器602和通信接口603可通过总线604或其他方式连接，本申请实施例以通过总线604连接为例。
其中，处理器601(或称CPU(Central Processing Unit，中央处理器))是计算机设备的计算核心以及控制核心，其可以解析计算机设备内的各类指令以及处理计算机设备的各类数据，例如：CPU可以用于解析用户向计算机设备所发送的开关机指令，并控制计算机设备进行开关机操作；再如：CPU可以在计算机设备内部结构之间传输各类交互数据，等等。通信接口603可选的可以包括标准的有线接口、无线接口(如Wi-Fi、移动通信接口等)，受处理器601的控制用于收发数据。存储器602(Memory)是计算机设备中的记忆设备，用于存放程序和数据。可以理解的是，此处的存储器602既可以包括计算机设备的内置存储器，当然也可以包括计算机设备所支持的扩展存储器。存储器602提供存储空间，该存储空间存储了计算机设备的操作系统，可包括但不限于：Windows系统、Linux系统等等，本申请对此并不作限定。
在一个实施例中，所述处理器601，具体用于：
确定待测试系统的模型图，所述模型图中包括用于表征系统状态的状态节点以及状态节点之间的转移路径，所述转移路径用于表征状态节点之间的状态转移条件；
对所述模型图中的目标状态节点添加故障路径，生成添加故障路径后的模型图，所述故障路径用于进行故障注入；
根据所述添加故障路径后的模型图生成测试用例，所述测试用例中包括故障逻辑，所述故障逻辑是针对所述故障路径注入的；
用于利用所述测试用例对所述待测试系统进行测试，生成测试结果。
在一个实施例中，所述处理器601，具体用于：
确定所述待测试系统的系统状态，以及确定所述待测试系统的任意两个系统状态之间的状态转移信息，所述状态转移信息用于指示两个系统状态之间是否可转移，并且当两个系统状态之间可转移时用于指示两个系统状态之间进行有向转移的条件；
根据所述待测试系统的系统状态以及所述待测试系统的任意两个系统状态之间的状态转移信息，构建所述待测试系统的模型图。
在一个实施例中，所述处理器601，具体用于：
从所述模型图包括的状态节点中确定目标状态节点；
确定故障注入逻辑，根据所述故障注入逻辑在所述模型图中为所述目标状态节点添加故障路径，得到添加故障路径后的模型图。
在一个实施例中，所述处理器601，具体用于：
从所述添加故障路径后的模型图包括的状态节点中确定起始状态节点和结束状态节点；
对所述添加故障路径后的模型图进行遍历，确定从所述起始状态节点到所述结束状态节点的一条或多条参考路径；
根据所述一条或多条参考路径生成相应的测试用例。
在一个实施例中，所述处理器601，具体用于：
从所述一条或多条参考路径中确定故障路径和转移路径；
确定故障逻辑集合，所述故障逻辑集合中包括一个或多个故障逻辑；
从所述故障逻辑集合中确定所述故障路径对应的目标故障逻辑，并根据所述目标故障逻辑和所述转移路径生成相应的测试用例。
在一个实施例中，所述处理器601，具体用于：
利用所述测试用例对所述待测试系统进行测试，得到所述待测试系统的测试状态信息；
根据所述测试用例中的故障逻辑和所述测试状态信息，生成测试结果。
在一个实施例中，所述处理器601，具体用于：
根据所述测试用例中的故障逻辑和所述测试状态信息，确定待测试系统的故障位置和所述故障位置对应的故障类型；
根据所述故障位置和所述故障位置对应的故障类型，生成测试结果。
在本申请实施例中，通过在待测试系统的模型图中的目标状态节点添加故障路径，生成添加故障路径后的模型图，根据添加故障路径后的模型图生成测试用例，其中，测试用例中包括故障逻辑，利用测试用例对待测试系统进行测试，生成测试结果，可以高效地生成测试用例，同时还可以在测试用例中设计故障注入，提高测试的质量和效率。
本领域普通技术人员可以理解实现上述实施例方法中的全部或部分流程，是可以通过计算机程序来指令相关的硬件来完成，所述的程序可存储于一计算机可读取存储介质中，该程序在执行时，可包括如上述测试方法的实施例的流程。其中，所述的存储介质可为磁碟、光盘、只读存储记忆体(Read-Only Memory,ROM)或随机存储记忆体(Random AccessMemory,RAM)等。
本申请一个或多个实施例还提供了一种计算机程序产品或计算机程序，该计算机程序产品或计算机程序包括计算机指令，该计算机指令存储在计算机可读存储介质中。计算机设备的处理器从计算机可读存储介质读取该计算机指令，处理器执行该计算机指令，使得该计算机设备执行上述各方法的实施例中所执行的步骤。
以上所述实施例仅表达了本申请的几种实施方式，其描述较为具体和详细，但并不能因此而理解为对申请专利范围的限制。应当指出的是，对于本领域的普通技术人员来说，在不脱离本申请构思的前提下，还可以做出若干变形和改进，这些都属于本申请的保护范围。因此，本申请专利的保护范围应以所附权利要求为准。

Claims (10)

1.一种测试方法，其特征在于，所述方法包括：
确定待测试系统的模型图，所述模型图中包括用于表征系统状态的状态节点以及状态节点之间的转移路径，所述转移路径用于表征状态节点之间的状态转移条件；
对所述模型图中的目标状态节点添加故障路径，生成添加故障路径后的模型图，所述故障路径用于进行故障逻辑注入；
根据所述添加故障路径后的模型图生成测试用例，所述测试用例中包括故障逻辑，所述故障逻辑是针对所述故障路径注入的；
利用所述测试用例对所述待测试系统进行测试，生成测试结果。
2.根据权利要求1所述的方法，其特征在于，所述确定待测试系统的模型图，包括：
确定所述待测试系统的系统状态，以及确定所述待测试系统的任意两个系统状态之间的状态转移信息，所述状态转移信息用于指示两个系统状态之间是否可转移，并且当两个系统状态之间可转移时用于指示两个系统状态之间进行有向转移的条件；
根据所述待测试系统的系统状态以及所述待测试系统的任意两个系统状态之间的状态转移信息，构建所述待测试系统的模型图。
3.根据权利要求1或2所述的方法，其特征在于，所述对所述模型图中的目标状态节点添加故障路径，生成添加故障路径后的模型图，包括：
从所述模型图包括的状态节点中确定目标状态节点；
确定故障注入逻辑，根据所述故障注入逻辑在所述模型图中为所述目标状态节点添加故障路径，得到添加故障路径后的模型图。
4.根据权利要求1或2所述的方法，其特征在于，所述根据所述添加故障路径后的模型图生成测试用例，包括：
从所述添加故障路径后的模型图包括的状态节点中确定起始状态节点和结束状态节点；
对所述添加故障路径后的模型图进行遍历，确定从所述起始状态节点到所述结束状态节点的一条或多条参考路径；
根据所述一条或多条参考路径生成相应的测试用例。
5.根据权利要求4所述的方法，其特征在于，所述根据所述一条或多条参考路径生成相应的测试用例，包括：
从所述一条或多条参考路径中确定故障路径和转移路径；
确定故障逻辑集合，所述故障逻辑集合中包括一个或多个故障逻辑；
从所述故障逻辑集合中确定所述故障路径对应的目标故障逻辑，并根据所述目标故障逻辑和所述转移路径生成相应的测试用例。
6.根据权利要求1所述的方法，其特征在于，所述利用所述测试用例对所述待测试系统进行测试，生成测试结果，包括：
利用所述测试用例对所述待测试系统进行测试，得到所述待测试系统的测试状态信息；
根据所述测试用例中的故障逻辑和所述测试状态信息，生成测试结果。
7.根据权利要求1所述的方法，其特征在于，所述根据所述测试用例中的故障逻辑和所述测试状态信息，生成测试结果，包括：
根据所述测试用例中的故障逻辑和所述测试状态信息，确定待测试系统的故障位置和所述故障位置对应的故障类型；
根据所述故障位置和所述故障位置对应的故障类型，生成测试结果。
8.一种测试装置，其特征在于，所述装置包括：
确定模块，用于确定待测试系统的模型图，所述模型图中包括用于表征系统状态的状态节点以及状态节点之间的转移路径，所述转移路径用于表征状态节点之间的状态转移条件；
处理模块，用于对所述模型图中的目标状态节点添加故障路径，生成添加故障路径后的模型图，所述故障路径用于进行故障注入；
所述处理模块，还用于根据所述添加故障路径后的模型图生成测试用例，所述测试用例中包括故障逻辑，所述故障逻辑是针对所述故障路径注入的；
所述处理模块，还用于利用所述测试用例对所述待测试系统进行测试，生成测试结果。
9.一种计算机设备，其特征在于，包括存储器、通信接口以及处理器，其中，所述存储器、所述通信接口和所述处理器相互连接，所述存储器存储有计算机程序代码，所述处理器调用所述存储器中存储的计算机程序代码，用于执行权利要求1～7任一项所述的测试方法。
10.一种计算机可读存储介质，存储有计算机程序，其特征在于，所述计算机程序被处理器执行时实现权利要求1～7任一项所述的测试方法。
CN202110382456.9A 2021-04-08 2021-04-08 一种测试方法、装置、存储介质及设备 Pending CN115203008A (zh)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN202110382456.9A CN115203008A (zh) 2021-04-08 2021-04-08 一种测试方法、装置、存储介质及设备

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN202110382456.9A CN115203008A (zh) 2021-04-08 2021-04-08 一种测试方法、装置、存储介质及设备

Publications (1)

Publication Number Publication Date
CN115203008A true CN115203008A (zh) 2022-10-18

Family

ID=83570486

Family Applications (1)

Application Number Title Priority Date Filing Date
CN202110382456.9A Pending CN115203008A (zh) 2021-04-08 2021-04-08 一种测试方法、装置、存储介质及设备

Country Status (1)

Country Link
CN (1) CN115203008A (zh)

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN117596165A (zh) * 2024-01-18 2024-02-23 中国人民解放军军事科学院系统工程研究院 一种基于逻辑功能封装的软件无线电标准符合性测试方法及装置
CN118394583A (zh) * 2024-06-27 2024-07-26 苏州元脑智能科技有限公司 磁盘状态转化的测试方法、装置、设备、介质及程序产品

Cited By (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN117596165A (zh) * 2024-01-18 2024-02-23 中国人民解放军军事科学院系统工程研究院 一种基于逻辑功能封装的软件无线电标准符合性测试方法及装置
CN117596165B (zh) * 2024-01-18 2024-03-29 中国人民解放军军事科学院系统工程研究院 一种基于逻辑功能封装的软件无线电标准符合性测试方法及装置
CN118394583A (zh) * 2024-06-27 2024-07-26 苏州元脑智能科技有限公司 磁盘状态转化的测试方法、装置、设备、介质及程序产品

Similar Documents

Publication Publication Date Title
US9329983B2 (en) Computer program testing
US9727407B2 (en) Log analytics for problem diagnosis
Skowyra et al. A verification platform for SDN-enabled applications
CN107241315B (zh) 银行网关接口的接入方法、装置及计算机可读存储介质
CN115203008A (zh) 一种测试方法、装置、存储介质及设备
CN113572726B (zh) 一种多模态网络控制-数据平面一致性校验方法及装置
CN113722020A (zh) 接口调用方法、装置和计算机可读存储介质
CN107113199B (zh) 用于分析和处理通信序列的分析装置
CN110609786B (zh) 软件测试方法、装置、计算机设备和存储介质
US20170262032A1 (en) Method and apparatus for controlling a network node
CN113468045B (zh) 一种服务器批量配置软件的测试系统、方法及组件
CN110569140A (zh) 一种运维方法及装置
CN113835786A (zh) 一种数据对接系统、方法和计算机可读存储介质
WO2014075471A1 (zh) 一种物联网终端应用一体化生成系统和方法
CN110413437B (zh) 网络命名空间异常处理方法、装置、设备及可读存储介质
CN116097226A (zh) 用于将故障注入分布式系统的装置和方法
KR101794016B1 (ko) 분산 컴퓨팅 기반의 어플리케이션 객체 분석 방법, 이를 수행하는 어플리케이션 객체 분석 서버 및 이를 저장하는 기록매체
Becker et al. A safety-certified vehicle OS to enable software-defined vehicles
Hamarash MODEL-Based Performance Quality Assessment for IoT Applications.
CN111966599A (zh) 一种虚拟化平台可靠性测试方法、系统、终端及存储介质
Edmondson et al. Automating testing of service-oriented mobile applications with distributed knowledge and reasoning
CN113518974A (zh) 用于找出并标识网络中的计算节点的系统和方法
CN113176994B (zh) 一种基于函数计算的Mock数据方法及装置
US12093160B1 (en) IoT event detector correctness verification
CN110830274A (zh) 一种通信设备仿真方法和装置

Legal Events

Date Code Title Description
PB01 Publication
PB01 Publication
SE01 Entry into force of request for substantive examination
SE01 Entry into force of request for substantive examination