CN1885273A

CN1885273A - 一种逻辑测试的功能覆盖率分析方法

Info

Publication number: CN1885273A
Application number: CN 200510035490
Authority: CN
Inventors: 麻远声
Original assignee: Huawei Technologies Co Ltd
Current assignee: Huawei Technologies Co Ltd
Priority date: 2005-06-21
Filing date: 2005-06-21
Publication date: 2006-12-27
Anticipated expiration: 2025-06-21
Also published as: CN100349132C

Abstract

一种逻辑测试的功能覆盖率分析方法，包括如下步骤：(a)在参考模型中相应的功能分支上插入“探针”；(b)在测试用例的测试过程中执行到“探针”时，调用统计函数把该探针的描述信息记录到统计表中；(c)在当前用例执行完毕后，把统计表的记录有当前测试用例所覆盖的功能分支的记录信息打印到该测试用例的日志文件中；(d)在所有测试用例测试完毕后，依次打开每个测试用例的日志文件，汇总所有测试用例的功能分支的覆盖信息，生成“已测功能分支统计表”；(e)扫描参考模型代码，生成探测点树；(f)比较该“已测功能分支统计表”及该探测点树，获取功能覆盖率信息。本发明的逻辑测试功能覆盖率分析方法，具有操作简单、获得的信息更加可靠及测试点的增删、变更更加灵活的优点。

Description

一种逻辑测试的功能覆盖率分析方法

技术领域

本发明涉及一种探测测试用例的激励是否充分的方法，具体来讲，涉及一种逻辑测试的功能覆盖率分析方法。

背景技术

逻辑的功能需求一般可以翻译为“在XX激励下，逻辑应当XX响应”的形式。为了验证逻辑需求规格书中的某项功能需求是否实现，需要给逻辑施加相应的各种激励数据(如，配置寄存器、向逻辑发送数据包等)，然后判断逻辑的响应数据是否与需求规格书中所定义的一致。如果施加给该逻辑的激励数据是充分的，且逻辑对激励的响应是正确的话，则该条逻辑功能就被正确地实现了。逻辑测试的通过需要满足：逻辑对激励的响应的正确性及施加给逻辑的激励的充分性两个条件。

在对大规模逻辑的测试过程中，由于激励数据和响应数据都非常庞大，且响应和激励的映射关系也比较复杂，所以用人工的方法来分析响应是否正确非常困难。图1中示出了现有的一种测试分析方法。如图1所示，可把由激励产生器所产生的激励数据同时作用于参考模型(Reference Model，RM)和逻辑系统(即被测逻辑)，然后通过响应比较器来比较该RM和该被测逻辑的响应是否一致。如果在比较结果中该RM和该被测逻辑的响应是一致的，则说明该被测逻辑和参考模型都正确响应了该激励数据；否则，如果比较结果不一致，则被测逻辑和参考模型必然有一个的响应是不符合逻辑需求规格书，需要查找问题的根源，并进行重新测试。控制脚本会控制该激励产生器产生激励数据，并能接收响应比较器的比较结果。

前述的将参考模型的响应数据与被测逻辑的响应数据进行比较来分析被测逻辑的响应是否确性的方法，已成为最普遍采用的一种逻辑系统测试的方法，但在该方法中未找到对激励充分性进行检验的理想方法。

对于测试数据的充分性，业界最普遍的做法是直接根据需求规格书上的功能要求，控制激励产生器产生各种相应的激励数据进行测试。而不分析和度量该实际的激励是否正确和充分。

但是，测试人员编写激励产生器的控制脚本来控制激励产生器产生激励数据时难免出现遗漏或错误，但由于现有方法没有反馈和报告机制，现实中这种遗漏或错误不易被测试人员所察觉，所以就很容易导致漏测或出现错误。另一方面，即使控制脚本正确，有时由于激励产生器的错误，实际作用在被测逻辑和RM的数据已经并非是测试人员所期望的，这种错误也不易被测试人员所察觉，也很容易导致漏测。

