CN111488276B - 基于代码跟踪的软件可靠性测试方法和装置 - Google Patents

基于代码跟踪的软件可靠性测试方法和装置 Download PDF

Info

Publication number
CN111488276B
CN111488276B CN202010265596.3A CN202010265596A CN111488276B CN 111488276 B CN111488276 B CN 111488276B CN 202010265596 A CN202010265596 A CN 202010265596A CN 111488276 B CN111488276 B CN 111488276B
Authority
CN
China
Prior art keywords
code
model
lts
reliability
information
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.)
Active
Application number
CN202010265596.3A
Other languages
English (en)
Other versions
CN111488276A (zh
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.)
Tianhang Changying (Jiangsu) Technology Co.,Ltd.
Original Assignee
Beihang University
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 Beihang University filed Critical Beihang University
Priority to CN202010265596.3A priority Critical patent/CN111488276B/zh
Publication of CN111488276A publication Critical patent/CN111488276A/zh
Application granted granted Critical
Publication of CN111488276B publication Critical patent/CN111488276B/zh
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00Error detection; Error correction; Monitoring
    • G06F11/36Preventing errors by testing or debugging software
    • G06F11/3668Software testing
    • G06F11/3672Test management
    • G06F11/3684Test management for test design, e.g. generating new test cases
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00Error detection; Error correction; Monitoring
    • G06F11/36Preventing errors by testing or debugging software
    • G06F11/3668Software testing
    • G06F11/3672Test management
    • G06F11/3688Test management for test execution, e.g. scheduling of test suites

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)
  • Stored Programmes (AREA)
  • Debugging And Monitoring (AREA)

Abstract

本发明涉及一种基于代码跟踪的软件可靠性测试方法和装置,属于软件测试技术领域,解决了现有技术中缺少代码跟踪,以及静态信息提取比较不适合检测模型与代码的一致性的问题。方法包括:进行可靠性策略模型到代码的跟踪以获得可靠性策略代码,其中,跟踪包括定位和映射;基于可靠性策略代码插桩获得Log文件,其中,Log文件包括可靠性策略代码的执行路径信息;基于Log文件构建代码LTS;构建可靠性策略UML时序图模型;将可靠性策略UML时序图模型转换为模型LTS;提取代码LTS的分支路径作为代码路径,并提取模型LTS的所有分支路径作为模型路径;以及判断模型路径与代码路径是否匹配。实现代码跟踪和准确的模型与代码的动态一致性检验方法。

Description

