CN110750459B - 基于白盒分析的测试用例自动生成和测试进程管理方法 - Google Patents
基于白盒分析的测试用例自动生成和测试进程管理方法 Download PDFInfo
- Publication number
- CN110750459B CN110750459B CN201911012761.8A CN201911012761A CN110750459B CN 110750459 B CN110750459 B CN 110750459B CN 201911012761 A CN201911012761 A CN 201911012761A CN 110750459 B CN110750459 B CN 110750459B
- Authority
- CN
- China
- Prior art keywords
- test
- analysis
- code
- white
- function
- 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
Links
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
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)
- Debugging And Monitoring (AREA)
Abstract
本发明提出了一种基于白盒分析的测试用例自动生成和测试进程管理方法,包括:配置测试环境,分析并显示用户代码结构;对用户代码进行白盒静态分析,获取白盒分析结果;以白盒分析结果为基础进行测试进程管理,包括:获取用户的测试需求,根据测试需求设计测试进程和对应的测试用例,对自动生成和客户自定义的测试用例进行管理;以白盒分析结果为基础进行动态测试,包括:充分性测试、覆盖率测试、功能测试、时间性能测试、变量动态分析、动态内存分析,然后生成动态测试报告;以白盒分析结果为基础将测试用例进行执行,得出测试结果和函数调用关系图中各个节点的的覆盖情况。本发明可以降低用户测试工作量,提高测试效率。
Description
技术领域
本发明涉及软件测试技术领域,特别涉及一种基于白盒分析的测试用例自动生成和测试进程管理方法。
背景技术
现有技术中通常主要针对功能测试,只为用户提供测试用例输入的接口和测试结果观测的接口,而不会帮助用户生成和执行测试用例,也无法进行测试进程的管理,测试过程的记录、追溯等功能,这种技术实现思路会造成以下后果:
(1)在仿真的或真实的目标机环境下,为用户提供数字化的外部数据注入端口、提供功能输出观测点,这样通常只能满足用户功能测试的需求,如图1所示;
(2)不以白盒分析为基础,无法为用户提供准确的系统架构分析,无法为用户提供设计测试用例的基础参照信息,尤其不利于对整个大系统不熟悉的测试人员;
(3)没有完备的白盒分析数据,无法为用户提供测试用例设计过程中的输入输出参考值,设计用例效率低;
(4)没有白盒分析数据,无法为用户提供自动测试用例生成功能,无法将执行过的测试用例与用户代码关联起来为用户提供覆盖情况、测试效率等关键的辅助信息;
(5)在不提供自动测试用例生成功能的情况下,无法为用户提供自动测试用例执行、充分性测试等附加功能。
现有的技术方案,尤其是应用于卫星仿真领域的相关系统,通常是基于项目的,以实际功能测试需求为基础进行测试工作的,主要功能实现考虑的是为用户提供测试环境,并不考虑白盒测试,因此通常不为用户提供基于白盒分析的测试用例自动生成和测试进程管理功能,其存在的客观缺点如下:
(1)测试目的单一
现有技术通常只以完成测试环境搭建,满足用户功能测试需求为目标,并不为客户提供白盒分析和以此为基础的测试功能。
(2)测试流程管理
传统系统通常不对测试过程进行管理,没有完整的测试需求、测试代码、用例、结果的追溯管理,测试覆盖率、完成度、测试效果不明确。而本系统在全流程数据存储的基础上,可以提供需求测试代码、测试用例、测试结果的双向追溯。
(3)测试用例自动生成
传统系统通常不提供如本发明中所阐述的如此完备的以白盒分析为基础的测试用例自动生成功能,通常只有测试用例的自定义和测试用例的执行功能。
(4)测试手段局限
传统技术未提供对整个系统中所有代码、分支的充分性测试,只有功能性测试,这会导致大量的代码未进行充分的测试,甚至被遗漏。
发明内容
本发明的目的旨在至少解决所述技术缺陷之一。
为此,本发明的目的在于提出一种基于白盒分析的测试用例自动生成和测试进程管理方法。
为了实现上述目的,本发明的实施例提供一种基于白盒分析的测试用例自动生成和测试进程管理方法,包括如下步骤:
步骤S1,配置测试环境,分析并显示用户代码结构;
步骤S2,对用户代码进行白盒静态分析,获取白盒分析结果;
步骤S3,以白盒分析结果为基础进行测试进程管理,包括:获取用户的测试需求,根据所述测试需求设计测试进程和对应的测试用例,对自动生成和客户自定义的测试用例进行管理,以便于用户调用执行、查看、回归和双向追溯;
步骤S4,以白盒分析结果为基础进行动态测试,包括:充分性测试、覆盖率测试、功能测试、时间性能测试、变量动态分析、动态内存分析,然后生成动态测试报告;
步骤S5,以白盒分析结果为基础将测试用例进行执行,得出测试结果和函数调用关系图中各个节点的的覆盖情况。
进一步,在所述步骤S3中,根据白盒分析结果,自动生成测试用例,包括如下步骤:
在白盒分析结果的基础上,具有独立的测试用例生成模块,基于对被测代码静态分析的完整数据库,实现测试用例的自动生成和管理。
进一步,创建测试用例,自动根据白盒分析结果和用户选择的代码函数调用关系图节点分析出白盒信息,所述白盒信息包括:该调用关系中各个函数的关系、与该函数调用关系直接相关的变量、变量的取值范围。
进一步,在所述步骤S4中,所述充分性测试包括:
(1)逻辑充分性测试:在对被测试软件进行静态分析的基础上得出被测试系统的所有逻辑关系,并自动在该基础上生成覆盖所有逻辑关系的测试用例并自动执行;
(2)数据充分性测试:在对被测试软件进行静态分析的基础上得出被测系统的所有数据情况,并自动在该基础上生成可以覆盖所有测试数据的测试用例并自动执行。
进一步,在所述步骤S4中,所述覆盖率测试包括测试用例对测试需求的的覆盖程度和对被测试代码的覆盖程度,其中,覆盖率测试支持语句覆盖分析、分支覆盖分析、MCDC覆盖分析;
所述功能测试包括以程序的应用功能为需求,自动生成测试用例,加载运行取得测试结果。
进一步,所述动态测试包括:支持边界测试、过程接口测试、功能测试。
进一步,在所述步骤S4中,
所述时间性能测试包括:统计所有函数的执行时间,执行次数,最大执行时间、最小执行时间、平均执行时间;统计任意两点之间的执行时间,执行次数,最大执行时间、最小执行时间、平均执行时间;统计函数的执行时间及占用系统时间的比例;统计函数运行的平均时间及最长时间;统计函数的调用次数。
进一步,在所述步骤S4中,
所述变量动态分析包括:对测试过程中对全局变量变化过程的监控和记录;
所述动态内存分析包括:监测动态内存分配中存在的缺陷。
进一步,所述动态内存分析包括:统计动态内存分配点、统计动态内存释放点、计算动态内存的分配和释放情况汇总。
进一步,在所述步骤S5中,对测试进程、测试用例执行结果、测试用例具体输入输出信息、测试用例执行统计信息、测试进程管理总表进行管理,对自动生成和客户自定义的测试用例进行管理,方便用户调用执行、查看、回归;可在测试需求等相关文档的基础上,实现测试文档、用例、代码、结果的双向追溯,统计测试覆盖情况。
本发明附加的方面和优点将在下面的描述中部分给出,部分将从下面的描述中变得明显,或通过本发明的实践了解到。
附图说明
本发明的上述和/或附加的方面和优点从结合下面附图对实施例的描述中将变得明显和容易理解,其中:
图1为传统技术的功能测试界面的示意图;
图2为根据本发明实施例的基于白盒分析的测试用例自动生成和测试进程管理方法的流程图;
图3为根据本发明实施例的用户代码结构的示意图;
图4为根据本发明实施例的扇出示意图;
图5为根据本发明实施例的代码执行路径分析的示意图;
图6为根据本发明实施例的不可达代码标识的示意图;
图7为根据本发明实施例的内存溢出的示意图;
图8为根据本发明实施例的函数调用关系的示意图;
图9为根据本发明实施例的函数调用关系的界面图;
图10为根据本发明实施例的函数被调用关系的示意图;
图11为根据本发明实施例的代码控制流程图;
图12为根据本发明实施例的白盒分析的示意图;
图13为根据本发明实施例的选择要创建测试进程的函数调用节点的示意图;
图14为根据本发明实施例的生成测试路径的示意图;
图15为根据本发明实施例的测试用例自动生成的示意图;
图16为根据本发明实施例的白盒分析结果的示意图;
图17为根据本发明实施例的测试需求管理的界面图;
图18为根据本发明实施例的测试需求描述的界面图;
图19为根据本发明实施例的选择关联测试进程的界面图;
图20为根据本发明实施例的测试用例管理的界面图;
图21为根据本发明实施例的测试进程管理的界面图;
图22为根据本发明实施例的图形化关联界面图;
图23为根据本发明实施例的覆盖率测试的界面图;
图24为根据本发明实施例的功能测试的界面图;
图25为根据本发明实施例的性能测试的界面图;
图26为根据本发明实施例的测试进程管理的界面图;
图27为根据本发明实施例的测试用例执行结果的统计示意图;
图28为根据本发明实施例的测试用例具体输入输出信息的示意图;
图29为根据本发明实施例的测试用例执行统计信息的示意图;
图30为根据本发明实施例的测试进程管理总表的界面图。
具体实施方式
下面详细描述本发明的实施例,所述实施例的示例在附图中示出,其中自始至终相同或类似的标号表示相同或类似的元件或具有相同或类似功能的元件。下面通过参考附图描述的实施例是示例性的,旨在用于解释本发明,而不能理解为对本发明的限制。
近年来,我国航天事业飞速发展,在轨卫星数量已经超过140颗,并承接越来越多国外的卫星研制及发射订单,承担单位呈现出任务重、立项型号多、个性化差异大及工期紧的显著特点。
在多年卫星地面仿真系统测试、研发项目经验积累的基础上,自主研发了嵌入式集成仿真测试环境。系统为卫星的研发、监控、测试提供一套基于可视化工具的,灵活、通用、系统化与可扩展的卫星地面仿真系统,支持仿真环境的快速搭建、支持全数字和半物理仿真,支持实时和超实时仿真。全面满足卫星研制地面仿真模拟及测试需要,大幅度的提升各型号卫星项目的研发周期和生产周期;全面支持卫星地面监控和问题跟踪处理,为保证上天卫星的在轨正常运行提供有效的技术支撑。
基于以上需求,为了支撑用户系统的测试,本发明提出一种基于白盒分析的测试用例自动生成和测试进程管理方法,在进行CPU和外部设备仿真的基础上为用户提供了测试用例自动生成和进程管理功能,该功能是以系统对于加载的用户测试代码的白盒分析为基础。
如图2所示,本发明实施例的基于白盒分析的测试用例自动生成和测试进程管理方法,包括如下步骤:
步骤S1,配置测试环境,分析并显示用户代码结构。
具体的,在本步骤中,通过工具进行工程的配置,在此过程中会配置系统采用的CPU(ERC32、1750等)和加载的用户代码,配置完成后,系统可以加载并显示用户代码。
在此过程中,系统会分析用户代码结构,包含项目中所有的.c文件、c++文件、.h文件等文件,包含每个文件中的所有函数,通过树形结构显示用户代码结构,如图3所示。通过图3所示的界面,可以查看用户的代码结构和每个文件的代码信息。
步骤S2,对用户代码进行白盒静态分析,获取白盒分析结果。
在本步骤中,自动对用户代码进行白盒分析,白盒静态分析是在程序不执行的状态下,通过对被检测软件进行建模,发现满足所有可能执行状态的软件属性,再通过对事先预定的规则库的分析来检测软件中的错误漏洞。
本发明提供静态的白盒分析结果,包括用户被测试系统的代码结构、函数调用关系、扇入扇出、度量元信息等白盒分析结果;被测系统的哪些路径及函数进行测试;每个测试路径具体的测试用例内容;每个测试用例的具体输入输出、执行结果等信息。
静态分析是在代码通过编译之后再对代码进行分析。静态分析工具相比编译器,对代码进行了更加严格的检查,像数组越界访问、内存泄漏、使用不当的类型转换等问题,都可以通过静态分析工具检查出来,甚至可以在分析工具的分析标准里定义代码的编写规范,在检测到不符合编写规范的代码时抛出告警,这些功能都是编译器没有的。静态分析可以从软件的编程规则,静态特征等多个方面,量化地定义质量模型,并检查、评估软件质量。贯穿于软件开发、代码评审、单元/集成测试、系统测试、以及软件维护阶段。它面向源代码进行工作。针对编码、测试和维护。
在各个阶段,采用白盒分析可以实现改进软件工程的实践,训练程序员编写良好的代码和测试活动,确保系统易于维护,减少风险。本发明可定期地检查整个软件的质量。
在本发明的实施例中,通过加载软件代码进行静态分析,提供以下静态分析结果:
1、编码规则检查
能检查编码规格的符合性,也能根据要求定制规则、注释行数及比例、代码可达性。支持自定义规则、自定义编码规则规则集和MISRA C编码规范检查。
2、度量元分析
显示扇入扇出、注释率、函数个数、代码行数、圈复杂度。
2.1、扇入扇出
(1)扇出
模块的扇出是指模块的直属下层模块的个数,如图4所示。一般认为,设计得好的系统平均扇出是3或4。一个模块的扇出数过大或过小都不理想,过大比过小更严重。一般认为扇出的上限不超过7。扇出过大意味着管理模块过于复杂,需要控制和协调过多的下级。解决的办法是适当增加中间层次。
(2)扇入
一个模块的扇入是指有多少个上级模块调用它。扇人越大,表示该模块被更多的上级模块共享。这当然是所希望的。但是不能为了获得高扇人而不惜代价,例如把彼此无关的功能凑在一起构成一个模块,虽然扇人数高了,但这样的模块内聚程度必然低。这是应避免的。对于设计得好的系统,上层模块有较高的扇出,下层模块有较高的扇人。其结构图像清真寺的塔,上面尖,中间宽,下面小。
基于以上原因,程序的扇入扇出情况是重要的静态分析结果之一,可以为程序的编写人员提供代码质量的重要辅助衡量信息,参考表1所示。
函数 | 扇入 | 扇出 |
Main | 0 | 3 |
Test1 | 2 | 3 |
Test2 | 4 | 2 |
Test3 | 3 | 5 |
End | 2 | 0 |
表1
2.2 Line代码行数(LinesofCode)
代码行数是通过计算执行的代码行数来量度软件块的大小。虽然和上面的特征一样,这个值也是越低越好。这是由于以更少的代码完成功能就能减少考虑的时长。
1、不是每行代码都相等。有些行是非常简单,有些却非常复杂,会花费数小时来计算。
2、不计算已删除或已覆盖的代码。
3、有时将一行复杂的代码分割成几行会令它更容易理解;在这样的情况下,增加了代码行但更容易维护。
4、除非设计完善并彻底测试过,而且已成型的所有代码是出自你本人,否则代码行数不会精确反映投入软件中的努力的量。
2.3注释率分析:
在统计代码行数的基础上,通过分析代码的注释率,判断代码的可读性,有效的提高程序的健壮性。
2.4可维护指数(MaintainabilityIndex):
最后是可维护指数,范围是0到100,用来指示所有类,成员,命名空间或项目的可维护性.事实上,它是一个之前所有度量值的合计值,但它也同时包含一些额外的度量值,像霍尔斯特德量(HalsteadVolume),该值用来量度程序的总长度和词汇数.与之前的度量值不同,这个值是越高越好。
2.5 McCabe复杂度:
圈复杂度(CyclomaticComplexity)是一种代码复杂度的衡量标准。它可以用来衡量一个模块判定结构的复杂程度,数量上表现为独立现行路径条数,也可理解为覆盖所有的可能情况最少使用的测试用例数。圈复杂度大说明程序代码的判断逻辑复杂,可能质量低且难于测试和维护。程序的可能错误和高的圈复杂度有着很大关系。
圈复杂度度量的是程序中线性独立路径的数量;例如:如果程序中不包含控制、判断、条件语句(例如if,swith等),那么复杂度就是1;因为整个程序只有一条执行路径;如果程序包含一条IF语句,那么就会有两条路径来执行完整个程序(IF为TRUE,IF为FALSE),所以这时候的复杂度就是2;两个嵌套的IF语句,或者包含两个判断条件的一个IF语句,复杂度就是4。
圈复杂度主要与分支语句(if、else、,switch等)的个数成正相关。可以在图1中看到常用到的几种语句的控制流图(表示程序执行流程的有向图)。当一段代码中含有较多的分支语句,其逻辑复杂程度就会增加。
在计算圈复杂度时,通过程序控制流图方便的计算出来,使用的计算公式是V(G)=e–n+2,e代表在控制流图中的边的数量(对应代码中顺序结构的部分),n代表在控制流图中的节点数量,包括起点和终点。所有终点只计算一次,即便有多个return或者throw;节点对应代码中的分支语句。
2.6 Halstead复杂度分析:
Halstead复杂度是以程序中出现的运算符和运算元为计数对象,以它们出现的次数作为计数目标(直接测量指标),然后据以计算出程序容量、工作量。
3、执行路径分析
代码执行路径分析、不可达代码标识。
3.1、代码执行路径分析,如图5所示。
3.2、不可达代码标识,如图6所示。
4、内存溢出、数组
4.1、内存溢出
内存溢出是指应用系统中存在无法回收的内存或使用的内存过多,最终使得程序运行要用到的内存大于能提供的最大内存,如图7所示。内存溢出可以实现空指针访问、未初始化的指针访问和数组下标溢出检查。
5、指针操作分析,缓冲区溢出静态分析
作为一种重要的编程语言,C语言至今仍被大量应用于开发各种系统软件与应用软件。同其它一些语言一样,C显式地支持指针操作以及动态内存的处理,这大大地提高了语言的表达能力。但是,使用带指针的语言编程是一项容易出错的工作,有可能产生大量的内存错误。又因为有些这样的错误不易重现,难以查找诱发错误的原因,所以内存错误通常很难检测。静态检查(staticchecking)技术是检测软件错误的一种重要技术。它通过直接分析源代码来发现程序中的错误,而不需要实际运行。由于其具有覆盖率较高、能够在早期发现错误和易于使用的优点,因而被大量地应用于软件查错中。
6、函数调用关系图
函数调用关系图可以查看整个程序的调用结构与调用关系,调用图显示过程和函数之间的关系,非常适用于检查应用系统的设计,如图8所示。
函数调用关系图可以实现:在函数调用关系图上单击节点可以显示相应函数的源代码,提供图形化分析显示。
采用函数调用关系图,可以实现本工程分析;加载其他需分析的工程(加载源代码文件、加载预处理文件);通过颜色来将不同进程节点产生的函数调用关系区分开;函数调用关系图和源代码关联显示,可以互动;可以通过鼠标拖动函数调用关系图,选中函数高亮、居中显示,并在右侧显示对应代码;提供函数调用关系图的放大缩小、拖动功能,方便客户观察图形。
(1)函数调用关系图:对用户被测系统的所有文件进行白盒分析,绘制每个文件中各个函数的调用关系图,用户可以明确的了解整个被测试系统的代码层级结构,如图9所示。
(2)函数被调用关系图
对用户被测系统的所有文件进行白盒分析,绘制每个文件中各个函数的被调用关系图,用户可以明确的了解整个被测试系统的代码层级结构,如图10所示。
7、代码控制流程图
控制流图显示算法的逻辑路径。其图形表示适用于评价函数的复杂性,提供图形化分析显示。代码控制流程图,可以显示函数内的控制流关系,如图11所示。
在本发明的实施例中,EIST代码控制流图可以实现:
显示代码控制流图和显示代码时,在旁边单独区域显示所有已定义和全局和局部变量,双击局部变量,可以弹出该局部变量的定义和调用处及相关代码;
分支标红,显示相应参数取值;
代码控制流图和源代码关联显示,可以互动;
可以通过鼠标拖动代码控制流图,选中控制流图节点高亮、居中显示,并在右侧显示对应代码;
提供代码控制流图的放大缩小、拖动功能,方便客户观察图形。
8、数据流分析
数据流分析是一项编译时使用的技术,它能从程序代码中收集程序的语义信息,并通过代数的方法在编译时确定变量的定义和使用。通过数据流分析,可以不必实际运行程序就能够发现程序运行时的行为,这样可以帮助大家理解程序。数据流分析被用于解决编译优化、程序验证、调试、测试、并行、向量化和片行编程环境等问题。
数据流图也称为数据流程图dateflowdiagram,DFD,是一种便于用户理解和分析系统数据流程的图形工具,他摆脱了系统和具体内容,精确的在逻辑上描述系统的功能、输入、输出和数据存储等,是系统逻辑模型的重要组成部分。
数据流分析,能够输出所有函数所使用的、修改的全局变量,IO端口,可以实现以下功能:
数据流分析是用控制流程图来分析数据发生异常现象;数据流分析可以分析初始化的、被赋值的或被引用过程中行为序列的异常;如未初始化的变量,未初始化的指针或引用,数组下标越界等错误。对以前引用的变量或指针再次赋值等异常。统计数据的使用情况,被那些函数使用,被那些函数修改;分析数据的改变,影响到使用此数据的派生变量;分析数据的前向影响分析,哪些数据影响到此数据的变化,以及所占的权重,便于进行测试用例的设计。本发明可以找出引用未定义的变量,对以前引用的变量再次赋值等异常。被测系统中的所有变量。
对用户被测系统的所有文件进行白盒分析,获取所有的变量信息,包括变量名称、变量类型、最大值、最小值和步长,如图12所示。
步骤S3,以白盒分析结果为基础进行测试进程管理,包括:获取用户的测试需求,根据测试需求设计测试进程和对应的测试用例,对自动生成和客户自定义的测试用例进行管理,以便于用户调用执行、查看、回归和双向追溯。
具体的,在本步骤中,基于白盒分析的测试进程创建:
基于以上白盒分析结果,可以为用户提供测试进程创建管理功能,可以通过函数调用关系图或被调用关系图选择要创建测试进程的函数调用节点,选择途中需要测试的函数节点,即被标识为蓝色的函数节点,如图13所示。在系统中选择确认按钮,即可以该条函数调用关系路径为基础生成对应的测试进程,如图14所示。
具体的,根据白盒分析结果,自动生成测试用例,包括如下步骤:
在白盒分析结果的基础上,本发明具有独立的测试用例生成模块,基于对被测代码静态分析的完整数据库,实现测试用例的自动生成和管理。
创建测试用例,自动根据白盒分析结果和用户选择的代码函数调用关系图节点分析出白盒信息,白盒信息包括:该调用关系中各个函数的关系、与该函数调用关系直接相关的变量、变量的取值范围。
如图15所示,基于白盒分析的测试用例自动生成及管理:在程序白盒静态分析的基础上,自动为被测试软件生成测试用例,支持这些测试用例的自动执行、自动测试数据记录等功能,可以大大降低软件测试工作中的重复工作,加快测试过程、规范测试流程、降低测试成本。
路径 | Flag | x | y | z | 结果 |
4-10-19-22-23-29 | 3 | 4 | 4 | 2 | Z=-1 |
7-10-19-22-23-29 | 3 | 2 | 4 | 2 | …… |
7-13-19-22-23-29 | 2 | 2 | 3 | 3 | …… |
7-13-16-22-23-29 | 4 | 1 | 2 | 4 | …… |
7-13-16-22-26-29 | 4 | 1 | -1 | 4 | …… |
…… | …… | …… | …… | …… | …… |
表2
以测试进程为基础,可以创建测试用例,参考图15和表2,自动根据白盒分析结果和用户选择的代码函数调用关系图节点分析出该调用关系中各个函数的关系、与该函数调用关系直接相关的变量、变量的取值范围等白盒信息,如图16所示。
本发明支持为用户提供自动生成该函数调用关系路径下所有测试用例的功能。
本发明支持为用户提供的测试用例输入输出自行配置,根据用户选择的输入变量自动生成测试用例输入,根据用户配置的输出数据观测需求反馈测试结果,最终为用户提供完整的测试用例及执行结果,该执行结果可以直观的反馈到函数调用关系图上,每各函数是否进行了测试,通过哪些测试用例进行了测试,每个测试用例是否通过等。
在本发明的实施例中,本发明可以基于测试需求对测试进程进行管理,如图17所示。在“测试需求管理”界面可以查看数据库中已经创建好的测试需求,另外,点击“新建需求”,可以在本页面输入测试需求的标题、需求概述,并选择要关联的测试进程,如图18所示。点击“关联进程”后,如图19所示。在以上界面,可以选择已经创建好的测试进程,作为与该测试需求关联的测试进程,选择完成后,点击确定。完成测试需求的标题、需求概述的填写,并完成关联测试进程的添加后,点击“保存修改”。确定保存测试需求后,点击“确定”按钮,完成测试需求的创建和保存。
此外,本发明还可以实现测试进程管理,功能主要如下:基于对被测试系统的白盒分析进行测试节点管理、基于函数调用/被调用关系的测试进程创建和测试需求管理。图20为测试用例管理的界面图。图21为测试进程管理的界面图。
此外,本发明还可以对测试结果进行分析,在测试需求、测试规划、测试方案、测试实施阶段主要完成以下功能:支持嵌入式软件全生命周期各阶段文档间建立双向动态关联。
本发明具有独立的测试用例管理模块。对自动生成和客户自定义的测试用例进行管理,方便用户调用执行、查看、回归;可在测试需求等相关文档的基础上,实现测试文档、用例、代码、结果的双向追溯,统计测试覆盖情况。支持嵌入式集成测试各阶段的文档和数据的双向动态关联:测试需求文档与测试设计文档的关联、测试设计文档与源码的关联、源码与测试用例的关联以及各阶段内部文档的关联。实现多个测试进程的统一管理,方便回滚测试,方便多人同时进行测试,同时进行不同测试目的测试。
图形化关联关系显示代码、测试用例、静态分析图、动态运行结果图的关系,如图22所示。
本发明可以实现嵌入式软件全生命周期各阶段文档间的自动双向追溯和定位。支持建立测试需求文档、测试设计文档、源代码、测试用例、测试结果等之间任一点的双向追踪和定位功能。实现嵌入式软件全生命周期各阶段文档和数据的覆盖分析。本发明支持量化地指出各阶段对上一级文档的没有实现的需求和功能,实现嵌入式集成测试各阶段文档和数据的影响分析。本发明支持对嵌入式集成测试各阶段文档和数据中的任何一点的变更,可量化地指出正向和逆向的影响深度和广度以及具体位置。
本发明可以提供分析报表,支持提供测试进程中的影响分析、覆盖分析、追踪分析报表。本工具的进程管理主要完成测试进程创建和管理,在该功能模块下,高级用户可以对这个工程下的进程进行管理,针对不同的测试需求,在该功能模块下创建测试进程。根据测试需求,可分别为语句覆盖、条件覆盖、性能分析、功能测试等创建独立的测试进程,每个进程可以根据用户在程序控制流图中选择的不同区域实现针对该区域生成独立的测试用例,项目实施人员只需根据权限完成高级用户建立好的各个测试进程即可。
步骤S4,以白盒分析结果为基础进行动态测试,包括:充分性测试、覆盖率测试、功能测试、时间性能测试、变量动态分析、动态内存分析,然后生成动态测试报告。
动态测试主要由覆盖率测试、时间性能测试、代码和变量动态跟踪监控等功能。动态测试的代码和数据参数变量值的跟踪监控,在程序动态运行过程中,对所有的运行代码和变量的变化都进行记录,图形化显示参数变量的变化过程。一般跟踪的都是代码,无法反应数据的变化。本工具的测试跟踪功能,同时跟踪和记录代码和数据的变化,完全记录和回放系统的过程。
本步骤可以提供动态的白盒测试结果,包括提供代码测试覆盖率、性能结果、变量动态分析等,协助系统用户管理测试流程、了解测试进度、观测测试结果、提高测试效率。
(1)充分性测试:
充分性测试指测试进行时,不仅完成代码的100%覆盖测试,而且要依据参数变量的实际取值范围以及变量的值域范围,自动生成边界值测试用例,以及覆盖整个值域的测试用例,在系统测试时,能够完全覆盖变量的值域范围的测试,达到变量值域范围的100%覆盖测试。只有达到代码逻辑和数据双重100%覆盖的测试,称之为满足充分性测试。
1)逻辑充分性测试:
在对被测试软件进行静态分析的基础上得出被测试系统的所有逻辑关系,包括分支情况、条件组合等,并自动在该基础上生成可以覆盖所有可能的逻辑关系的测试用例并自动执行,从而达到自动覆盖所有逻辑关系的充分性测试。
2)数据充分性测试:
在对被测试软件进行静态分析的基础上得出被测系统的所有数据情况,包括数据的取值范围、步长,并自动在该基础上生成可以覆盖所有可能的测试数据的测试用例并自动执行,从而达到自动覆盖所有数据可能取值的充分性测试,同时,这种自动生成并执行的流程高效、快速,为完整验证数据提供了最有效的手段。
(2)覆盖率测试
覆盖率是度量测试完整性的一个手段,是测试有效性的一个度量。通过已执行代码表示,用于可靠性、稳定性以及性能的评测。测试覆盖是对测试完全程度的评测。测试覆盖是由测试需求和测试用例的覆盖或已执行代码的覆盖表示的,如图23所示。
覆盖率测试包括对测试需求和测试用例的覆盖程度、已执行代码的覆盖程度。在本发明的实施例中,覆盖率测试支持语句覆盖分析、分支覆盖分析、MCDC覆盖分析。并且,动态测试还支持边界测试、过程接口测试、功能测试。
在动态测试中,本环境可以在函数调用关系图和代码控制流图、源码的基础上直观的向开发或测试人员显示哪些代码未被测试到,有助于工程师设计新的测试用例提高代码测试覆盖率或分析不可达代码,帮助发现隐藏的错误。在函数调用图和代码控制流图中,支持通过颜色来标示显示了哪些节点或代码被执行了,哪些没有被执行。本发明的工具支持在图上单击节点即可显示相应的源代码,查看源码有助于设计合理的测试用例完成相关测试。本环境可以支持将已经执行的测试结果记录下来,随后每增加一个测试用例,对应增加的覆盖率信息都会增量的进行统计。覆盖率测试支持语句覆盖分析、分支覆盖分析、MCDC覆盖分析;支持边界测试、过程接口测试、功能测试。语句覆盖分析的过程,需要在代码框或程序的流程图中选择需要测试的程序代码,根据参数变量的取值范围自动生成测试用例,加载运行,分析所选择的被测代码的正确性。语句覆盖可以是单条语句,可以是多条语句,甚至是全部代码。语句覆盖可以在线选择、加载运行,观测运行过程及结果。分支覆盖分析的过程,在程序的流程图中选择需要测试的分支,根据参数变量的取值条件,自动生成测试用例,加载运行,局部测试分支执行的正确性。分支覆盖可以是单个分支,也可以是多个分支。分支覆盖可以在线选择、加载运行,观测运行过程及结果。MCDC覆盖分析的过程,可以在控制流程图中选择需要测试的路径,根据相应参数变量的取值组合条件,自动生成测试用例,加载运行,观测所选路径的测试结果。路径测试可以使单条路径,也可以是多条路径。路径测试可以在线选择、加载运行,观测运行过程及结果。
(3)功能测试
功能测试包括以程序的应用功能为需求,自动生成测试用例,加载运行取得测试结果。功能测试的过程为,以程序的应用功能为需求,选择某条路径或多条路径,自动生成测试用例,加载运行,取得测试结果。如图24所示,可以在根据功能测试的需求在函数调用关系图上选取需测试功能涉及的函数执行流程。
(4)性能测试
如图25所示,时间性能测试包括:统计所有函数的执行时间,执行次数,最大执行时间、最小执行时间、平均执行时间;统计任意两点之间的执行时间,执行次数,最大执行时间、最小执行时间、平均执行时间;统计函数的执行时间及占用系统时间的比例;统计函数运行的平均时间及最长时间;统计函数的调用次数。
在嵌入式系统中,程序的性能通常是非常重要的。经常会有这样的要求,在特定时间内处理一个中断,或生成具有特定定时要求的一帧。开发人员面临的问题是决定应该对哪一部分代码进行优化来改进性能,常常会花大量的时间去优化那些对性能没有任何影响的代码。性能分析工具会提供有关的数据,说明执行时间是如何消耗的,是什么时候消耗的,以及每个例程所用的时间。根据这些数据,确定哪些例程消耗大部分执行时间,从而可以决定如何优化软件,获得更好的时间性能。对于大多数应用来说,大部分执行时间用在相对少量的代码上,费时的代码估计占所有软件总量的5%~20%。性能分析工具不仅能指出哪些例程花费时间,而且与调试工具联合使用可以引导开发人员查看需要优化的特定函数,性能分析工具还可以引导开发人员发现在系统调用中存在的错误以及程序结构上的缺陷。
本环境可以对被测软件进行时间性能测试,主要实现如下功能:支持统计所有函数的执行时间,执行次数,最大执行时间、最小执行时间、平均执行时间;支持统计任意两点之间的执行时间,执行次数,最大执行时间、最小执行时间、平均执行时间;统计函数的执行时间及占用系统时间的比例;统计函数运行的平均时间及最长时间;统计函数的调用次数,如表3所示。
函数 | 调用次数 | 最大执行时间 | 最小执行时间 | 平均执行时间 | 占比 |
Main.c | 1 | 12765 | 12765 | ||
Test1 | 3 | 2106 | 1855 | 2011 | 47.26% |
Test2 | 2 | 3005 | 2969 | 2984 | 46.75% |
表3(5)变量动态分析
变量动态分析包括:对测试过程中对全局变量变化过程的监控和记录。能够完成测试过程中对全局变量变化过程的监控和记录,能够有效的在测试过程中为测试人员提供全局的监控变量手段,更加直观有效的了解被测试软件在运行过程中的数据变化流程。
(6)动态内存
动态内存分析包括:监测动态内存分配中存在的缺陷。其中,动态内存分析包括:统计动态内存分配点、统计动态内存释放点、计算动态内存的分配和释放情况汇总。在嵌入式系统中,内存约束通常是有限的。内存分析工具用来处理在动态内存分配中存在的缺陷。当动态内存被错误地分配后,通常难以再现,可能导致的失效难以追踪,使用内存分析工具可以避免这类缺陷进入功能测试阶段。目前有两类内存分析工具--软件的和硬件的。基于软件的内存分析工具可能会对代码的性能造成很大影响,从而严重影响实时操作;基于硬件的内存分析工具价格昂贵,而且只能在工具所限定的运行环境中使用。在本发明中,动态内存分析可以统计动态内存分配点、统计动态内存释放点、计算动态内存的分配和释放情况汇总。
(7)动态测试报告生成
本环境提供动态测试报告的自动生成工具,针对动态测试过程中生成的相关测试数据和结果,提供自动生成测试报告功能,用户可以选择性的将各项测试结果生成到测试报告中,测试报告格式可定制。
步骤S5,以白盒分析结果为基础将测试用例进行执行,得出测试结果和函数调用关系图中各个节点的的覆盖情况,对自动生成和客户自定义的测试用例进行管理,方便用户调用执行、查看、回归;可在测试需求等相关文档的基础上,实现测试文档、用例、代码、结果的双向追溯,统计测试覆盖情况。
具体的,对测试进程、测试用例执行结果、测试用例具体输入输出信息、测试用例执行统计信息、测试进程管理总表进行管理。本发明根据白盒分析结果对测试用例执行的支撑。通过虚拟仿真CPU的运行,将测试用例进行执行,得出测试结果,提供测试结果统计情况,提供函数调用关系图中各个节点的的覆盖情况,为用户提供基于白盒分析的测试用例设计测试过程支撑。
图26为测试进程管理的界面图,图27为测试用例执行结果统计界面图,图28为测试用例具体输入输出信息的界面图,图29为测试用例执行统计信息的界面图;图30为测试进程管理总表的界面图。
本发明实施例的基于白盒分析的测试用例自动生成和测试进程管理方法,采用分布式部署,支持整个测试环境的分布式部署,如运行用户代码的仿真CPU、数据库、测试执行可以支持在多台机器上运行,通过TCP/IP进行数据交换。
根据本发明实施例的基于白盒分析的测试用例自动生成和测试进程管理方法,在白盒分析的基础上可以自动生成完备的,覆盖所有代码和分支,覆盖有效测试和无效测试的强大测试用例集,并提供自动执行功能,降低用户测试工作量,提高测试效率。
(1)以白盒分析为基础的测试用例自动生成
在白盒分析的基础上,具有独立的测试用例生成模块,基于对被测代码静态分析的完整数据库,实现测试用例的自动生成和管理。本环境的白盒分析结果完备,且通过数据库进行管理,可追溯。
(2)以测试需求为导向的测试管理
本环境提供以测试需求为导向的测试管理,即具体测试需求是什么,依据此需求设计的测试进程有哪些,每个测试进程由哪些测试用例来实现,每个测试进程或测试用例具体涉及到了哪些用户代码,哪些测试需求已经得到测试,具体测试覆盖率是多少等。
(3)测试管理
具有独立的测试用例管理模块。对自动生成和客户自定义的测试用例进行管理,方便用户调用执行、查看、回归;可在测试需求等相关文档的基础上,实现测试文档、用例、代码、结果的双向追溯,统计测试覆盖情况。
(4)充分性测试
在完备的变量、内存、寄存器分析和测试用例数据库数据的基础上,自动生成测试用例,实现逻辑的充分性和数据的充分性测试。
(5)测试结果与白盒分析结果的追溯
在完成测试用例的执行后,可以明确的追溯用例具体测试的代码或函数是哪些,测试结果如何,哪些代码已经被测试覆盖到。
(6)具有独立的测试用例生成模块,基于对被测代码静态分析的完整数据库,实现测试用例的自动生成和管理。
(7)具有独立的测试进程和用例管理模块。对自动生成和客户自定义的测试用例进行管理,方便用户调用执行、查看、回归;可在测试需求等相关文档的基础上,实现测试文档、用例、代码、结果的双向追溯,统计测试覆盖情况。
(8)在完备的变量、内存、寄存器等信息的白盒分析和测试用例数据库数据的基础上,自动生成测试用例,实现逻辑的充分性和数据的充分性测试。
(9)支持基于函数调用/被调用关系图的测试进程创建。
(10)支持以测试进程管理为基础的测试用例自动生成。
(11)支持测试用例的自动化执行。
(12)支持测试用例结果的自动统计、显示,并可以通过与白盒分析出来的所有图形、数据进行比对,直观的反应测试情况。
(13)支持将测试环境使用过程中的所有相关数据记录到数据库中进行管理,数据完整性强,可追溯。
(14)支持分布式部署,提高系统运行效率。
(15)提供测试用例管理和自动化生成功能,提高用户测试效率。
(16)在每个进程测试过程中,按照时间节点保存有多个测试回归点,可以随时回滚到以前的测试回归点,重新测试,或者开始新的测试进程。实现多个测试进程的统一管理,方便回滚测试,方便多人同时进行测试,同时进行不同测试目的测试。支持建立测试需求文档、测试设计文档、源代码、测试用例、测试结果等之间任一点的双向追踪和定位功能。
本发明针对系统开发人员,可以解决在设计初期的原理验证问题或在真实目标机系统制造出来之前、硬件测试环境无法搭建的情况下为开发人员提供开发验证环境,可有效缩短系统的开发周期,减少开发测试过程中对硬件环境的依赖性,降低开发测试费用,提高嵌入式软件开发和测试的灵活性,并提供灵活高效的测试和验证能力。
针对系统测试人员,虚拟化的测试环境可在硬件不具备的情况下尽早的在模拟环境中进行白盒测试,降低测试环境搭建成本,实现软硬件缺陷隔离,降低白盒测试难度,模拟故障注入,提高测试进度。为测试人员提供监控功能,可全程管理测试数据和仿真数据,提供图形、表格等多种直观监控方式,可根据用户需求保存仿真数据和测试数据。本发明可将全程的测试数据进行图形化显示、文件保存和数据库保存,方便用户查询回看。
针对地面监控人员,在被测系统运行过程中,全程记录系统相关变量、寄存器、内存的数据,并在此数据基础上为地面监控人员提供图形化的观测界面,提供文件保存功能,方便用户进行后续查询回看。
在行业应用方面,本发明在相关行业的应用,可以大大节约科研经费,缩短研发周期,是广大科研技术人员、管理人员的得力辅助。在航天系统仿真、航天测控、卫星轨道仿真、卫星遥感测绘任务规划、卫星通信链路验证、卫星组网、飞行器研发、空间站指挥控制、火箭发射、导弹轨迹模拟、地面站监控、雷达、无人机、舰船、装甲、飞行空管等关键领域,可以提供专业的集成测试环境。
本发明实施例的基于白盒分析的测试用例自动生成和测试进程管理方法,适用于以下场合:
随着数字化时代的到来,大量系统架构复杂、功能日益强大的嵌入式系统正不断进入市场,应用也日趋复杂,这对嵌人式软件的开发技术和测试技术提出了更高的要求。嵌人式系统的复杂性和集成度越来越高,其中的软件部分也开始在整个嵌入式系统中占有越来越多的比例,并经常实现硬件的功能。嵌入式系统的专用程度较高,所以对其可靠性的要求也比较高,为了保证系统的稳定性,避免由于其可能出现的失效而导致灾难性的后果,要求对嵌人式系统,包括嵌入式软件进行严格的测试、确认和验证。
在软件测试周期中,如果不更早地进行白盒测试,将耗费更多的财力和人力。传统的软件测试理论不能直接用于嵌入式软件测试,因此,研究嵌入式软件的测试方法和策略,对于提高开发、测试效率,缩短研发周期,降低成本,提高和改善嵌入式软件的质量有重要意义。
大多数软件测试方法都可以直接或间接地用于嵌入式软件的测试,但是由于操作系统的实时和嵌入式特性,嵌入式软件测试也面临一些特殊的问题。
嵌入式系统在人类生活中发挥着重要的作用,包括飞行控制器这样的控制系统,以及洗衣机这样的家用电器。目前,嵌入式系统中软件的比重越来越大,也越来越复杂,保证嵌入式软件的可靠性正面临严峻的挑战。
本发明可进行被测嵌入式软件的运行、调试及测试工作,可有效缩短系统的开发周期,减少开发测试过程中的人工分析和设计测试用例时间成本,降低开发测试费用,提高嵌入式软件开发和测试的灵活性,并提供灵活高效的测试和验证能力。
在本说明书的描述中,参考术语“一个实施例”、“一些实施例”、“示例”、“具体示例”、或“一些示例”等的描述意指结合该实施例或示例描述的具体特征、结构、材料或者特点包含于本发明的至少一个实施例或示例中。在本说明书中,对上述术语的示意性表述不一定指的是相同的实施例或示例。而且,描述的具体特征、结构、材料或者特点可以在任何的一个或多个实施例或示例中以合适的方式结合。
尽管上面已经示出和描述了本发明的实施例,可以理解的是,上述实施例是示例性的,不能理解为对本发明的限制,本领域的普通技术人员在不脱离本发明的原理和宗旨的情况下在本发明的范围内可以对上述实施例进行变化、修改、替换和变型。本发明的范围由所附权利要求及其等同限定。
Claims (10)
1.一种基于白盒分析的测试用例自动生成和测试进程管理方法,其特征在于,包括:
步骤S1,配置测试环境,分析并显示用户代码结构;
步骤S2,对用户代码进行白盒静态分析,获取白盒分析结果;
步骤S3,以白盒分析结果为基础进行测试进程管理,包括:获取用户的测试需求,根据所述测试需求设计测试进程和对应的测试用例,对自动生成和客户自定义的测试用例进行管理,以便于用户调用执行、查看、回归和双向追溯;
步骤S4,以白盒分析结果为基础进行动态测试,包括:充分性测试、覆盖率测试、功能测试、时间性能测试、变量动态分析、动态内存分析,然后生成动态测试报告;
步骤S5,以白盒分析结果为基础将测试用例进行执行,得出测试结果和函数调用关系图中各个节点的的覆盖情况;
所述步骤S2中,静态的白盒分析结果,包括用户被测试系统的代码结构、函数调用关系、扇入扇出、度量元信息作为白盒分析结果;
对被测系统的路径及函数进行测试,包括每个测试路径具体的测试用例内容和每个测试用例的具体输入输出、执行结果信息;
通过加载软件代码进行静态分析,提供以下静态分析结果:
编码规则检查:检查编码规格的符合性,根据要求定制规则、注释行数及比例、代码可达性,支持自定义规则、自定义编码规则规则集和MISRAC编码规范检查;
度量元分析:扇入扇出、注释率、函数个数、代码行数、圈复杂度;
其中扇出是指模块的直属下层模块的个数,系统平均扇出是3或4;
扇入是指有多少个上级模块调用它;
对于设计得好的系统,上层模块有较高的扇出,下层模块有较高的扇入,结构图为上面尖,中间宽,下面小;
所述代码行数是通过计算执行的代码行数来量度软件块的大小;
所述注释率的分析是在统计代码行数的基础上,通过分析代码的注释率,判断代码的可读性,提高程序的健壮性;
可维护指数:范围是0到100,用来指示所有类,成员,命名空间或项目的可维护性,含一些额外的度量值,用来量度程序的总长度和词汇数;
圈复杂度是一种代码复杂度的衡量标准,用来衡量一个模块判定结构的复杂程度,数量上表现为独立现行路径条数,为覆盖所有的可能情况最少使用的测试用例数;Halstead复杂度分析,以程序中出现的运算符和运算元为计数对象,以它们出现的次数作为计数目标,然后据以计算出程序容量、工作量;
数据流分析:从程序代码中收集程序的语义信息,并通过代数的方法在编译时确定变量的定义和使用;
函数调用关系图:查看整个程序的调用结构与调用关系,调用图显示过程和函数之间的关系,非常适用于检查应用系统的设计。
2.如权利要求1所述基于白盒分析的测试用例自动生成和测试进程管理方法,其特征在于,在所述步骤S3中,根据白盒分析结果,自动生成测试用例,包括如下步骤:
在白盒分析结果的基础上,具有独立的测试用例生成模块,基于对被测代码静态分析的完整数据库,实现测试用例的自动生成和管理。
3.如权利要求2所述基于白盒分析的测试用例自动生成和测试进程管理方法,其特征在于,
创建测试用例,自动根据白盒分析结果和用户选择的代码函数调用关系图节点分析出白盒信息,所述白盒信息包括:该调用关系中各个函数的关系、与该函数调用关系直接相关的变量、变量的取值范围。
4.如权利要求1所述的基于白盒分析的测试用例自动生成和测试进程管理方法,其特征在于,在所述步骤S4中,所述充分性测试包括:
(1)逻辑充分性测试:在对被测试软件进行静态分析的基础上得出被测试系统的所有逻辑关系,并自动在该基础上生成覆盖所有逻辑关系的测试用例并自动执行;
(2)数据充分性测试:在对被测试软件进行静态分析的基础上得出被测系统的所有数据情况,并自动在该基础上生成可以覆盖所有测试数据的测试用例并自动执行。
5.如权利要求1所述的基于白盒分析的测试用例自动生成和测试进程管理方法,其特征在于,在所述步骤S4中,所述覆盖率测试包括测试用例对测试需求的的覆盖程度和对被测试代码的覆盖程度,其中,覆盖率测试支持语句覆盖分析、分支覆盖分析、MCDC覆盖分析;
所述功能测试包括以程序的应用功能为需求,自动生成测试用例,加载运行取得测试结果。
6.如权利要求1所述的基于白盒分析的测试用例自动生成和测试进程管理方法,其特征在于,所述动态测试包括:支持边界测试、过程接口测试、功能测试。
7.如权利要求1所述的基于白盒分析的测试用例自动生成和测试进程管理方法,其特征在于,在所述步骤S4中,
所述时间性能测试包括:统计所有函数的执行时间,执行次数,最大执行时间、最小执行时间、平均执行时间;统计任意两点之间的执行时间,执行次数,最大执行时间、最小执行时间、平均执行时间;统计函数的执行时间及占用系统时间的比例;统计函数运行的平均时间及最长时间;统计函数的调用次数。
8.如权利要求1所述的基于白盒分析的测试用例自动生成和测试进程管理方法,其特征在于,在所述步骤S4中,
所述变量动态分析包括:对测试过程中对全局变量变化过程的监控和记录;
所述动态内存分析包括:监测动态内存分配中存在的缺陷。
9.如权利要求1所述的基于白盒分析的测试用例自动生成和测试进程管理方法,其特征在于,所述动态内存分析包括:统计动态内存分配点、统计动态内存释放点、计算动态内存的分配和释放情况汇总。
10.如权利要求1所述的基于白盒分析的测试用例自动生成和测试进程管理方法,其特征在于,在所述步骤S5中,对测试进程、测试用例执行结果、测试用例具体输入输出信息、测试用例执行统计信息、测试进程管理总表进行管理,对自动生成和客户自定义的测试用例进行管理,方便用户调用执行、查看、回归;可在测试需求相关文档的基础上,实现测试文档、用例、代码、结果的双向追溯,统计测试覆盖情况。
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN201911012761.8A CN110750459B (zh) | 2019-10-23 | 2019-10-23 | 基于白盒分析的测试用例自动生成和测试进程管理方法 |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN201911012761.8A CN110750459B (zh) | 2019-10-23 | 2019-10-23 | 基于白盒分析的测试用例自动生成和测试进程管理方法 |
Publications (2)
Publication Number | Publication Date |
---|---|
CN110750459A CN110750459A (zh) | 2020-02-04 |
CN110750459B true CN110750459B (zh) | 2023-10-20 |
Family
ID=69279559
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
CN201911012761.8A Active CN110750459B (zh) | 2019-10-23 | 2019-10-23 | 基于白盒分析的测试用例自动生成和测试进程管理方法 |
Country Status (1)
Country | Link |
---|---|
CN (1) | CN110750459B (zh) |
Families Citing this family (8)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN111597115A (zh) * | 2020-05-19 | 2020-08-28 | 上海航天计算机技术研究所 | 一种嵌入式操作系统自动化闭环测试系统及测试方法 |
CN113760690A (zh) * | 2020-06-05 | 2021-12-07 | 腾讯科技(深圳)有限公司 | 分析程序接口的方法、装置和计算机设备 |
CN112783765B (zh) * | 2021-01-13 | 2024-02-09 | 北京轩宇信息技术有限公司 | 一种适用于指针的单元测试用例生成方法及装置 |
CN113377683B (zh) * | 2021-08-12 | 2022-01-28 | 神州数码融信软件有限公司 | 软件测试用例的生成方法、系统、设备、终端、介质及应用 |
CN113760771A (zh) * | 2021-09-14 | 2021-12-07 | 中国农业银行股份有限公司 | 集成测试用例的执行方法及装置 |
CN113821210A (zh) * | 2021-09-17 | 2021-12-21 | 中汽创智科技有限公司 | 一种文件解析方法、装置及存储介质 |
CN114510405A (zh) * | 2022-01-28 | 2022-05-17 | 腾讯科技(深圳)有限公司 | 指标数据评估方法、装置、设备、存储介质及程序产品 |
CN117009230B (zh) * | 2023-07-25 | 2024-04-16 | 北京泰策科技有限公司 | 一种基于代码覆盖率评测的精准测试方法及系统 |
Citations (5)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
EP1926021A1 (en) * | 2006-11-27 | 2008-05-28 | Sysopen Digia Oyj | Software test case generation |
CN102419728A (zh) * | 2011-11-01 | 2012-04-18 | 北京邮电大学 | 基于覆盖率量化指标确定软件测试过程充分性的方法 |
CN104077232A (zh) * | 2014-07-21 | 2014-10-01 | 上海零一拼装信息技术有限公司 | 一种基于用例与源码双向追溯的测试装置及方法 |
CN106021113A (zh) * | 2016-05-31 | 2016-10-12 | 浪潮电子信息产业股份有限公司 | 一种精准测试的实现方法 |
CN109522215A (zh) * | 2018-10-12 | 2019-03-26 | 中国铁道科学研究院集团有限公司通信信号研究所 | 铁路信号系统安全苛求软件的自动化测试平台 |
-
2019
- 2019-10-23 CN CN201911012761.8A patent/CN110750459B/zh active Active
Patent Citations (5)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
EP1926021A1 (en) * | 2006-11-27 | 2008-05-28 | Sysopen Digia Oyj | Software test case generation |
CN102419728A (zh) * | 2011-11-01 | 2012-04-18 | 北京邮电大学 | 基于覆盖率量化指标确定软件测试过程充分性的方法 |
CN104077232A (zh) * | 2014-07-21 | 2014-10-01 | 上海零一拼装信息技术有限公司 | 一种基于用例与源码双向追溯的测试装置及方法 |
CN106021113A (zh) * | 2016-05-31 | 2016-10-12 | 浪潮电子信息产业股份有限公司 | 一种精准测试的实现方法 |
CN109522215A (zh) * | 2018-10-12 | 2019-03-26 | 中国铁道科学研究院集团有限公司通信信号研究所 | 铁路信号系统安全苛求软件的自动化测试平台 |
Non-Patent Citations (4)
Title |
---|
冯灵霞等.软件测试技术.西安:西安电子科技大学出版社,2017,(第1版),166-169. * |
刘利强等.嵌入式软件技术.哈尔滨:哈尔滨工程大学出版社,2009,(第1版),49-53. * |
张焕国等.可信计算.武汉:武汉大学出版社,2011,(第1版),274-279. * |
韩炜.可信嵌入式软件开发方法与实践.北京:航空工业出版社,2017,(第1版),159-161. * |
Also Published As
Publication number | Publication date |
---|---|
CN110750459A (zh) | 2020-02-04 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
CN110750459B (zh) | 基于白盒分析的测试用例自动生成和测试进程管理方法 | |
Gouveia et al. | Using HTML5 visualizations in software fault localization | |
Jeanneret et al. | Estimating footprints of model operations | |
US9239773B1 (en) | Method and system for debugging a program that includes declarative code and procedural code | |
CN101739339A (zh) | 一种基于程序动态依赖关系的软件故障定位方法 | |
Nugroho et al. | Assessing uml design metrics for predicting fault-prone classes in a java system | |
Nusrat et al. | How developers optimize virtual reality applications: A study of optimization commits in open source unity projects | |
CN106529304B (zh) | 一种安卓应用并发漏洞检测系统 | |
Virgínio et al. | On the test smells detection: an empirical study on the jnose test accuracy | |
Han et al. | A systematic mapping study of software performance research | |
US20130318499A1 (en) | Test script generation | |
Lumpe et al. | Learning better inspection optimization policies | |
US10579761B1 (en) | Method and system for reconstructing a graph presentation of a previously executed verification test | |
Qian et al. | A embedded software testing process model | |
Long et al. | Mutation-based exploration of a method for verifying concurrent Java components | |
Khatri et al. | Improving the testability of object-oriented software during testing and debugging processes | |
Lutz et al. | Testing tools (software) | |
Li et al. | Automatically generating functional scenarios from SOFL CDFD for specification inspection | |
Granja et al. | Techniques for regression testing: Selecting test case sets taylored to possibly modified functionalities | |
Goodenough et al. | Software quality assurance: Testing and validation | |
Timóteo et al. | Software metrics: A survey | |
Beutner et al. | Checking and Sketching Causes on Temporal Sequences | |
Jalilian et al. | Automatic generation of test cases for error detection using the extended Imperialist Competitive Algorithm | |
Overstreet | Model testing: is it only a special case of software testing? | |
Grabner et al. | Debugging of concurrent processes |
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 |