在另外一种方法中，在测试之前根据需求规格以某种方式(如以EXCEL表格的方式)定义好输入的数据必须覆盖的那些集合，在测试过程中用工具检查实际的输入数据是否涵盖了这些集合，如果没有涵盖，则说明激励不够充分，提醒测试人员补充相应测试用例。

但这种方法是由测试人员根据需求规格来定义输入数据必须涵盖的数据集合，其是人为的定义过程，同样难免出现疏漏。另一方面，由于这种集合直观性差，所以定义过程工作量较大而且不易重用，修改起来也很困难，所以实际效果不够理想。

发明内容

本发明所要解决的技术问题在于，提供一种逻辑测试的功能覆盖率分析方法，可以自动地探测探测数据是否充分以及缺少哪些激励数据等信息，从而使满足测试数据充分的目的。

为了解决上述技术问题，本发明采用的技术方案在于：提供了一种逻辑测试的功能覆盖率分析方法，包括如下步骤：(a)在参考模型中相应的功能分支上插入“探针”；(b)在测试用例的测试过程中执行到“探针”时，调用统计函数把当前功能分支的探测点信息记录到统计表中；(c)在测试用例执行完毕把统计表的信息打印到这个测试用例的日志文件中；(d)在所有测试用例测试完毕后，依次打开每个测试用例的日志文件，汇总所有测试用例覆盖的功能分支的探测点统计信息，生成“已测功能分支统计表”；(e)扫描参考模型代码，生成探测点树；(f)比较“已测功能分支统计表”及该探测点树，获取功能覆盖率信息。

其中，每一个“探针”中包含有一个表示该功能分支执行次数的计数器，且该统计表记录了当前测试用例的激励数据覆盖功能分支的探测点信息。

其中，所述探针包含有当前函数的调用路径，一个探针可以通过具体化调用路径而对应多个探测点。

其中，在步骤(b)中进一步包括：在参考模型中的每一个需要插入探针的proc中，获取当前的调用路径并赋给变量的步骤。

其中，在步骤(b)中进一步包括：判断统计表中是否有当前功能分支的探测点信息；如果在统计表中没有当前功能分支的探测点信息，则在统计表中增加一条记录，并将计数器置为1；如果统计表中已有当前功能分支的探测点信息，则将该探测点信息中的计数器加1。

其中，所述步骤(e)进一步包括：(e1)、对参考模型进行第一遍扫描，得到该参考模型中定义的proc，生成一个Proc表，以及生成每一proc对应的探针表；(e2)、对参考模型进行第二遍扫描，产生proc调用关系表，生成proc调用关系树；(e3)、利用proc调用关系树和探针表，给proc调用关系树上的每一个proc都添加上该proc的“探针”，生成探测点树。

其中，进一步包括在探针的描述信息中插入一个或多个变量来统计调试信息的步骤。

本发明的有益效果在于：

操作简单：与用EXCEL表格定义激励数据相比，在参考模型中所关心的路径上插入“探针”操作更加容易和方便。其他的工作诸如“探测点”的统计、“探测点树”的生成及未覆盖点的查找打印都是可以通过软件来完成。

获得的信息更加可靠：功能分支覆盖信息从参考模型中获取，要比从激励数据中获取更可靠。如果采用定义激励数据的方法，测试人员不易发现由于激励模块的错误而导致的问题。

测试点的增删、变更更加灵活。

附图说明

图1是现有的一种测试分析方法。

图2是本发明逻辑测试的功能覆盖率分析方法的主流程图。

图3是本发明中的proc调用关系树的示意图。

图4是本发明中的探测点树的示意图。

具体实施方式

本发明主要通过分析测试过程中RM的功能分支覆盖情况来反映逻辑的功能分支覆盖情况，从而判断激励数据是否充分。

