CN106415504B - 测试用例生成系统及记录测试用例的记录介质 - Google Patents

Abstract

本发明的目的在于，提供一种在测试目标代码时，能够使用时序逻辑式表示合格与否基准的技术。测试用例生成系统包括：控制内容生成部，其根据运行路径信息，生成与测试运行控制内容相关的信息，所述运行路径信息是由成为检测对象的目标代码或者可运行形式文件的模型搜索到的；合格与否条件生成部，其根据针对所述检测对象的包含时间要素的检测式和所述运行路径信息，生成与合格与否条件相关的信息，所述合格与否条件是由没有时间要素的判定式和运行该判定式的时刻组合而成的；以及测试用例生成部，其根据与所述测试运行控制内容相关的信息和与所述合格与否条件相关的信息，生成具有和所述检测式对应的合格与否条件的测试用例。

Description

测试用例生成系统及记录测试用例的记录介质

技术领域

本发明涉及一种用于进行软件检测的测试用例生成系统及记录了测试用例的记录介质。

背景技术

伴随着搭载于系统的软件的规模增大，正在变得难以对软件的规范、所有的代码通过审查来确认，或实施测试。此外，并行动作的软件中，有时会因为处理的时机而发生不良情况，这样的不良情况难以通过测试发现。作为针对这样的问题的处理，存在有应用作为形式化验证技术之一的即模型检测的方法。

在模型检测中，作为检测对象的设计，具体地是使用形式化描述语言表示软件规范、源代码(以下，这些称为“验证模型”)。此外，使用具有时间的概念和算符的逻辑式即时序逻辑式将检测对象所要求的性质作为属性来表现，或者通过没有时间概念的逻辑式将检测对象所要求的性质作为断言来表现。通过将这些验证模型、以属性或者是断言来表示的检测式输入至在计算机上工作的工具即模型检测器，并通过穷举状态搜索等数理方法来判定检测对象是否满足所要求的性质。此外，在不满足所要求的性质的情况下，反例被导出。

另一方面，源代码被编译而被转换为目标代码，进而作为以特定的形式被结合的可运行形式而被搭载于系统。这个过程中，即使源代码中没有不良情况，但由于编译器的错误、最优化的影响，也可能在目标代码中发生不良情况。此外，对制品的开发者来说，有想要确认软件的最终形态即目标代码是否有缺陷的需求。因此，如果可以对目标代码应用模型检测的话也有用。但是，由于根据目标代码工作的计算机而代码的表现不同的原因，针对目标代码的模型检测存在技术困难，非一般地实现的工具也不多。

作为针对该问题的对策，存在应用模型检测而生成测试用例的技术。由于模型检测器有通过验证模型对检测对象的运行路径、可取得的动作进行穷举搜索的功能，因此在测试用例生成技术中活用该功能。结构如下所述。

由成为检测对象即目标代码的初始代码的源代码制作验证模型，相对于源代码中想要测试的运行路径的终点来定义所谓的“没有到达该终点”的属性或者是断言。关于该属性或者断言的输入，模型检测器将到该终点的运行路径作为反例输出。例如，利用模型检测器SPIN(Simple Promela Interpreter)，在验证模型中在最后被执行的点上描述为assert(false)并执行检测。在描述了所述的断言的点被执行的用例存在的情况下，作为与从开始执行的点到执行结束的点为止的运行路径相关的信息的追迹(トレース)作为1个或者多个反例被输出。追迹1对应测试用例1(也可以对应执行了执行条件的多个测试用例)。该追迹包括对中途非确定性地选择的变量的赋值，也就是说输入值确定，在有多个进程的情况下也包含该执行顺序。将该追迹变换为用于执行测试的数据，将成为检测对象的目标代码设为在实体设备或者模拟器上执行的系统的输入。该数据成为测试用例或者是其的一部分。所谓测试用例，是表示测试条件的数据。在此，表示为“测试用例的一部分”的理由，是由于由追迹所变换的数据不包含合格与否基准、成为检测对象的程序的某几个执行条件。

由于该测试用例生成技术可以穷举运行路径，因此可以期望与相对于目标代码实施模型检测的情况同样的效果。作为进行应用了模型检测的测试用例生成的现有技术，存在有专利文献1。