基于代码跟踪的软件可靠性测试方法和装置
技术领域
本发明涉及软件测试技术领域,尤其涉及一种基于代码跟踪的软件可靠性测试方法和装置。
背景技术
软件可靠性是指“在给定的时间周期内,软件在限定条件下执行所要求的功能的能力”。在软件系统的需求描述阶段,系统需求通常被描述为功能需求和非功能需求。作为非功能需求的重要组成部分,可靠性需求描述了系统的可靠性约束。可靠性设计是针对可靠性需求所拟定的决策并给出解决方案,是保障系统在遭遇故障时能够正常运行的机制。
在设计阶段,基于可靠性设计的建模为代码开发人员实现预期的设计提供指导和依据。当前,随着系统规模的日趋庞大和功能复杂化,模型驱动的开发方法已经被广泛应用于软件系统的开发过程并为开发人员提供了指导,但是开发人员在实现可靠性设计的同时,也需要满足系统基本功能需求和其他非功能需求的设计;另外,系统代码版本更新、打补丁等也会使得可靠性设计产生相应的变更,对可靠性设计的完整实现带来了隐患。测试作为检查被测系统是否完整实现预期设计的有效手段,将辅助代码开发人员确认可靠性设计实现的完整性。
目前,针对可靠性的测试还是面向可靠性需求的,难以支持对可靠性设计的测试;部分可靠性测试的研究成果,只研究了通过设计阶段的可靠性测试模型生成测试用例的黑盒测试方法,无法验证可靠性设计在代码中是否完整实现。因此,研究可靠性设计是否在代码中得以实现是系统测试阶段亟待解决的关键问题之一。在软件系统开发周期中,需求与系统设计模型处于相对早期的阶段。随着不断的迭代开发过程,代码修改、版本更新等可能造成设计模型与代码实现不一致,从而造成后期系统高昂的开发、维护成本。目前已有研究中,更多的是关注UML类图模型与代码类之间的静态信息的一致性。但对于可靠性策略,其更多的关注模型元素之间的动态交互。因此纯静态信息的提取比较,不适合检测可靠性策略的模型与代码的一致性。
发明内容
鉴于上述的分析,本发明实施例旨在提供一种基于代码跟踪的软件可靠性测试方法和装置,用以解决现有方案缺少面向代码中可靠性策略跟踪,以及静态信息的提取比较不适合检测可靠性策略的模型与代码的一致性的问题。
一方面,本发明实施例提供了一种基于代码跟踪的软件可靠性测试方法,包括:对UML时序图和标号迁移系统LTS分别进行形式化描述;进行可靠性策略模型到代码的跟踪以获得可靠性策略代码,其中,所述跟踪包括定位和映射;基于所述可靠性策略代码插桩获得Log文件,其中,所述Log文件包括所述可靠性策略代码的执行路径信息;基于所述Log文件构建代码LTS;基于从软件系统整体设计模型中分离提取的可靠性策略切面模型,获取可靠性策略UML时序图模型的关键信息,以构建所述可靠性策略UML时序图模型,其中,所述可靠性策略切面模型为UML时序图的XMI文件;将所述可靠性策略UML时序图模型转换为模型LTS;提取所述代码LTS的分支路径作为代码路径,并提取所述模型LTS的所有分支路径作为模型路径;以及判断所述模型路径与所述代码路径是否匹配。
上述技术方案的有益效果如下:本发明实施例提供的基于代码跟踪的软件可靠性测试方法,通过可靠性策略模型到代码的跟踪获得可靠性策略代码;通过将可靠性策略设计模型的逻辑与源代码中的实现逻辑分别转换为同一种中间模型来判断二者满足一致性,弥补当前研究中对模型与代码动态一致性检测的缺失;该方法对可靠性策略模型与实现代码进行动态一致性检测,符合可靠性策略对实现逻辑正确性的要求,提供了更加高效的检测方法和更加准确的检测结果。
基于上述方法的进一步改进,所述定位为在软件系统源代码中找到可靠性策略的实现代码;以及所述映射为基于可靠性策略模型,将所述可靠性策略模型中的元素映射到所述实现代码中。
基于上述方法的进一步改进,利用复合检测进行可靠性策略模型到代码的跟踪以获得可靠性策略代码,其中,所述复合检测为约束配置、信息检索、基于方法调用图的检测、以及人工检测的结合,其中,所述约束配置为配置以下约束:可靠性策略关键词、基于需求的软件系统模块名称、和软件系统源代码文件格式;所述信息检索包括可靠性策略模型与代码信息的提取、检索匹配;以及所述方法调用图完整反映代码中各个类之间的方法调用关系以及描述代码的动态交互行为。
基于上述方法的进一步改进,基于所述可靠性策略代码插桩获得Log文件进一步包括:通过在所述可靠性策略代码的指定位置中插入代码片段作为探针,使得所述可靠性策略代码运行到所述指定位置时,通过执行所述代码片段来获得所述Log信息,其中,所述插桩规则包括:在所述跟踪的结果中,当根据名称直接匹配成功时,插入所述探针且将Tag标记为D;当根据所述名称没有匹配成功但与标记为D的所述直接匹配存在直接或间接依赖关系时,插入探针;当类根据名称直接匹配成功时,如果所述类的内部不存在标记为D的所述直接匹配,则在所述类的所有直接匹配中插入探针;以及在执行插桩的直接匹配的第一行和最后一行,插入探针。
基于上述方法的进一步改进,基于所述Log文件构建代码LTS包括:从所述log文件中提取可靠性策略一次完整的执行逻辑信息作为所述log信息;以及基于构建规则构建所述代码LTS,其中,所述构建规则包括:所述log信息中的每条log信息用于构建所述代码LTS中的一个起始状态节点和一个状态转移;所述log信息中的第一条log信息构建起始状态节点,并且所述log信息中的后续log信息构建的状态节点标记为顺序递增的数字;以及所述log信息中的最后一条log信息仅构建状态节点不构建状态转移。
基于上述方法的进一步改进,基于转换原则将所述可靠性策略UML时序图模型转换为模型LTS,所述转换原则包括:所述模型LTS的初始状态标记为0;所述可靠性策略UML时序图中的一条消息对应于所述模型LTS中的一个状态迁移;当在同一执行环境下第一条信息和第二条信息在时间轴上相邻时,所述第一条信息转换后的模型LTS目的状态等价于所述第二条信息转换后的模型LTS起始状态;以及当组合片段的每个子片段的起始信息转换为所述模型LTS,增加一个过渡状态和一个过渡迁移动作,其中,所述过渡状态的名称与所述起始信息的发送端名称一致,所述过渡迁移动作的类型为当前组合片段的类型。
基于上述方法的进一步改进,所述可靠性策略UML时序图模型包括ALT、OPT、LOOP和BREAK组合片段,其中,所述组合片段的转换规则还包括:所述组合片段结束时,增加一个过渡状态节点作为结束标志;所述ALT组合片段的转换原则还包括:先执行守卫条件为真的子片段;在所述ALT组合片段转换为所述LTS后,存在多个分支,分支数量与ALT组合片段中的子片段数量一致;所述OPT组合片段的转换原则还包括:当守卫条件为真时执行所述OPT组合片段,否则跳过所述OPT组合片段;在所述OPT组合片段转换为所述LTS后,存在两个分支;所述LOOP组合片段的转换原则还包括:当满足循环执行条件时,执行所述LOOP组合片段内的交互消息,否则结束循环;以及所述BREAK组合片段的转换原则还包括:当守卫条件为真时,执行所述BREAK组合片段内的交互消息;在所述BREAK组合片段转换为所述LTS时,存在两个分支;当所述BREAK组合片段属于另一组合片段时,执行完所述BREAK组合片段后,添加所述结束标志,然后执行所述另一组合片段,否则添加的结束标志作为全局结束状态节点。
基于上述方法的进一步改进,所述关键信息包括生命线、组合片段、和组合片段子片段。
基于上述方法的进一步改进,判断所述模型路径与所述代码路径是否匹配还包括设计一致性检测规则并根据所述一致性检测规则判断所述模型路径与所述代码路径是否匹配,其中,所述一致性检测规则包括:如果所述模型LTS中的一条交互消息对应于实现代码LTS中同一类的多个实现方法,当且仅当实现所述代码LTS的多个方法连续调用并且所述代码LTS与所述模型LTS的顺序一致时,满足一致性;如果所述模型LTS中的一条交互消息对应于实现代码LTS中多类的多个实现方法,当且仅当所述多类的多个实现方法连续调用,并且所述代码LTS与所述模型LTS的顺序一致时,满足一致性;如果所述模型LTS中的一条交互消息是自关联消息,则在所述代码LTS中有两种实现方式:调用同一类中的不同的另一方法和调用所述同一类中的同一方法;以及如果所述模型LTS中的一条交互消息的起始端的对象与接收端的对象不同,则当所述代码路径中起始节点的类映射的对象与所述模型路径中起始节点的对象保持相同时,保持一致性。
另一方面,本发明实施例提供了一种基于代码跟踪的软件可靠性测试装置,包括:形式化描述模块,用于对UML时序图和标号迁移系统LTS分别进行形式化描述;跟踪模块,用于进行可靠性策略模型到代码的跟踪以获得可靠性策略代码,其中,所述跟踪包括定位和映射;插桩模块,用于基于所述可靠性策略代码插桩获得Log文件,其中,所述Log文件包括所述可靠性策略代码的执行路径信息;代码LTS构建模块,用于基于所述Log文件构建代码LTS;提取模块,用于基于从软件系统整体设计模型中分离提取的可靠性策略切面模型,获取可靠性策略UML时序图模型的关键信息,以构建所述可靠性策略UML时序图模型,其中,所述可靠性策略切面模型为UML时序图的XMI文件;模型LTS构建模块,用于将所述可靠性策略UML时序图模型转换为模型LTS;提取模块,用于提取所述代码LTS的分支路径作为代码路径,并提取所述模型LTS的所有分支路径作为模型路径;以及判断模块,用于判断所述模型路径与所述代码路径是否匹配。
与现有技术相比,本发明至少可实现如下有益效果之一:
1、通过可靠性策略模型到代码的跟踪获得了可靠性策略代码;
2、本发明的技术方案简单、有效,通过将可靠性策略设计模型的逻辑与源代码中的实现逻辑分别转换为同一种中间模型来判断二者满足一致性,弥补了当前研究中对模型与代码动态一致性检测的缺失;
3、本发明的技术方案采用“基于模型测试”的思想,将可靠性策略模型和可靠性策略在源代码中实现的执行序列分别转换为同一种中间模型,并通过对比分析两者的中间模型进行判断;
4、本发明的技术方案对可靠性策略模型与实现代码进行动态一致性检测,符合可靠性策略对实现逻辑正确性的要求,提供了更加高效的检测方法和更加准确的检测结果;以及
5、本发明的高效准确的模型与代码之间的动态一致性检验方法,保障了可靠性设计在开发阶段得以正确实现,同时也提高系统后期维护效率。
本发明中,上述各技术方案之间还可以相互组合,以实现更多的优选组合方案。本发明的其他特征和优点将在随后的说明书中阐述,并且,部分优点可从说明书中变得显而易见,或者通过实施本发明而了解。本发明的目的和其他优点可通过说明书以及附图中所特别指出的内容中来实现和获得。
附图说明
附图仅用于示出具体实施例的目的,而并不认为是对本发明的限制,在整个附图中,相同的参考符号表示相同的部件。
图1为根据本发明实施例的基于代码跟踪的软件可靠性测试方法的流程图;
图2为根据本发明实施例的代码中可靠性策略跟踪确认方法整体流程示意图;
图3为根据本发明实施例的解析UML时序图的XMI文件流程图;
图4为根据本发明实施例的可靠性策略UML时序图与LTS模型数据结构的类图;
图5为根据本发明实施例的ALT组合片段到模型LTS的转换规则示意图;
图6为根据本发明实施例的OPT组合片段到模型LTS的转换规则示意图;
图7为根据本发明实施例的LOOP组合片段到模型LTS的转换规则示意图;
图8为根据本发明实施例的BREAK组合片段到模型LTS的转换规则示意图;
图9为根据本发明实施例的模型方法对应同一个类多个方法的一致性示意图;
图10为根据本发明实施例的模型方法对应不同类中多个方法的一致性示意图;
图11为根据本发明实施例的模型自关联消息与实现方法的一致性示意图;
图12为根据本发明实施例的一致性检测算法搜索回溯情形示意图;以及
图13为根据本发明实施例的基于代码跟踪的软件可靠性测试装置的框图。
附图标记:
1302-形式化描述模块;1304-跟踪模块;1306-插桩模块;1308-代码LTS构建模块;1310-提取模块;1312-模型LTS构建模块;1314-提取模块;以及1316-判断模块
具体实施方式
下面结合附图来具体描述本发明的优选实施例,其中,附图构成本申请一部分,并与本发明的实施例一起用于阐释本发明的原理,并非用于限定本发明的范围。
本发明的一个具体实施例,公开了一种基于代码跟踪的软件可靠性测试方法。如图1所示,基于代码跟踪的软件可靠性测试方法包括:在步骤S102中,对UML时序图和标号迁移系统LTS分别进行形式化描述;在步骤S104,进行可靠性策略模型到代码的跟踪以获得可靠性策略代码,其中,跟踪包括定位和映射;在步骤S106,基于可靠性策略代码插桩获得Log文件,其中,Log文件包括可靠性策略代码的执行路径信息;在步骤S108,基于Log文件构建代码LTS;在步骤S110中,基于从软件系统整体设计模型中分离提取的可靠性策略切面模型,获取可靠性策略UML时序图模型的关键信息,以构建可靠性策略UML时序图模型,其中,可靠性策略切面模型为UML时序图的XMI文件;在步骤S112中,将可靠性策略UML时序图模型转换为模型LTS;在步骤S114中,提取代码LTS的分支路径作为代码路径,并提取模型LTS的所有分支路径作为模型路径;以及在步骤S116中,判断模型路径与代码路径是否匹配。
与现有技术相比,本实施例提供的基于代码跟踪的软件可靠性测试方法。通过可靠性策略模型到代码的跟踪能够获得可靠性策略代码;通过将可靠性策略设计模型的逻辑与源代码中的实现逻辑分别转换为同一种中间模型来判断二者满足一致性,弥补当前研究中对模型与代码动态一致性检测的缺失;该方法对可靠性策略模型与实现代码进行动态一致性检测,符合可靠性策略对实现逻辑正确性的要求,提供了更加高效的检测方法和更加准确的检测结果。
下文中,参照图1对基于代码跟踪的软件可靠性测试方法进行详细描述。
基于代码跟踪的软件可靠性测试方法包括:在步骤S102中,对UML时序图和标号迁移系统LTS分别进行形式化描述(即,形式化定义)。对UML时序图和标号迁移系统LTS分别进行形式化描述包括:将UML时序图描述为八元组:SD={Obj,M,E,→,CF,OP,o,c},其中,Obj表示UML时序图中所有对象的集合;M表示UML时序图中所有消息的集合;E表示UML时序图中所有事件的集合;→表示UML时序图的消息集合M上的一个全局排序关系;CF表示UML时序图中所有组合片段的集合;OP表示UML时序图中所有隶属于组合片段的子片段的集合;O表示从E到OP的一个函数关系;C表示从OP到CF的一个函数关系;以及将标号迁移系统LTS描述为一个四元组:L={S,A,T,q0},其中,S表示标号迁移系统状态的有限非空集合;A表示标号迁移系统行为活动标号的有限非空集合;T表示系统状态迁移的集合;q0表示标号迁移系统的初始状态。UML时序图和标号迁移系统LTS的形式化描述能够指导后续需要从UML时序图模型中提取哪些信息以及转换规则的制定。
基于代码跟踪的软件可靠性测试方法还包括:在步骤S104中,进行可靠性策略模型到代码的跟踪以获得可靠性策略代码,其中,跟踪包括定位和映射。定位为在软件系统源代码中找到可靠性策略的实现代码;以及映射为基于可靠性策略模型,将可靠性策略模型中的元素映射到实现代码中。利用复合检测进行可靠性策略模型到代码的跟踪以获得可靠性策略代码,其中,复合检测为约束配置、信息检索、基于方法调用图的检测、以及人工检测的结合,其中,约束配置为配置以下约束:可靠性策略关键词、基于需求的软件系统模块名称、和软件系统源代码文件格式;信息检索包括可靠性策略模型与代码信息的提取、检索匹配;以及方法调用图完整反映代码中各个类之间的方法调用关系以及描述代码的动态交互行为。通过约束配置、信息检索、基于方法调用图的检测这三个步骤可以大大缩小查找范围,在最后使用人工检测不仅能避免耗费大量人力和时间,还能够有效提高跟踪的准确率。
基于代码跟踪的软件可靠性测试方法还包括:在步骤S106中,基于可靠性策略代码插桩获得Log文件,其中,Log文件包括可靠性策略代码的执行路径信息。基于可靠性策略代码插桩获得Log文件进一步包括:通过在可靠性策略代码的指定位置中插入代码片段作为探针,使得可靠性策略代码运行到指定位置时,通过执行代码片段来获得Log信息,其中,插桩规则包括:在跟踪的结果中,当根据名称直接匹配成功时,插入探针且将Tag标记为D;当根据名称没有匹配成功但与标记为D的直接匹配存在直接或间接依赖关系时,插入探针;当类根据名称直接匹配成功时,如果类的内部不存在标记为D的直接匹配,则在类的所有直接匹配中插入探针;以及在执行插桩的直接匹配的第一行和最后一行,插入探针。
基于代码跟踪的软件可靠性测试方法还包括:在步骤S108中,基于Log文件构建代码LTS。基于Log文件构建代码LTS包括:从log文件中提取可靠性策略一次完整的执行逻辑信息作为log信息;以及基于构建规则构建代码LTS,其中,构建规则包括:log信息中的每条log信息用于构建代码LTS中的一个起始状态节点和一个状态转移;log信息中的第一条log信息构建起始状态节点,并且log信息中的后续log信息构建的状态节点标记为顺序递增的数字;以及log信息中的最后一条log信息仅构建状态节点不构建状态转移。通过该构建规则,能够获得可靠性策略执行路径的代码LTS。
基于代码跟踪的软件可靠性测试方法还包括:在步骤S110中,基于从软件系统整体设计模型中分离提取的可靠性策略切面模型,获取可靠性策略UML时序图模型的关键信息,以构建可靠性策略UML时序图模型,其中,可靠性策略切面模型为UML时序图模型的XMI文件。具体地,关键信息包括生命线、组合片段、和组合片段子片段。
基于代码跟踪的软件可靠性测试方法还包括:在步骤S112中,将可靠性策略UML时序图模型转换为模型LTS。由于可靠性策略UML时序图模型与模型LTS的形式化定义不同,所以需要定义转换规则。基于转换原则将可靠性策略UML时序图模型转换为模型LTS,其中,该转换原则包括:模型LTS的初始状态标记为0;可靠性策略UML时序图中的一条消息对应于模型LTS中的一个状态迁移;当在同一执行环境下第一条信息和第二条信息在时间轴上相邻时,第一条信息转换后的模型LTS目的状态等价于第二条信息转换后的模型LTS起始状态;以及当组合片段的每个子片段的起始信息转换为模型LTS,增加一个过渡状态和一个过渡迁移动作,其中,过渡状态的名称与起始信息的发送端名称一致,过渡迁移动作的类型为当前组合片段的类型。
除了需要实现可靠性策略UML时序图模型整体转换为模型LTS,还需要单独考虑组合片段的转换规则。可靠性策略UML时序图模型包括ALT、OPT、LOOP和BREAK组合片段,其中,组合片段的转换规则还包括:组合片段结束时,增加一个过渡状态节点作为结束标志;ALT组合片段的转换原则还包括:先执行守卫条件为真的子片段;在ALT组合片段转换为LTS后,存在多个分支,分支数量与ALT组合片段中的子片段数量一致;OPT组合片段的转换原则还包括:当守卫条件为真时执行OPT组合片段,否则跳过OPT组合片段;在OPT组合片段转换为LTS后,存在两个分支;LOOP组合片段的转换原则还包括:当满足循环执行条件时,执行LOOP组合片段内的交互消息,否则结束循环;以及BREAK组合片段的转换原则还包括:当守卫条件为真时,执行BREAK组合片段内的交互消息;在BREAK组合片段转换为LTS时,存在两个分支;当BREAK组合片段属于另一组合片段时,执行完BREAK组合片段后,添加结束标志,然后执行另一组合片段,否则添加的结束标志作为全局结束状态节点。
基于代码跟踪的软件可靠性测试方法还包括:在步骤S114中,提取代码LTS的分支路径作为代码路径,并提取模型LTS的所有分支路径作为模型路径。
基于代码跟踪的软件可靠性测试方法还包括:在步骤S116中,判断模型路径与代码路径是否匹配。判断模型路径与代码路径是否匹配还包括设计一致性检测规则并根据一致性检测规则判断模型路径与代码路径是否匹配。模型LTS与代码LTS之间的一一对应关系几乎不存在,基本上是一对多的对应关系,因此,需要定义一致性检测规则。一致性检测规则包括:如果模型LTS中的一条交互消息对应于实现代码LTS中同一类的多个实现方法,当且仅当实现代码LTS的多个方法连续调用并且代码LTS与模型LTS的顺序一致时,满足一致性;如果模型LTS中的一条交互消息对应于实现代码LTS中多类的多个实现方法,当且仅当多类的多个实现方法连续调用,并且代码LTS与模型LTS的顺序一致时,满足一致性;如果模型LTS中的一条交互消息是自关联消息,则在代码LTS中有两种实现方式:调用同一类中的不同的另一方法和调用同一类中的同一方法;以及如果模型LTS中的一条交互消息的起始端的对象与接收端的对象不同,则当代码路径中起始节点的类映射的对象与模型路径中起始节点的对象保持相同时,保持一致性。
另外,基于代码跟踪的软件可靠性测试方法还包括:定义最小代码路径的数量,并且当代码路径的数量大于等于最小代码路径的数量时,确定一致性的检测结果准确。
下文中,参照图2至图12,以具体实例的方式对基于代码跟踪的软件可靠性测试方法进行详细描述。
随着互联网地发展,软件系统的规模在不断增大,对系统非功能属性的要求也越来越高,例如可靠性。可靠性策略是针对可靠性需求所拟定的决策并在软件系统架构层面给出解决方案。由于开发人员在系统实现过程中可能没有完全按照设计模型进行实现,或者后期代码升级维护过程中产生代码变更,破坏了可靠性策略的实现。因此我们需要检测系统代码中的可靠性策略是否按照设计模型进行了正确实现。图2给出了本发明代码中可靠性策略跟踪确认方法的整体流程。在图2中的可靠性策略切面模型(UML时序图)是基于系统总体架构模型、系统可靠性需求、可靠性策略库等得到的,默认是已存在的文档。因此我们要首先定义UML时序图与LTS模型的形式化定义,从UML模型的描述文件中提取关键信息。同时定义UML时序图到LTS模型的转换规则,基于该规则实现转换算法,完成可靠性策略UML时序图模型到LTS模型的转换;然后为了在系统源代码中找到可靠性策略的相关实现代码,提出了复合检测方法。通过结合约束配置、信息检索、基于方法调用图(Call Graph)的检测以及人工检测四种方法,完成可靠性策略设计模型到代码的跟踪。再定义代码插桩规则,完成可靠性策略实现代码的“源代码插桩”,运行并得到可靠性策略实现代码的执行路径Log信息。通过设计实现相关算法,利用Log构建可靠性策略代码执行路径的LTS模型;最后,分别从获取的可靠性策略UML时序图转换得到的LTS模型与可靠性策略实现代码执行路径构建的LTS模型中提取分支路径,定义一致性检测规则,实现一致性检测算法,对比这两个LTS模型产生的分支路径是否满足一致性,从而确认代码中可靠性策略的实现逻辑是否符合其设计模型。另外,为了提高该一致性检测结果的可信度,提出了一致性检测覆盖标准,避免代码路径无法完全覆盖的情况。
图2所示为实施本发明中所述方法的步骤流程图,现对具体步骤进行详细描述如下:
步骤一:定义UML时序图与标号迁移系统(Labelled Transition System,LTS)的形式化描述。
为了完成UML时序图到LTS模型的转换,首先需要完成UML时序图与LTS的形式化定义。该形式化定义也能指导后续需要从UML时序图中提取哪些信息以及转换规则的制定。
UML时序图可以表示成一个八元组:SD={Obj,M,E,→,CF,OP,o,c}。其中:Obj表示时序图中所有对象的集合;M表示时序图中所有消息的集合;E表示时序图中所有事件的集合;→表示UML时序图的消息集合M上的一个全局排序关系。它表示时序图中的所有消息在纵向时间轴上的先后关系;CF表示时序图中所有组合片段的集合;OP表示时序图中所有隶属于组合片段的子片段的集合;O表示从E到OP的一个函数关系。对于o(e)∈OP,表示事件e所隶属于的子片段;C表示从OP到CF的一个函数关系。对于c(op)∈CF,表示子片段op所隶属于的组合片段。
标号迁移系统可以表示为一个四元组:L={S,A,T,q0}。其中:S表示系统状态的有限非空集合;A表示系统行为活动标号的有限非空集合;T表示系统状态迁移的集合,是S×A×S的子集;q0表示系统的初始状态,可以看作只有一个元素的集合。因为本文中UML时序图转换得到的LTS只有一个初始状态,由UML时序图的入口消息决定。
步骤二:基于从软件系统整体设计模型中分离提取的可靠性策略切面模型(UML时序图),获取该UML时序图模型的关键信息。
通过以UML时序图导出的XMI文件为输入,解析该文件,提取出时序图中的所有关键信息并保存为UML时序图的数据结构实例中。
图3是解析UML时序图XMI文件流程图。在该流程图中,可以看到需要从UML时序图的XMI文件中提取出生命线、组合片段、组合片段子片段等关键信息,然后利用提取得到的信息构建出UML时序图数据结构的实例。图4是可靠性策略UML时序图(下文中,简称UML时序图)与LTS的数据结构,该图详细地展示出UML时序图与LTS模型应该保存的数据信息。
步骤三:定义UML时序图到LTS模型的转换原则,实现UML时序图到LTS的转换算法。
由于UML时序图与LTS模型的形式化定义不同,因此需要定义相关的转换原则,用于指导转换算法的实现。其中转换原则包括:(1)LTS系统的初始状态节点标记为0;(2)UML时序图(即,可靠性策略UML时序图)中的一条消息,对应LTS(即,模型LTS)中的一个状态迁移;(3)对于同一执行环境下的两条在时间轴上相邻的信息,将其转换为LTS后,第一条消息转换后的LTS目的状态等价于第二条消息转换后的LTS起始状态;(4)对于ALT、OPT等组合片段中每个子片段的第一条消息,将其转换为对应的LTS时,需要增加一个过渡状态和过渡迁移动作,过渡状态name与该第一条消息的发送端对象名称一致、过渡迁移动作的类型为当前组合片段的类型。
除了需要实现UML时序图整体到LTS的转换算法(如表2所示),还需要单独考虑ALT、OPT、LOOP和BREAK四种类型的组合片段到LTS的转换算法(如图5、图6、图7和图8)。在对UML时序图中的交互消息进行处理的时候,若该交互消息属于某一类型的组合片段,则调用对应的算法处理该片段内的所有消息并返回组合片段结束状态节点。
图5为根据本发明实施例的ALT组合片段到模型LTS的转换规则示意图。对于ALT片段,其存在多个守卫条件,且守卫条件先为true的子片段会得以执行。因此,对ALT组合片段而言,其转换为LTS后会存在若干分支,分支数量与组合片段内的子片段数量保持一致。每个分支均以[cfName,ALT,Ci]作为过渡迁移标号,其中Ci为每个子片段自身的守卫条件。由于每个子片段最后一条消息的接收端不一定是同一个对象,因此还需要在组合片段结束后,增加一个名称为ALT_CF_END过渡状态节点,如图6所示。
图6为根据本发明实施例的OPT组合片段到模型LTS的转换规则示意图。对于OPT组合片段,当其守卫条件为真时,该片段内的交互消息才会执行,否则会跳过该组合片段。因此,将OPT组合片段转换为LTS时,会出现两个分支,分别以[cfName,OPT,Ci]和[cfName,OPT,!Ci]作为过渡迁移标号。其中Ci与!Ci分别表示守卫条件为真与守卫条件为假。当该组合片段结束时,会通过一个名称为OPT_CF_END的过渡状态节点作为该组合片段的结束标志,如图6所示。
图7为根据本发明实施例的LOOP组合片段到模型LTS的转换规则示意图。对于LOOP组合片段,其存在一个循环执行条件,该条件包括一个初始值、极限值以及执行动作。待判断变量设定为初始值,接着判断变量的值是否不超过极限值。如果是,则以[cfName,LOOP,Ci]为过渡迁移标号开始执行组合片段内的交互消息,完成后使用执行动作修改变量的值;否则以[cfName,LOOP,!Ci]为过渡迁移标号结束循环。在执行完片段内最后一条消息后,需要重复上一次操作,先判断变量的值是否满足条件,再根据判断结果进行下一次操作。当该组合片段结束时,会通过一个名称为LOOP_CF_END的过渡状态节点作为该组合片段的结束标志,如图7所示。
图8为根据本发明实施例的BREAK组合片段到模型LTS的转换规则示意图。对于BREAK组合片段,当其守卫条件为真时,该片段内的交互消息才会执行。因此,将BREAK组合片段转换为LTS时,会出现两个分支,分别以[cfName,OPT,Ci]和[cfName,OPT,!Ci]作为过渡迁移标号。如果BREAK组合片段属于另一个组合片段(假设为CFb),则当BREAK片段执行完后,紧跟着BREAK_CF_END状态节点的是所属组合片段CFb结束节点的邻接状态节点;若BREAK组合片段不属于任何一个组合片段,则BREAK_CF_END状态节点就是全局结束状态节点,如图8所示。
表1:UML时序图到LTS的转换算法
Figure BDA0002441172040000121
Figure BDA0002441172040000131
步骤四:提出复合检测算法,完成可靠性策略设计模型到代码的跟踪。
关于模型与代码之间的跟踪,主要分为两个环节,定位与映射。定位是指在系统源代码中找到可靠性策略的实现代码;映射是指基于可靠性策略的设计模型,将模型中的元素映射到定位所得到的代码类上。本发明提出的复合检测方法同时适用于这两个环节,该复合检测方法通过将约束配置、信息检索、基于方法调用图的检测与人工检测结合起来,提高模型到代码跟踪的效率与准确率。
(1)约束配置:主要配置的约束包括可靠性策略关键词、基于需求的系统模块名称、系统源代码文件格式等;
(2)信息检索:该过程主要包括模型与代码信息提取、检索匹配。需要提取的模型信息包括可靠性策略关键词列表、策略模型所有对象名称列表和策略模型所有消息名称列表;需要提取的代码信息包括所有模块名称列表、每个模块下所有的包、每个包下所有的类、每个类中所有的方法以及每个类中所有的内部类。通过采用模糊匹配的原则来完成检索匹配,完成模型信息与代码信息的相关匹配。
(3)基于方法调用图的检测:方法调用图,能够完整地反映代码中各个类之间的方法调用关系以及描述代码的动态交互行为。为了避免单纯信息检索造成的信息遗漏的情况,将相关类之间的“调用距离”作为一项判断准则,若该调用距离不大于N(默认为5),则认为当前判断的类与起始基准类存在联系,将其作为匹配结果进行保存。
(4)人工检测:通过前三步骤,可以大大缩小查找范围,在最后使用人工检测不仅能避免耗费大量人力、时间的问题,还能有效提高跟踪的准确率。
表2与表3分别代表了利用本发明步骤四中提出的复合检测方法针对定位与映射过程的有效性。在这两个表格中,我们分别列举了两种检测方式的查准率与查全率:IR,即单纯使用信息检索的方式;Constraint&&IR&&Call Graph,即结合约束配置、信息检索与基于方法调用图的检测三种方法。
表2:复合检测在定位过程中的有效性验证
Figure BDA0002441172040000132
Figure BDA0002441172040000141
表3:复合检测在映射过程中的有效性验证
Figure BDA0002441172040000142
步骤五:基于步骤四得到的模型元素与代码实现的映射关系,基于源代码插桩,运行得到可靠性策略实现代码的执行路径Log信息。
步骤四已经获取到了可靠性策略的实现代码,因此需要定义插桩规则,通过在指定位置插入代码片段(“探针”),使得系统程序运行到该位置后,通过执行该“探针”而能够获取到控制流等Log信息。插桩规则包括:
(1)在步骤四得到的跟踪结果中,对于依靠名称直接匹配成功的方法,插入“探针”,且Tag标记为“D”;
(2)在步骤四得到的跟踪结果中,对于没有依靠名称匹配成功的方法但与标记为“D”的方法存在直接或间接依赖关系的,插入“探针”;
(3)在步骤四得到的跟踪结果中,对于依靠名称直接匹配成功的类,如果其内部不存在标记为“D”的方法,则在该类中所有的方法插入“探针”;以及
(4)在每个需要执行插桩的方法的第一行(保证程序执行到该方法会首先执行该语句)和最后一行(保证程序离开该方法前会执行该语句)插入“探针”。
步骤六:实现基于Log信息构建对应LTS模型的算法。
步骤五中得到的Log保存了可靠性策略实现代码的执行路径信息,因此可以基于该Log来构建可靠性策略实现代码执行路径的LTS模型。
由于可靠性策略时序图模型转换得到的LTS模型,是可靠性策略的一次完整流程。对于系统程序而言,只要程序不中断运行,Log文件中的信息就会不断增加,可靠性策略代码的实现逻辑可能会被重复多次执行,因此需要从Log中提取可靠性策略一次完整的执行逻辑信息,便于后续构建代码执行路径的LTS模型。本发明通过对Log文件中每行信息进行Hash,找到相邻两个完整流程的“入口”,利用该“入口”对应的行数差来获取一次完整流程所输出的总行数,并以此获得一次完整流程的Log信息。
通过定义构建规则,指导实现相关的构建算法(如表4所示)。构建规则包括:Log中每一行信息(即触发一次“探针”输出的内容),可用于构建LTS中一个起始状态节点及一个状态迁移;Log中第一条消息构建的起始状态节点标记为0,后续构建的状态节点使用顺序递增的数字来标记;Log中最后一条消息,只需要构建状态节点即可,不用构建状态迁移。从而相比于无法进行可靠性策略的代码跟踪的现有技术,本申请能够通过该构建规则能够实现可靠性策略的代码跟踪。
表4:基于Log构建LTS的算法
Figure BDA0002441172040000151
步骤七:针对步骤三与步骤六中得到的LTS模型,分别提取出他们的所有分支路径;从模型LTS得到的分支路径称为模型路径,代码LTS得到的分支路径称为代码路径。
步骤三与步骤六中分别得到了可靠性策略设计模型的LTS与可靠性策略实现代码的LTS。由于可靠性策略设计模型中可能存在选择、循环等分支,因此其转换得到的LTS中也会存在分支,因此需要提取出所有的分支路径;而可靠性策略实现代码的LTS由于是基于代码运行Log构建的,因此其代表代码运行的一条完整路径,不存在额外的分支路径。
步骤八:设计一致性检测规则,实现一致性检测算法,判断代码路径是否能够与模型路径成功匹配。
目前的软件开发工作中,模型元素与代码之间一一对应的情况几乎不存在,基本上是一对多的情况。因此为了检测可靠性策略设计模型LTS的分支路径与可靠性策略实现代码LTS的分支路径之间的一致性,需要定义一致性规则:
(1)如果策略模型中的一条交互消息对应实现代码中同一类的多个实现方法,当且仅当实现代码的多个方法连续调用,并且代码类顺序与模型对象顺序保持一致时,满足一致性,如图9所示;
(2)如果策略模型中一条交互消息对应策略实现代码中多个类中的多个实现方法,当且仅当这多个对应的实现类中的多个方法连续调用,并且代码类顺序(映射到同一模型对象的类之间顺序不限)与模型对象顺序保持一致时,满足一致性,如图10所示;
(3)如果策略模型中一条交互消息是自关联消息,即模型对象发送交互消息给自身,其在代码中有两种可能的实现方式:该方法调用同一类中的另一个不同方法(即常规调用)、该方法调用同一类中的同一个方法(即递归调用),如图11所示;
(4)如果策略模型中一条交互消息的起始端的对象与接收端的对象不同,则为了满足策略模型与代码之间的一致性,要求代码路径起始节点的类映射的模型对象与模型路径中起始节点的对象保持相同,否则立即返回不一致的检测结果。
根据一致性规则的第四条,由于模型路径与代码路径在执行匹配检测时,可能需要继续往后执行才能判断出当前的状态是否一致。因此本发明利用搜索和回溯的思想(如图12所示)来设计实现一致性检测算法。
表5:模型路径与代码路径的一致性检测算法
Figure BDA0002441172040000161
Figure BDA0002441172040000171
步骤九:定义一致性检测覆盖标准,提高检测结果可信度;分析并得到最终结果。
由于可靠性策略模型的LTS往往存在很多的分支路径,而代码执行路径的LTS在某一确定运行条件下只存在一条路径,因此为了提高一致性检测的可信度,避免误判的情况,可以通过更改代码运行时条件,产生新的代码执行路径的LTS,进行多次一致性检测。当可靠性策略模型的LTS分支路径数量较多时,通过改变运行时条件去重新产生代码执行路径的LTS会耗费太多的时间成本,且可能存在代码运行是路径无法完全覆盖的情况,因此本发明定义了一个最小的代码执行路径LTS的数量(Minimum Code LTS Number,MCLN)。产生的代码执行路径LTS数量只有不低于MCLN,满足一致性检测可信度要求,此次可靠性策略模型LTS与代码LTS之间的一致性检测结果才会认为是准确的。
本实例提出了一种基于指定置信度和期望的一致性检测可信度来计算MCLN。假设在当前的一致性检测流程中,可靠性策略模型LTS产生的分支路径的数量为MN,错误判断的概率为k,α是显著性水平。一致性检测结果可被接收的最低可信度要求为R,估计的可信度为R,则置信水平
Figure BDA0002441172040000172
可计算得到:
Figure BDA0002441172040000173
本发明最主要的贡献是提供了一种针对可靠性策略,检测其模型(UML时序图)与实现代码关于动态交互逻辑是否保持一致性的方法。本发明方法简单、有效,通过将可靠性策略设计模型的逻辑与源代码中的实现逻辑分别转换为同一种中间模型来判断二者满足一致性,弥补当前研究中对模型与代码动态一致性检测的缺失;该方法对可靠性策略模型与实现代码进行动态一致性检测,符合可靠性策略对实现逻辑正确性的要求,提供了针对可靠性策略更加高效的检测方法及更加准确的检测结果。
下文中,将参照图13,对基于代码跟踪的软件可靠性测试装置进行描述。
本发明的另一个具体实施例,公开了一种基于代码跟踪的软件可靠性测试装置。如图13所示,一种基于代码跟踪的软件可靠性测试装置包括:形式化描述模块1302,用于对UML时序图和标号迁移系统LTS分别进行形式化描述;跟踪模块1304,用于进行可靠性策略模型到代码的跟踪以获得可靠性策略代码,其中,跟踪包括定位和映射;插桩模块1306,用于基于可靠性策略代码插桩获得Log文件,其中,Log文件包括可靠性策略代码的执行路径信息;代码LTS构建模块1308,用于基于Log文件构建代码LTS;提取模块1310,用于基于从软件系统整体设计模型中分离提取的可靠性策略切面模型,获取可靠性策略UML时序图模型的关键信息,以构建可靠性策略UML时序图模型,其中,可靠性策略切面模型为UML时序图的XMI文件;模型LTS构建模块1312,用于将可靠性策略UML时序图模型转换为模型LTS;提取模块1314,用于提取代码LTS的分支路径作为代码路径,并提取模型LTS的所有分支路径作为模型路径;以及判断模块1316,用于判断模型路径与代码路径是否匹配。
基于代码跟踪的软件可靠性测试装置还包括多个其他模块,这些多个其他模块与基于代码跟踪的软件可靠性测试装置的步骤相对应。由于基于代码跟踪的软件可靠性测试装置与基于代码跟踪的软件可靠性测试方法相对应,所以为了避免赘述,没有对多个其他模块进行详细描述。
与现有技术相比,本实施例提供的基于代码跟踪的软件可靠性测试方法和装置包括以下技术:
1、通过可靠性策略模型到代码的跟踪获得了可靠性策略代码;
2、本发明的技术方案简单、有效,通过将可靠性策略设计模型的逻辑与源代码中的实现逻辑分别转换为同一种中间模型来判断二者满足一致性,弥补了当前研究中对模型与代码动态一致性检测的缺失;
3、本发明的技术方案采用“基于模型测试”的思想,将可靠性策略模型和可靠性策略在源代码中实现的执行序列分别转换为同一种中间模型,并通过对比分析两者的中间模型进行判断;
4、本发明的技术方案对可靠性策略模型与实现代码进行动态一致性检测,符合可靠性策略对实现逻辑正确性的要求,提供了更加高效的检测方法和更加准确的检测结果;以及
5、本发明的高效准确的模型与代码之间的动态一致性检验方法,保障了可靠性设计在开发阶段得以正确实现,同时也提高系统后期维护效率。
本领域技术人员可以理解,实现上述实施例方法的全部或部分流程,可以通过计算机程序来指令相关的硬件来完成,所述的程序可存储于计算机可读存储介质中。其中,所述计算机可读存储介质为磁盘、光盘、只读存储记忆体或随机存储记忆体等。
以上所述,仅为本发明较佳的具体实施方式,但本发明的保护范围并不局限于此,任何熟悉本技术领域的技术人员在本发明揭露的技术范围内,可轻易想到的变化或替换,都应涵盖在本发明的保护范围之内。