如图2所示，是本发明逻辑测试的功能覆盖率分析方法的主流程图。在测试之前，测试人员需要根据需求规格在RM中相应的功能分支上插入“探针”(步骤S210)。插入“探针”的工作需要手工完成，其他的工作比如测试点的统计覆盖率的计算以及未覆盖信息的打印可以通过自动化工具完成。

“探针”实际上是一个函数调用，每一个“探针”中包含有一个表示该功能分支的路径的变量和执行次数的计数器。在测试用例的测试过程中执行到“探针”时，调用统计函数把当前分支及其描述信息记录到统计表中(步骤S220)，在本发明的一个实施例中，具体的记录方法为：如果统计表中没有这个分支，就在统计表中增加一条记录，并将计数信息添上1；如果统计表中已有这个分支，就将这个分支的计数器加1。这个统计表记录了当前测试用例的激励数据覆盖功能分支信息。该测试用例执行完毕后，把统计表的信息打印到这个测试用例的日志文件中(步骤S230)。

在所有测试用例测试完毕后，逐个打开所有的测试用例的日志文件，统计所有测试用例覆盖的功能分支得到“已测功能分支”的集合(步骤S240)；然后扫描RM代码得到“总的功能分支集合”(即探测点树)(步骤S250)；比较“已测功能分支”和“总的功能分支”(步骤S260)；从而来获得该被测试逻辑中哪些功能尚未覆盖、覆盖率为多少等信息(步骤S270)。测试人员利用这些信息，就可以有目的有针对的增加测试用例和测试数据，最终达到所有功能全面覆盖的目的(步骤S280)。

下面结合一个实例，对本发明的逻辑测试的功能覆盖分析方法进行详细说明。

一、需求假设

下面我们以用工具命令语言(Tool Command Language，下简称为“TCL语言”)实现的RM为例，通过举例的方式来说明本发明的具体实现过程。对于其他语言实现的RM，除了调用栈的获取方法不同外，其他方面基本相同。

假设某个被测逻辑的功能需求如下：

1：处理的包长范围为：64Byte-1500Byte，丢弃小于64Byte和大于1500Byte数据包。

2：丢弃CRC(循环冗余校验码)错误的数据包。

3：丢弃除ARP(Address Resolution Protocol，地址解析协议)、TCP(TransferControl Protocol，传输控制协议)之外的数据包。

4：对于ARP：进行DMAC(目的MAC地址)检查，如果DMAC不等于广播地址或本设备MAC(media access control，媒体存取控制)地址，则直接丢弃。通过DMAC检查的ARP包转发给CPU进行处理。

5：对于TCP：进行DMAC检查(方法同ARP)；进行DIP(目的IP地址)检查，如果DIP不是本设备IP地址，则丢弃。对于通过DMAC检查和DIP检查的数据包，向CPU转发。

二、RM的形式

对于该需求假设，其TCL语言格式的RM伪代码描述如下(圆括号中的数字为行号)：

proc Root{Paket}{ (01)

if{包长小于64Byte }{ (02)

丢弃处理； (03)

}elseif{包长大于1500Byte}{ (04)

丢弃； (05)

}elseif{Crc错误}{ (06)

丢弃； (07)

}elseif{激励数据是Arp包}{ (08)

调用Arp包处理proc ArpProc； (09)

}elseif{激励数据是Tcp包}{ (10)

调用Arp包处理proc TcpProc； (11)

}else{ (12)

丢弃； (13)

} (14)} (15)proc ArpProc{Paket}{ (16)

调用DMAC检查proc DMAC_CHECK获得DMAC检查结果； (17)

if{DMAC检查结果没有通过}{ (18)

丢弃处理； (19)

}else{ (20)

向CPU转发； (21)

} (22)} (23)proc TcpProc{Paket}{ (24)

调用DMAC检查proc DMAC_CHECK获得DMAC检查结果； (25)

调用DIP检查proc DIP_CHECK获得DIP检查结果； (26)

if{DMAC检查结果没有通过}{ (27)

丢弃处理； (28)

}elseif{DIP检查结果没有通过}{ (29)

丢弃处理； (30)

}else{ (31)

向CPU转发； (32)

} (33)} (34)proc DMAC_CHECK{Paket}{ (35)

if{DMAC等于本设备MAC地址}{ (36)

返回DMAC检查通过信息； (37)

}elseif{DMAC等于广播地址}{ (38)

返回DMAC检查通过信息； (39)

}else{ (40)

返回DMAC检查不通过信息； (41)

} (42)} (43)proc DIP_CHECK{Paket}{ (44)

if{DIP等于本设备IP地址}{ (45)

返回DIP检查通过信息； (46)

}else{ (47)

返回DIP检查不通过信息； (48)

} (49)

} (50)