现有技术文献

专利文献

专利文献1：日本特开2010-102624号公报

发明内容

发明要解决的问题

在软件的模型检测中，可以使用时序逻辑式来表示合格与否基准。但是，在目标代码的检测时，由于一个一个的测试是在实体设备或者模拟器上执行的，不可以使用时序逻辑式表示合格与否基准。在模型检测中，由于是处理作为时序逻辑式的算符的“通常”、“将来”，在所有的控制点(模型检测中的执行步骤)逻辑式被评价。但是，在目标代码的测试中，合格与否判定变为预先确定的时刻上的逻辑式的评价。通常，往往只在执行后的一点评价合格与否判定的逻辑式。因此，不可以向使用实体设备、模拟器执行测试的系统输入时序逻辑式作为合格与否基准，不可以实施包含通过时序逻辑式表示那样的时间概念的性质的评价。

本发明的目的是在测试目标代码时，提供一种可以使用时序逻辑式表现合格与否基准的技术。

解决问题的手段

为了解决上述课题，例如采用权利要求书内记载的结构。本申请包含多个解决上述课题的单元，但如果举出一例的话，提供了一种测试用例生成系统，其包括：控制内容生成部，其根据运行路径信息，生成与测试运行控制内容相关的信息，所述运行路径信息是由成为检测对象的目标代码或者可运行形式文件的模型搜索到的；合格与否条件生成部，其根据针对所述检测对象的包含时间要素的检测式和所述运行路径信息，生成与合格与否条件相关的信息，所述合格与否条件是由没有时间要素的判定式和运行该判定式的时刻组合而成的；以及测试用例生成部，其根据与所述测试运行控制内容相关的信息和与所述合格与否条件相关的信息，生成具有和所述检测式对应的合格与否条件的测试用例。

此外，根据其他例子，提供一种计算机可读取的记录介质，其特征在于，记录了具有数据结构的数据，所述数据结构是用于使计算机执行对成为检测对象的目标代码或者可运行形式文件检测的处理的测试用例的数据结构，其包含与测试运行控制内容相关的信息，以及与由没有时间要素的判定式和运行该判定式的时刻组合而成的合格与否条件相关的信息。

发明的效果

根据本发明，在对目标代码测试时，可以使用时序逻辑式表示合格与否基准。由此，能够检测的内容相比于只有没有时间概念的逻辑式时也扩大了。，通过将在运用模型检测生成了的测试用例中检测目标代码与该合格与否基准的表示相配合，可以实现和相对于目标代码通过模型检测来检测由时序逻辑描述的属性时同样的效果。

本发明关联的进一步的特征根据本说明书的描述，附图而变得明确。此外，上述以外的课题、结构以及效果，通过以下实施例的说明而明确。

附图说明

图1是实现本发明的测试用例生成系统的系统的构成图。

图2是示出和本发明的实施例中测试用例生成程序的功能关联程序的构成的图。

图3是本发明中的测试用例生成程序的处理流程图。

图4是本发明的实施例中的控制内容生成部的处理流程图。

图5是本发明的实施例中的合格与否条件生成部的处理流程图。

图6是属性的句法模式相关的数据库的一例。

图7是示出成为检测对象的抽样程序、该验证模型和追迹的一例。

图8是示出本发明的实施例中的测试运行控制内容信息及合格与否判定信息的一例。

图9是示出本发明的实施例中输出的测试用例的一例。

具体实施方式

以下，参照附图对本发明的实施例进行说明。再者，附图表示遵循本发明的原理的具体的实施例，但这些是用于本发明的理解的图，决不是用于限定地解释本发明的图。此外，关于各图中共同的结构附上同一参照编号。

图1是实现本发明的测试用例生成系统的系统的构成图。本发明是生成测试用例的系统，该测试用例用于对由源代码编译过的目标代码、可执行形式进行检测的测试系统。测试用例如上所述，是表示测试条件的数据。

本发明是作为软件工具被实现的。测试用例生成系统的各功能作为软件被安装。测试用例生成系统具备计算机110。计算机110具备：主运算装置(CPU)111、主存储装置(RAM)112、存储介质(ROM)113、辅助存储装置(硬盘)114、输入装置(键盘、指示设备等)130、显示装置(显示器、打印机等)140。

