CN118567971A - 用于测试计算机程序的方法 - Google Patents
用于测试计算机程序的方法 Download PDFInfo
- Publication number
- CN118567971A CN118567971A CN202410213607.1A CN202410213607A CN118567971A CN 118567971 A CN118567971 A CN 118567971A CN 202410213607 A CN202410213607 A CN 202410213607A CN 118567971 A CN118567971 A CN 118567971A
- Authority
- CN
- China
- Prior art keywords
- computer program
- subroutine
- called
- test
- storage location
- 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
Links
Classifications
-
- G—PHYSICS
- G06—COMPUTING OR CALCULATING; COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F11/00—Error detection; Error correction; Monitoring
- G06F11/36—Prevention of errors by analysis, debugging or testing of software
- G06F11/362—Debugging of software
- G06F11/3636—Debugging of software by tracing the execution of the program
- G06F11/364—Debugging of software by tracing the execution of the program tracing values on a bus
-
- G—PHYSICS
- G06—COMPUTING OR CALCULATING; COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F11/00—Error detection; Error correction; Monitoring
- G06F11/36—Prevention of errors by analysis, debugging or testing of software
- G06F11/3668—Testing of software
- G06F11/3672—Test management
- G06F11/3692—Test management for test results analysis
-
- G—PHYSICS
- G06—COMPUTING OR CALCULATING; COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F11/00—Error detection; Error correction; Monitoring
- G06F11/36—Prevention of errors by analysis, debugging or testing of software
- G06F11/3668—Testing of software
- G06F11/3672—Test management
- G06F11/3676—Test management for coverage analysis
-
- G—PHYSICS
- G06—COMPUTING OR CALCULATING; COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F11/00—Error detection; Error correction; Monitoring
- G06F11/36—Prevention of errors by analysis, debugging or testing of software
- G06F11/362—Debugging of software
- G06F11/3636—Debugging of software by tracing the execution of the program
-
- G—PHYSICS
- G06—COMPUTING OR CALCULATING; COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F11/00—Error detection; Error correction; Monitoring
- G06F11/36—Prevention of errors by analysis, debugging or testing of software
- G06F11/3668—Testing of software
- G06F11/3672—Test management
- G06F11/3684—Test management for test design, e.g. generating new test cases
-
- G—PHYSICS
- G06—COMPUTING OR CALCULATING; COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F11/00—Error detection; Error correction; Monitoring
- G06F11/36—Prevention of errors by analysis, debugging or testing of software
- G06F11/3668—Testing of software
- G06F11/3672—Test management
- G06F11/3688—Test 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)
- Debugging And Monitoring (AREA)
Abstract
根据各种实施方式,描述了一种用于测试计算机程序的方法,包括:执行计算机程序直到调用子程序;确定调用堆栈中存储有被调用子程序的返回地址或堆栈基指针的存储位置;将观察点设置到所确定的存储位置上;将断点设置到被调用的子程序的返回命令上;继续执行所述计算机程序;并且如果所设置的观察点由于写入到所述存储位置而在所设置的断点之一之前就已被触发,则指示所述计算机程序有错误。
Description
技术领域
本公开涉及用于测试计算机程序的方法。
背景技术
开发软件应用程序的一个重要组成部分是测试,并且在发现错误的情况下的相应的错误纠正。特别是,应识别并纠正导致应用程序失败的错误。一个重要的方面在此是鉴于如下方面进行测试:重要的存储区域未被无意地(或被攻击者)访问,即:通过内存监控进行测试,例如通过所谓的(内存)消毒器所进行的那样。在常见的桌面和服务器硬件、例如x86上借助于各种消毒器对软件进行的编译和测试是一种针对能够发现诸如心血(Heartbleed)漏洞之类的以前很长一段时间未被检测到的错误的措施。
特别是对于嵌入式系统上的计算机程序,例如通常与安全相关的车辆控制装置而言,全面的测试(还包括此类内存监控)尤为重要。然而,用于桌面和服务器硬件的消毒器不能用于此类系统,或者只能很差地用于此类系统,因为嵌入式系统通常具有有限的资源,而此类消毒器的资源需求很大,因此不能被使用,或者甚至可能影响计算机程序运行,使得错误会首先发生。
因此,期望一种用于测试能够进行内存监控并且适合于嵌入式系统的计算机程序的方法。
发明内容
根据各种实施方式,提供了一种用于测试计算机程序的方法,包括:执行计算机程序直至调用子程序;确定调用堆栈中存储有被调用子程序的返回地址或堆栈基指针的存储位置(Speicherstelle);将观察点(Watchpoints)设置到所确定的存储位置上,将断点(Breakpoints)设置到被调用的子程序的返回命令上,继续执行计算机程序,并且如果所设置的观察点由于写入到该存储位置而在所设置的断点之一之前就已被触发,则指示计算机程序有错误。
上述方法使得能够借助调试器在嵌入式系统上通过内存监视器进行测试(即,使用消毒器)。这在使用模糊测试进行测试的情况下特别适用,因为模糊测试也可以以调试器控制的方式实现,并且可以以这种方式有效地用于嵌入式系统。
消毒器可以使用代码插装来实现。然而,为此,要么需要源代码可用,要么需要基于二进制文件的特定于指令集的插装(二进制插装),这是非常容易受到攻击的。基于仿真器(Emulator)的替代式插装也是非常平台特定的,并且每个嵌入式平台都需要自己的仿真器。上述方法使得能够使用调试器控制的消毒器进行测试,并且不需要插装或仿真,并且因此可应用于许多情况。
需要注意的是,对于返回地址和栈基指针都可以执行上述操作,即,可以通过上述方式监控这两个存储位置以调用子程序。
下面给出各种示例性实施例。
实施例1是如上所述的用于测试计算机程序的方法。
实施例2是根据实施例1的方法,包括:通过如下方式确定所述存储位置:在用于调用所述子程序的命令处停止所述计算机程序的执行并逐步执行实现用于调用所述子程序的命令(Instruktion)的机器指令(Befehl)直到到达存储所述返回地址或堆栈基指针的机器指令,以及根据所述机器命令确定所述存储位置。
子程序的调用通常包括多个机器指令。这些机器指令依次执行,直到到达存储返回地址或堆栈基指针的指令。然后可以根据该指令确定存储位置。可以通过将断点设置到用于调用的指令上来停止所述执行。
实施例3是根据实施例1或2的方法,包括:在嵌入式系统上执行计算机程序并通过连接到嵌入式系统的测试系统设置观察点和断点。
根据各种实施方式,特别是使得在嵌入式系统本身上测试用于嵌入式系统的计算机程序(包括内存监控)成为可能。
实施例4是根据实施例1至3之一的方法,包括:选择子程序的集合,并且对于所选择的集合中的每个子程序:执行计算机程序直到该子程序被调用,确定调用堆栈中存储有被调用子程序的返回地址或堆栈基指针的存储位置,将观察点设置到所确定的存储位置上,将断点设置到被调用的子程序的返回命令上,继续执行计算机程序并且在所设置的观察点由于写入到该存储位置而在所设置的断点之一之前就已被触发的情况下指示计算机程序有错误。
因此,可以监控子程序的集合是否可能覆盖其返回地址或其堆栈基指针。例如,所选择的集合是在另一个(“上级”)子程序中所调用的子程序(或至少其中一部分)。
实施例5是根据实施例4的方法,包括:将断点设置到所选择的子程序集合的子程序上。
因此,当调用子程序时自动停止所述执行,从而于是可以容易地确定其中存储被调用的子程序的返回地址或堆栈基指针的调用堆栈的存储位置。
实施例6是根据实施例1至5之一的方法,包括:通过用多个测试用例(例如通过测试系统)进行模糊测试来测试计算机程序(例如在嵌入式系统上),其中每个测试用例指定子程序的相应集合,并且对于针对测试用例所指定的集合中的每个子程序包括:执行计算机程序直到调用该子程序;确定调用堆栈中存储有被调用的子程序的返回地址或堆栈基指针的存储位置;将观察点设置到所确定的存储位置上;将断点设置到被调用的子程序的返回命令上;继续执行计算机程序,并且在所设置的观察点由于写入到该存储位置而在所设置的断点之一之前就已被触发的情况下指示计算机程序有错误。
因此,内存监控可以成为模糊测试的一部分,其中模糊器可以选择受监控的子程序。由此,即使是在其上执行计算机程序的(例如嵌入式的)系统上只有一定数量的断点和观察点可用的情况下,也能够发现鉴于针对计算机程序的许多不同输入和计算机程序的子程序的返回地址或堆栈基指针的覆盖方面的错误。
实施例7是根据实施例1至6之一的方法,包括:当所设置的断点之一被触发时删除观察点。
于是,观察点的触发只能在断点之一的触发之前发生,并且因此可以被解释为错误而无需进一步检查。
实施例8是根据实施例1至7之一的方法,其中该计算机程序是用于机器人设备的控制程序并且取决于测试计算机程序的结果利用计算机程序来控制机器人设备。
换句话说,可以提供一种用于控制机器人设备的方法,其中通过使用消毒器进行测试来确保针对返回地址和/或堆栈基址指针的覆盖方面的安全性。
实施例9是一种测试装置,其被设置为执行根据实施例1至8之一的方法。
实施例10是一种计算机程序,其具有指令,当由处理器执行这些指令时,这些指令使处理器执行根据实施例1至8之一所述的方法。
实施例11是一种存储指令的计算机可读介质,当由处理器执行这些指令时,这些指令使处理器执行根据实施例1至8之一所述的方法。
附图说明
在附图中,类似的附图标记通常指代整体不同视图中的相同部分。附图不一定是按比例的,而是通常将重点放在表示本发明的原理上。在下面的描述中,参考以下附图描述各个方面。
图1示出了用于开发和/或测试软件应用程序的计算机。
图2示出了表示根据一种实施方式的用于测试计算机程序的方法的流程图。
以下详细描述涉及到的附图为了解释的目的而示出了可以在其中实施本发明的本公开的具体细节和方面。可以使用其他方面并且可以执行结构上、逻辑上和电气上的改变,而并不脱离本发明的保护范围。本公开的各个方面不一定是相互排斥的,因为本公开的一些方面可以与本公开的一个或多个其他方面组合以形成新的方面。
下面更详细地描述各种示例。
具体实施方式
图1示出了用于开发和/或测试软件应用程序的计算机100。
计算机100具有CPU(中央处理单元)101和工作存储器(RAM)102。工作存储器102用于例如从硬盘103加载程序代码,并且CPU 101执行该程序代码。
在该示例中假设:用户意图使用计算机100来开发和/或测试软件应用程序。
为此,用户在CPU 101上运行软件开发环境104。
软件开发环境104使得用户能够开发和测试用于各种设备106、即目标硬件、诸如用于控制机器人设备(包括机器人手臂和自主车辆)或用于移动(通信)设备的嵌入式系统的应用程序105。为此目的,CPU 101可以运行仿真器作为软件开发环境104的一部分,以模拟(simulieren)为其开发或已开发了应用程序的相应设备106的行为。如果其仅用于测试来自另一来源的软件,则软件开发环境104也可以被视为或设计为软件测试环境。
用户可以通过通信网络107将完成的应用程序分发到相应的设备106。代替经由通信网络107,这还可以以另一种方式来进行,例如使用USB棒。
然而,在此发生之前,用户应该测试应用程序105以避免将运行不正常的应用程序分发到设备106。
一种测试方法是所谓的模糊测试。模糊测试或Fuzz测试(模糊测试)是一种自动化软件测试方法,其中,无效的、意外的或随机的数据作为输入而被输送到要测试的计算机程序。然后鉴于异常,例如崩溃、缺失失败的内置代码断言或潜在的内存泄漏方面来监控该程序。
通常,模糊器(即使用模糊测试的测试程序)用于测试处理结构化输入的程序。该结构例如是在文件格式或文件格式或协议方面被指定的并区分有效和无效输入。有效的模糊器会产生半有效的输入,这些输入是“足够有效”的,以便不会被被待测试程序的输入解析器直接拒绝,但又是“足够无效”的,以便揭示出在待测试程序中未被正确处理的意外行为方式和边缘情况。
下面描述了模糊测试的上下文中使用的术语:
·模糊测试或Fuzz测试是将随机生成的输入发送到目标程序(待测试程序)并观察其响应的自动化测试过程。
·模糊器或模糊引擎是自动生成输入的程序。因此,它不会链接到待测试软件,也不会执行插装(Instrumentierung)。但是,它具有插装代码、生成测试用例和执行待测试程序的能力。著名的例子是afl和libfuzzer。
·模糊测试目标是应通过模糊测试所测试的软件程序或函数。模糊测试目标的一个主要特征应该在于,所述模糊测试目标潜在地接受了(annehmen)模糊器在模糊测试过程期间所生成的不可信输入。
·模糊测试(Fuzz-Test)是模糊器和模糊测试目标(Fuzz-Target)的组合版本。于是,模糊测试目标可以是经插装的代码,在所述经插装的代码的情况下,模糊器链接到(即提供)其输入。模糊测试是可执行的。模糊器还可以启动、观察和停止多个模糊测试(通常每秒数百或数千个),其中,每个模糊测试所使用的由模糊器生成的输入都略有不同。
·测试用例是来自模糊测试的特定输入和特定测试轮次。通常,对于可重现性而言感兴趣的过程(发现新的代码路径或崩溃)被存储。通过这种方式,利用相应输入的特定测试用例也可以在未连接到模糊器的模糊测试目标、例如程序的发布版本上执行。
·覆盖引导的模糊测试(英文:coverage-guided fuzzing)使用代码覆盖率信息作为模糊测试期间的反馈,以识别出输入是否导致了执行新的代码路径或块。
·基于生成的模糊测试(英文:generation-based fuzzing)使用关于目标程序(模糊测试目标)的先验知识来创建测试输入。针对这种先验知识(Vorwissen)的一个例子是与模糊测试目标的输入规范相符的语法,即模糊测试目标(即待测试程序)的输入语法。
·静态插装是将命令插入到(待测试)程序中以获得关于所述执行的反馈。它通常由编译器实现,并且例如可以说明在所述执行期间所到达的代码块。
·动态插装是在运行时间期间对(待测试)程序的执行的控制,以便从执行中生成反馈。其通常通过操作系统的系统功能性或通过使用仿真器来实现。
·调试器是一种设备或程序,其可以控制目标设备或目标程序并且可以提供多个函数,例如用于调用寄存器或内存值以及在各个步骤中暂停和执行目标程序。
·通过调试器对目标程序或设备的指令设置断点,以便在到达时停止所述执行并将此情况通知待控制进程。
·通过调试器将数据观察点设置为目标程序或目标设备的存储地址,以便在访问该存储地址时停止所述执行,并通过触发中断将此情况通知待控制进程。
嵌入式系统通常具有一个微控制器,用于处理输入并以输出进行响应以履行特定任务。尽管微控制器使用与常规用户程序相同的存储模型并使用相同的编程语言进行编程,但它们的程序测试起来要困难得多。为了实现调试,微控制器通常提供使用断点(停止点)中断程序、在各个步骤中运行程序指令以及在存储地址上设置观察点的可能性。当访问相应的存储区域时,观察点会触发中断。硬件断点和观察点通常作为微控制器的调试单元中的物理寄存器实现,因此它们的数量是有限的并且取决于相应的系统。例如,典型的微控制器的最大数量是四个断点和两个数据观察点。通常观察点可以区分读访问和写访问。
特别是,断点和观察点可用于实现调试器驱动的模糊测试,从而不需要任何插装。
模糊测试也称为调试器驱动的模糊测试,可以非常有效地查找触发可观察行为(例如崩溃或重新启动)的错误。但是,无法观察到所有类型的错误,因为程序会默默地失败。一个例子是心血漏洞。心血漏洞的本质在于,它只读取超出数组边界的内容,而写入操作会导致容易观察到的分段错误。
心血漏洞只有在Address Sanitizer(地址消毒器)(ASan)的帮助下才被发现。ASan在程序编译期间插入额外的指令、元数据和检查,以防止存储损坏中的错误。当程序中有此类消毒指令可用时,与没有消毒器相比,在调试程序时可以发现更多错误。特别是,在待测试程序(即模糊测试目标)中设有消毒器以发现附加错误的情况下,诸如模糊测试之类的自动化测试就会出色地发挥作用。
对于嵌入式系统,例如具有ARM架构的数据处理设备,此类消毒器不如标准平台(例如x86平台)那么易于使用。对此存在多种原因:
·嵌入式系统对于实现消毒器而言是资源有限的。例如,Asan需要两倍的内存,MSan(MemorySanitizer(内存消毒器))需要2.5倍的资源,并且UBSan(UndefinedBehaviorSanitizer(未定义行为消毒器))甚至需要三倍的程序工作内存。
·消毒器会增大经编译的二进制文件的大小。在汽车行业中,此类二进制文件的大小通常接近目标硬件的可用闪存。因此,消毒器的附加插装不适配于闪存。
·由于消毒器的附加插装以及元数据的收集和跟踪,消毒器的使用会导致相应硬件上二进制程序的运行时间较慢。嵌入式系统严重依赖于异步事件,例如:中断,并且使得消毒器可能会导致基于时间的误报错误,即消毒器可能会在运行时期间引入新的错误。
·嵌入式系统通常没有用于显示运行时错误的用户界面。例如,在x86系统上,分段错误会被传递到STDERR,从而使用户看到该崩溃。另一方面,嵌入式系统会默默地失败,即用户不会注意到,并在崩溃后重新启动。
根据各种实施方式,因此提供了一种处理方式,其使得能够将内存监控(即,消毒器功能)用于嵌入式系统,特别是使得内存监控可以用于调试器驱动的模糊测试。在此,内存监控本身可以在调试器(或用于模糊测试的调试器)的帮助下实现。
在基于调试器的模糊测试中,执行测试的系统(例如,对应于计算机100)和目标系统(目标硬件,例如嵌入式系统,例如目标设备106)之间的交互通过调试连接(即,调试接口)来进行,其中所述调试连接例如由专用调试器硬件设备提供。测试输入数据以输入向量的形式传输到目标系统106,例如经由WiFi或CAN总线(取决于目标设备106的类型),即通信网络107在所述测试中是这样的调试连接(当分发被测试软件时,通信网络于是可以是任何其他通信网络)。执行该测试的系统,以下也称为测试系统100,通过调试连接控制目标系统中目标程序(即,待测试程序)的执行,即开始所述执行和在中断(特别是由数据观察点所触发的中断)之后恢复所述执行。
调试器驱动的消毒器不需要插装或仿真,而是只需要具有设置断点和观察点的可能性的到目标系统(例如在其上执行所述软件的嵌入式系统)的调试接口。所述类型的调试接口和调试能力是通用的并且进一步可用,从而导致下面描述的处理方式的广泛且容易的适用性。此外,目标系统的存储器只有很小的负载,例如对于元数据,因为与消毒器相关的大多信息都被收集并存储在调试器的主机侧(即,在测试系统100中)。目标程序的经编译的二进制文件的大小没有被增加,因为它就像是其针对目标系统106对于使用所规定的那样可以在测试中被使用。
当到达断点时,调试器会停止目标系统。因此,下面描述的处理方式仅在极少数情况下导致基于时间的误警报。这些误警报也可以通过其他测试技术来消除,例如通过随后验证目标系统上发现的错误。使用调试器还可以提供对目标系统的内部结构的清楚了解。
下面描述的处理方式用于内存监控,即,检测出待测试程序对存储器区域的不期望的写入或读取。计算机程序由作用于内存的指令组成。为了避免无意地并发使用存储空间,通常将存储器分为不同的区域,即堆栈、堆和静态内存。
堆栈(其中,这里指的是调用堆栈(即调用栈,英文call stack或者procedurestack))是一个不断增长的存储区域,所述存储区域针对子程序的局部变量而给所述子程序提供空间。每个函数在堆栈上都有自己的存储区域。堆栈存储器是通过减少堆栈指针(连续内存)来分配的。通过减少堆栈基指针和堆栈指针来分派针对被调用函数的堆栈帧
在C中,例如通过调用函数malloc、realloc或calloc来给堆内存的存储区域分派所需的内存大小,并使用free函数再次释放所分派的存储区域,并可以在后续的分派请求中对其再次使用。堆内存通常被用于在不同函数之间共享的长期变量。
为了正确执行程序,重要的是:不超过所分派的内存的边界。确保在例如C、C++这样的内存不安全的语言中的正确内存访问是程序员的责任。忽视所分派内存的边界可能会导致严重的安全意外事件,例如:用于远程代码执行或数据泄露。
根据一个实施例,为了识别出堆栈溢出,特别是子程序(函数、方法或过程)的返回地址的危险覆盖,使用观察点来监控相应的存储位置,即堆栈的存储返回地址的存储位置。在下文中,观察点指的是写入观察点,即在写入存储位置时(但不一定在读取时)触发的观察点,因为应该确定出覆盖。但是,可以使用如下观察点,所述观察点在写入和读取时被触发并且当其被触发时被检查:是否写入实际上是该原因。存储位置存储具有取决于相应架构(例如,32位)的字长的字,并且由相应的地址来标识。
下面假设:测试系统100(可能根据用户输入)选择一个或多个子程序,从此出发,所有后续方法都受到保护。测试系统100对每个所选择的子程序执行以下操作:
1.将断点(即停止点)设置到所选子程序中的全部子程序调用指令(即“call”指令)(或所选部分)上。
2.启动所选择的子程序。
3.如果(由于所设置的断点之一)发生中断,则逐步向前执行,直到当前堆栈帧(即其断点预料了所述中断的用于调用的堆栈帧)被存储在该堆栈上(这可以取决于架构约定通过进行调用的子程序或被调用的子程序来完成)。
4.将写入观察点设置到所存储的返回地址(即最接近当前堆栈边界的返回地址)上。
5.将断点设置到被调用子程序的每个返回指令(即“return”命令)上。
6.如果在到达被调用子程序的返回指令之前触发写入观察点,则可能发生:返回地址被无意覆盖。在这种情况下,测试系统100因此指示发生了错误,这又可以触发安全措施的执行。
替代地,如果没有观察点可用的话(例如,因为只有有限数量可用并且它们已被用于其他返回地址),则也可以在到达返回指令之前检查所存储的返回地址。由于嵌入式系统上的断点和观察点的数量可能是有限的,因此可能并非所有被调用的子程序都能够以上述方式被测试。如果是这种情况,则被测试的子程序调用的子集例如被随机选择,或者这些子程序调用在目标程序的多次运行中被相继测试。
另外,不仅可以以这种方式来保护返回地址,还可以例如保护被调用子程序的堆栈基指针(Stack BasePointer)。该堆栈基指针也存储在堆栈上。表格1示出了针对被调用子程序的堆栈帧的典型结构。每行表示一个存储位置。
表格1
总体而言,根据不同实施方式提供了如图2所示的方法。
图2示出了流程图200,其表示根据一种实施方式的用于测试计算机程序的方法。
在201中,执行(待测试)计算机程序,直至调用子程序。
在202中,确定调用堆栈的存储位置(例如,执行计算机程序的系统的存储器中的对应地址),在所述存储位置中存储被调用子程序的返回地址或堆栈基指针。
在203中,将观察点设置到所确定的存储位置。
在204中,将断点设置到被调用子程序的返回命令。
在205中,计算机程序继续执行并且在所设置的观察点由于写入到该存储位置而在所设置的断点之一之前就已被触发的情况下指示计算机程序有错误。例如,这可以通过在触发观察点时进行相应的检查来完成,或者简单地通过在触发断点之一时(可能自动地)删除该观察点来完成。于是,观察点的触发只能在断点之一的触发之前发生。
根据不同实施方式,该方法可以由在测试系统上运行的测试工具(即,测试程序)自动执行,特别是由模糊测试程序使用或包括在模糊测试程序中的测试工具。因此,上述方法(及其在此描述的各种实施方式)可以在(由模糊测试程序执行的)模糊测试的范畴内自动(并且重复地)执行。
图2的方法可以由具有一个或多个数据处理单元的一个或多个计算机执行。术语“数据处理单元”可以理解为能够实现数据或信号处理的任何类型的实体。例如,数据或信号可以根据由数据处理单元执行的至少一种(即一种或多于一种)特定功能来处理。数据处理单元可以是模拟电路、数字电路、逻辑电路、微处理器、微控制器、中央处理器(CPU)、图形处理单元(GPU)、数字信号处理器(DSP)、可编程门阵列集成电路(FPGA),或包含其的任何组合或由此形成。用于实现本文中更详细描述的相应功能的任何其他方式也可以理解为数据处理单元或逻辑电路装置。此处详细描述的由数据处理单元执行的其中一个或多个方法步骤可以由所述数据处理单元所执行的一个或多个特定功能来执行(例如,实现)。
图2的处理方式用于测试程序、例如针对机器人设备的控制软件。术语“机器人设备”可以理解为指代任何技术系统,例如计算机控制的机器、车辆、家用电器、电动工具、制造机器、个人助理或访问控制系统。所述控制软件也可以针对数据处理系统、例如导航设备来使用。
图2的方法例如由测试装置(例如,图1中的计算机100和目标设备106)来执行。
尽管本文已经说明和描述了具体实施方式,但是本领域技术人员可认识到:所示出和描述的具体实施方式可以被各种替代和/或等效实现方案替代,而并不脱离本发明的保护范围。本申请旨在涵盖本文所讨论的特定实施方式的任何适配或变化。因此,本发明旨在仅由权利要求书及其等同物来限制。
Claims (11)
1.一种用于测试计算机程序的方法,包括:
执行计算机程序直到调用子程序;
确定调用堆栈中存储有被调用的子程序的返回地址或堆栈基指针的存储位置;
将观察点设置到所确定的存储位置上;
将断点设置到被调用的子程序的返回命令上;
继续执行所述计算机程序;并且
如果所设置的观察点由于写入到所述存储位置而在所设置的断点之一之前就已被触发,则指示所述计算机程序有错误。
2.根据权利要求1所述的方法,包括:通过如下方式确定所述存储位置:在用于调用所述子程序的命令处停止所述计算机程序的执行并逐步执行实现用于调用所述子程序的命令的机器指令直到到达存储所述返回地址或堆栈基指针的机器指令,以及根据所述机器命令确定所述存储位置。
3.根据权利要求1或2所述的方法,包括:在嵌入式系统上执行所述计算机程序并通过连接到嵌入式系统的测试系统设置所述观察点和所述断点。
4.根据权利要求1至3中任一项所述的方法,包括:选择子程序的集合,并且对于所选择的集合中的每个子程序:
执行所述计算机程序直到所述子程序被调用,
确定调用堆栈中存储有被调用子程序的返回地址或堆栈基指针的存储位置,
将观察点设置到所确定的存储位置上,
将断点设置到被调用的子程序的返回命令上,
继续执行所述计算机程序并且在所设置的观察点由于写入到所述存储位置而在所设置的断点之一之前就已被触发的情况下指示所述计算机程序有错误。
5.根据权利要求4所述的方法,包括:将断点设置到所选择的子程序集合的子程序上。
6.根据权利要求1至5中任一项所述的方法,包括:
通过用多个测试用例进行模糊测试来测试所述计算机程序,其中每个测试用例指定子程序的相应集合,并且对于针对所述测试用例所指定的集合中的每个子程序包括:
执行所述计算机程序直到调用所述子程序;
确定调用堆栈中存储有被调用的子程序的返回地址或堆栈基指针的存储位置;
将观察点设置到所确定的存储位置上;
将断点设置到被调用的子程序的返回命令上;
继续执行所述计算机程序,并且
在所设置的观察点由于写入到所述存储位置而在所设置的断点之一之前就已被触发的情况下指示所述计算机程序有错误。
7.根据权利要求1至6中任一项所述的方法,包括:
当所设置的断点之一被触发时删除所述观察点。
8.根据权利要求1至7中任一项所述的方法,其中所述计算机程序是用于机器人设备的控制程序并且取决于测试所述计算机程序的结果利用所述计算机程序来控制所述机器人设备。
9.一种测试装置,所述测试装置被设置为执行根据权利要求1至8中任一项所述的方法。
10.一种计算机程序,所述计算机程序具有指令,当由处理器执行所述指令时,所述指令使所述处理器执行根据权利要求1至8中任一项所述的方法。
11.一种存储指令的计算机可读介质,当由处理器执行所述指令时,所述指令使所述处理器执行根据权利要求1至8中任一项所述的方法。
Applications Claiming Priority (2)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| DE102023201815.2 | 2023-02-28 | ||
| DE102023201815.2A DE102023201815A1 (de) | 2023-02-28 | 2023-02-28 | Verfahren zum Testen eines Computerprogramms |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| CN118567971A true CN118567971A (zh) | 2024-08-30 |
Family
ID=92423018
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN202410213607.1A Pending CN118567971A (zh) | 2023-02-28 | 2024-02-27 | 用于测试计算机程序的方法 |
Country Status (3)
| Country | Link |
|---|---|
| US (1) | US20240289257A1 (zh) |
| CN (1) | CN118567971A (zh) |
| DE (1) | DE102023201815A1 (zh) |
Families Citing this family (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US20200293421A1 (en) * | 2019-03-15 | 2020-09-17 | Acentium Inc. | Systems and methods for identifying and monitoring solution stacks |
Family Cites Families (3)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JPH06103109A (ja) * | 1992-09-22 | 1994-04-15 | Hitachi Ltd | データプロセッサ、及びこれを用いるデバッグ装置 |
| US5611043A (en) * | 1994-03-18 | 1997-03-11 | Borland International, Inc. | Debugger system and method for controlling child processes |
| US10191836B2 (en) * | 2016-12-28 | 2019-01-29 | Nxp Usa, Inc. | Software watchpoints apparatus for variables stored in registers |
-
2023
- 2023-02-28 DE DE102023201815.2A patent/DE102023201815A1/de active Pending
- 2023-12-28 US US18/399,020 patent/US20240289257A1/en active Pending
-
2024
- 2024-02-27 CN CN202410213607.1A patent/CN118567971A/zh active Pending
Also Published As
| Publication number | Publication date |
|---|---|
| DE102023201815A1 (de) | 2024-08-29 |
| US20240289257A1 (en) | 2024-08-29 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| US6634020B1 (en) | Uninitialized memory watch | |
| KR101019209B1 (ko) | 임베디드 소프트웨어의 인터페이스 자동 추출 장치 및 그방법 | |
| US9678816B2 (en) | System and method for injecting faults into code for testing thereof | |
| US6378087B1 (en) | System and method for dynamically detecting unchecked error condition values in computer programs | |
| US9069894B2 (en) | Data collisions in concurrent programs | |
| Ge et al. | Reverse debugging of kernel failures in deployed systems | |
| US7711914B2 (en) | Debugging using virtual watchpoints | |
| Jeong et al. | Fifa: A kernel-level fault injection framework for arm-based embedded linux system | |
| CN118567971A (zh) | 用于测试计算机程序的方法 | |
| Rubanov et al. | Runtime verification of linux kernel modules based on call interception | |
| US20240403203A1 (en) | Method for testing a computer program | |
| US20240419579A1 (en) | Method for testing a computer program | |
| Coppik et al. | TrEKer: Tracing error propagation in operating system kernels | |
| US20240311276A1 (en) | Method for testing a computer program | |
| US20240403191A1 (en) | Method for testing a computer program | |
| US20250004934A1 (en) | Method for testing a computer program | |
| US20250004917A1 (en) | Method for testing a computer program | |
| US20250004916A1 (en) | Method for testing a computer program | |
| US20250004911A1 (en) | Method for testing a computer program | |
| Artho et al. | Enforcer–efficient failure injection | |
| US20250378008A1 (en) | Method for learning a state machine for a program | |
| Li et al. | Traditional Techniques for Software Fault Localization | |
| CN116737533A (zh) | 用于测试计算机程序的方法 | |
| Preisner | Towards Static Analysis of Interrupt Blocking Time in Operating System Kernels | |
| CN116737432A (zh) | 用于进行软件差错清除的方法 |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| PB01 | Publication | ||
| PB01 | Publication |