由于RM和被测逻辑是在相同的激励下，所以只要RM中的某个分支执行到了，则被测逻辑的相应功能也就必然测试到了。例如，如果RM的第(3)行执行了，说明被测逻辑的激励也有小于64Byte的数据包；同样，如果第(9)行、第(11)行执行到了，说明被测逻辑曾经收到ARP包和TCP包。

三、插入“探针”后的RM的形式

为了反映RM中每条路径在测试时是否执行以及执行的次数，需要在RM中所关心的路径上插入“探针”，插入“探针”之后的RM形式如下(尖括号中的数字是为测试功能覆盖率新增加的内容的行号)：

proc Root{Paket}{ (01)

获取当前的调用栈存入变量CallPath； <01>

if{包长小于64Byte}{ (02)

TestPoint″$CallPath-＞TP01：包长小于64byte″； <02>

丢弃处理； (03)

}elseif{包长大于1500Byte}{ (04)

TestPoint″$CallPath-＞TP02：包长大于1500byte″； <03>

丢弃处理； (05)

}elseif{Crc错误}{ (06)

TestPoint″$CallPath-＞TP03：CRC错误″； <04>

丢弃处理； (07)

}elseif{激励数据是Arp包}{ (08)

调用Arp包处理proc ArpProc进行处理； (09)

}elseif{激励数据是Tcp包}{ (10)

调用Arp包处理proc TcpProc进行处理； (11)

}else{ (12)

TestPoint″$CallPath-＞TP04：本逻辑不支持的包类型，丢弃″； <05>

丢弃处理； (13)

} (14)

} (15)

proc ArpProc{Paket}{ (16)

获取当前的调用栈存入变量CallPath； <06>

调用DMAC检查proc DMAC_CHECK获得DMAC检查结果； (17)

if{DMAC检查结果没有通过}{ (18)

TestPoint″$CallPath-＞TP01：DMAC检查结果没有通过″； <07>

丢弃处理； (19)

}else{ (20)

TestPoint″$CallPath-＞TP02：正常包″； <08>

向CPU转发； (21)

} (22)

} (23)

proc TcpProc{Paket}{ (24)

获取当前的调用栈存入变量CallPath； <09>

调用DMAC检查proc DMAC_CHECK获得DMAC检查结果； (25)

调用DIP检查proc DIP_CHECK获得DIP检查结果； (26)

if{DMAC检查结果没有通过}{ (27)

TestPoint″$CallPath-＞TP01：DMAC检查结果没有通过″； <10>

丢弃处理； (28)

}elseif{DIP检查结果没有通过}{ (29)

TestPoint″$CallPath-＞TP02：DIP检查结果没有通过″； <11>

丢弃处理； (30)

}else{ (31)

TestPoint″$CallPath-＞TP03：正常包″； <12>

向CPU转发； (32)

} (33)

} (34)

proc DMAC_CHECK{Paket}{ (35)

获取当前的调用栈存入变量CallPath； <13>

if{DMAC等于本设备MAC地址}{ (36)

TestPoint″$CallPath-＞TP01：DMAC等于本地MAC，DMAC检查通过″； <14>

返回DMAC检查通过信息； (37)

}elseif{DMAC等于广播地址}{ (38)

TestPoint″$CallPath-＞TP02：DMAC等于广播地址，DMAC检查通过″； <15>

返回DMAC检查通过信息； (39)

}else{ (40)

TestPoint″$CallPath-＞TP03：DMAC检查不通过″； <16>

返回DMAC检查不通过信息 (41)

} (42)

} (43)