实现本发明的软件是作为测试用例生成程序120，存储于计算机110的ROM113内，通过CPU111读出并执行。计算机110的CPU111根据测试用例生成程序120来执行规定的处理。

将成为检测对象即目标代码的初始代码的源代码的文件，或以该源代码为基础作成的验证模型的文件存储于计算机110上的硬盘114中。可以从键盘等输入装置130进行对于测试用例生成程序120的用户操作。测试用例生成程序120的输出作为向显示器等显示装置140的显示、向硬盘114的数据文件生成而实现。作为另一例子，测试用例生成程序120的输出，也可以是经由网络的向未图示的外部计算机的输出，通过向CD-ROM等外部存储介质的数据文件形式的写入实现的输出。此外，其他的程序也可以和测试用例生成程序120一样地被处理，CPU111执行其他的程序并进行输出。

图2是示出ROM113内存储的测试用例生成程序120的构成、以及与测试用例生成程序120相关的其他程序的构成。验证模型生成程序210将成为作为检测对象的目标程序的初始代码的源代码200作为输入，生成验证模型215。如上所述，在此的验证模型215使用形式化描述语言将软件规范或者源代码表现出来。

运行路径搜索程序220对关于检测对象的验证模型215进行搜索，输出运行路径信息(例如，以下说明的追迹225)。更详细地说，运行路径搜索程序220将向验证模型215追加了测试用例生成用(狭义地是追迹生成用)的属性或者断言的文件作为输入，将成为测试用例的初始的追迹组225作为反例而生成1个或多个。运行路径搜索程序220在反例的生成中使用公知的模型检测器。本实施例中，利用SPIN作为模型检测器。反例的生成数可以根据对模型检测器的选项制定来调整。

测试用例生成程序120将追迹组225和时序逻辑式235作为输入，生成测试用例组280。在此，时序逻辑式235是对于成为检测对象的目标代码或者可执行形式的属性，是包含时间要素的检测式。测试用例生成程序120采取以下的结构。测试用例生成程序具备运行路径解析部230、控制内容生成部240、合格与否条件生成部250、测试用例生成部260。

运行路径解析部230将验证模型215作为输入而接收，对包含验证模型215所表示的源代码200内的处理调用关系的控制流进行解析。源代码用C语言描述的情况下，处理调用关系是函数调用树。运行路径解析部230将控制流的信息作为解析结果输出，该控制流的信息在测试用例生成程序120内被利用。再者，追迹组225如果包含控制流的信息的话，也可以不从验证模型215，而从追迹组225解析控制流。也就是说，也可以将追迹组225作为运行路径解析部230的输入。

控制内容生成部240将追迹组225作为输入，生成与对追迹组225的各追迹控制测试运行的内容有关的信息(以下，称为“测试运行控制内容信息”)。在此，所谓测试运行的控制内容，具体地说是对变量或个人计算机的寄存器等的数据进行操作、中断或实时OS(Operation System(操作系统))中的任务启动等的处理运行、将成为检测对象的程序的运行状态作为条件的触发(指定条件的成立为止的待机)等，对包含检测对象程序的举动的测试的执行内容造成影响的操作的信息。此外，测试运行的控制内容和执行该操作的时刻的信息配对。测试运行控制内容信息对于1个追迹，作为1个或者多个事件队列被规定。

合格与否条件生成部250将追迹组225、时序逻辑式235作为输入而接收，对于追迹组225的各追迹，输出与合格与否条件相关的信息(以下，称之为“合格与否条件信息”)。该合格与否条件信息由没有时间要素的判定式和执行该判定式的时刻组合而成。此外，在合格与否条件信息中，对于1个追迹，规定1个或者多个的合格与否判定的事件队列。

测试用例生成部260根据控制内容生成部240输出的测试运行控制内容信息和合格与否条件生成部250输出的合格与否条件信息，输出测试用例组280。测试用例组280是可以输入至测试系统290的形式。测试用例生成部260使用来自运行路径解析部230的控制流的信息，将测试运行控制内容信息和合格与否条件信息的事件队列作为1个事件队列按运行顺序排列。其后，测试用例生成部260通过将按运行顺序排列的事件队列转换为输入至测试系统的格式，生成测试用例组280。