Claims (8)

1.一种基于代码跟踪的软件可靠性测试方法,其特征在于,包括:
对UML时序图和标号迁移系统LTS分别进行形式化描述;
进行可靠性策略模型到代码的跟踪以获得可靠性策略代码,其中,所述跟踪包括定位和映射;
基于所述可靠性策略代码插桩获得Log文件,其中,所述Log文件包括所述可靠性策略代码的执行路径信息;
基于所述Log文件构建代码LTS;
基于从软件系统整体设计模型中分离提取的可靠性策略切面模型,获取可靠性策略UML时序图模型的关键信息,以构建所述可靠性策略UML时序图模型,其中,所述可靠性策略切面模型为UML时序图的XMI文件;
将所述可靠性策略UML时序图模型转换为模型LTS,其中,基于转换原则将所述可靠性策略UML时序图模型转换为模型LTS,
所述转换原则包括:所述模型LTS的初始状态标记为0;所述可靠性策略UML时序图中的一条消息对应于所述模型LTS中的一个状态迁移;当在同一执行环境下第一条信息和第二条信息在时间轴上相邻时,所述第一条信息转换后的模型LTS目的状态等价于所述第二条信息转换后的模型LTS起始状态;以及当组合片段的每个子片段的起始信息转换为所述模型LTS,增加一个过渡状态和一个过渡迁移动作,其中,所述过渡状态的名称与所述起始信息的发送端名称一致,所述过渡迁移动作的类型为当前组合片段的类型;
所述可靠性策略UML时序图模型包括ALT、OPT、LOOP和BREAK组合片段,其中,所述组合片段的转换规则还包括:所述组合片段结束时,增加一个过渡状态节点作为结束标志;所述ALT组合片段的转换原则还包括:先执行守卫条件为真的子片段;在所述ALT组合片段转换为所述LTS后,存在多个分支,分支数量与ALT组合片段中的子片段数量一致;所述OPT组合片段的转换原则还包括:当守卫条件为真时执行所述OPT组合片段,否则跳过所述OPT组合片段;在所述OPT组合片段转换为所述LTS后,存在两个分支;所述LOOP组合片段的转换原则还包括:当满足循环执行条件时,执行所述LOOP组合片段内的交互消息,否则结束循环;以及所述BREAK组合片段的转换原则还包括:当守卫条件为真时,执行所述BREAK组合片段内的交互消息;在所述BREAK组合片段转换为所述LTS时,存在两个分支;当所述BREAK组合片段属于另一组合片段时,执行完所述BREAK组合片段后,添加所述结束标志,然后执行所述另一组合片段,否则添加的结束标志作为全局结束状态节点;
提取所述代码LTS的分支路径作为代码路径,并提取所述模型LTS的所有分支路径作为模型路径;以及
判断所述模型路径与所述代码路径是否匹配。
2.根据权利要求1所述的软件可靠性测试方法,其特征在于,
所述定位为在软件系统源代码中找到可靠性策略的实现代码;以及
所述映射为基于可靠性策略模型,将所述可靠性策略模型中的元素映射到所述实现代码中。
3.根据权利要求1所述的软件可靠性测试方法,其特征在于,利用复合检测进行可靠性策略模型到代码的跟踪以获得可靠性策略代码,其中,所述复合检测为约束配置、信息检索、基于方法调用图的检测、以及人工检测的结合,其中,
所述约束配置为配置以下约束:可靠性策略关键词、基于需求的软件系统模块名称、和软件系统源代码文件格式;
所述信息检索包括可靠性策略模型与代码信息的提取、检索匹配;以及
所述方法调用图完整反映代码中各个类之间的方法调用关系以及描述代码的动态交互行为。
4.根据权利要求1所述的软件可靠性测试方法,其特征在于,基于所述可靠性策略代码插桩获得Log文件进一步包括:通过在所述可靠性策略代码的指定位置中插入代码片段作为探针,使得所述可靠性策略代码运行到所述指定位置时,通过执行所述代码片段来获得Log信息,其中,插桩规则包括:在所述跟踪的结果中,
当根据名称直接匹配成功时,插入所述探针且将Tag标记为D;
当根据所述名称没有匹配成功但与标记为D的所述直接匹配存在直接或间接依赖关系时,插入探针;
当类根据名称直接匹配成功时,如果所述类的内部不存在标记为D的所述直接匹配,则在所述类的所有直接匹配中插入探针;以及
在执行插桩的直接匹配的第一行和最后一行,插入探针。
5.根据权利要求1所述的软件可靠性测试方法,其特征在于,基于所述Log文件构建代码LTS包括:
从所述log文件中提取可靠性策略一次完整的执行逻辑信息作为所述log信息;以及
基于构建规则构建所述代码LTS,其中,所述构建规则包括:
所述log信息中的每条log信息用于构建所述代码LTS中的一个起始状态节点和一个状态转移;
所述log信息中的第一条log信息构建起始状态节点,并且所述log信息中的后续log信息构建的状态节点标记为顺序递增的数字;以及
所述log信息中的最后一条log信息仅构建状态节点不构建状态转移。
6.根据权利要求1所述的软件可靠性测试方法,其特征在于,所述关键信息包括生命线、组合片段、和组合片段子片段。
7.根据权利要求1所述的软件可靠性测试方法,其特征在于,判断所述模型路径与所述代码路径是否匹配还包括设计一致性检测规则并根据所述一致性检测规则判断所述模型路径与所述代码路径是否匹配,其中,所述一致性检测规则包括:
如果所述模型LTS中的一条交互消息对应于实现代码LTS中同一类的多个实现方法,当且仅当实现所述代码LTS的多个方法连续调用并且所述代码LTS与所述模型LTS的顺序一致时,满足一致性;
如果所述模型LTS中的一条交互消息对应于实现代码LTS中多类的多个实现方法,当且仅当所述多类的多个实现方法连续调用,并且所述代码LTS与所述模型LTS的顺序一致时,满足一致性;
如果所述模型LTS中的一条交互消息是自关联消息,则在所述代码LTS中有两种实现方式:调用同一类中的不同的另一方法和调用所述同一类中的同一方法;以及
如果所述模型LTS中的一条交互消息的起始端的对象与接收端的对象不同,则当所述代码路径中起始节点的类映射的对象与所述模型路径中起始节点的对象保持相同时,保持一致性。
8.一种基于代码跟踪的软件可靠性测试装置,其特征在于,包括:
形式化描述模块,用于对UML时序图和标号迁移系统LTS分别进行形式化描述;
跟踪模块,用于进行可靠性策略模型到代码的跟踪以获得可靠性策略代码,其中,所述跟踪包括定位和映射;
插桩模块,用于基于所述可靠性策略代码插桩获得Log文件,其中,所述Log文件包括所述可靠性策略代码的执行路径信息;
代码LTS构建模块,用于基于所述Log文件构建代码LTS;
提取模块,用于基于从软件系统整体设计模型中分离提取的可靠性策略切面模型,获取可靠性策略UML时序图模型的关键信息,以构建所述可靠性策略UML时序图模型,其中,所述可靠性策略切面模型为UML时序图的XMI文件;
模型LTS构建模块,用于将所述可靠性策略UML时序图模型转换为模型LTS,其中,基于转换原则将所述可靠性策略UML时序图模型转换为模型LTS,
所述转换原则包括:所述模型LTS的初始状态标记为0;所述可靠性策略UML时序图中的一条消息对应于所述模型LTS中的一个状态迁移;当在同一执行环境下第一条信息和第二条信息在时间轴上相邻时,所述第一条信息转换后的模型LTS目的状态等价于所述第二条信息转换后的模型LTS起始状态;以及当组合片段的每个子片段的起始信息转换为所述模型LTS,增加一个过渡状态和一个过渡迁移动作,其中,所述过渡状态的名称与所述起始信息的发送端名称一致,所述过渡迁移动作的类型为当前组合片段的类型;
所述可靠性策略UML时序图模型包括ALT、OPT、LOOP和BREAK组合片段,其中,所述组合片段的转换规则还包括:所述组合片段结束时,增加一个过渡状态节点作为结束标志;所述ALT组合片段的转换原则还包括:先执行守卫条件为真的子片段;在所述ALT组合片段转换为所述LTS后,存在多个分支,分支数量与ALT组合片段中的子片段数量一致;所述OPT组合片段的转换原则还包括:当守卫条件为真时执行所述OPT组合片段,否则跳过所述OPT组合片段;在所述OPT组合片段转换为所述LTS后,存在两个分支;所述LOOP组合片段的转换原则还包括:当满足循环执行条件时,执行所述LOOP组合片段内的交互消息,否则结束循环;以及所述BREAK组合片段的转换原则还包括:当守卫条件为真时,执行所述BREAK组合片段内的交互消息;在所述BREAK组合片段转换为所述LTS时,存在两个分支;当所述BREAK组合片段属于另一组合片段时,执行完所述BREAK组合片段后,添加所述结束标志,然后执行所述另一组合片段,否则添加的结束标志作为全局结束状态节点;
提取模块,用于提取所述代码LTS的分支路径作为代码路径,并提取所述模型LTS的所有分支路径作为模型路径;以及
判断模块,用于判断所述模型路径与所述代码路径是否匹配。
CN202010265596.3A 2020-04-07 2020-04-07 基于代码跟踪的软件可靠性测试方法和装置 Active CN111488276B (zh)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN202010265596.3A CN111488276B (zh) 2020-04-07 2020-04-07 基于代码跟踪的软件可靠性测试方法和装置

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN202010265596.3A CN111488276B (zh) 2020-04-07 2020-04-07 基于代码跟踪的软件可靠性测试方法和装置