proc DIP_CHECK{Paket}{ (44)

获取当前的调用栈存入变量CallPath； <17>

if{DIP等于本设备IP地址}{ (45)

TestPoint″$CallPath-＞TP01：DIP检查通过″； <18>

返回DIP检查通过信息； (46)

}else{ (47)

TestPoint″$CallPath-＞TP02：DIP检查不通过″； <19>

返回DIP检查不通过信息； (48)

} (49)

} (50)

在RM中的每一个需要插入探针的proc中，都要获取当前的调用路径并赋给变量CallPath，例如第<1>行因为是参考模型的“根”proc，执行后CallPath获取的调用路径为ROOT。对于第<6>行，因为ArpProc在执行中一定是被ROOT调用的，所以执行后CallPath的结果为ROOT-＞ArpProc。而对于第<13>行，由于DMAC_CHECK这个proc可能被ArpProc或TcpProc调用，所以根据执行时具体的调用的情况，可能的返回结果为：ROOT-＞ArpProc-＞DMAC_CHECK或ROOT-＞TcpProc-＞DMAC_CHECK。将获取到的调用路径赋给“探针”中的变量CallPath。调用栈的获取可以通过TCL的info level命令来获取。

每个“探针”的格式为：TestPoint″$CallPath-＞探针编号：探测信息描述″；例如第<2>行，就是一个“探针”。其中，TestPoint为一个用于测试点统计的proc名，该proc统计当前的分支执行的次数。其中的$CallPath用刚才获得的具体路径替代。第一次执行<2>行时在统计表中添加一条统计信息：

“1 ROOT-＞TP01：包长小于64byte”，

最前面的1是该分支执行次数的计数器，第二次执行到该“探针”时，将计数加1，统计表中的信息变为：

“2 ROOT-＞TP01：包长小于64byte”。

同样，第一次执行<14>行时，根据当时的调用路径，在统计表中添加一条统计信息：

“1 ROOT-＞ArpProc-＞DMAC CHECK-＞TP01：DMAC等于本地MAC，DMAC检查通过”或

“1 ROOT->TcpProc-＞DMAC CHECK-＞TP01：DMAC等于广播地址，DMAC检查通过”；

表示该探针探测到该路径被执行了一次。每次执行“探针”时，在统计表中添加新记录(第一次执行)或将计数器加1(统计表中已经存在的分支)。

四、“探针”、“探测点”、“探测点统计表”、“探测点树”的概念

其中，“探针”如上所述是指在测试中为统计RM的各分支执行情况而在RM中添加的一条语句，这条语句的格式为：TestPoint″$CallPath-＞探针编号：探测信息描述″；“探测点”的概念为：“具体的探测路径-＞探针编号：探测信息描述″。也就是说，把探针信息中的调用路径变量具体化之后，这个探针信息就是一个一个“探测点”。一个“探针”对应一个或多个“探测点”。

例如，第<2>行这个“探针”对应的“探测点”为：“ROOT-＞TP01：包长小于64byte”；而第<15>行的探针根据DMAC CHECK是由ArpProc调用还是由TcpProc调用的不同情况，可能对应以下两个“探测点”之一：

“ROOT-＞ArpProc-＞DMAC CHECK-＞TP01：DMAC等于本地MAC，DMAC检查通过”或

“ROOT-＞TcpProc-＞DMAC CHECK-＞TP01：DMAC等于广播地址，DMAC检查通过”。

具体在测试过程中执行的是“探针”，统计的是“探测点”。“探测点统计表”统计了被执行了的探测点以及其执行次数。如果我们关心的所有探测点都执行到了，那么激励数据就是充分的。RM中所有的proc构成“探测点树”的各个分支，所有的“探测点”构成了“探测点树”的所有“叶子”。RM中所有的proc和“探测点”共同构成了一个完整的“探测点树”。