测试用例组280被记录于硬盘114等存储装置或者是规定的计算机可读取的记录介质。测试系统290是运行由源代码200编译的目标代码、可运行形式文件的检测的系统。测试系统290使用测试用例组280，对上述目标代码、可运行形式文件检测。由此，通过将时序算符导入至合格与否条件的测试用例组280，可以对检测对象的目标代码、可运行形式检测。

图3是测试用例生成程序120所运行的处理流程图。首先，步骤300中开始处理，接下来，步骤310中，运行路径解析部230解析验证模型215的控制流并输出控制流的信息。

从步骤320到步骤340被反复执行。由于从步骤320到步骤340是对于追迹组225的各追迹而执行的，因此仅反复与追迹组225所包含的追迹数相应的次数。在步骤320中，控制内容生成部240解析追迹组225从而输出测试运行控制内容信息。在步骤330中，合格与否条件生成部250根据追迹组225和时序逻辑式235输出合格与否条件信息。在步骤340中，测试用例生成部260根据测试运行控制内容信息和合格与否条件信息输出测试用例组280的1个测试用例。反复以上操作，在步骤390结束处理。

图4是将控制内容生成部240的步骤320的处理流详细化的图。在步骤400开始处理。从步骤410开始到步骤440，仅反复与追迹组225的各追迹所包含的处理的步骤数相应的次数。在步骤410中，控制内容生成部240将成为处理对象的各追迹所包含的步骤从开头一个一个地抽取。在此，在一次运行中抽取未抽取的处理步骤中接下来要运行的处理步骤之一并解释内容。

在步骤420中，控制内容生成部240判定步骤410中抽取的处理的种类。如果处理是通过对变量(包含个人计算机的寄存器)赋值的输入值设定的话，进行步骤430。处理是进程启动的话则进行步骤440。判定为输入值设定的条件是，处理是赋值语句，被赋值的变量被设定为输入值。判定为启动进程的条件是，该处理是作为进程起点被指定的函数的最初处理。可以使用来自运行路径解析部230的控制流信息判定是否是函数的最初处理。

在步骤430中，控制内容生成部240向输出的测试运行控制内容信息追加对变量的赋值的处理。作为运行时刻的信息，被赋予该处理的描述位置(函数、行等)。处理的描述位置可以由追迹取得，或者追溯来自运行路径解析部230的控制流信息而取得。

在步骤440中，和步骤430同样的，控制内容生成部240向测试运行控制内容信息追加用于使追迹的处理所表示的中断、任务启动发生的控制处理。验证模型的各进程在检测对象的程序中相当的处理(中断、任务启动等)的信息作为设定于控制内容生成部240的内容，选择与处理相应的控制处理。反复以上操作，在步骤490结束处理。

图5是将合格与否条件生成部250的步骤330的处理流程图详细化的图。在步骤500开始处理。在步骤510中，合格与否生成部250对输入的时序逻辑式235的语法解析。解析了的语法以AST(Abstract Syntax Tree(抽象语法树))的形式表示为内部数据。在步骤520中，合格与否条件生成部250将通过步骤510解析了的时序逻辑式235的语法和与合格与否条件生成部250具有的属性的语法模式相关的数据库(检测式解读信息)对照，抽取一致的模式。

在步骤530中，合格与否条件生成部250从通过步骤510解析的属性的语法中抽取利用于测试用例的合格与否判定的逻辑式(判定式)。此外，合格与否条件生成部250根据来自运行路径解析部230的控制流信息和在步骤520判定的属性的模式，生成1个或多个有关进行合格与否判定的时刻的信息。最终，合格与否条件生成部250通过把这些逻辑式(判定式)和有关判定时刻的信息配对，生成合格与否条件信息。执行以上的处理，在步骤590结束处理。

接下来，对本实施例的测试用例生成系统中处理的信息进行说明。关于以下的几个信息，使用“表格”结构进行说明，但也不一定用表格的数据结构来表示，也可以用其他的数据结构来表示。因此，由于是表示不依赖于数据结构的信息，以下中，将使用表格表示的数据简称为“信息”。