Publications (2)

Publication Number Publication Date
CN111488276A CN111488276A (zh) 2020-08-04
CN111488276B true CN111488276B (zh) 2021-07-27

Family

ID=71811663

Family Applications (1)

Application Number Title Priority Date Filing Date
CN202010265596.3A Active CN111488276B (zh) 2020-04-07 2020-04-07 基于代码跟踪的软件可靠性测试方法和装置

Country Status (1)

Country Link
CN (1) CN111488276B (zh)

Families Citing this family (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN112148257B (zh) * 2020-09-11 2022-08-09 中国运载火箭技术研究院 飞行控制软件可靠性设计方法、装置及计算机存储介质
CN113778860B (zh) * 2021-08-16 2023-11-28 北京仿真中心 基于模型检测的系统运行时验证方法、系统和计算机设备

Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN101833504A (zh) * 2010-04-19 2010-09-15 张翀斌 一种基于模型检验的时序软件质量缺陷检测方法及系统
CN104375842A (zh) * 2014-12-05 2015-02-25 中国人民解放军理工大学 一种自适应软件uml建模及其形式化验证方法
WO2017048662A1 (en) * 2015-09-19 2017-03-23 Microsoft Technology Licensing, Llc Predicated read instructions
CN107678964A (zh) * 2017-09-29 2018-02-09 云南大学 一种构件动态演化内部一致性保证方法
CN108830085A (zh) * 2018-06-13 2018-11-16 天津大学 基于扩展UML的Web应用形式化建模及验证方法

Family Cites Families (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN101847123B (zh) * 2010-05-26 2012-11-21 北京航空航天大学 一种机载计算机软件测试通用体系的构建方法
CN108536581B (zh) * 2018-03-08 2021-11-19 华东师范大学 一种针对源代码的运行时形式化验证方法

Patent Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN101833504A (zh) * 2010-04-19 2010-09-15 张翀斌 一种基于模型检验的时序软件质量缺陷检测方法及系统
CN104375842A (zh) * 2014-12-05 2015-02-25 中国人民解放军理工大学 一种自适应软件uml建模及其形式化验证方法
WO2017048662A1 (en) * 2015-09-19 2017-03-23 Microsoft Technology Licensing, Llc Predicated read instructions
CN107678964A (zh) * 2017-09-29 2018-02-09 云南大学 一种构件动态演化内部一致性保证方法
CN108830085A (zh) * 2018-06-13 2018-11-16 天津大学 基于扩展UML的Web应用形式化建模及验证方法

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
《基于路径覆盖插桩的可执行代码测试工具实现》;王轶等;《计算机工程》;20120522;第38卷(第5期);第35-37,40页 *

Also Published As

Publication number Publication date
CN111488276A (zh) 2020-08-04

Similar Documents

Publication Publication Date Title
Mao et al. Learning probabilistic automata for model checking
US8312440B2 (en) Method, computer program product, and hardware product for providing program individuality analysis for source code programs
US20020091968A1 (en) Object-oriented data driven software GUI automated test harness
US20070011671A1 (en) Method for the static analysis of concurrent multi-threaded software
US20110047532A1 (en) Methods and apparatuses for selective code coverage
Usman et al. A survey of consistency checking techniques for UML models
CN111382070B (zh) 兼容性测试方法、装置、存储介质和计算机设备
CN111488276B (zh) 基于代码跟踪的软件可靠性测试方法和装置
CN108694320B (zh) 一种多安全环境下敏感应用动态度量的方法及系统
CN111581106A (zh) 二进制程序漏洞测试方法、装置及可读存储介质
CN113050953A (zh) 基于注释生成代码的方法、装置及存储介质
Dong et al. Orplocator: Identifying read points of configuration options via static analysis
CN114547318A (zh) 故障信息获取方法、装置、设备和计算机存储介质
Zhang et al. Understanding large language model based fuzz driver generation
CN114510722A (zh) 增量代码的静态检测方法及检测系统
CN112395199B (zh) 基于云计算的分布式软件实例测试方法及软件开发平台
CN113868136A (zh) 一种基于Go语言可执行形式化语义的程序漏洞分析方法
CN111475415B (zh) 一种可靠性策略模型与代码的一致性检测方法和装置
CN115310095A (zh) 一种区块链智能合约混合形式化验证方法及系统
CN116756021A (zh) 基于事件分析的故障定位方法、装置、电子设备及介质
CN111459984B (zh) 基于流式处理的日志数据处理系统及方法
CN114462043A (zh) 基于强化学习的Java反序列化漏洞检测系统及方法
JP7111967B2 (ja) プログラム検証プログラム、プログラム検証方法およびプログラム検証装置
CN113312054A (zh) 针对嵌入式软件架构的软件栈消耗分析方法及分析装置
CN112925874A (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
GR01 Patent grant
GR01 Patent grant
TR01 Transfer of patent right
TR01 Transfer of patent right

Effective date of registration: 20220127

Address after: 215488 No. 301, building 11, phase II, Taicang University Science Park, No. 27, Zigang Road, science and education new town, Taicang City, Suzhou City, Jiangsu Province

Patentee after: Tianhang Changying (Jiangsu) Technology Co.,Ltd.

Address before: 100191 No. 37, Haidian District, Beijing, Xueyuan Road

Patentee before: BEIHANG University