实际测试过程中执行了哪些“探测点”可以通过“探测点统计表”统计出来，而“探测点树”可以通过软件自动计算出来。这样，我们就可以比较“探测点统计表”和“探测点树”，如果所有的叶子都执行了，说明我们所关心的所有路径都被测试了，也就说明激励是充分的；相反如果“探测点树”中的某些“叶子”没有被执行，这时我们就要分析以下原因，看看该“探测点”不被执行是否合理，如果有些“叶子”确实无法执行到，那么测试也是充分的；如果本应执行到的“叶子”没有被执行，则说明存在漏测。

五、“探测点树”的生成。

下面介绍“探测点树”的计算方法——“两遍扫描法”。

第一遍扫描，产生“proc表”和每个proc的探针表。

从RM的第一行开始，逐行读出RM的每一行，结合TCL语法，利用正则表达式匹配的办法我们就可以得出该RM中定义了那些proc，以及每个proc拥有的探针。

在本例中扫描完一遍后，我们就得到了该RM中所定义的proc的一个列表——“proc表”，和每个proc所拥有的探针列表——“探针表”。例如在前面的例子中，

“proc表”有以下5条记录：

ROOT

ArpProc

TcpProc

DMAC_CHECK

DIP_CHECK

“探针表”有以下14条记录：

ROOT-＞TP01：包长小于64byte

ROOT-＞TP02：包长大于1500byte

ROOT-＞TP03：CRC错误

ROOT-＞TP04：本逻辑不支持的包类型，丢弃

ArpProc-＞TP01：DMAC检查结果没有通过

ArpProc-＞TP02：正常包

TcpProc-＞TP01：DMAC检查结果没有通过

TcpProc-＞TP02：DIP检查结果没有通过

TcpProc-＞TP03：正常包

DMAC_CHECK-＞TP01：DMAC等于本地MAC，DMAC检查通过

DMAC_CHECK-＞TP02：DMAC等于广播地址，DMAC检查通过

DMAC_CHECK-＞TP03：DMAC检查不通过

DIP_CHECK-＞TP01：DIP检查通过

DIP_CHECK-＞TP02：DIP检查不通过

第二遍扫描，产生proc调用关系表。

由于第一遍扫描RM时已经产生了proc表，第二遍扫描RM时如果发现RM中某一行中有proc表中的某个proc，并且满足TCL的调用的语法，则就是一个proc调用。用正则表达式很容易获取proc调用关系。

第二编扫描后获得的proc调用关系列表，其内容如下：

ROOT-＞ArpProc

ROOT-＞TcpProc

ArpProc-＞DMAC_CHECK

TcpProc-＞DMAC_CHECK

TcpProc-＞DIP_CHECK

然后根据proc列表和proc调用关系列表就可以很容易计算出proc调用关系树：计算出的proc调用关系树描述如下：

ROOT

ROOT-＞ArpProc

ROOT-＞ArpProc-＞DMAC_CHECK

ROOT-＞TcpProc

ROOT-＞TcpProc-＞DMAC_CHECK

ROOT-＞TcpProc-＞DIP_CHECK

其具体形式可如图3所示，其中，每个圆圈表示一个“proc表”记录，而每条路径表示一种调用关系。

然后根据proc调用关系树和探针表就可以生成“探测点树”，生成的方法为，给proc调用树上的每一个proc都添加上该proc的“探针”，生成的“探测点树”内容如下：

ROOT

ROOT-＞TP01：包长小于64byte

ROOT-＞TP02：包长大于1500byte

ROOT-＞TP03：CRC错误

ROOT-＞TP04：本逻辑不支持的包类型，丢弃

ROOT-＞ArpProc

ROOT-＞ArpProc-＞TP01：DMAC检查结果没有通过

ROOT-＞ArpProc-＞TP02：正常包

ROOT-＞ArpProc-＞DMAC_CHECK