图6示出了与属性的语法模式有关的数据库即属性解读表格(检测式解读信息)600。属性解读表格600是图5的步骤510中所参照的信息。属性解读表格600包含将属性变换为合格与否条件的规则。属性解读表格600，例如存储于硬盘114等存储装置中，合格与否条件生成部250读取该信息并进行上述的处理。可以在测试用例生成程序120中仅处理具有属性解读表格600所规定的语法形式的属性。

本实施例中，属性解读表格600包含对于每个属性语法形式的模式所附上的规则编号601、属性语法形式602、合格与否条件603和各合格与否判定间的关系(用于作为1个测试用例整体的合格与否判定时的各合格与否判定间的关系)604作为构成项目。本例中，属性解读表格600中处理的属性设为LTL(Linear Temporal Logic(线性时序逻辑))。

属性解读表格600中存储有2个时序逻辑式的模式。1个是G(expr)，另1个是F(expr)。G是意味着“通常”的时序算符，F是意味着“将来”的时序算符。此外expr在此是示出逻辑式的抽象表示。expr成为利用于合格与否判定的逻辑式。

在规则编号601的“R1”的记录中，描述了“G(expr)”在测试用例中变换为“在(执行的)各函数的出入口判定expr”的规则。这样的规则是通过描述规则的语言、进行变换的程序自身来表示。此外，在规则编号601的“R1”的记录中，将基于expr的各判定的结果用于作为1个测试用例整体的合格与否判定时，被指定取得各判定结果的“AND”。同样的，在规则编号601的“R2”的记录中，F(expr)被变换为“在各函数的出入口判定expr”，且在作为1个测试用例整体的合格与否判定时，被指定取得各判定结果的“OR”。

属性解读表格600中所指定的内容可以根据利用的测试系统的功能而变更。例如，测试系统可以在检测对象的程序的各语句(ステートメント)中实施合格与否判定的情况下，也可以指定为G(expr)变换成“在(执行的)各语句的执行后判定expr”。此外，属性解读表格600可以处理图6所示以外的语法形式。

图7中示出如下内容：成为检测对象的实例程序的由C语言所描述的源代码710；通过SPIN的模型描述语言Promela写出源代码710，还追加了测试用例用的断言assert(0)的验证模型720；和通过SPIN执行验证模型720的检测而获得追迹的一例730。

源代码710的函数在验证模型720中被变换为inline宏。此外，源代码中，DI0表示数字输入的寄存器。对源代码中的变量a的DI0的代入被表示为在验证模型720中对变量a的0或1的非决定性的代入。追迹730是对变量a代入1的用例。但是为了便于说明，和实际的追迹(反例)的形式是不同的。再者，变量a相对于测试用例生成程序120被指定为输入。此外，测试用例生成程序120中，将G(x≤1)指定为属性。

运行路径解析部230解析验证模型720并生成AST，对AST搜索，在各inline中发现利用其他inline的描述，由此对原来的源代码710的函数调用树进行解析。在此可知main→func1这样的调用关系。

图8和图9示出将验证模型720和追迹730作为输入，测试用例生成程序120运行图3的处理并输出的数据。图8示出了测试运行控制内容信息810以及合格与否条件信息820。测试运行控制内容信息810包含编号811、测试运行控制处理的种类812和该处理的内容813作为构成项目。此外，合格与否信息820包含编号821、测试运行控制处理的种类(合格与否判定也作为运行控制的一种)822和该处理的内容823作为构成项目。图9示出了测试用例900。在图8及图9中，各信息的1行表示一个事件、执行测试系统的处理的1个步骤。再者，测试用例900被设为另外变换为向测试系统输入的形式。

对控制内容生成部240的处理进行说明。控制内容生成部240将追迹730作为输入接收，其后，解析追迹730，抽取向输入变量代入1的处理。控制内容生成部240进一步根据记载于追迹730的处理的位置(对应于图7的720的第12行)和控制流信息，判定该处理在函数main中实施。利用该判定结果，控制内容生成部240输出测试运行控制内容信息810。在控制内容生成部240输出的测试运行控制内容信息810中，事件队列的长度变为2。第1个事件是将进入main函数作为条件的触发。第2个事件是向变量a代入1的处理。