ROOT-＞ArpProc-＞DMAC_CHECK-＞TP01：DMAC等于本地MAC，DMAC检查通过

ROOT-＞ArpProc-＞DMAC_CHECK-＞TP02：DMAC等于广播地址，DMAC检查通过

ROOT-＞ArpProc-＞DMAC_CHECK-＞TP03：DMAC检查不通过

ROOT-＞TcpProc

ROOT-＞TcpProc-＞TP01：DMAC检查结果没有通过

ROOT-＞TcpProc-＞TP02：DIP检查结果没有通过

ROOT-＞TcpProc-＞TP03：正常包

ROOT-＞TcpProc-＞DMAC_CHECK

ROOT-＞TcpProc-＞DMAC_CHECK-＞TP01：DMAC等于本地MAC，DMAC检查通过

ROOT-＞TcpProc-＞DMAC_CHECK-＞TP02：DMAC等于广播地址，DMAC检查通过

ROOT-＞TcpProc-＞DMAC_CHECK-＞TP03：DMAC检查不通过

ROOT-＞TcpProc-＞DIP_CHECK

ROOT-＞TcpProc-＞DIP_CHECK-＞TP01：DIP检查通过

ROOT-＞TcpProc-＞DIP_CHECK-＞TP02：DIP检查不通过

这其实就是探测点树的文本形式描述。其树形结构请参照图4所示，其中每一个小横线就表示该proc的一个“探针”。

六、测试的过程。

具体测试的过程如下：

(1)根据需求规格，在RM中相应路径上插入“探针”。

(2)测试执行。每个测试用例执行过程中所命中的“探测点”都会自动计入“当前测试用例的探测点统计表”，执行完毕后将“当前测试用例的探测点统计表”统计到的信息(执行了的“探测点”以及执行的次数)打印到当前测试用例的执行日志文件中。

(3)生成总的“探测点统计表”。在所有测试用例执行完毕后，用软件去统计每个测试用例的探测点覆盖信息。统计方法是依次打开每个测试用例的执行日志文件，从中读出探测点统计信息，然后进行汇总即可。汇总后生成总的“探测点统计表”。在汇总的过程中打印出每个测试用例所新增加的“探测点”和重复测到的“探测点”。如果某个测试用例新增加的“探测点”和重复测到的“探测点”都为0，则说明该测试用例的激励中没有我们所期望的激励数据，是一个无效的测试用例；如果某个测试用例新增加的“探测点”为0而重复测到的“探测点”不为0，则说明该测试用例所测到的“测试点”以前都测试过了，该测试用例属于重复测试用例；一个测试用例只有它新增加的“探测点”不为0才是有价值的。利用该信息可以剔除一些意义不大的测试用例。

(4)生成“探测点树”。扫描RM文本，生成“探测点树”，该“树”是“探测点”的全集。

(5)对比该“探测点树”与总的“探测点统计表”，计算覆盖率，打印相应信息。将“探测点树”中的各个“探测点”的执行情况打印出来。如果某个“探测点”执行次数为0，则给出警告信息供测试人员分析是否存在漏测。

七、“探针”还可以用作测试信息的统计

在探针的描述信息中插入变量还可用以统计调试信息。例如在描述信息中插入包长变量就可以统计出所收到的各种长度的数据包的数量。因为包长不同导致探测点的描述信息不同，而在统计过程中只有调用路径、探针编号、描述信息完全相同，才被认为是同一个探测点。在探测点的描述信息中插入各种变量，就可以统计出在测试中实际出现的各个变量取值的组合情况。

例如，如果在根proc中插入探针：

TestPoint″$CallPath-＞TP05：PktLen＝$PktLen″；

则当实际收到的包长是100时，在统计表中添加：

″1 ROOT-＞TP05：PktLen＝100″；

当又收到包长为200时，在统计表中添加：

″1 ROOT-＞TP05：PktLen＝200″；

当再次收到包长为100时，在统计表将第一条的计数器加1：