接下来，对合格与否条件生成部250的处理进行说明。合格与否条件生成部对追迹730和属性G(x≤1)进行解析，从而输出合格与否信息820。这时，合格与否条件生成部250参照记载于属性解读表格600的规则。该例子中，合格与否条件生成部250在属性解读表格600中选择(参照)规则“R1”，其结果按照控制流的信息，在main函数的入口、func1函数的入口、func1函数的出口、main函数的出口设定触发，在各触发之后立刻设定合格与否判定。也就是说，输出的合格与否条件信息820在main函数的入口、func1函数的入口、func1函数的出口、main函数的出口启动触发，在启动触发之后变为判定为x≤1的内容。再者，在图8、图9中省略了在作为1个测试用例整体的合格与否判定中取得各判定结果的AND的情况，但该信息被提供给了合格与否条件信息820和测试用例900。也就是说，合格与否条件生成部250将示出了在作为1个测试用例整体的合格与否判定中取得各判定结果的AND的信息添加于合格与否条件信息，最终，测试用例生成部260添加了上述信息并生成测试用例。

接下来，对测试用例生成部260的处理进行说明。测试用例生成部260测试运行控制内容信息810和合格与否条件信息820输出测试用例900。如图9所示。测试用例900包含步骤编号901、测试运行控制的处理种类(合格与否判定也作为测试运行控制的一种)902和测试运行控制的处理内容903作为构成项目。在此，在测试用例生成部260输出的测试用例900中，测试运行控制内容信息810和合格与否条件信息820被合成而变为1个信息。测试用例生成部260判定为在main函数的入口的触发重复，将重复的部分汇集为1个。

图8及图9的例子中，输入值设定、触发、合格与否判定作为测试运行的处理种类而被记下。假设除此之外还准备了示出中断、任务启动的描述。在取得运行中断、任务启动的处理的时刻的情况下也可以利用触发。该触发条件中，如果所利用的测试系统能以程序的语句单位指定时刻的话，只要在追迹中即将转变进程之前指定运行的语句的运行终止时间即可。在所利用的测试系统可以检测函数的出入口的情况下，可能有将上述语句的函数的入口以及从此开始的规定时间的经过作为触发条件的方法。

综上所述，由于在程序的运行的各处判定了属性的逻辑式(x≤1)，因此可以实现和属性的“通常”同样的合格与否判定。只在函数的出入口判定的情况虽不会完全地再现模型检测的各语句中的判定，但是会进行以其为标准的判定。此外，通过根据所利用的语句的功能而变更属性解读表格600的规则，也可以将判定频率变为和模型检测同等的。

接下来，对属性的时序算符是“将来”的情况进行说明。该例子中，合格与否条件生成部250在属性解读表格600中选择(参照)规则“R2”，按照控制流的信息生成设定了触发及合格与否判定的合格与否条件信息。这之后，测试用例生成部260通过该合格与否条件信息和由控制内容生成部240输出的测试运行控制内容信息，输出测试用例900。

更详细地说，在所输入的属性的时序算符是“将来”时，在作为一个测试用例整体的合格与否判定中取得各判定结果的OR的情况，除了在测试用例900中被指定以外，作为最后的事件而追加合格与否判定的触发。在此，测试用例生成程序120中，指定F(x>1)为属性。如果F(x>1)的话，将x>1作为条件的触发被追加至测试用例900的最后。触发的超时(タイムアウト)时间设定于测试用例生成程序120中，被提供给测试用例900(图中未记载)。是否运行将逻辑式设为条件的触发是在测试系统290中和合格与否条件同样地被判定及记录。此外，该判定结果在测试系统290中也可以利用于1个测试用例整体的合格与否判定。综上所述，由于在程序的执行中至少在1处以上属性的逻辑式(x>1)成立的情况下可以对其检测，因此可以实现和属性的“将来”同样的合格与否判定。

综上所述，在检测目标代码时，可以使用时序逻辑式作为合格与否基准。由此，可以将“通常”、“将来”这样的时序算符的表示导入至合格与否条件。此外，在应用了模型检测的测试用例生成中向合格与否基准导入时序逻辑式的话，可以针对目标代码实现和实施模型检测同样的检测。通过这些，可以达到软件不良情况减少和系统的可靠性提高。