″2 ROOT-＞TP05：PktLen＝100″。

利用这种方法可以很方便的统计出收到的各种包长的数量。

同样，在探针中插入多个变量时，可以统计出在测试过程中出现的这多个变量的各种组合情况。

在上述实施例中，是以采用TC1语言编写的参考模型来对本发明进行说明，其不是为了限定本发明，在本发明的其他实施例中，也可以在Verilong、VHDL、VB、C/C++等语言编写的参考模型中用类似的方法来实现。其实现方法依具体实现语言的语法而略有不同，主要是调用栈的获取方法不同，诸如TCL语言可以使用“info level”指令来获取调用栈，而其他语言可参考其用户手册，该点对本领域的普通技术人员来说是易于理解的。

本发明所采用的逻辑测试的功能覆盖分析方法，具有如下优点：

操作简单：与用EXCEL表格定义激励数据相比，在RM中所关心的路径上插入“探针”操作更加容易和方便。其他的工作诸如“探测点”的统计、“探测点树”的生成及未覆盖点的查找打印都是可以通过软件来完成。

获得的信息更加可靠：分支覆盖信息从RM中获取，要比从激励数据中获取更可靠。如果采用定义激励数据的方法，测试人员不易发现由于激励模块的错误而导致的问题。

测试点的增删、变更更加灵活。

Claims

1、一种逻辑测试的功能覆盖率分析方法，其特征在于，包括如下步骤：

(a)在参考模型中相应的功能分支上插入“探针”；

(b)在测试用例的测试过程中执行到“探针”时，调用统计函数把当前功能分支的探测点信息记录到统计表中；

(c)该测试用例执行完毕后，把统计表的信息打印到该测试用例的日志文件中；

(d)在所有测试用例测试完毕后，依次打开每个测试用例的日志文件，汇总所有测试用例覆盖的功能分支的探测点统计信息，生成“已测功能分支”的集合；

(e)扫描参考模型代码，生成探测点树；

(f)比较“已测功能分支”的集合及该探测点树，获取功能覆盖率信息。

2、如权利要求1所述的逻辑测试的功能覆盖率分析方法，其特征在于，每一个“探针”中包含有一个表示该功能分支的路径的变量和执行次数的计数器。

3、如权利要求2所述的逻辑测试的功能覆盖率分析方法，其特征在于，所述统计表记录了当前测试用例的激励数据所覆盖的功能分支信息。

4、如权利要求1所述的逻辑测试的功能覆盖率分析方法，其特征在于，所述探针包含有当前函数的调用路径变量，一个探针可以通过具体化调用路径而对应多个探测点。

5、如权利要求1到4任一项所述的逻辑测试的功能覆盖率分析方法，其特征在于，在步骤(b)中进一步包括：在参考模型中的每一个需要插入探针的proc中，获取当前的调用路径并赋给变量的步骤。

6、如权利要求2所述的逻辑测试的功能覆盖率分析方法，其特征在于，在步骤(b)中进一步包括：

判断统计表中是否含有当前探测点的记录信息；

如果在统计表中没有当前功能分支的探测点信息，则在统计表中增加一条记录，并将计数器置为1；

如果统计表中已有当前功能分支的探测点信息，则将该探测点信息中的计数器加1。

7、如权利要求1、2、3、4、6任一项所述的逻辑测试的功能覆盖率分析方法，其特征在于，所述步骤(e)进一步包括：

(e1)、对参考模型进行第一遍扫描，得到该参考模型中所定义的proc，生成一个Proc表，以及生成每一proc对应的探针表；

(e2)对参考模型进行第二遍扫描，产生proc调用关系表，并生成proc调用关系树；

(e3)给proc调用关系树上的每一个proc都添加上该proc的“探针”，生成探测点树。

8、如权利要求1所述的逻辑测试的功能覆盖率分析方法，其特征在于，进一步包括在探针的描述信息中插入一个或多个变量来统计调试信息的步骤。