本发明并不限于上述的实施例而包括了各种各样的变形例。上述实施例是为了让本发明容易理解而详细说明的实施例，未必要限定于具备所说明的全部的结构的实施例。此外，也可以将某个实施例的结构的一部分替换为其他实施例的结构。此外，也可以在某个实施例的结构上加上其他实施例的结构。此外，也可以对于各实施例的结构进行其他结构的追加、删除、置换。

上述的各结构、功能等可以通过解释、执行处理器分别实现各个功能的程序由软件来实现。实现各功能的程序等的信息可以存储于一些记录装置或者是记录介质。此外，可以将拥有如图9中例示那样的数据结构的测试用例的数据存储于一些记录装置或者是记录介质。

符号说明

100 ：测试用例生成系统

110 ：计算机

111 ：CPU

113 ：ROM

114 ：硬盘

120 ：测试用例生成程序

130 ：输入装置

140 ：显示装置

200 ：源代码

210 ：验证模型生成程序

215 ：验证模型

220 :运行路径搜索程序

225 ：追迹组

230 ：运行路径解析部

235 ：时序逻辑式

240 ：控制内容生成部

250 ：合格与否条件生成部

260 ：测试用例生成部

280 ：测试用例组

290 ：测试系统

600 ：属性解读表格

710 ：源代码

720 ：验证模型

730 ：追迹

810 ：测试运行控制内容信息

820 ：合格与否条件信息

900 ：测试用例。

Claims (8)

1.一种测试用例生成系统，其特征在于，包括：

控制内容生成部，其以运行路径信息为输入，生成与测试运行控制内容相关的信息，所述运行路径信息是由成为检测对象的目标代码或者可运行形式文件的模型搜索到的；

合格与否条件生成部，其根据针对所述检测对象的包含时间要素的检测式和所述运行路径信息，生成与合格与否条件相关的信息，所述合格与否条件是由没有时间要素的判定式和运行该判定式的时刻组合而成的；以及

测试用例生成部，其根据与所述测试运行控制内容相关的信息和与所述合格与否条件相关的信息，生成具有和所述检测式对应的合格与否条件的测试用例，

所述检测式的所述时间要素是通常的意思时，所述合格与否条件生成部向与所述合格与否条件相关的信息添加第1信息，所述第1信息表示取得所述合格与否条件的判定结果的AND，

所述测试用例生成部添加所述第1信息并生成所述测试用例，

所述检测式的所述时间要素是将来的意思时，所述合格与否条件生成部向与所述合格与否条件相关的信息添加第2信息，所述2信息表示取得所述合格与否条件的判定结果的OR，

所述测试用例生成部添加所述第2信息并生成所述测试用例。

2.根据权利要求1所述的测试用例生成系统，其特征在于，

所述检测式的所述时间要素是将来的意思时，所述测试用例生成部输出与所述检测式对应的所述合格与否条件的触发被添加为最后的事件的所述测试用例。

3.根据权利要求1所述的测试用例生成系统，其特征在于，

所述合格与否条件生成部参照包含将所述检测式变换为所述合格与否条件的规则的检测式解读信息，生成与所述合格与否条件相关的信息。

4.根据权利要求3所述的测试用例生成系统，其特征在于，

所述检测式解读信息包含所述检测式的语法形式、所述合格与否条件和以1个测试用例整体来进行合格与否判定时的合格与否条件间的关系作为构成项目。

5.根据权利要求1所述的测试用例生成系统，其特征在于，

还具备根据所述模型解析控制流信息的运行路径解析部。

6.根据权利要求5所述的测试用例生成系统，其特征在于，

所述测试用例生成部使用所述控制流的信息，排列与所述测试运行控制内容相关的信息和与所述合格与否条件相关的信息，由此生成所述测试用例。

7.根据权利要求5所述的测试用例生成系统，其特征在于，

所述控制内容生成部使用所述控制流的信息，生成与所述测试运行控制内容相关的信息。

8.根据权利要求5所述的测试用例生成系统，其特征在于，

所述合格与否条件生成部使用所述控制流的信息，生成与所述合格与否条件相关的信息。